菜单
Use when writing governance constraints for HARNESS.md, translating governance language into operational meaning, reviewing existing governance constraints for falsifiability, or when "/governance-constrain" needs guidance on the authoring workflow.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | governance-constraint-design |
| description | Use when writing governance constraints for HARNESS.md, translating governance language into operational meaning, reviewing existing governance constraints for falsifiability, or when "/governance-constrain" needs guidance on the authoring workflow. |
A governance constraint encodes operational meaning, not governance language. The phrase "ensure human oversight" is governance language — it sounds precise but means different things to different people. A governance constraint translates that language into a verification slot with defined pass/fail criteria, evidence requirements, and failure actions.
This skill teaches how to make that translation. It is referenced by
the /governance-constrain command for guided authoring and by the
harness-enforcer agent when validating governance constraint quality.
Governance language carries meaning in one reference frame but is implemented in another. The regulator writes "meaningful human oversight." The engineer implements a boolean approval gate. The compliance team audits the approval log. All three frames are satisfied syntactically while governance fails semantically — the approval happens, but the oversight is absent.
A governance constraint must make this translation explicit.
Every governance constraint must answer three questions:
If the constraint cannot answer all three, it is governance language pretending to be a constraint. It belongs in a policy document, not in HARNESS.md.
Before writing a governance constraint, articulate what the governance requirement means from three perspectives:
| Frame | Question | Example ("human review required") |
|---|---|---|
| Engineering | What must the reviewer technically verify? | Reviewer must check that generated code has tests, follows naming conventions, and handles error paths |
| Compliance | What audit trail must exist? | PR approval record with reviewer name, timestamp, and at least one substantive comment |
| AI system | What does the automated gate check? | PR cannot merge without at least one approved review from a CODEOWNERS member |
Flag divergence. If the three frames describe different things, the governance requirement is ambiguous. Resolve the ambiguity before writing the constraint — do not push it into HARNESS.md and hope enforcement resolves it.
Every governance constraint in HARNESS.md should use this extended
format (in addition to the standard Rule/Enforcement/Tool/Scope
fields from the constraint-design skill):
See references/governance-constraint-template.md for the full
template with examples.
Governance constraints follow the same promotion ladder as all
constraints (see the constraint-design skill):
harness-enforcer reviews against the constraint
prose using LLM judgementStart at unverified. Promote when the constraint language is stable and you have confidence in the verification method. Most governance constraints will land at agent enforcement because governance meaning requires judgement — few governance checks can be reduced to a shell command.
constraint-design
skill directlygovernance-audit-practice skillgovernance-observability
skillSee references/anti-patterns.md for the full gallery of governance
constraint anti-patterns with falsifiable rewrites.
This skill should be used when the user asks to "assess AI literacy", "run an assessment", "check literacy level", "evaluate our AI collaboration", "where are we on the framework", or wants to determine their team's AI literacy level using the ALCI instrument.
This skill should be used when an agent is deciding whether to author a dynamic workflow — a self-authored, ephemeral multi-agent harness — for a task. Use when the user asks about "dynamic workflows", "multi-agent harness", "fan-out", "subagents in parallel", "adversarial verification", "the ultracode trigger", "should I use a workflow", or when a task looks long-running, massively parallel, highly structured, or adversarial. Names the six composable patterns, the election rubric for when NOT to spend the extra compute, and the two governance invariants (INV-1 ephemeral-proposes, INV-2 quarantine).
This skill should be used when the user asks about "verification slots", "integrating a linter", "adding a deterministic tool", "harness-enforcer", "constraint enforcement interface", "wrapping a tool", or needs the technical reference for how deterministic and agent-based checks work in the harness framework.
Use when setting up automatic PR constraint enforcement via GitHub Actions — covers the advisory-vs-blocking split, workflow installation, configuration options, and reading the output
Use when the user wants to estimate or predict the cost, token usage, or time of a task BEFORE it runs — "how much will this feature cost to build", "estimate the tokens for this spec", "what will this slice cost", "predict the agent-compute time before I commit" — produces a token + time estimate as a range with disclosed confidence, adding a dollar figure only when an observability/costs snapshot grounds it. The prospective sibling of cost-tracking, which records actual spend after the fact.
Use when the user wants to capture AI tool costs, review spending trends, set cost budgets, or integrate cost data into health snapshots — guides quarterly cost capture, records data in a structured format, and updates MODEL_ROUTING.md with observed cost patterns