Use after scope-need and relevant specialist skills approve work. Takes the scoped-need document and produces a flat, ordered list of discrete changes required. Each change is scoped to be a single commit.
Installation
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.
Use after scope-need and relevant specialist skills approve work. Takes the scoped-need document and produces a flat, ordered list of discrete changes required. Each change is scoped to be a single commit.
Enumerate changes
A scoped need describes what is being delivered. An enumerated change list describes what must move in the repo. This skill is the transformation.
host's change lists vary: a narrow bug fix might be two to three commits; a new verifier addition might be four to six; a provisioning-flow refinement with managed-update recovery might be eight to twelve; a soul-registry on-chain contract addition with Safe-ready governance coordination is larger. The single-commit rule holds regardless.
Input required
An approved scoped-need document from scope-need. Specialist-skill findings (from maintain-governance-rubric, provision-managed-instance, evolve-soul-registry, audit-trust-and-safety, coordinate-framework-feedback, review-advisor-brief) if applicable. Load prior context with memory_recent.
The walk
Walk the scoped need against every surface of host:
A change that touches none of these isn't really a change.
The ordering rules
Test-first for bug fixes. Regression test first (fails against current code), then fix. Especially important for multi-tenant-isolation, trust-API-auth, on-chain-adjacent, provisioning, managed-update bugs.
Governance-rubric additions land together. A new verifier + its evidence policy + its documentation land in one commit where practical.
Solidity contract changes land separately. Each contract change is its own commit with Slither / hardhat / solhint run results cited in the commit body.
On-chain deploy steps land in isolated commits. Sepolia deploy → mainnet Safe-ready payload → mainnet execution; each as separate events, each committed with its evidence.
Consumer-release-verification changes (scripts / certification / readiness) land in isolated commits given their supply-chain sensitivity.
CDK changes land separately from Go code. CDK affects every deploy; isolation matters for bisect and rollback.
web/ changes land separately. The SPA has its own build and CSP story.
SSM parameter / Secrets Manager access changes land with the Go code that uses them.
gov-infra/pack.json changes are governance events in their own commits with documentation explaining the rubric shift.
Dependency bumps land in isolated commits for bisect clarity.
Framework-consumption changes — idiomatic consumption of new framework version lands with the bump; framework awkwardness routes to coordinate-framework-feedback.
Documentation rides with the behavior it describes — provisioning-doc updates ride with provisioning-code changes, attestation-doc with trust-API changes, contract-docs with contract changes.
The mission-scope rule
Every enumerated item must answer: is this host-mission work, or scope growth outside?
Scope growth (refuse): tenant-side content / user / moderation, general identity provider for non-lesser, general payments beyond tipping + host billing, cross-tenant queries, reading tenant content into host's plane, local framework patches.
If any item is scope growth, stop and revisit scope-need.
The governance-rubric rule
Every enumerated item must also answer: does this touch the gov-infra rubric (verifiers, evidence policy, pack.json)?
No — default.
Yes — additive (new verifier, new evidence requirement) — proceed with maintain-governance-rubric findings referenced.
Yes — modifying or loosening — refuse unless explicitly authorized with governance-change process documented; maintain-governance-rubric walk is mandatory.
The multi-tenant-isolation rule
Every enumerated item must also answer: does this touch the multi-tenant boundary?
No — default (preserves tenant isolation).
Yes — change traverses tenant boundary — refuse unless explicitly authorized with documented reasoning and elevated review.
The on-chain rule
Every enumerated item must also answer: does this touch Solidity contracts, on-chain-reaching Go code, or Safe-ready governance payloads?
No — default.
Yes — Solidity — Slither + solhint + hardhat test evidence referenced; Sepolia deploy precedes mainnet; Safe-ready for non-trivial mutations.
Yes — on-chain Go code only — idempotency, dry-run mode, explicit confirmation patterns preserved.
The consumer-release-verification rule
Every enumerated item must also answer: does this touch the release-verification pipeline (scripts, certification, readiness checks)?
No — default.
Yes — elevated scrutiny because this is a supply-chain frontier; coordinate with provision-managed-instance walk.
The trust-API / CSP / instance-auth rule
Every enumerated item must also answer: does this touch the trust API, instance-auth, attestations, or CSP?
No — default.
Yes — tightening or preserving — proceed with audit-trust-and-safety findings.
Yes — loosening — refuse unless explicitly authorized with documented reasoning and elevated review.
The framework-consumption rule
Every enumerated item must also answer: does this consume AppTheory / TableTheory / FaceTheory idiomatically?
Idiomatic — proceed.
Workaround — stop. Route through coordinate-framework-feedback.
The single-commit rule
Each enumerated item fits in one commit:
One logical intent
go build ./... succeeds
go test ./... passes
go vet ./... passes
gofmt -l . empty
For CDK: cdk synth --context stage=lab succeeds
For web/: lint + build clean; CSP validation passes
For contracts/: hardhat test passes; Slither clean; solhint clean
For gov-infra/: verifiers pass (including this commit's scope); evidence emits
No commit depends on a later item to compile or pass tests / verifiers
