orchestrator: Skill for Claude Code

FR Governance Workflow

Execute feature request governance through its phases: Author, Select, Plan, Implement, Verify & Close, and — on request — Post-closure audit.

Phase 0: Author (when creating a new FR)

An FR is a funded hypothesis, not a specification. Phase 2 step 0 will rebuild every factual claim it makes; write claims so they can be rebuilt selectively rather than distrusted wholesale.

1. Every count carries its method and revision. Write 200 references / 37 files (rust_source.rb scannable_source, at 2b5738ad), not 200 references across 37 files. A number whose derivation is named can be re-derived alone; a bare number taints every other number in the document.

2. Mark what was not verified. single-method, unverified is a valid and useful annotation — it routes the implementer's attention. The corrections record across FR-127–144 shows the expensive errors were not the marked-uncertain claims but the confidently bare ones. A precedent cited as transferable ("do it the way batch X did") must name the premise that makes it transfer; FR-141 B5 found the B4a precedent did not transfer because its premise — imports resolving inside the layer — did not hold.

3. Apply Phase 6's measurement discipline to every number you write. The two rules there (second derivation, pinned revisions) exist because authoring-time numbers failed exactly those ways.

4. An FR that proposes a new concept must spend it. If the FR adds a ResourceKind, a top-level command group, or a new user-facing noun, it carries the concept-budget justification from CONTRIBUTING.md — why this is not a field, a parameter or a subcommand of something that exists. Two costs are invisible at authoring time and permanent afterwards: a new kind mints resource.<snake_kind>.apply/.delete into control_action_audit and recorded audit action names are never renamed, and a concept that overlaps an existing one leaves every later reader unable to choose between them. Where the FR claims a difference from an existing concept, state it behaviourally — what the system does differently — never as intent. FR-166 found the cost of not doing this: EnvStore and SecretStore have byte-identical specs, differ in three real behaviours, and the guide described the difference only as "intended for sensitive values", so the one thing that would have let a reader choose correctly was the one thing not written down.