Menu
Use when user wants to build Gemara Policy artifacts for audit preparation or compliance program setup
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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