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
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
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
