一键导入
audit-pipeline
Use when user wants to build Gemara Policy artifacts for audit preparation or compliance program setup
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when user wants to build Gemara Policy artifacts for audit preparation or compliance program setup
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when user mentions Rego, Conftest, OPA, "generate policy", or "assessment logic" in the context of Gemara catalogs. Generates Rego policies from Gemara Control Catalogs for Kubernetes (Deployments, Pods, DaemonSets, StatefulSets, CronJobs, Jobs, Services, NetworkPolicies, Ingress, RBAC, ConfigMaps, Secrets), CI/CD pipelines (GitHub Actions, GitLab CI, Azure Pipelines), Conftest, or OPA. Accepts mode argument: "single" (default, one requirement at a time) or "batch" (all at once)
Set up complypack for this project — generate complypack.yaml, warm the artifact cache, and optionally configure MCP integration
Use when starting any compliance task — establishes skill ordering and MCP grounding requirements before any other complypack skill runs
Use before generating any Rego policy or assessment logic — generates human-reviewable test cases from assessment requirements before any policy is written
Use when user mentions Rego, Conftest, OPA, AMPEL, "generate policy", or "assessment logic" in the context of Gemara catalogs. Generates policies from Gemara Control Catalogs for Kubernetes (Deployments, Pods, DaemonSets, StatefulSets, CronJobs, Jobs, Services, NetworkPolicies, Ingress, RBAC, ConfigMaps, Secrets), CI/CD pipelines (GitHub Actions, GitLab CI, Azure Pipelines), Conftest, OPA, or AMPEL
| name | audit-pipeline |
| description | Use when user wants to build Gemara Policy artifacts for audit preparation or compliance program setup |
Guide users through building a Gemara Policy (applicability statement) from their system architecture and governance sources. The Gemara Policy is the formal contract between audit and engineering, functionally equivalent to an ISO 27001 Statement of Applicability or a NIST System Security Plan.
CRITICAL: Every stage MUST read control IDs, requirement IDs, and parameter values from MCP resources. DO NOT generate these from memory. The MCP server is the source of truth.
| Stage | Artifact | Purpose |
|---|---|---|
| scoping | .complytime/scoping.yaml | System profile + Control Catalog scoping + gap analysis |
| mapping | .complytime/delta-report.yaml | Parameter delta analysis + harmonization across framework layers |
| adherence | .complytime/child-policy.yaml | Compile the child Policy with adherence plan |
After adherence, invoke /comply:build-assessment to generate assessment logic for use with complyctl.
.complytime/ directory exists and which artifacts are present.complytime/ directory → start at scopingscoping.yaml exists but no delta-report.yaml → offer mappingdelta-report.yaml exists but no child-policy.yaml → offer adherencechild-policy.yaml exists → pipeline complete, offer to re-run any stage or proceed to /comply:build-assessmentscoping.yamldelta-report.yamlRead the stage instructions from this skill's base directory before proceeding:
scoping.mdmapping.mdadherence.md/comply:audit-pipeline status:
[done] scoping — .complytime/scoping.yaml
[done] mapping — .complytime/delta-report.yaml
[next] adherence — not yet run