@oevery/rsp 3.1.0-beta.1 → 3.1.0-beta.3

package/skills/rsp/SKILL.md

@@ -4,225 +4,97 @@ description: Use this skill when initializing RSP, operating an existing .rsp pr
 license: MIT
 metadata:
   author: oevery
-  version: "2026.07.25.2"
+  version: "2026.07.28.1"
 ---
 
 # RSP Skill
 
-Load this skill when you need to initialize RSP, operate `.rsp/`, audit or repair RSP state, or make a durable-update decision before archive.
+Use RSP to derive one current action from project authority and durable work artifacts. This Skill is the preferred operational guide; `.rsp/rsp-rules.md` is the runtime fallback when the Skill is unavailable.
 
-This skill is the preferred operational guide. `.rsp/rsp-rules.md` is the only runtime fallback protocol when this skill is unavailable; old projects migrate to it with `rsp update`.
+Nearest project instructions and relevant `CONTEXT.md` remain authoritative. Choose response and artifact languages independently: localize human-facing response prose, but preserve canonical RSP headings, WorkRefs, paths, commands, identifiers, and machine values. Write persistent artifacts in domain, system, user, or operator language; mention AI or agents only when they are actual product actors or constraints.
 
-Prefer exact file paths, exact commands, and exact durable facts over vague summaries.
+## Scope
 
-Choose response language and artifact language independently. Render human-facing response headings, field labels, explanations, and conclusions in the language explicitly requested for the response; otherwise follow response-specific project instructions, then the conversation language. Write artifact prose in the language explicitly requested for that artifact; otherwise follow artifact-specific project instructions, then the existing artifact's language, then the conversation language. Preserve canonical RSP artifact headings, keywords, identifiers, paths, commands, and machine-consumed values unchanged. Response-only Continuation and Durable Decision headings and labels are not canonical artifact headings and must be localized.
-
-Write persistent artifacts in domain, system, user, or operator language. Mention AI or agents only when they are actual product actors, consumers, interface participants, or constraints; using AI to perform the work is not itself a durable fact.
-
-## When to use
-
-- Use for RSP setup, repair, focused RSP work, and pre-archive durable decisions.
-- Use when a user explicitly asks to adopt, inspect, or operate the RSP workflow.
-
-## When not to use
-
-- Do not load for general coding tasks unrelated to `.rsp/`.
-- Do not load when the repository does not use RSP and the user did not ask to adopt it.
-- Do not create an RSP change for a simple current-session task unless the user explicitly wants RSP tracking.
-- Do not treat this skill or the fallback protocol as a replacement for nearest project `AGENTS.md` instructions or relevant module `CONTEXT.md`.
+Use this Skill for RSP setup or repair, focused `.rsp/` work, and the durable-update decision before archive. Do not use it for unrelated coding or create a Change for a simple session task unless the user explicitly requests tracking.
 
 ## Derive one next action
 
-Before operating the workflow, derive the current stage from user intent, nearest project authority, `rsp status --json`, the selected Change's readiness, fresh verification evidence, and blockers. Stages are derived guidance, never persisted state.
-
-### Route implementation evidence
-
-When work has reached implementation, classify the decisive evidence before selecting a capability:
-
-- **Diagnosis:** an observed failure is reproducible or materially evidenced, but its cause or owning layer remains unexplained. Conflicting, intermittent, or multi-layer symptoms also take this branch. Select `rsp-diagnose` only when it is available; otherwise use the manual diagnosis fallback: reproduce, locate, test the smallest discriminating hypothesis, and return the evidenced cause without speculative production edits.
-- **TDD:** there is no unexplained failure, the required or corrected behavior is clear, and test-first work is explicitly required by the user, selected Change, or project instructions, or a concrete changed risk makes an observed pre-mutation RED materially safer. Concrete risks include public APIs or protocols, persisted data, security or money, concurrency or cancellation, complex state transitions, and defects that escaped to production. Select `rsp-tdd` only when it is available; otherwise use the manual TDD fallback: observe the focused RED, make the minimum GREEN change, optionally REFACTOR while green, then rerun required checks. Behavior being testable, a test being possible, or the work being a fix is not sufficient by itself.
-- **Ordinary implementation:** this is the default when diagnosis does not apply and no TDD gate above is met. Continue with ordinary `rsp-implement` when the required behavior, cause, or edit is sufficiently evidenced, or use the single manual implementation/verification action when that Skill is unavailable.
-
-Diagnosis takes precedence over TDD: do not encode an unexplained symptom as a guessed regression test. Fresh verification is required, but a new test is only one evidence option; prefer the cheapest decisive existing test, static check, build, or acceptance evidence that covers the changed risk. Each branch returns its evidence, Tasks, Verify updates, and unresolved Blockers to the same selected Change. Capability availability changes execution assistance, not the owner or required outcome.
-
-### Route release documentation
-
-Use the release-documentation branch only when the selected Change explicitly owns a confirmed release identity or range and still has unfinished changelog, release-note, or migration work. Lifecycle stage, completed implementation, or archive readiness alone is insufficient; ordinary Changes continue to the Core durable decision.
-
-Treat release identity as an owner decision. It is confirmed only by an explicit user instruction or authoritative repository release configuration; never infer it from version ordering, a previous prerelease, commit contents, or planned prose. Until confirmation, keep any release ledger version-neutral and leave version manifests, target changelog headings, exact-version README commands, versioned release notes, and tag comparisons unchanged.
-
-When both conditions hold, select `rsp-release-docs` when available. Otherwise use the manual release-documentation fallback against the same Change: confirm the release range and audience, build one net-release evidence ledger, and project it into the repository-owned changelog, release notes, and applicable migration guidance. This route prepares or audits documentation only; it does not grant commit, tag, push, release creation, publication, deployment, or approval authority.
-
-An explicit request to create a release tag, hosted release, registry publication, or equivalent public release has an additional mandatory finalization gate. Before any external action, require either one selected Change or one explicitly named archived release Change to own the confirmed release identity and range, then select the `rsp-release-docs` **Finalize for publication** branch even if the prose was already reviewed. When project authority requires archive before final Git delivery, finish the durable decision and lifecycle closeout first, commit that closeout, and rerun the exact finalization checks against the post-archive candidate ref; only that immutable candidate may receive `ready`. The gate inspects the public tag/package release surfaces, rejects transient publication-state prose in shipped artifacts, and returns a credential-free `ready` or `not ready` handoff. If the Skill is unavailable, perform the same checks with the manual fallback. Neither result executes or grants authority for the external action.
-
-After an observed publication, use the `rsp-release-docs` **Reconcile published release** branch only when the selected or explicitly named archived release owner has unfinished external verification or mutable public-surface corrections. Keep immutable discrepancies historical and assign a corrective version or owner instead of moving tags or rewriting packages.
-
-Apply these gates in order:
+Read user intent, nearest authority, `rsp status --json`, the selected Change and its readiness, fresh verification evidence, and blockers. Stages are derived guidance, never persisted state.
 
-1. If authority, selection, or a material owner decision is ambiguous, return the one decision or evidence needed to proceed. If a declared blocker prevents the next operation, return its owning artifact or person; do not route around it.
-2. If the user explicitly requests managed continuation, select `rsp-manage` only when it is available. Its eligibility gate activates only for one focused ready Change with genuinely independent slices, long authorized continuation, or interruption recovery; an ineligible request returns the exact ordinary Core or Discipline next action without mutation or controller artifacts. Managed routing is never implicit and grants no lifecycle, Git, publication, deployment, approval, or human-acceptance authority.
-3. If the user requests a report-only review against a fixed scope, select `rsp-review` only when it is available; otherwise name the manual read-only review and return its findings to the selected Change's Tasks, Verify, or Blockers.
-4. If the user explicitly requests a tag, hosted release, registry publication, or published-release reconciliation, resolve exactly one selected or explicitly named archived release owner with the confirmed identity and range, then run the `rsp-release-docs` finalization or reconciliation branch and return its credential-free result. This gate precedes ordinary no-focus and implementation routing so a post-archive release owner is not replaced by an unrelated ready Change. Missing owner evidence returns the exact required release owner; the gate never executes or grants the external action.
-5. If no Change is selected, use the status plan to name one ready WorkRef and the direct focus action. For tiny settled work, return the direct engineering action without creating RSP state. For unclear non-trivial work, select `rsp-shape` only when it is available and the user authorized its Change mutation; otherwise give the manual fallback of creating or refining one Change.
-6. If the user or Shape has isolated one material domain, module/seam, or evidence-seeking design question for the selected Change, select `rsp-design` when available; otherwise return the compact manual design fallback: inspect project authority and the live path, compare credible alternatives, separate evidence from owner choice, and return the result to the same WorkRef without implementation or durable-truth mutation.
-7. If the selected Change is not shape-ready and no bounded design question has been isolated, select `rsp-shape` under the same authority rule or give the manual fallback of completing its Proposal, Spec, Design, Tasks, Verify, and Blockers.
-8. If a shape-ready Change has incomplete implementation tasks, or its required verification is missing, stale, or failed, apply the implementation-evidence routing above. Select only its resulting available capability when authorized; otherwise name its manual fallback owned by that Change.
-9. If implementation Tasks and required verification pass with no blocker, and the selected Change meets both ordinary release-documentation conditions above, select `rsp-release-docs` under the same availability rule or use its manual fallback. Return its evidence and surface dispositions to the same Change.
-10. Otherwise, when required Tasks and verification pass with no blocker, perform the Core durable decision. Archive only after required current facts and rationale are written or explicitly judged unnecessary. Recommend explicit archive as the next action before final Git delivery; Core does not execute archive or grant authority to stage, commit, push, or publish. Keep each completed Change independently reviewable. If later Git authority is granted, deliver that Change as its own logical commit before a separately owned Release Change finalizes versioned shipped surfaces in a dedicated release commit.
+Apply these routes in order:
 
-State the derived stage, one next action, required input, returned owner, and decisive evidence. Name at most one available optional capability. Only name an optional capability when it is the one next action, and treat it as available only when it appears in the host's loaded skill inventory. Missing optional capabilities never invalidate RSP; always provide the manual fallback against the same owner.
+Before later-turn mutation under a direct report, tiny, or small route, rederive routing from the now-authorized objective and prospective work. If it materially expands into cross-module implementation, multiple acceptance surfaces, repeated production-path correction, real-host validation, or lifecycle delivery, establish or reuse the smallest sufficient WorkRef, then apply managed preflight and fresh qualification before mutation. Follow-ups that remain tiny/small stay direct. Elapsed time and message count are never escalation evidence.
 
-Do not preload, enumerate, or recursively invoke optional capabilities. Do not infer implementation, review, Git, publication, or approval authority from routing, readiness, or capability availability.
+1. Stop for ambiguous authority or selection and return the one required input and its owner. For a material owner decision inside an explicit managed request, continue to the Shape preflight in route 2 so repository inspection precedes the single owner question; otherwise stop here.
+2. For a requested completion or continuation that is not a report-only review or release operation, read [managed routing](references/managed-routing.md) when the request is explicitly managed or the effective status policy has `manage.activation: auto`. It owns owner preflight, qualification, successor discovery, bounded review convergence, and lifecycle/Git separation. Select `rsp-manage` only after that preflight for an eligible selected ready Change or shallow Group; otherwise return the ordinary Core or Discipline action. Automatic activation grants controller selection only; planning, product mutation, lifecycle, Git, and external authority remain separately derived.
+3. Route an explicit report-only review with fixed scope to `rsp-review` when available, otherwise perform the same read-only review manually.
+4. Route an explicit release-documentation, finalization, publication, or reconciliation operation through [Release operations](#release-operations) before ordinary Change routing.
+5. Route one explicit isolated material domain, module/seam, or evidence-seeking design question to installed `rsp-design`; never manually emulate it. Without a selected Change, use report-only Pre-Change Design only for an already bounded question; return its result without inventing a WorkRef or artifact. With a selected Change, return to that WorkRef. Only when unavailable, its manual fallback inspects authority and the live path, compares credible alternatives, and separates evidence from owner choice without implementation or durable-truth mutation.
+6. With no selected Change, name one ready WorkRef and direct focus action. For tiny settled work, return the direct engineering action. When outcome, scope, non-goals, acceptance, or decomposition is materially unclear, use `rsp-shape` when available and Change mutation is authorized; otherwise manually create or refine one Change to the same ready boundary.
+7. If the Change is not shape-ready, route to Shape under the same authority rule.
+8. For incomplete implementation or stale, missing, or failed verification, use [Implementation evidence](#implementation-evidence).
+9. When Tasks and required verification pass without blockers, perform the durable decision. Do not infer a release operation from Change completion.
 
-## Workflows
+State the derived stage, one next action, required input, returned owner, and decisive evidence. Name at most one optional capability, only when it is the next action and appears in the host's loaded Skill inventory. Missing capabilities never invalidate RSP: give the manual fallback against the same owner. When Core or qualified Manage has derived one authorized RSP-owned local commit boundary, route exact staging, structured message construction, local commit execution, and post-commit observation to `rsp-commit`; if unavailable, use the bounded manual action in durable review against the same owner. Do not preload, enumerate, or recursively invoke optional capabilities.
 
-### Setup or repair
+### Implementation evidence
 
-1. Initialize with `npx -y @oevery/rsp init [--agents-mode managed|print] [--with-project-setup]`.
-2. `--with-project-setup` creates and focuses `changes/project-setup.md`; otherwise create it with `npx -y @oevery/rsp create project-setup` only when explicit bootstrap tracking is still needed.
-3. Fill the bootstrap change if it exists, write durable architecture facts to `.rsp/specs/design.md`, and keep stable scoped operating instructions in the nearest project-owned `AGENTS.md`.
-4. For diagnostics, run `npx -y @oevery/rsp doctor`.
-5. For safe deterministic repairs, run `npx -y @oevery/rsp doctor --fix` or `npx -y @oevery/rsp update`.
-6. When auditing manually, verify `.rsp/`, managed roots, and nested Spec parents are real directories; the project `AGENTS.md`, managed markers, fallback/config files, indexes, and placeholders are regular files; `AGENTS.md` has the managed block; `specs/design.md` and the configured Decision Record directory exist; every group has one valid brief with matching direct children; work and archive trees are flat or one group level; and `focus.d/` markers match executable Changes.
-7. Treat `doctor --fix` `fixed` entries as actual filesystem changes. An empty `fixed` array or `No safe fixes needed.` means the repair pass changed nothing.
-8. Do not use repair commands for semantic decisions such as stale focus removal, durable updates, or archive readiness.
+- **Diagnosis first:** diagnosis takes precedence over TDD for an evidenced but unexplained, conflicting, intermittent, or multi-layer failure. Use `rsp-diagnose` when available; its manual fallback reproduces, locates, and tests the smallest discriminating hypothesis. Do not encode an unexplained symptom as a guessed regression test.
+- **TDD when justified:** use `rsp-tdd` only when test-first is explicitly required by the user, Change, or project instructions, or when a concrete changed risk makes a pre-mutation RED materially safer. Public contracts, persisted data, security or money, concurrency, complex transitions, and escaped defects qualify; mere testability or being a fix does not. Its manual fallback observes the focused RED, makes the minimum GREEN change, and refactors only while green.
+- **Ordinary implementation by default:** use `rsp-implement`, or the equivalent bounded edit and verification, once the behavior, cause, and owner are sufficiently evidenced.
 
-### Focused work
+All branches return evidence, Tasks, Verify updates, and blockers to the same Change. Fresh verification is required, but a new test is only one option; use the cheapest decisive check that covers the changed risk.
 
-1. Follow the managed `AGENTS.md` read order: nearest instructions, relevant context, this skill or fallback protocol, focus, optional sibling Group Brief, selected Change, then relevant Specs and Decision Records.
-2. Treat only `focus.d/` markers as current RSP work; do not treat unfocused files in `changes/` as current work unless the user explicitly asks or you run `npx -y @oevery/rsp focus <name>`.
-3. Resolve executable Change names as either `<change>` or one direct `<group>/<change>` child. Require a real `changes/` root and real existing `focus.d/`, `archives/`, and group prefixes; reject symlinks, incomplete inspection, deeper paths, and file/directory identity collisions.
-4. Use a Change Group only for at least two independently executable Changes sharing one goal or completion contract. Create it with `npx -y @oevery/rsp group create <group> [goal]`, then replace the brief placeholders and declare every direct child identity and boundary under `Slices` before creating children.
-5. Treat logical `<group>/brief`, physically stored as `<group>/00-brief.md`, as non-executable and non-focusable. For grouped work, read it before the selected child Change. Its `Slices` declaration order guides navigation; a Brief blocker is inherited as an external blocker by every direct child without creating edges. Archive children independently, then close only the brief with `npx -y @oevery/rsp group close <group>` when all group gates pass.
-6. Declare an exact prerequisite only as `- requires \`<change-work-ref>\`: <reason>` under the dependent Change's `Blockers`. Targets must be executable Changes, not Group Briefs. Keep external blockers as ordinary prose and never infer an edge from them.
-7. Use `npx -y @oevery/rsp status --json` as the derived dependency view. Read `plan.nodes`, `plan.ready`, `plan.edges`, `plan.blocked`, and `plan.waves`; nodes distinguish selected Changes from prerequisite context, and each edge reads as “`change` requires `requires`” with `reason` and `state`. Filtered plans retain the transitive prerequisite closure needed to explain the selection. Human status renders the same flat graph as a dependency forest; do not infer nested JSON ownership from that presentation. Do not create or maintain a separate graph or copy live delivery state into a Group Brief. Archived prerequisites resolve without rewriting the dependent Change, while incomplete archive inspection produces no ready plan.
-8. Read the focused change before editing code.
-9. If a focused change is missing an explicit `kind`, repair the frontmatter before continuing.
-10. Run `npx -y @oevery/rsp check --focused` before treating focused work as ready; resolve dependency errors, placeholders, or clarification warnings when they represent real unfinished content.
-11. Treat `rsp check` warnings as deterministic hygiene signals, not as the durable-update decision.
-12. Use `npx -y @oevery/rsp create <name> --lite` only when the user explicitly wants RSP tracking for a small, straightforward change.
-13. Convert actionable `## Tasks` checkboxes into your agent-local task tracker when one is available.
-14. Keep implementation sequential by default; parallelize only independent read-only discovery or mechanical checks.
-15. Update `## Tasks`, `## Verify`, and any invalidated `## Proposal`, `## Spec`, or `## Design` content in the same working session as implementation facts change.
-16. Keep the selected Change as a convergent snapshot of the current plan and final decisive evidence. Replace stale or superseded content; keep routine attempts, RED/GREEN loops, command transcripts, and correction chronology in the response, then compress any material history to final outcomes, coverage, omissions, and unresolved risks before archive.
-17. Keep temporary debugging notes, task history, and command transcripts out of `specs/` and project-owned `AGENTS.md` instructions.
+### Release operations
 
-### Route artifacts by owner
+Route here only when the user explicitly requests release documentation, finalization, publication, or reconciliation and the operation has a confirmed identity or range with unfinished release-surface work. A selected Change is not required, and lifecycle stage or archive readiness alone is insufficient.
 
-Use one semantic routing matrix throughout shaping, execution, and pre-archive review:
+Release identity is an owner decision confirmed only by explicit user instruction or authoritative repository release configuration. Never infer it from version order, a previous prerelease, commits, or planned prose. Until confirmation, keep ledgers version-neutral and leave manifests, target changelog headings, exact-version commands, versioned notes, and tag comparisons unchanged.
 
-| Content | Owner | Boundary |
-| --- | --- | --- |
-| Planned future design | selected Change `## Design` | Never write planned state as current truth. |
-| Implemented stable current facts | smallest relevant Spec, usually `.rsp/specs/design.md` or an existing domain Spec | Write only observed stable facts under authority. |
-| Lasting rationale and tradeoffs | one exact file under `durableReview.decisionRecordsPath` | Judge independently from current facts; do not duplicate them. |
-| Stable scoped navigation or current context | project-owned `CONTEXT.md`, when that convention exists | Preserve project ownership and edit only with explicit authority. |
-| Stable operating instructions | nearest project-owned `AGENTS.md` outside the managed RSP block | Preserve project ownership and edit only with explicit authority. |
-| Temporary execution state | response continuation | Not durable truth; write a file only when explicitly authorized. |
+Select `rsp-release-docs` when available or use its manual evidence-led fallback. An explicit tag, hosted release, registry publication, or equivalent public action must pass its **Finalize for publication** branch against a clean exact candidate after implementation Change closeout. Finalize versioned shipped surfaces in a separate release commit when Git delivery is authorized. The credential-free `ready` or `not ready` handoff never executes or grants commit, tag, push, release creation, publication, deployment, or approval authority.
 
-When accepted work remains, return this compact artifact-scoped continuation in the response:
+Use an optional Release Change only for material decisions, cross-stage coordination, recovery, blockers, or acceptance needing a persistent owner—never for a mechanical checklist. After observed publication, use **Reconcile published release** for unfinished verification or authorized mutable-surface corrections; preserve immutable history and assign drift to a corrective version or owner.
 
-```md
-## <localized RSP Continuation heading>
-- <localized WorkRef label>: <selected Change>
-- <localized Authority label>: <project, Change, Spec, decision, or report pointers>
-- <localized Current state label>: <completed, partial, failed, unavailable, or blocked plus decisive state>
-- <localized Changed artifacts label>: <paths or none>
-- <localized Fresh verification label>: <command and result, or pending reason>
-- <localized Blockers label>: <exact blocker and owner, or none>
-- <localized Next action label>: <smallest bounded action and owner>
-```
-
-Treat this continuation shape as semantic field order rather than fixed English wording. Localize its human-facing title and labels to the response language while preserving WorkRefs, paths, commands, identifiers, and machine-consumed values. A localized label may retain a technical token in parentheses but must not use that English token alone; for example, use `工作引用（WorkRef）` in a Chinese response. Do not use the response language to rewrite referenced project artifact prose.
-
-The continuation points to existing owners; it is not a second state store. On resume, reopen every authority pointer, inspect worktree and artifact drift, and refresh any verification supporting the next action. Never create hidden handoff/controller state or persist the continuation without explicit path authority.
-
-### Handle an active Git conflict
-
-When a merge, rebase, or cherry-pick conflict intersects authorized implementation:
-
-1. Inspect the exact Git operation, conflicted paths, current index/worktree, and pre-existing user changes.
-2. Interpret base, ours, and theirs in that operation; trace the relevant behavior and authority instead of choosing a side mechanically.
-3. Resolve only evidenced content inside the WorkRef and mutation authority. Preserve unrelated work and do not stage the resolution unless separately authorized.
-4. Stop when the conflict includes unrelated user work, an unresolved product decision, incomplete side/base evidence, or out-of-scope content. Return the exact conflict and required owner input in the continuation.
-5. After an authorized working-tree resolution, rerun affected checks and return their fresh result.
-
-Do not continue or abort the Git operation, commit, push, or infer Git delivery authority from implementation or conflict-resolution authority. RSP does not need a separate merge-conflict Skill for this fallback.
+## Operate the selected Change
 
-### Pre-archive durable decision
+Before focusing or mutating a different WorkRef, compare dirty product or durable-truth paths with the prior owner's declared or observed paths. Overlap never transfers ownership: continue the same open WorkRef, explicitly reopen archived acceptance when authorized and applicable, use an explicitly authorized integration owner, or stop for boundary resolution. Disjoint authorized work may proceed without staging or forcing a commit; insufficient evidence stops the transition.
 
-1. Run `npx -y @oevery/rsp check --focused` for focused work, or `npx -y @oevery/rsp check` when reviewing all open changes.
-2. Run `npx -y @oevery/rsp show --focused --json` or `npx -y @oevery/rsp ready <name> --json` to collect readiness, warnings, context paths, and `durableReview` guidance.
-3. Treat `durableReview.factCandidateTargets` and `durableReview.decisionRecordsPath` as advisory routing context, not as permission to edit generated indexes or invent a Decision Record filename.
-4. Treat `Spec` delta markers (`### ADDED`, `### MODIFIED`, `### REMOVED`) as planning aids only; do not merge them automatically.
-5. Read only the current Change, relevant Specs and Decision Records, nearest project-owned `AGENTS.md`, and code files needed for the semantic decision.
-6. Produce the durable decision output before archiving.
+Read the focused Change, its sibling Group Brief when grouped, and only the relevant Specs and Decision Records before implementation. Use generated local `.rsp/specs/**/00-index.md` files only as direct-child navigation; never treat them as durable owners. Run `npx -y @oevery/rsp check --focused` before treating it as ready. Only `focus.d/` markers select current work; open filenames do not. Preserve one explicit `kind` and the canonical Proposal, Spec, Design, Tasks, Verify, and Blockers sections.
 
-## Durable decision
+Keep the Change a convergent snapshot of the current plan and final decisive evidence. Replace superseded content; keep routine attempts, RED/GREEN chronology, temporary probes, and command transcripts in the response. Update Tasks, Verify, and any invalidated Proposal, Spec, or Design in the same session.
 
-Choose one current-fact decision and one rationale decision independently.
+Persist only `open` and `archived`; derive readiness, blockers, stage, and next actions. Do not infer implementation, review, Git, publication, or approval authority from focus, readiness, routing, or capability availability.
 
-Current facts:
+When fresh evidence shows that an archived executable Change did not meet its original acceptance, keep the correction under the same WorkRef by explicitly running `rsp reopen <work-ref> --reason <text>`. Reopen retains the selected archive as history, restores and focuses open work, and adds unfinished Task and Verify evidence. If multiple archives share the WorkRef, require exact `--from .rsp/archives/...` selection rather than choosing the newest. Treat the open WorkRef as current dependency state; do not cascade into archived dependents or implicitly reopen a closed Change Group. Use a new corrective Change for genuinely new scope or an independently delivered correction. Reopen is lifecycle mutation only and grants no Git, release, publication, deployment, or approval authority.
 
-- `No current-fact update needed`
-- `Update existing spec or scoped instruction`
-- `Create a new durable spec` only when the knowledge is project-level, reusable, and does not fit `specs/design.md`, an existing spec, or a scoped project instruction
+Load detailed procedures only when their path is active:
 
-Rationale:
+- Read [setup and repair](references/setup-repair.md) before initializing, auditing, migrating, or repairing RSP state.
+- Read [groups and dependencies](references/groups-dependencies.md) before creating, focusing, planning, or closing grouped/dependent work.
+- Read [conflict handling](references/conflict-handling.md) only when an active merge, rebase, or cherry-pick conflict intersects authorized work.
+- Read [durable review](references/durable-review.md) only after required Tasks and verification pass, or when auditing archive readiness.
 
-- `No Decision Record needed`
-- `Create or update a Decision Record`
+## Ownership and safety
 
-Prefer no update on either axis when there is no concrete stable fact or lasting rationale worth rereading.
+Route planned design to the selected Change; stable implemented facts to the smallest relevant Spec or authorized scoped instruction; lasting rationale to one exact Decision Record; stable navigation to project-owned `CONTEXT.md`; stable operating rules to project-owned `AGENTS.md`; and temporary continuation to the response. Never write planned state as current truth or duplicate facts into rationale.
 
-Write a durable update only when one of these is true:
+Use RSP commands for managed setup, focus, repair, indexes, archive, and reopen. Do not directly create command-owned files, edit generated indexes or `.rsp/rsp-rules.md` as durable truth, or modify the managed RSP block. Preserve unrelated work. Core recommends explicit archive only after the durable decision; it does not execute archive or grant staging, commit, push, publication, deletion, deployment, approval, or human-acceptance authority. A configured `manage.closeout` preset remains dormant unless Core selected and qualified Manage for the current continuation; declined, unavailable, or unselected Manage leaves Core advisory even under `lifecycle` or `local`. Core also does not execute reopen without explicit lifecycle authority. The qualified Manage rules in [managed routing](references/managed-routing.md) are the sole scoped exceptions.
 
-- the change altered stable system behavior
-- the change changed a project boundary, default, or constraint
-- future agents or developers would likely make mistakes without the fact
-- the fact is worth rereading in later sessions as durable project knowledge
+When accepted work remains, return a localized continuation with these semantic fields in order: `WorkRef`, `Authority`, `Current state`, `Changed artifacts`, `Fresh verification`, `Blockers`, `Next action`. Preserve technical values. The continuation points to existing owners, is not a second state store, and must not be persisted without explicit path authority. On resume, reopen its pointers, inspect drift, and refresh decisive evidence.
 
-Create or update a Decision Record only when the choice is hard to reverse, would be surprising without context, and reflects a real tradeoff. Decision Records own rationale, alternatives, tradeoffs, and consequences; Specs own what is currently true.
+## Durable decision output
 
-Apply the artifact-routing matrix and choose the smallest correct target:
-
-- project-wide design, boundaries, defaults, and durable context -> `.rsp/specs/design.md`
-- stable project or module operating instructions -> nearest project-owned `AGENTS.md`, only with authority to edit its non-managed content
-- stable navigation or scoped current context -> project-owned `CONTEXT.md`, only when the project uses it and authority permits the edit
-- an additional reusable project-level spec -> `.rsp/specs/<name>.md`
-- lasting rationale -> one exact Markdown file under `durableReview.decisionRecordsPath`
-
-Do not choose generated indexes, `.rsp/rsp-rules.md`, or the managed RSP block in `AGENTS.md` as ordinary durable writeback targets.
-
-Prefer `.rsp/specs/design.md` or an existing durable file before creating a new spec file.
-
-Write stable facts or lasting rationale, not narrative history, task-by-task notes, temporary debugging history, or archive-only detail. Do not duplicate current facts into a Decision Record or rationale into a Spec. If you cannot identify concrete durable content, do not invent it.
-
-## Output template
-
-Use these semantic fields in this exact order. Localize the heading and human-facing labels to the response language; preserve the decision values shown in angle brackets as canonical values.
+After loading [durable review](references/durable-review.md), choose current facts and rationale independently. Localize headings and labels, but preserve the canonical values below:
 
 ```md
 ## <localized Durable Decision heading>
 - <localized Current facts label>: <No current-fact update needed | Update existing spec or scoped instruction | Create a new durable spec>
 - <localized Current-fact target label>: <exact file path or N/A>
-- <localized Facts to write label>:
-  - <durable fact or none>
+- <localized Facts to write label>: <durable facts or none>
 - <localized Decision Record label>: <No Decision Record needed | Create or update a Decision Record>
 - <localized Decision Record target label>: <exact file path or N/A>
-- <localized Rationale to write label>:
-  - <lasting rationale or none>
+- <localized Rationale to write label>: <lasting rationale or none>
 - <localized Archive ready label>: <yes | no>
 ```
 
-These are response labels, not canonical RSP artifact headings. A localized label may retain its technical field identity in parentheses; for example, a Chinese response may use `## 持久化决策`, `决策记录（Decision Record）`, and `可归档（Archive ready）`, but not their English labels alone.
-
-Rules for the output:
-
-- Each target must be an exact file path when its decision requires an update; `durableReview.decisionRecordsPath` is a directory, not the final target.
-- `Facts to write` must contain durable facts, not task history or debugging notes.
-- `Rationale to write` must contain lasting rationale, alternatives, tradeoffs, or consequences, not a duplicate of current facts.
-- If real blockers remain or a required fact or rationale update is not yet written, `Archive ready` must be `no`.
-- If neither axis has a missing update and remaining verify risk is consciously accepted, `Archive ready` may be `yes`.
-- Do not use CLI warning text as a substitute for semantic durable-update judgment.
-- CLI `archiveReady: judgment` means the skill or a human must decide; it is not automatic approval.
+Response-only Continuation and Durable Decision labels are not canonical artifact headings. In Chinese, for example, use `## 持久化决策`, `决策记录（Decision Record）`, and `可归档（Archive ready）`, not English labels alone. A required unwritten update or real blocker makes archive readiness `no`; CLI `archiveReady: judgment` is advisory, not approval.

package/skills/rsp/references/conflict-handling.md

@@ -0,0 +1,11 @@
+# Conflict handling
+
+Load this reference only when an active merge, rebase, or cherry-pick conflict intersects authorized implementation.
+
+1. Inspect the exact Git operation, conflicted paths, index/worktree, and pre-existing user edits.
+2. Interpret base, ours, and theirs in that operation; resolve behavior from authority and evidence rather than choosing a side mechanically.
+3. Modify only evidenced content inside the WorkRef and mutation authority. Preserve unrelated work and do not stage without separate authority.
+4. Stop for unrelated user work, an unresolved product decision, incomplete side/base evidence, or out-of-scope content. Return the exact conflict and owner input.
+5. After an authorized working-tree resolution, rerun affected checks.
+
+Conflict-resolution authority does not authorize continuing or aborting the Git operation, staging, committing, or pushing.

package/skills/rsp/references/durable-review.md

@@ -0,0 +1,17 @@
+# Durable review
+
+Load this reference only after required Tasks and verification pass, or when auditing archive readiness.
+
+Run `rsp check --focused` and `rsp show --focused --json`, or `rsp ready <name> --json` for an explicit Change. Treat `durableReview.factCandidateTargets` and `decisionRecordsPath` as routing advice, not permission. Spec delta markers are planning aids and are never promoted automatically.
+
+Choose current facts and rationale independently. Use no update when there is no stable fact or lasting rationale worth rereading.
+
+Write a current-fact update only when implementation changed a stable behavior, boundary, default, or constraint that future maintainers need. Prefer the smallest existing domain Spec, `.rsp/specs/design.md` for project-wide boundaries/navigation, or an explicitly authorized scoped `CONTEXT.md`/`AGENTS.md`; create a new Spec only for reusable project-level truth that fits nowhere existing.
+
+Create or update a Decision Record only for a hard-to-reverse or surprising choice with a real tradeoff. It owns rationale, alternatives, tradeoffs, and consequences—not duplicated current facts. Choose one exact file under `durableReview.decisionRecordsPath`, not the directory itself.
+
+Never use generated indexes, archives, `.rsp/rsp-rules.md`, or the managed RSP block as ordinary writeback targets. Keep narrative history, debugging notes, task chronology, and transient evidence out of Specs and Decisions.
+
+Before archive, compress the Change to current design, completed outcomes, decisive evidence, omissions, remaining risks, and blockers. Archive only after required updates are written or explicitly unnecessary. Ordinary work needs later explicit Git authority for one independently reviewable logical commit. A `manage.closeout` preset applies only when Core selected and qualified Manage for the current continuation; declined, unavailable, or unselected Manage leaves Core advisory and configuration executes neither archive nor commit. In a qualified managed continuation, lifecycle closeout is independent from Git and follows the effective ceiling: `manual` leaves archive advisory, while `lifecycle` or `local` permits `rsp archive <change-work-ref>` after Core durable review unless nearer authority narrows it. For a shallow Group with lifecycle closeout, independently review and archive each child, re-derive completion, and run `rsp group close <group>` only after every child and Group gate passes. Inspect each complete lifecycle diff before deciding Git separately. `manual` and `lifecycle` grant no commit; `local` may justify recovery checkpoints and, after lifecycle closeout, requires one `rsp-commit` invocation for a terminal non-small Change or Group when owner, paths, fresh decisive verification, and a clean exact boundary are known and no nearer denial exists. Terminal small work defaults to no commit; ambiguous, mixed, stale, or denied boundaries stop without staging. A separately authorized release operation may use a dedicated release commit. Push remains separate and requires the user to mention it explicitly.
+
+When commit eligibility and authority exist, give `rsp-commit` one envelope containing the Change, Group/wave, or confirmed release owner, exact allowed paths, decisive evidence, lifecycle state, and current authority. If that Skill is unavailable, perform the same bounded manual action: reread nearest authority and owner; inspect staged, unstaged, and untracked paths, the cached diff, and recent non-merge messages; stop without staging on ambiguity or stale evidence; stage only allowed paths; re-inspect the complete cached boundary; derive a repository-consistent Conventional subject plus a proportionate body and truthful RSP trailers; create one local commit; then observe its complete message, paths, remaining worktree, and remote safety without amending or performing any external action.

package/skills/rsp/references/groups-dependencies.md

@@ -0,0 +1,11 @@
+# Groups and dependencies
+
+Load this reference before creating, focusing, planning, or closing grouped or dependent work.
+
+- Executable WorkRefs are `<change>` or one direct `<group>/<change>` child. Deeper paths are unsupported.
+- Use a Change Group only for at least two independently executable Changes sharing a goal or completion contract. Create it with `npx -y @oevery/rsp group create <group> [goal]`, replace placeholders, and declare each direct child under `Slices` before creating it.
+- `<group>/brief`, stored as `<group>/00-brief.md`, is not executable or focusable. Read it before a selected child. Its declaration order guides navigation and its blockers are inherited as external blockers, not graph edges.
+- Declare an exact prerequisite only as `- requires \`<change-work-ref>\`: <reason>` under the dependent Change's `Blockers`. Targets must be executable Changes.
+- Use `rsp status --json` as the derived dependency view. `plan.nodes`, `ready`, `edges`, `blocked`, and `waves` are authoritative for the current inspection. Each edge means “change requires prerequisite”; filtered plans retain transitive prerequisite context.
+- Do not infer nested ownership from the human dependency forest, create a parallel graph, or copy live delivery state into a Group Brief. Archived prerequisites resolve without rewriting dependents; incomplete inspection fails closed.
+- Archive children independently. Close the brief with `rsp group close <group>` only after every direct child and group completion gate passes.

package/skills/rsp/references/managed-routing.md

@@ -0,0 +1,51 @@
+# Managed routing
+
+Load this reference only for a requested completion or continuation that is not a report-only review or release operation and is either explicitly managed or has effective `manage.activation: auto` in status. Missing configuration preserves `explicit` activation with `local` closeout compatibility. Invalid configuration fails closed as `explicit` plus `manual` and must remain visible.
+
+## PREFLIGHT — resolve the owner
+
+Treat the requested goal and independently allowed planning and product mutations as a transient authority envelope. Automatic activation grants controller selection only and never adds planning or product-mutation authority. Resolve the smallest sufficient owner before testing Manage eligibility.
+
+Before focusing, dispatching, or mutating a different WorkRef, inspect dirty paths and the diff against the prior owner's declared and observed product or durable-truth paths. Overlap never changes owner implicitly: continue the same open WorkRef, explicitly reopen its archived acceptance when authorized and applicable, use an explicitly authorized integration owner, or stop for boundary resolution. Disjoint authorized work may proceed without staging or a forced commit; insufficient ownership evidence stops the transition.
+
+- Reuse one unambiguous selected ready owner.
+- Return tiny settled work to direct engineering without a synthetic Change or controller artifact.
+- For clear non-trivial work with no sufficient ready owner, an explicit managed request authorizes only in-scope RSP planning artifacts unless the user requests no edits. Under automatic activation, route to Shape only when the current request or nearer authority independently permits those artifacts; configuration alone never does. Then re-read status/readiness and re-evaluate without another authorization round.
+- If repository evidence leaves a material product, acceptance, public-interface, scope, mutation-authority, external-action, or human choice, Shape returns the single highest-impact owner decision and creates no implementation or controller artifact.
+
+A prior direct report, tiny, or small route is not sticky. Before later-turn mutation, rederive from the now-authorized objective and prospective work. Material expansion into cross-module implementation, multiple acceptance surfaces, repeated production-path correction, real-host validation, or lifecycle delivery requires Core to establish or reuse the smallest sufficient WorkRef and rerun this preflight plus fresh Manage qualification before mutation. Unchanged tiny/small follow-ups remain direct; elapsed time and message count alone never trigger escalation.
+
+PREFLIGHT is complete only when one selected ready Change or shallow Group owns the requested outcome and no material decision remains.
+
+## QUALIFY — select or decline Manage
+
+Select `rsp-manage` only for one selected ready Change or shallow Group that qualifies through at least one independent path: genuinely independent slices, prospectively long authorized continuation, or interruption recovery. A Change with long/recovery work does not also need independent or parallelizable slices. Derive “long” before dispatch from the authorized objective and its expected phases; elapsed wall-clock minutes are never qualification evidence. Small coupled one-step work and worker-only work remain ineligible and return to ordinary Core or Discipline action. Automatic routing is policy-selected, bounded by the requested goal, and not inferred from readiness alone.
+
+## CONTINUE — rederive from evidence
+
+After accepted managed progress, re-read `rsp status --json` and apply PREFLIGHT again.
+
+- Continue a clear in-scope ready successor.
+- When ownership is clearly missing, Manage suspends dispatch and returns discovery evidence to Core. Shape keeps a cohesive correction in its Change, gives one independently verifiable and archivable result one Change, or gives at least two such results sharing one goal one shallow Group. Core then requalifies without another authorization round.
+- Stop naturally only when neither a ready successor nor clearly missing ownership remains.
+- Stop earlier for a material behavior, acceptance, public-interface, scope, mutation-authority, external-action, or human decision.
+
+Never persist the goal envelope, WorkSet, waves, discovery classification, or transition chronology.
+
+## CONVERGE — bound review correction
+
+After a managed fixed-scope re-review, correlate the report, selected Change, original authority, fresh verification, and transient convergence count. Return an in-scope `accepted` remaining or new Finding as `correction-needed` to another bounded Resolve Findings pass without asking the user to continue. Resolve Findings never self-loops.
+
+Allow at most three Resolve Findings passes per Change and stop earlier when the same Finding remains after two completed corrections. Stop for `needs-clarification`, material behavior/interface/scope or authority change, verification-budget expansion, an additional real-host/provider/network run outside existing authority, failed or unavailable decisive verification, or repeated non-convergence. Never persist the convergence count or correction chronology.
+
+## CLOSE — apply the bounded preset
+
+Enter CLOSE only when Core selected and QUALIFY accepted Manage for the current continuation. If Manage was declined, unavailable, or unselected, every `manage.closeout` preset is dormant: ordinary Core may report readiness and the explicit next lifecycle or Git action, but configuration executes neither archive nor commit. Do not infer the current-continuation gate from readiness, an earlier managed run, or project policy alone; keep the selection and qualification result transient.
+
+After that gate passes, use effective `manage.closeout` as an automatic grant ceiling, narrowed by nearer restrictions and host enforcement. `manual` grants neither automatic archive nor commit. `lifecycle` grants lifecycle closeout after Core durable review but no Git action. `local` adds separately justified recovery checkpoints and the deterministic terminal route below. Explicit current-turn authority may allow a named local action that the preset does not automate; denial still wins.
+
+When lifecycle closeout is granted, archive a Change after Core durable review. A shallow Group independently reviews and archives each child, re-derives completion, then runs `rsp group close <group>` only after every child and the Group gate pass. Inspect the complete lifecycle diff after each mutation, including terminal owners.
+
+Decide Git delivery separately. Under `local` or explicit commit authority, accepted downstream work may justify an exact-path recovery checkpoint unless commits are reserved or denied. Terminal small work defaults to no commit. After lifecycle closeout, a qualified `local` terminal non-small Change or Group with a derived owner, allowed paths, fresh decisive verification, one clean exact boundary, and no nearer denial must be handed exactly once to `rsp-commit`; do not require the user to repeat `commit`. An ambiguous, mixed, stale, or denied boundary stops without staging. Commit owns structured message construction, one local commit, and post-commit observation; when unavailable, return the equivalent bounded Core manual action against the same owner.
+
+Push requires an explicit user mention plus an unambiguous remote, branch, and milestone. Never force-push; preserve local commits on failure. Managed authority never includes publication, deployment, approval, or human acceptance.

package/skills/rsp/references/setup-repair.md

@@ -0,0 +1,11 @@
+# Setup and repair
+
+Load this reference only before initializing, auditing, migrating, or repairing RSP-managed state.
+
+1. Initialize with `npx -y @oevery/rsp init [--agents-mode managed|print] [--with-project-setup]`.
+2. `--with-project-setup` creates and focuses `changes/project-setup.md`. Without it, create that Change only when explicit bootstrap tracking is still needed.
+3. Put project-wide boundaries in `.rsp/specs/design.md`, use generated local `00-index.md` files only for direct-child navigation, put cohesive reusable facts in the smallest domain Spec, and keep stable operating instructions in the nearest project-owned `AGENTS.md` outside its managed block.
+4. Diagnose with `npx -y @oevery/rsp doctor`. Apply only deterministic repairs with `doctor --fix` or `rsp update`; `fixed` entries are real filesystem mutations, while an empty list means nothing changed.
+5. Do not use repair commands to decide stale focus, semantic durable updates, or archive readiness.
+
+For manual audit, require `.rsp/`, managed roots, and nested Spec parents to be real directories. Require the project `AGENTS.md`, managed markers, fallback/config files, generated local `00-index.md` files, and placeholders to be regular files. Confirm the managed block, root and populated-directory Specs indexes, `specs/design.md`, configured Decision Record exclusion, valid group briefs and direct children, supported path depth, and focus markers matching executable Changes. Symlinks, special files, incomplete inspection, unrecognized reserved indexes, and file/directory identity collisions fail closed.

package/skills/rsp-commit/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: rsp-commit
+description: Create one authorized, exact-scope local commit for an RSP-owned Change, Group wave, or confirmed release boundary with a repository-consistent structured message.
+license: MIT
+metadata:
+  author: oevery
+  version: "2026.07.26.1"
+---
+
+# RSP Commit
+
+Create one reviewable local commit after Core or qualified Manage has already derived the owner, allowed paths, decisive verification, lifecycle state, and commit authority. Skill availability grants none of those facts. Accept only one Change, one integration-coupled Group wave, one Group closeout, or one confirmed release commit boundary.
+
+## Audit the envelope
+
+Read nearest project authority, the relevant open Change, Group Brief and children, archive, or confirmed release owner, then inspect `git status`, staged, unstaged, and untracked paths, the cached diff, and recent non-merge commit messages. Recheck the supplied verification and lifecycle facts against current repository state.
+
+Stop without staging when the owner, allowed paths, commit authority, verification, lifecycle state, or logical boundary is missing, ambiguous, stale, or conflicts with unrelated work. Stop when an allowed path contains mixed owned and unrelated changes that cannot be staged without guessing. Never infer archive, Group closeout, commit, push, tag, publication, approval, amend, rebase, force-push, or history-rewrite authority.
+
+## Derive the message
+
+Choose subject language from explicit current instruction, then nearest repository authority, then the clear style of recent non-merge commits. Response language, RSP artifact language, and preferences remembered from another repository do not select it. When recent history is materially mixed and no nearer rule resolves it, return the single language decision to its owner.
+
+Use the repository's established Conventional Commit form when present. Derive type and scope from the owned outcome and repository history, not from the conversation. Keep the subject concise and imperative or otherwise repository-consistent.
+
+A tiny or mechanical boundary may be subject-only when that subject fully explains it. For a non-trivial Change, integration wave, Group closeout, or release commit, add two to four concise bullets covering:
+
+- the observable outcome;
+- material behavior or compatibility boundaries; and
+- an important omission or risk when one affects review.
+
+Do not copy file lists, command transcripts, routine verification output, execution chronology, or the full Change/archive. Add only truthful trailers: one `RSP-WorkRef:` per included WorkRef, `RSP-Group:` when the Group is the commit owner, authoritative external references already owned by the work, and `BREAKING CHANGE:` only for an actual breaking change. Never invent an issue, co-author, sign-off, breaking change, or AI attribution.
+
+## Commit the exact boundary
+
+Stage only the explicit allowed paths. Re-read `git status --short`, inspect the complete cached path list and cached diff, and confirm they represent exactly one owner boundary with no sensitive material. If the cached boundary is wrong, stop and leave unrelated work untouched; do not repair it by broad staging, destructive reset, or history rewrite.
+
+Create one local commit with the prepared subject, optional body, and trailers. Do not push, tag, publish, amend, rebase, or force-push. Afterward observe `HEAD`, the complete committed message, committed paths, remaining worktree state, and remote refs when a remote-safety assertion is required. A commit command succeeding is insufficient if the observed message or paths differ from the prepared boundary.
+
+## Return the receipt
+
+Return the commit SHA, owner and included WorkRefs, committed paths, parsed subject/body/trailers, remaining worktree paths, and explicit omissions. Report a stop before staging, commit failure, or post-commit mismatch truthfully; never silently amend or create a second commit to repair the first.

package/skills/rsp-design/SKILL.md

@@ -1,21 +1,26 @@
 ---
 name: rsp-design
-description: Resolve one material domain-model, module/seam, or evidence-seeking design question for an explicit or unambiguously focused RSP Change without implementing production behavior or writing durable project truth.
+description: Resolve one material domain-model, module/seam, or evidence-seeking design question before a Change or for an explicit or focused RSP Change without implementing production behavior or writing durable project truth.
 license: MIT
 metadata:
   author: oevery
-  version: "2026.07.22.2"
+  version: "2026.07.27.1"
 ---
 
 # RSP Design
 
-Resolve one design question and return the result to its existing RSP owner. Do not implement the result.
+Resolve one design question. Do not implement it.
 
 ## Establish the question and authority
 
-Require an explicit WorkRef or exactly one unambiguous focus marker. Read the nearest project instructions and context, the RSP core Skill or fallback protocol, the selected Change and sibling Group Brief, then the smallest relevant Specs, decisions, code, tests, callers, and runtime evidence.
+State one explicit bounded design question. Read project authority and the smallest relevant Specs, decisions, code, tests, callers, and runtime evidence.
 
-State the single material question before analysis. If the WorkRef, question, required evidence, owner intent, or mutation authority is missing or ambiguous, stop with the smallest blocker. Never invent product intent.
+Choose one ownership mode:
+
+- **Pre-Change Design:** use when no Change is selected and the request already contains one bounded design question. When this Skill is installed, Core selects it instead of manually emulating the discipline; the manual fallback is only for an unavailable Skill. Remain report-only and return to the user. If outcome, scope, non-goals, acceptance, or decomposition remains materially unclear, return the request to Shape instead of creating an implicit planning owner. Do not invent a WorkRef, continuation, or artifact.
+- **Tracked Design:** require an explicit WorkRef or exactly one unambiguous focus marker. Read the selected Change and sibling Group Brief, then return the result to the same WorkRef.
+
+Stop on an ambiguous question, evidence boundary, owner intent, authorized-write owner, or required mutation authority. Never invent product intent.
 
 ## Load one design mode
 
@@ -25,11 +30,11 @@ Load only the reference matching the question:
 - Read [module and seam design](references/module-seams.md) for interface obligations, caller complexity, adapters, test surfaces, or seam placement.
 - Read [reversible exploration](references/reversible-exploration.md) only when a material conclusion depends on unobserved behavior and a cheap safe probe can provide it.
 
-Keep evidence-driven conclusions separate from choices only the owner can make. Compare at least one credible alternative when alternatives exist; do not manufacture options for a conclusion forced by evidence or authority.
+Separate evidence-driven conclusions from owner choices. Compare one credible alternative when alternatives exist; do not manufacture options when evidence or authority forces the conclusion.
 
 ## Preserve artifact ownership
 
-Default to report-only. When the user or project explicitly authorizes updating the selected Change, write settled planned design only under its `Design` section. Do not write Specs, Decision Records, `CONTEXT.md`, `AGENTS.md`, production code, lifecycle state, focus, archives, or Git state. Identify possible durable current facts or rationale only as artifact-routing candidates for the Core durable review.
+Default to report-only. Pre-Change Design never mutates artifacts. In Tracked Design, when the user or project explicitly authorizes updating the selected Change, write settled planned design only under its `Design` section. Do not write Specs, Decision Records, `CONTEXT.md`, `AGENTS.md`, production code, lifecycle state, focus, archives, or Git state. Identify possible durable current facts or rationale only as artifact-routing candidates for the Core durable review.
 
 An exploration additionally requires explicit disposable-code authority and the cleanup contract in its reference. A design request alone grants neither production mutation nor external side-effect authority.
 
@@ -37,7 +42,7 @@ An exploration additionally requires explicit disposable-code authority and the
 
 Follow Core's response-versus-artifact language boundary: use the requested language for natural prose, while any authorized `Design` update follows the selected Change's language and canonical headings. Do not use a technical token alone as a response label; retain it only in parentheses after a localized label. Return these semantic fields:
 
-- selected WorkRef and exact question;
+- ownership mode, selected WorkRef when tracked, and exact question;
 - inspected evidence and material gaps;
 - recommendation and evidence-driven reasoning;
 - credible alternatives and tradeoffs;
@@ -45,4 +50,4 @@ Follow Core's response-versus-artifact language boundary: use the requested lang
 - artifact routing and any authorized Change update;
 - smallest next action.
 
-Return to Shape or the user against the same WorkRef. Do not create parallel state, recursively invoke another Skill, implement, review, archive, stage, commit, push, publish, deploy, or approve.
+Pre-Change results return to the user; name Shape as the smallest next action only when accepted work needs an executable owner. Tracked results return to Shape or the user against the same WorkRef. Do not create parallel state, recursively invoke another Skill, implement, review, archive, stage, commit, push, publish, deploy, or approve.