codex-skill-foundry-governed

name	codex-skill-foundry-governed
description	Use for high-complexity Codex work that needs risk classification, auditability, validation evidence, documentation synchronization, directive tracking, and rollback-aware execution.

Codex Governed

Operating Rule

Use the smallest governed process that can honestly support the final claim.

Default sequence:

1. clarify the task contract when ambiguity could change execution
2. classify risk, side effects, and rollback needs
3. inspect current state before changing it
4. identify coupled files, flows, and contracts
5. make the smallest coherent change
6. validate with evidence matched to risk
7. update documentation and directive trackers when affected
8. report results, checks, blockers, and residual risk

Do not treat governance as paperwork. Add process only when it improves safety, evidence, traceability, or maintainability.

When To Use

Use this tier for:

1. release-sensitive work
2. CI, validation, policy, or governance changes
3. auth, payment, production, secret, or data-sensitive work
4. migrations or rollback-sensitive changes
5. broad multi-file changes
6. formal reviews, audits, ratings, or readiness claims
7. durable user directives that need fulfillment evidence

Move to a lighter tier for tiny local edits, answer-only requests, or simple commands where governance would add noise.

Task Contract

Before substantive work, establish:

1. goal
2. scope
3. non-goals
4. constraints
5. acceptance criteria
6. validation depth
7. rollback or recovery expectations

Ask only questions that materially change execution. Discover safe details from files and environment before asking.

Risk Tiers

Classify work by the highest matching tier:

1. low: answer-only, inspection-only, or tiny reversible text edits
2. standard: normal code, docs, command, or workflow changes with local validation
3. governed: policy, CI, release posture, multi-file contracts, or durable directive changes
4. critical: destructive, production, auth, payment, data-loss, secret, migration, or unclear rollback risk

Critical work requires explicit confirmation before irreversible mutation and a credible rollback or recovery path.

Sequencing

Follow dependency-correct order:

1. clarify only when needed
2. inspect before mutation
3. establish safety rails before risky actions
4. update shared contracts before dependent callers when compatibility is preserved
5. update tests near changed behavior
6. update docs after behavior, workflow, or policy changes
7. validate from cheap checks to expensive checks
8. report residual risk clearly

Parallelize only independent reads or checks. Do not parallelize writes or commands sharing mutable state.

Diagnosis

For bugs, failures, regressions, or reported root causes:

1. capture the observed symptom
2. treat suggested causes as hypotheses
3. inspect or reproduce direct evidence before patching
4. consider at least one plausible alternative when feasible
5. fix the verified cause
6. rerun the reproducer or targeted check

If the cause cannot be verified, limit changes to safe mitigation and say what remains uncertain.

Validation Evidence

Validation must match the risk claim:

1. syntax, formatting, or static checks for file correctness
2. unit tests for logic and branches
3. integration or contract tests for boundaries
4. browser or end-to-end tests for critical user flows
5. smoke checks for startup or runtime behavior
6. policy or schema validators for governed artifacts

Never claim full safety when an important validation layer was blocked. Report the blocker and residual risk.

Documentation And Directives

Update durable artifacts when work changes:

1. setup, run, deploy, or test commands
2. public APIs, configuration, environment variables, or file formats
3. user-visible behavior
4. operational caveats
5. policy or workflow expectations
6. long-lived user directives and their fulfillment status

Directive tracking should be compact, evidence-based, and bounded. Mark work done only when evidence supports it.

Backup And Rollback

Before destructive or hard-to-reverse work:

1. identify the rollback path
2. confirm a backup or recovery route exists when impact is high
3. avoid proceeding when rollback is unknown and the impact is critical
4. document blocked recovery assumptions

Do not impose backup ceremony on low-risk reversible edits.

Reviews And Audits

For review, rate, score, assess, evaluate, benchmark, or compare requests:

1. lead with findings
2. cite file, command, or artifact evidence
3. define a weighted rubric totaling 100 when scoring is requested or useful
4. explain major deductions
5. identify missing validation and residual risk
6. recommend the smallest corrective action

Final Response

When complete:

1. state what changed
2. state what was validated
3. state what was not validated and why
4. state residual risk
5. include file references when useful
6. keep the response concise