[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71RY8NXSYW195GP68CCTBSE":3,"skill-same:01M71RY8NXSYW195GP68CCTBSE":83},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":14,"repositoryHtmlUrl":60,"repositoryHomepageUrl":6,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M71RY8NXSYW195GP68CCTBSE","k8s-audit",null,"Audit a Kubernetes cluster for policy compliance — enumerate every resource in scope and report the EXACT set that violates a stated rule (e.g. missing resource limits\u002Fprobes\u002Flabels, disallowed image repos or tags, RBAC bindings, PodDisruptionBudgets, admission\u002FOPA-Gatekeeper\u002FKyverno constraints). Use whenever the task is \"list\u002Ffind all resources that violate policy X\" or a security-posture \u002F compliance check across many resources, as opposed to diagnosing one unhealthy workload.","blouargant\u002Fomnis","blouargant","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F5691896?v=4","01M71RWETBTYXSMT6FFC4Q7HPW","Bertrand Louargant","01M71RWEV3G47S696JYH8EA7W2",0,"MIT","https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis\u002Fblob\u002Fdevelop\u002Fregistry\u002Fskills\u002Fk8s-audit\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"k8s audit","audit","k8s","across","limits","labels","kyverno","cluster","resources","scope","as","image","list","SET","playbook","opa","rbac","workload","repos","security","2026-11-10 13:02:02",false,"---\nname: k8s-audit\ndescription: Audit a Kubernetes cluster for policy compliance — enumerate every resource in scope and report the EXACT set that violates a stated rule (e.g. missing resource limits\u002Fprobes\u002Flabels, disallowed image repos or tags, RBAC bindings, PodDisruptionBudgets, admission\u002FOPA-Gatekeeper\u002FKyverno constraints). Use whenever the task is \"list\u002Ffind all resources that violate policy X\" or a security-posture \u002F compliance check across many resources, as opposed to diagnosing one unhealthy workload.\nmetadata:\n  author: blouargant@chapsvision.com\n  tags: \"kubernetes, audit, compliance, policy, gatekeeper, opa, kyverno, security, playbook\"\n---\n\n# Kubernetes Compliance Audit\n\nThe *playbook* for a POLICY-COMPLIANCE AUDIT: given a rule, check **every**\nresource in scope and report the **exact set** that violates it — no misses, no\nfalse alarms. This is a different discipline from `k8s-triage`:\n\n| | k8s-triage | k8s-audit |\n|---|---|---|\n| Goal | find *why one workload is broken* | find *which resources break a rule* |\n| Scope | one workload, deep | every resource, wide |\n| Success | root cause | a precise VIOLATING set |\n\nAuditing is **read-only** — never mutate the cluster during an audit.\n\nAudits are scored on **precision AND recall**: a flagged compliant resource\n(false positive) and a missed violation (false negative) both count against you.\nReal audit suites deliberately plant **compliant decoys** (to catch\nover-reporting) and **subtle violations off the happy path** (to catch\nunder-reporting). Beating them is a matter of discipline, not cleverness.\n\n## Procedure\n\n### Phase 1 — Pin the rule as a precise predicate\n\n1. **Read the rule literally** and restate it as a testable predicate before\n   touching the cluster. Nail down three things:\n   - **Which kinds** it applies to (Pods? Deployments? Ingresses? RoleBindings?\n     PDBs? all workload controllers?).\n   - **The exact condition** (the field(s) and the failing value).\n   - **The scope of the condition:**\n     - *cluster-wide* vs a *single namespace*;\n     - *pod-level* (one fact per pod) vs *container-level* (evaluated per\n       container);\n     - **conjunction vs disjunction** — \"missing **both** a readiness **and** a\n       liveness probe\" (violates only when BOTH are absent) is NOT \"missing a\n       readiness **or** liveness probe\" (violates when EITHER is absent). Read\n       the \"and\"\u002F\"or\"\u002F\"both\" wording exactly.\n2. **When the wording is genuinely ambiguous**, pick the reading the grader most\n   likely intends — usually the **stricter, smaller-result-set** interpretation\n   — state your interpretation in one line, and do **not** flag borderline\n   resources on a generous stretch of the rule.\n\n### Phase 2 — Enumerate the COMPLETE candidate set\n\n3. **List everything in scope — do not sample.** Get the full set as structured\n   output so nothing is skipped:\n   ```bash\n   kubectl get \u003Ckinds> -n \u003Cns> -o json     # or -A for cluster-wide\n   ```\n   Count the candidates so you know exactly how many you must classify. Every\n   candidate ends the audit as either *violating* (with cited evidence) or\n   *compliant*.\n\n### Phase 3 — Extract fields deterministically, on EVERY path\n\n4. **Use `-o jsonpath` \u002F `-o json | jq` — never eyeball `describe`.** Structured\n   extraction is what stops you missing a field. Example (all container images,\n   all container types, across all pods):\n   ```bash\n   kubectl get pods -n \u003Cns> -o json | jq -r '\n     .items[] | .metadata.name as $n\n     | ( (.spec.containers \u002F\u002F []) + (.spec.initContainers \u002F\u002F [])\n         + (.spec.ephemeralContainers \u002F\u002F []) )[]\n     | \"\\($n)\\t\\(.name)\\t\\(.image)\"'\n   ```\n5. **Inspect EVERY relevant path — the misses hide off the happy path.** A rule\n   about images, limits, probes, or securityContext applies to **all** container\n   types unless the rule explicitly narrows it:\n   - **Pods:** `.spec.containers[]`, **`.spec.initContainers[]`**,\n     **`.spec.ephemeralContainers[]`**.\n   - **Workload controllers** (Deployment \u002F StatefulSet \u002F DaemonSet \u002F Job \u002F\n     ReplicaSet): the pod template —\n     `.spec.template.spec.{containers,initContainers,ephemeralContainers}`.\n   - **CronJob:** `.spec.jobTemplate.spec.template.spec.{containers,initContainers,ephemeralContainers}`.\n   - **Pod-level fields** a rule may target directly:\n     `.spec.automountServiceAccountToken`, `.spec.serviceAccountName`,\n     `.spec.securityContext`, `.metadata.labels`\u002F`.metadata.annotations` — and\n     remember container-level overrides can differ from the pod-level value.\n\n   > The single most common miss is auditing `spec.containers` only and\n   > overlooking an `initContainer`. Enumerate all three container lists, every\n   > time.\n\n### Phase 3b — RBAC extraction recipe (deterministic)\n\nFor an RBAC rule (which ClusterRoles\u002FRoles grant a permission on a resource),\nfollow this mechanically instead of shortlisting roles by name.\n\n#### ClusterRoles \u002F Roles\n\n- NEVER shortlist roles by name (grepping for \"endpoint\", \"controller\", …). Run\n  ONE mechanical filter over the COMPLETE set and flag every match:\n  ```bash\n  kubectl get clusterroles -o json | jq -r '.items[] |\n    select(.rules[]? |\n      ((.resources \u002F\u002F []) | any(. == \"endpoints\" or . == \"*\")) and\n      ((.verbs \u002F\u002F [])     | any(. == \"create\" or . == \"update\" or . == \"patch\"\n                                or . == \"delete\" or . == \"deletecollection\" or . == \"*\"))\n    ) | .metadata.name' | sort -u\n  ```\n  Adapt the resource\u002Fverb lists to the rule under audit. A wildcard `*` in verbs\n  or resources DOES grant the permission — it matches.\n- AGGREGATION: edit\u002Fadmin-style permissions are frequently carried by\n  **aggregation ClusterRoles** (labelled\n  `rbac.authorization.k8s.io\u002Faggregate-to-edit` \u002F `…-admin` \u002F `…-view`), e.g.\n  `system:aggregate-to-edit`. These hold the offending rules in their own\n  `.rules` and MUST be flagged when they match the filter — do not skip a role\n  because its name doesn't mention the audited resource, or because it is a\n  built-in. Evidence = the matching rule, regardless of the role's name.\n\n### Phase 4 — Classify with evidence, resisting decoys\n\n6. **Evidence-first flagging.** Flag a resource **only** when you can quote the\n   concrete field **and value** that fails the predicate (e.g.\n   `resource-003 initContainers[0].image = nginx:latest → repo not in allow-list`).\n   If you cannot point at the offending field, it is **not** a violation — do not\n   flag it. \"On-topic\", \"looks related\", or \"probably\" is not evidence.\n7. **Decoy awareness.** Assume compliant look-alikes are planted. A resource in\n   the same category as the rule is **not** automatically a violation — before\n   flagging, re-read the predicate and confirm the resource actually FAILS it,\n   not merely that it's about the same subject. When unsure, the resource is\n   **compliant** (do not flag on a hunch).\n8. **Per-container vs per-pod resolution.** If the rule is per-container, a\n   resource violates when **any** in-scope container fails it; still cite the\n   specific container. If the rule is per-pod, evaluate the pod as a whole.\n\n### Phase 5 — Report in the grader's exact format\n\n9. **Match the requested output byte-for-byte.** If the task asks for\n   `VIOLATING: \u003Cname>` lines, emit **one line per violating resource, the\n   resource name only**, nothing else on the line — no prose, no compliant\n   resources, no counts mixed in. If no format is specified, list the violating\n   resource names, then a short evidence appendix (one line each: resource →\n   field → value). The grader's format always wins over this skill's default.\n\n## Checking an audit (leader \u002F coordinator)\n\nWhen you delegated the audit, check what comes back before reporting it:\n\n- A flag backed by a **quoted offending field** → **include**.\n- A flag with **no quoted field**, or one that looks like an on-topic decoy →\n  **inspect that one resource yourself** with a targeted read and decide on the\n  field evidence.\n- A flag **no field supports** → **drop it**.\n\n(A second, independent audit pass by another agent was tried on the gatekeeper\nsuite and changed no result at about 2.5× the cost; it is not part of this flow.)\n\n## Hard rules\n\n1. **Read-only.** Never `apply`\u002F`patch`\u002F`delete`\u002F`edit`\u002F`scale`\u002F`exec`-write\n   during an audit. An audit reports; it does not remediate (propose fixes\n   separately if asked).\n2. **Enumerate completely.** Never sample or stop early — every in-scope resource\n   must be classified.\n3. **Every container type, every time** — `containers` + `initContainers` +\n   `ephemeralContainers` (and the pod template for controllers).\n4. **Cite a field for every flag.** No quoted offending field ⇒ not a violation.\n5. **Decoys are compliant.** Do not flag a resource merely for being on-topic.\n6. **Read the rule's scope exactly** — namespace vs cluster, per-pod vs\n   per-container, and \"and\"\u002F\"or\"\u002F\"both\" logic.\n7. **RBAC denial → report the boundary**, do not retry with a different identity.\n8. **RBAC recipe is mandatory** (Phase 3b). For an RBAC rule, filter the complete\n   role set by resource+verb (wildcards match) and flag aggregation ClusterRoles\n   by their own `.rules` — never shortlist by name.\n\n## Output rule\n\nFinish with a single line: `Result: audited-\u003CN-violations> | clean | blocked`\n— unless the task specifies a grader output format, in which case that format is\nthe whole answer.\n","# Kubernetes Compliance Audit\n\nThe *playbook* for a POLICY-COMPLIANCE AUDIT: given a rule, check **every**\nresource in scope and report the **exact set** that violates it — no misses, no\nfalse alarms. This is a different discipline from `k8s-triage`:\n\n| | k8s-triage | k8s-audit |\n|---|---|---|\n| Goal | find *why one workload is broken* | find *which resources break a rule* |\n| Scope | one workload, deep | every resource, wide |\n| Success | root cause | a precise VIOLATING set |\n\nAuditing is **read-only** — never mutate the cluster during an audit.\n\nAudits are scored on **precision AND recall**: a flagged compliant resource\n(false positive) and a missed violation (false negative) both count against you.\nReal audit suites deliberately plant **compliant decoys** (to catch\nover-reporting) and **subtle violations off the happy path** (to catch\nunder-reporting). Beating them is a matter of discipline, not cleverness.\n\n## Procedure\n\n### Phase 1 — Pin the rule as a precise predicate\n\n1. **Read the rule literally** and restate it as a testable predicate before\n   touching the cluster. Nail down three things:\n   - **Which kinds** it applies to (Pods? Deployments? Ingresses? RoleBindings?\n     PDBs? all workload controllers?).\n   - **The exact condition** (the field(s) and the failing value).\n   - **The scope of the condition:**\n     - *cluster-wide* vs a *single namespace*;\n     - *pod-level* (one fact per pod) vs *container-level* (evaluated per\n       container);\n     - **conjunction vs disjunction** — \"missing **both** a readiness **and** a\n       liveness probe\" (violates only when BOTH are absent) is NOT \"missing a\n       readiness **or** liveness probe\" (violates when EITHER is absent). Read\n       the \"and\"\u002F\"or\"\u002F\"both\" wording exactly.\n2. **When the wording is genuinely ambiguous**, pick the reading the grader most\n   likely intends — usually the **stricter, smaller-result-set** interpretation\n   — state your interpretation in one line, and do **not** flag borderline\n   resources on a generous stretch of the rule.\n\n### Phase 2 — Enumerate the COMPLETE candidate set\n\n3. **List everything in scope — do not sample.** Get the full set as structured\n   output so nothing is skipped:\n   ```bash\n   kubectl get \u003Ckinds> -n \u003Cns> -o json     # or -A for cluster-wide\n   ```\n   Count the candidates so you know exactly how many you must classify. Every\n   candidate ends the audit as either *violating* (with cited evidence) or\n   *compliant*.\n\n### Phase 3 — Extract fields deterministically, on EVERY path\n\n4. **Use `-o jsonpath` \u002F `-o json | jq` — never eyeball `describe`.** Structured\n   extraction is what stops you missing a field. Example (all container images,\n   all container types, across all pods):\n   ```bash\n   kubectl get pods -n \u003Cns> -o json | jq -r '\n     .items[] | .metadata.name as $n\n     | ( (.spec.containers \u002F\u002F []) + (.spec.initContainers \u002F\u002F [])\n         + (.spec.ephemeralContainers \u002F\u002F []) )[]\n     | \"\\($n)\\t\\(.name)\\t\\(.image)\"'\n   ```\n5. **Inspect EVERY relevant path — the misses hide off the happy path.** A rule\n   about images, limits, probes, or securityContext applies to **all** container\n   types unless the rule explicitly narrows it:\n   - **Pods:** `.spec.containers[]`, **`.spec.initContainers[]`**,\n     **`.spec.ephemeralContainers[]`**.\n   - **Workload controllers** (Deployment \u002F StatefulSet \u002F DaemonSet \u002F Job \u002F\n     ReplicaSet): the pod template —\n     `.spec.template.spec.{containers,initContainers,ephemeralContainers}`.\n   - **CronJob:** `.spec.jobTemplate.spec.template.spec.{containers,initContainers,ephemeralContainers}`.\n   - **Pod-level fields** a rule may target directly:\n     `.spec.automountServiceAccountToken`, `.spec.serviceAccountName`,\n     `.spec.securityContext`, `.metadata.labels`\u002F`.metadata.annotations` — and\n     remember container-level overrides can differ from the pod-level value.\n\n   > The single most common miss is auditing `spec.containers` only and\n   > overlooking an `initContainer`. Enumerate all three container lists, every\n   > time.\n\n### Phase 3b — RBAC extraction recipe (deterministic)\n\nFor an RBAC rule (which ClusterRoles\u002FRoles grant a permission on a resource),\nfollow this mechanically instead of shortlisting roles by name.\n\n#### ClusterRoles \u002F Roles\n\n- NEVER shortlist roles by name (grepping for \"endpoint\", \"controller\", …). Run\n  ONE mechanical filter over the COMPLETE set and flag every match:\n  ```bash\n  kubectl get clusterroles -o json | jq -r '.items[] |\n    select(.rules[]? |\n      ((.resources \u002F\u002F []) | any(. == \"endpoints\" or . == \"*\")) and\n      ((.verbs \u002F\u002F [])     | any(. == \"create\" or . == \"update\" or . == \"patch\"\n                                or . == \"delete\" or . == \"deletecollection\" or . == \"*\"))\n    ) | .metadata.name' | sort -u\n  ```\n  Adapt the resource\u002Fverb lists to the rule under audit. A wildcard `*` in verbs\n  or resources DOES grant the permission — it matches.\n- AGGREGATION: edit\u002Fadmin-style permissions are frequently carried by\n  **aggregation ClusterRoles** (labelled\n  `rbac.authorization.k8s.io\u002Faggregate-to-edit` \u002F `…-admin` \u002F `…-view`), e.g.\n  `system:aggregate-to-edit`. These hold the offending rules in their own\n  `.rules` and MUST be flagged when they match the filter — do not skip a role\n  because its name doesn't mention the audited resource, or because it is a\n  built-in. Evidence = the matching rule, regardless of the role's name.\n\n### Phase 4 — Classify with evidence, resisting decoys\n\n6. **Evidence-first flagging.** Flag a resource **only** when you can quote the\n   concrete field **and value** that fails the predicate (e.g.\n   `resource-003 initContainers[0].image = nginx:latest → repo not in allow-list`).\n   If you cannot point at the offending field, it is **not** a violation — do not\n   flag it. \"On-topic\", \"looks related\", or \"probably\" is not evidence.\n7. **Decoy awareness.** Assume compliant look-alikes are planted. A resource in\n   the same category as the rule is **not** automatically a violation — before\n   flagging, re-read the predicate and confirm the resource actually FAILS it,\n   not merely that it's about the same subject. When unsure, the resource is\n   **compliant** (do not flag on a hunch).\n8. **Per-container vs per-pod resolution.** If the rule is per-container, a\n   resource violates when **any** in-scope container fails it; still cite the\n   specific container. If the rule is per-pod, evaluate the pod as a whole.\n\n### Phase 5 — Report in the grader's exact format\n\n9. **Match the requested output byte-for-byte.** If the task asks for\n   `VIOLATING: \u003Cname>` lines, emit **one line per violating resource, the\n   resource name only**, nothing else on the line — no prose, no compliant\n   resources, no counts mixed in. If no format is specified, list the violating\n   resource names, then a short evidence appendix (one line each: resource →\n   field → value). The grader's format always wins over this skill's default.\n\n## Checking an audit (leader \u002F coordinator)\n\nWhen you delegated the audit, check what comes back before reporting it:\n\n- A flag backed by a **quoted offending field** → **include**.\n- A flag with **no quoted field**, or one that looks like an on-topic decoy →\n  **inspect that one resource yourself** with a targeted read and decide on the\n  field evidence.\n- A flag **no field supports** → **drop it**.\n\n(A second, independent audit pass by another agent was tried on the gatekeeper\nsuite and changed no result at about 2.5× the cost; it is not part of this flow.)\n\n## Hard rules\n\n1. **Read-only.** Never `apply`\u002F`patch`\u002F`delete`\u002F`edit`\u002F`scale`\u002F`exec`-write\n   during an audit. An audit reports; it does not remediate (propose fixes\n   separately if asked).\n2. **Enumerate completely.** Never sample or stop early — every in-scope resource\n   must be classified.\n3. **Every container type, every time** — `containers` + `initContainers` +\n   `ephemeralContainers` (and the pod template for controllers).\n4. **Cite a field for every flag.** No quoted offending field ⇒ not a violation.\n5. **Decoys are compliant.** Do not flag a resource merely for being on-topic.\n6. **Read the rule's scope exactly** — namespace vs cluster, per-pod vs\n   per-container, and \"and\"\u002F\"or\"\u002F\"both\" logic.\n7. **RBAC denial → report the boundary**, do not retry with a different identity.\n8. **RBAC recipe is mandatory** (Phase 3b). For an RBAC rule, filter the complete\n   role set by resource+verb (wildcards match) and flag aggregation ClusterRoles\n   by their own `.rules` — never shortlist by name.\n\n## Output rule\n\nFinish with a single line: `Result: audited-\u003CN-violations> | clean | blocked`\n— unless the task specifies a grader output format, in which case that format is\nthe whole answer.\n",{"name":5,"metadata":54,"description":7},{"tags":55,"author":56},"kubernetes, audit, compliance, policy, gatekeeper, opa, kyverno, security, playbook","blouargant@chapsvision.com","develop","c9440489468f6bbafc65e9a10811428ac0ef2619","registry\u002Fskills\u002Fk8s-audit","https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis","https:\u002F\u002Fgithub.com\u002Fblouargant","2026-11-10 16:30:07",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add blouargant\u002Fomnis --skill k8s-audit",{"tool":69,"command":70},"bunx","bunx skills add blouargant\u002Fomnis --skill k8s-audit",{"tool":72,"command":73},"pnpm","pnpm dlx skills add blouargant\u002Fomnis --skill k8s-audit","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis\u002Fblob\u002Fdevelop\u002Fregistry\u002Fskills\u002Fk8s-audit\u002FSKILL.md",true,[77],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"permissions.json","REFERENCE","参考文档",1176,"https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis\u002Fblob\u002Fdevelop\u002Fregistry\u002Fskills\u002Fk8s-audit\u002Fpermissions.json",[84,113,132,159,181,209],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":93,"publishedAt":49},"01M71RZKQ64WTDCV48Z4Y071FA","skill-creator","Create or update a skill playbook (SKILL.md) for the agent. Use when the user wants to create a new skill, add a skill, define a new agent capability, update an existing skill, edit a skill, refine a skill playbook, or specialise the agent for a new domain.","https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis\u002Fblob\u002Fdevelop\u002Fregistry\u002Fskills\u002Fskill-creator\u002FSKILL.md",[90],{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[94,95,96,97,98,99,100,101,102,103,104,105,106,43,107,108,109,110,111,112],"skill creator","creator","new agent","domain","for","new","define","use","Existing","when","create","update","refine","edit","a skill","new skill","add","user","existing skill",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":49},"01M71RZJ15NMV6FXBZD1AQF3K7","review","Review a body of work (source code, configuration, documents, infra manifests, …) for correctness, clarity, and obvious risks. Use this skill whenever the user asks for a review, audit or critique.","https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis\u002Fblob\u002Fdevelop\u002Fregistry\u002Fskills\u002Freview\u002FSKILL.md",[],[115,120,121,122,30,98,123,101,124,125,126,127,128,129,130,131,111],"infra","work","critique","clarity","body","source","manifests","documents","configuration","correctness","code","source code",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":141,"publishedAt":49},"01M71RZFP8KJEANYXAH6AX68G0","pdf","Fallback PDF text extractor using pdftotext (poppler). Use ONLY when the preferred `liteparse` skill is unavailable or for a quick plain-text dump of a simple text PDF — for the best PDF parsing (scanned, multi-column, layout-heavy, or non-PDF formats) prefer the `liteparse` skill.","https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis\u002Fblob\u002Fdevelop\u002Fregistry\u002Fskills\u002Fpdf\u002FSKILL.md",[138],{"categoryNo":139,"categoryName":140,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理",[142,143,144,145,146,147,148,149,98,150,151,152,153,154,101,155,103,156,157,158],"PDF","text","multi","quick","simple","parsing","pdf text extractor","layout","liteparse","plain-text","column","only","formats","pdftotext","plain","pdf parsing","file",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":167,"publishedAt":49},"01M71RZDAHNX7JC52P5HH5XPEG","pandoc","This skill should be used when converting documents between formats (Markdown, DOCX, PDF, HTML, LaTeX, etc.) using pandoc. Use for format conversion, document generation, and preparing markdown for Google Docs or other word processors.","https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis\u002Fblob\u002Fdevelop\u002Fregistry\u002Fskills\u002Fpandoc\u002FSKILL.md",[165,166],{"categoryNo":139,"categoryName":140,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},[161,168,142,169,98,170,101,171,127,103,172,173,174,175,176,177,154,178,179,180],"docx","Word","document generation","document","conversion","generation","markdown","format","google","google docs","docs","html","LaTeX",{"skillNo":182,"name":150,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":196,"publishedAt":49},"01M71RZ7PSG17ES4CQWA6860F5","Preferred local parser for extracting text from PDFs, images, and scanned\u002Flayout-heavy documents (OCR, screenshots, complex PDFs) — far better than pdftotext. Use this FIRST for any PDF, image, or OCR text-extraction or conversion task. NOTE for Office documents (DOCX, PPTX, XLSX, ODT) — for plain text extraction prefer the `pandoc` skill, which needs no LibreOffice; only use LiteParse for Office docs when you need its layout\u002FOCR\u002Fscreenshot output. The `pdf` skill (pdftotext) is only a fallback for when LiteParse cannot be installed.","https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis\u002Fblob\u002Fdevelop\u002Fregistry\u002Fskills\u002Fliteparse\u002FSKILL.md",[186,187,190,193],{"categoryNo":139,"categoryName":140,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":188,"categoryName":189,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":191,"categoryName":192,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000004","电子表格",{"categoryNo":194,"categoryName":195,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000034","行政与办公人员",[150,197,198,199,168,200,142,201,202,203,204,205,206,153,155,127,103,40,207,208],"images","app","ocr","which","pptx","extracting","xlsx","managed","local","pipx","you","needs",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":215,"publishedAt":49},"01M71RZ2Y9KY94NRBV4WMH73G5","linux-admin","Safely make a change to a Linux workstation — install\u002Fremove packages, manage systemd services and timers, edit and validate configuration files, manage users\u002Fpermissions and networking. Detect the distro and package manager, determine whether the target is package-managed or hand-maintained, preview or simulate every change, back up configs before editing, and prefer the package manager and drop-in overrides so the host stays consistent and secure. Use whenever a change to the local Linux host is required (install, remove, enable, disable, start, stop, edit a config, add a user, change permissions or networking).","https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis\u002Fblob\u002Fdevelop\u002Fregistry\u002Fskills\u002Flinux-admin\u002FSKILL.md",[],[216,217,218,219,220,221,222,223,224,204,205,225,226,227,228,229,230,231,232,233],"linux","linux admin","admin","back","workstation","package manager","pacman","remove","up","systemd services","files","host","drop","preview","hand","permissions","packages","change"]