@oevery/rsp 2.0.3 → 3.1.0-beta.0

package/skills/rsp-implement/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: rsp-implement
+description: Implement exactly one selected, ready RSP Change within explicit mutation authority. Use when the user asks to implement or fix tracked work and requires code/tests plus truthful Tasks, Blockers, and fresh verification evidence; never infer Git, publication, review, TDD, or diagnosis authority.
+license: MIT
+metadata:
+  author: oevery
+  version: "2026.07.24.1"
+---
+
+# RSP Implement
+
+Implement one selected Change and return facts.
+
+## Select and inspect
+
+Require an explicit WorkRef or one unambiguous focus marker. A Group Brief is context, not executable work. Stop when selection, readiness, product authority, acceptance, or required decisions are unresolved.
+
+Read nearest instructions, Core or fallback, Change and Brief, relevant Specs and decisions, worktree, then the smallest owning code/test chain. Use normal repository discovery; do not guess owners.
+
+## Preserve authority
+
+Identify outcome, owners, verification, and pre-existing work. Modify only Change requirements, Tasks, Verify, and Blockers. Preserve unrelated modified, staged, and untracked work. Stop when overlap would discard, guess, or rewrite pre-existing intent.
+
+Git delivery, publication, deployment, approval, and out-of-scope deletion require separate explicit authority. For conflicts, inspect base/ours/theirs, preserve unrelated work, resolve only evidenced scope, rerun checks, and stop before staging, continuing, aborting, or committing. Verify named findings first.
+
+## Classify implementation evidence
+
+Classify evidence before mutation and after failure:
+
+- An unexplained failure returns `rsp-diagnose` when available; otherwise return Core's manual diagnosis fallback.
+- Return `rsp-tdd` only when test-first work is explicitly required by the user, selected Change, or project instructions, or a concrete changed risk makes pre-mutation RED materially safer; use Core's manual TDD fallback when unavailable. Behavior being testable, a test being possible, or the work being a fix is not sufficient by itself.
+- Continue ordinary implementation by default when diagnosis does not apply, the required behavior, cause, or edit is sufficiently evidenced, and no explicit or concrete-risk TDD gate is met.
+
+Diagnosis precedes TDD. Do not invoke another Skill from inside this Skill. If evidence changes the route, stop mutation and return the next action, evidence, and same selected Change. Do not reproduce either discipline inside Implement or invoke review or delivery.
+
+## Implement and verify
+
+Implement the smallest complete slice. Update Tasks after outcomes exist; keep unresolved issues in Blockers.
+
+After final mutation, run required Change checks and narrower risk checks. 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. Record command, scope, result, and omissions. Prior runs are stale; failed or unavailable verification cannot support completion. Rerun after relevant edits.
+
+Keep a new test only when it protects observable behavior or a real boundary, adds distinct future confidence, avoids duplicate or implementation-detail coverage, and has proportionate maintenance cost. Otherwise remove the disposable test, fixture, and helper before completion, then use smallest sufficient final evidence. User, Change, and project retention requirements remain authoritative.
+
+Record concise fresh evidence when Change Verify owns it. Do not create a receipt store or mandate one shell wrapper.
+
+## Return ownership
+
+Report whether the Change is completed, partial, blocked before implementation, verification-failed, verification-unavailable, or verification-blocked. Use failed for an exercised defect; use unavailable when a missing tool, dependency, service, credential, or environment prevents execution. Use blocked only when scoped checks pass but a required gate fails solely from a confirmed pre-existing or out-of-scope baseline defect; never waive affected gates.
+
+When work remains, follow Core's response-versus-artifact language boundary and return `WorkRef`, `Authority`, `Current state`, `Changed artifacts`, `Fresh verification`, `Blockers`, and `Next action`. They are not durable truth; persistence requires explicit path authority.
+
+Claim completion only when required Tasks and checks pass and no blocker remains. Do not claim review, archive, Git delivery, or release unless separately performed with explicit authority.

package/skills/rsp-manage/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: rsp-manage
+description: Continue one explicitly requested focused RSP Change through genuinely independent bounded slices or interruption recovery while keeping ordinary work on existing Core and Discipline paths.
+license: MIT
+metadata:
+  author: oevery
+  version: "2026.07.24.1"
+---
+
+# RSP Manage
+
+Manage one focused Change only after the user explicitly requests managed continuation. Keep RSP artifacts as durable truth and process data transient.
+
+## Qualify before mutation
+
+Require one focused, ready Change and sufficient mutation authority. Snapshot the user authority, nearest instructions and context, Group Brief when present, Change, relevant Specs and Decisions, current RSP status, and worktree once.
+
+Activate only for at least two non-overlapping mutation scopes with independent verification, genuinely long authorized continuation, or interruption recovery whose stale-evidence cost justifies orchestration. A small single slice, tightly coupled scopes, or host worker availability alone is ineligible. On decline, make no mutation, create no dispatch envelope, receipt, budget, or controller state, and return the exact Core or Discipline next action without executing it.
+
+Identify allowed mutations, required verification, unavailable acceptance, and lifecycle, Git, publication, deployment, approval, or other external-action boundaries. Preserve unrelated work. Unless the user sets a tighter limit, allow at most four worker dispatches and one corrective retry for the whole run.
+
+## Dispatch only real work
+
+Send an internal compact envelope only to a worker that will execute an eligible slice:
+
+```md
+- WorkRef: <focused Change>
+- Objective: <one observable slice>
+- Authority: <exact inputs and allowed mutations>
+- Return: <changed artifacts, decisive verification, omissions, and stop boundary>
+```
+
+Parallelize only non-overlapping mutation scopes with independent verification. Keep overlapping mutations and dependent verification sequential. Workers receive no implied focus, lifecycle, durable-write, Git, publication, deployment, approval, or cleanup authority.
+
+For each slice choose the cheapest decisive focused check. Run at most one broader integration gate, and only when combined mutations create integration risk or project authority requires it. Do not multiply checks per worker or retain disposable process tests.
+
+## Continue from current evidence
+
+After each return inspect the actual diff and freshly observed verification. Accept a slice only when the owned output exists, decisive checks pass, omissions are named, and the Change still owns the result. Continue only after positive progress.
+
+Use the one corrective retry only when new evidence identifies an in-scope correction. Otherwise stop at the failure. Inspect current worktree and evidence after returns, but reread stable authority only during interruption recovery or when evidenced authority or worktree drift could invalidate the snapshot.
+
+Treat handoffs as transient pointers, never project truth. During recovery, reread current authority and referenced evidence, return changed or unverifiable completion to pending, and enforce the remaining finite limits. Never create durable controller status, retry graphs, receipts, or parallel lifecycle state.
+
+## Preserve artifact and authority boundaries
+
+Keep dispatch details, retry history, limits, and process chronology out of Changes, Specs, Decision Records, and the user-facing final result. Update the selected Change only with converged requirements, completed outcomes, decisive evidence, omissions, and real blockers. Durable facts and rationale still use Core's normal artifact-routing decision.
+
+Treat archive guidance as advisory unless the run has explicit lifecycle-closeout authority and Core has completed its durable decision. Archive never grants Git or publication authority.
+
+Stop at an unresolved owner decision, unavailable service, credential, device, environment, or human acceptance; missing external-action authority; verification without an evidenced in-scope correction; drift; or exhausted limits. Do not route around the boundary.
+
+Return only completed and pending slices, fresh verification, omissions, the real boundary owner, and one next action. Do not expose dispatch, retry, or budget chronology and do not claim archive, Git, publication, deployment, approval, or human acceptance that was not completed under explicit authority.

package/skills/rsp-release-docs/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: rsp-release-docs
+description: Prepare and audit evidence-based changelogs, release notes, and migration notes. Use when drafting or updating release documentation, reviewing an Unreleased section, summarizing a version range, deciding references or omissions, or checking that release prose matches shipped behavior and repository conventions.
+license: MIT
+metadata:
+  author: oevery
+  version: "2026.07.22.1"
+---
+
+# RSP Release Docs
+
+Build one release evidence ledger, then project it into the repository's release surfaces. Treat Git history as navigation, not product truth.
+
+## Establish authority
+
+Resolve requirements in this order:
+
+1. Follow the user's explicit scope, audience, language, format, reference, and mutation requirements.
+2. Follow the applicable instruction hierarchy; nearer project instructions override broader host or personal defaults.
+3. Follow existing release-tool configuration.
+4. Preserve the target artifact's current structure, terminology, and language.
+5. Match prior published releases and tag, link, and tracker conventions.
+6. Apply the defaults in this Skill only where the repository is silent.
+
+Use the higher-precedence source when two sources conflict. Ask one focused question only when the unresolved choice would materially change the public result. Read [convention discovery](references/convention-discovery.md) when locating or reconciling repository and personal conventions. Persist a preference only when the user explicitly authorizes its project or personal instruction owner.
+
+Completion criterion: name the release range, target version or draft state, audience, output surfaces, language, link style, and allowed mutations from observed authority.
+
+## Select the branch
+
+- **Audit:** inspect existing release prose and return findings without editing.
+- **Prepare:** draft requested artifacts; for a formal release, always include release notes. Update a changelog only when the repository owns one or the user requests one. Include migration guidance whenever users must act.
+- **Finalize:** replace Unreleased markers, dates, comparison links, or draft labels only when the release identity is confirmed.
+
+Publication is a separate branch. Preparing prose never grants commit, tag, push, release creation, registry publication, deployment, deletion, or approval authority.
+
+Completion criterion: every requested surface has one disposition: draft, update, audit only, not applicable, or blocked by a named decision.
+
+## Collect evidence
+
+Inspect the smallest sufficient set:
+
+- previous release tag or user-supplied base and the target ref;
+- commits and net diff in the release range;
+- PRs, issues, tracked Changes, changesets, news fragments, and release PRs when available;
+- public API, CLI, configuration, packaging, migration, security, and operator-facing changes;
+- existing changelog, prior release notes, migration guides, version files, and release configuration;
+- fresh verification and known acceptance gaps when the release claims compatibility or readiness; label archived evidence with its observed revision or date instead of presenting it as current.
+
+Use diffs and direct consumers to verify behavior. Use commit messages and labels to locate intent. Prefer accepted work artifacts and public documentation for business meaning. Reconcile disagreements explicitly instead of choosing the most convenient source.
+
+Completion criterion: every commit and every relevant tracked item in the range is represented by evidence or has an explicit exclusion reason.
+
+## Build the release ledger
+
+Create a working ledger before writing prose. Keep it in the response or temporary work unless the repository already owns release fragments or the user authorizes a path.
+
+For each net change record:
+
+- evidence identifiers and links;
+- user-visible or operator-visible outcome;
+- affected audience;
+- breaking, deprecation, security, compatibility, or migration impact;
+- changelog disposition;
+- release-note disposition;
+- reference choice;
+- exclusion or uncertainty, if any.
+
+Collapse multiple commits into one outcome. Omit changes added and reverted within the same range. Fold fixes to never-released behavior into the final feature description. Keep internal work out unless it changes public behavior, packaging, compatibility, security, operations, or release integrity.
+
+Completion criterion: the ledger describes the net released state rather than commit chronology, and every exclusion is intentional.
+
+## Project the artifacts
+
+Read [output contracts](references/output-contracts.md) before creating a new format, preparing a major or breaking release, or producing more than one surface.
+
+### Changelog
+
+Write a concise cumulative record of notable outcomes. Preserve existing categories; otherwise use Keep a Changelog categories and omit empty sections. Put breaking changes and required action first. Describe behavior, not implementation mechanics.
+
+### Release notes
+
+Write a release-specific narrative for the observed audience. Lead with the most important outcomes, make required action prominent, include compatibility or known limitations when evidenced, and link to the full changelog or comparison range. Do not merely duplicate the changelog.
+
+### Migration notes
+
+State who is affected, required actions in order, changed defaults or removed surfaces, compatibility window, validation steps, and rollback or support path when known. Use a separate guide when the instructions would overwhelm the release notes.
+
+Completion criterion: every statement maps to the ledger, each surface serves its distinct audience and lifetime, and terminology remains consistent across surfaces.
+
+## Apply reference policy
+
+Follow repository policy first. Otherwise:
+
+1. Add a version-level compare or tag link.
+2. Prefer PR links for implementation context.
+3. Prefer issue or tracked-work links for rationale and migration context.
+4. Use commit links when no better semantic anchor exists, exact provenance matters, or the user requires them.
+
+Do not force a reference onto every bullet. Use stable public links only; keep private tracker identifiers out of public prose unless the repository already exposes them.
+
+Completion criterion: references add useful context without turning the artifact into a Git log or exposing private information.
+
+## Audit before returning
+
+Check all of the following:
+
+- range and version identity are consistent across artifacts;
+- every ledger item is included or intentionally excluded;
+- no claim exceeds implementation or verification evidence;
+- verification counts, package identities, and compatibility claims name their observed revision or date when they were not refreshed in the current run;
+- breaking, migration, deprecation, security, and known-limit information is prominent where applicable;
+- user-visible net outcomes are not fragmented by commit;
+- links, dates, headings, language, and terminology match observed conventions;
+- changelog and release notes agree without becoming copies;
+- working-tree edits stay within authorized files.
+
+Return the release range, artifacts drafted or changed, coverage and exclusions, unresolved decisions, validation performed, and whether any external release action occurred.
+
+Completion criterion: the result is evidence-complete, convention-compatible, and truthful about omissions and publication state.

package/skills/rsp-release-docs/references/convention-discovery.md

@@ -0,0 +1,65 @@
+# Convention discovery
+
+Use this reference when a repository may have personal, project, tool, or historical release conventions. Discover; do not introduce a new configuration file merely to satisfy this Skill.
+
+## Authority sources
+
+Inspect only relevant, non-secret sources:
+
+1. Current user instructions, including requested audience, language, tone, links, output paths, and whether edits are allowed.
+2. Applicable instructions, with the nearest project instruction winning over broader host or personal defaults.
+3. Project release documents such as `CONTRIBUTING.md`, maintainer guides, or a documented release checklist.
+4. Existing target artifacts such as `CHANGELOG.md`, `NEWS.md`, release-note templates, upgrade guides, or an in-app What's New source.
+5. Release configuration and package scripts.
+6. Recent published releases and tags.
+
+Do not scan unrelated home-directory configuration. Do not print tokens, registry credentials, private URLs, authorization headers, or hidden release secrets. When a named config may contain secrets, inspect only the keys needed to identify release behavior. Keep a newly stated preference session-local unless the user explicitly authorizes an existing project or personal instruction owner.
+
+## Common configuration signals
+
+Look for these only when present or relevant:
+
+- `.github/release.yml`, Release Drafter, or GitHub Release templates;
+- release-please manifest/configuration;
+- `.changeset/config.json` and changeset fragments;
+- Towncrier, Changie, or similar news fragments;
+- `cliff.toml`, conventional-changelog, semantic-release, or commit-and-tag-version configuration;
+- monorepo package boundaries and per-package changelogs;
+- package scripts, CI release workflows, and version files;
+- tracker labels such as breaking, feature, fix, skip-changelog, or security.
+
+Treat generated release notes and automation output as evidence inventories. Human-facing claims still require semantic review.
+
+## Adaptation decisions
+
+Resolve these dimensions independently:
+
+| Dimension | Evidence to prefer |
+| --- | --- |
+| Audience | Explicit request, established release surface, prior releases |
+| Language | Explicit request, nearest project instruction, target artifact, prior published releases, conversation |
+| Voice | Existing artifact and product terminology |
+| Categories | Existing artifact/config; Keep a Changelog only as fallback |
+| Version and tags | Confirmed target, manifests, release config, prior tags |
+| References | Existing links and tracker policy; generic hierarchy only as fallback |
+| Output paths | Existing release owner or explicit path authority |
+| Detail | Audience needs, release risk, and existing cadence |
+
+Personal preferences refine the project format where compatible. Project-owned parsers, schemas, and release contracts win when a stylistic preference would break them. Report the conflict when the user must choose.
+
+For language specifically, apply the table order without reordering it: an explicit surface-specific request wins; otherwise follow the nearest project instruction, then that target artifact's established language, then prior published releases, and finally the conversation language.
+
+## Repository shapes
+
+- **Library or SDK:** emphasize public API, compatibility, deprecation, migration, runtime support, and precise references.
+- **Application:** emphasize visible workflows, changed defaults, operator action, rollout, and known limitations.
+- **CLI:** emphasize command/flag/config semantics, output contracts, migration, and shell compatibility.
+- **Monorepo:** determine the released unit before collecting evidence; avoid mixing unrelated packages.
+- **GitHub-Releases-only project:** draft release notes without creating `CHANGELOG.md` unless requested.
+- **Fragment-based project:** use accepted fragments as semantic evidence, then verify the net diff and release boundary.
+
+## Conflict examples
+
+- If the user requests Chinese release notes but `CHANGELOG.md` is consistently English, keep the changelog English and draft the release notes in Chinese unless the user explicitly asks to translate both.
+- If the user requests commit IDs but prior releases use PR links, preserve PR links and add commit links only for exact provenance unless the user explicitly overrides the project style.
+- If a tool requires two synchronized formats, update both from one ledger while preserving each parser's syntax.

package/skills/rsp-release-docs/references/output-contracts.md

@@ -0,0 +1,115 @@
+# Output contracts
+
+Use these as fallbacks. Preserve an established repository format whenever it exists.
+
+The generic baseline is Keep a Changelog 1.1.0 for cumulative structure and Semantic Versioning 2.0.0 for version meaning. Treat Conventional Commits, forge-generated notes, and label-based categorization as evidence inventories rather than finished prose.
+
+## Release evidence ledger
+
+Maintain a temporary table or equivalent structured notes:
+
+| Evidence | Net outcome | Audience | Risk/action | Changelog | Release notes | Reference | Exclusion/uncertainty |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| PR, issue, Change, commits, diff, docs, verification | What users receive | Users, developers, operators, maintainers | Breaking, migration, security, compatibility, none | Section or omit | Section or omit | PR, issue, work item, commit, compare | Reason or owner decision |
+
+The ledger is an analysis device, not a new project state store. Persist it only when the repository already owns release fragments or the user authorizes a destination.
+
+## Default changelog shape
+
+```markdown
+# Changelog
+
+## [Unreleased]
+
+## [3.0.0] - YYYY-MM-DD
+
+### Added
+
+- Add a user-visible capability. ([#123])
+
+### Changed
+
+- **Breaking:** Change an existing contract. See the [migration guide].
+
+### Fixed
+
+- Prevent an observable failure in a supported workflow. ([abc1234])
+
+[Unreleased]: https://github.com/OWNER/REPO/compare/v3.0.0...HEAD
+[3.0.0]: https://github.com/OWNER/REPO/compare/v2.0.0...v3.0.0
+[#123]: https://github.com/OWNER/REPO/pull/123
+[abc1234]: https://github.com/OWNER/REPO/commit/abc1234...
+[migration guide]: https://example.com/migration
+```
+
+Use Added, Changed, Deprecated, Removed, Fixed, and Security as fallback categories. Omit empty categories. Do not add an Unreleased section when the established project intentionally does not use one.
+
+## Default release-note shape
+
+```markdown
+# Version 3.0.0
+
+One short paragraph explaining the release's purpose and who benefits.
+
+## Highlights
+
+- Outcome and benefit, grouped by capability rather than commit.
+
+## Breaking changes and migration
+
+- Who is affected, what action is required, and where to find the full guide.
+
+## Other changes
+
+- Notable improvements and fixes that matter to this audience.
+
+## Compatibility and known limitations
+
+- Supported environments, verified coverage, and explicit non-claims.
+
+**Full changelog:** https://github.com/OWNER/REPO/compare/v2.0.0...v3.0.0
+```
+
+Omit inapplicable sections. Prefer three to seven scannable themes for a typical release; group small visible fixes without hiding high-impact items. Include contributors when the established release surface values attribution.
+
+## Migration contract
+
+For each required action, answer:
+
+1. Who is affected?
+2. What old behavior or surface changes?
+3. What must they do, in what order?
+4. What compatibility window or deadline applies?
+5. How can they verify success?
+6. What rollback, recovery, or support path exists?
+
+Keep a short summary in release notes and link a dedicated guide when the procedure is long, conditional, or operationally risky.
+
+## Reference rules
+
+- Add one compare or tag link for the release range when the forge supports it.
+- Prefer PR links for reviewable implementation context.
+- Prefer issue or tracked-work links for rationale and migration context.
+- Prefer commit links for exact fixes, backports, audit provenance, projects without PRs, or explicit user policy.
+- Keep references optional per bullet; a link must earn its visual cost.
+
+## Net-release examples
+
+- Five commits build one new capability: write one outcome.
+- A feature is added and reverted before release: omit it.
+- A bug is found and fixed before users receive the new feature: fold the final behavior into the feature item.
+- An internal refactor changes no public, packaging, security, or operator behavior: exclude it and record the reason in the coverage audit.
+- A dependency update changes the minimum runtime or bundled behavior: include the observable compatibility impact, not the dependency housekeeping.
+
+## Integrity gate
+
+Before finalizing, require:
+
+- complete range coverage with explicit exclusions;
+- traceable claims and no inferred readiness;
+- archived verification labeled as historical, with a fresh finalization gate when the release range has advanced;
+- matching versions, dates, tags, and links;
+- visible breaking and migration action;
+- no leaked private identifiers or secrets;
+- no external publication implied by a draft;
+- a diff limited to authorized release artifacts.

package/skills/rsp-review/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: rsp-review
+description: Review an RSP-tracked code, document, or mixed change against a fixed comparison scope and project authorities. Use for read-only findings before fixes, durable review, archive, or delivery; keep Code and Document states separate and never implement, commit, publish, or approve.
+license: MIT
+metadata:
+  author: oevery
+  version: "2026.07.22.3"
+---
+
+# RSP Review
+
+Review one fixed change scope without modifying it. Be concise, separate Code and Document judgment, and emit one deduplicated report.
+
+## Fix scope and authority
+
+Resolve before judging:
+
+- one immutable comparison point or explicit fixed file set;
+- reviewed files, including relevant untracked files named by the user;
+- the selected Change and, for grouped work, its Group Brief;
+- nearest project instructions and only relevant Specs and Decision Records;
+- any caller-supplied implementation summary.
+
+Do not switch branches or mutate the worktree to discover scope. If the comparison point is unavailable, report the review as blocked. If multiple focus markers or authorities select different intent, name the conflict, mark dependent pipelines blocked, and do not guess. Continue only pipelines whose inputs remain authoritative.
+
+The user request fixes the requested outcome and allowed operations subject to nearest project instructions. The selected Change defines the intended delta, Specs define stable current facts, and Decision Records define lasting rationale. Implementation and tests are evidence, not authority for missing requirements. Report missing authority instead of inventing a rule, acceptance criterion, or preference.
+
+## Classify the scope
+
+- **Code:** executable code, tests, configuration, scripts, schemas, executable prompts, Skills, commands, hooks, and workflows.
+- **Document:** requirements, plans, Changes, Specs, Decision Records, ADRs, explanatory documentation, and user-facing documentation.
+
+Determine applicability only from artifacts inside the fixed comparison scope. A Change, Spec, instruction, implementation file, or test read only as authority or evidence is not thereby a reviewed artifact. Run each applicable pipeline; return `skipped` for a pipeline with no reviewed artifacts even when authority of that kind was inspected, and never return `clean` for authority-only documents. When such authority is missing, ambiguous, or conflicting, record it in Review Scope, Coverage, and Verdict; do not emit a Finding owned by a skipped pipeline. An executable document may need both; merge evidence for the same underlying issue into one cross-artifact finding.
+
+Inspect in a bounded order: fixed status/diff, selected authority, then only the smallest direct behavior chain and tests needed to resolve a concrete question. Stop when every applicable pipeline can be judged. Do not search unrelated files or broaden authority merely to fill Coverage or Findings.
+
+## Review Code
+
+Check in this order:
+
+1. Safety and correctness: reachable bugs, data loss, security violations, invalid state transitions, broken contracts, unsafe failures, and regressions.
+2. Change and Spec fidelity: observable behavior against explicit intent and stable facts.
+3. Project standards: only rules established by nearest instructions or authoritative local conventions.
+4. Production reachability — hard gate before completing a seam-dependent Finding: when a Finding or suggested correction depends on an adapter, wrapper, validator, normalizer, or similar seam, name the direct production caller, compare its actual callee with that seam, and verify that the changed production consumer actually reaches that seam. Put the comparison in Evidence or Coverage. If the live path bypasses the seam, report the bypass and do not present an isolated seam fix as sufficient.
+5. Regression evidence — hard gate before `clean`: for every changed Code artifact, compare public return and failure behavior at the comparison point with the reviewed diff. Changing failure delivery between throw/rejection, sentinel values, `null`, status codes, or result objects is always a failure-contract change, even when implementation matches the selected Change. Without a focused test or other explicit verification evidence, emit a Finding and return `issues_found`. Absence of a new test is not actionable by itself: apply the simple deterministic-correction exception when the public behavior shape is preserved and no risky branch, state transition, concurrency, persistence, security behavior, or failure delivery changes, even though the corrected value differs. The exception never applies to a failure-contract change.
+6. Simplicity: unnecessary abstraction, duplication, indirection, dependency, or scope expansion with a concrete smaller alternative; never trade away required behavior.
+
+Anchor each Finding to changed lines or the smallest behavior chain. State a realistic trigger and impact. Do not report formatting, naming, generated output, taste, or hypothetical cleanup without authority or demonstrated downside.
+
+## Review Documents
+
+Classify each document by its semantic role: requirement/Change, implementation plan, Spec, Decision Record/ADR, or explanatory/user documentation. Then check:
+
+1. Authority and traceability of claims and decisions.
+2. Internal and cross-artifact coherence, including current implementation facts.
+3. Completeness and ambiguity: undefined terms, unverifiable completion, and choices disguised as decisions. Report an unresolved product, operational, rollback, migration, or completion choice as an ambiguity Finding when no authority resolves it; ask for owner judgment and mark a dependent result blocked only when the choice prevents coherent review.
+4. Feasibility of named paths, interfaces, sequencing, safety, migration, and executable verification, at the detail appropriate to the document role.
+5. Scope and concision: scope leakage, duplicate authority, unrelated requirements, or verbosity hiding a contract.
+
+Before the Document verdict, enumerate every unresolved choice in each changed document. Any unresolved product, operational, rollback, migration, ownership, or completion choice must either have resolving authority or produce an ambiguity Finding; do not stop after finding other defects.
+
+Anchor Findings to the smallest heading or claim. Do not apply code-style or test-coverage rules to semantic documents, auto-fix meaning, or rewrite prose for taste.
+
+## Report
+
+Render headings, field labels, explanations, and verdict prose in the language explicitly requested by the user; otherwise follow nearest project instructions, then the conversation language. Treat the shape below as semantic field order rather than fixed English wording: translate its human-facing labels when the output language differs. Preserve paths, commands, identifiers, WorkRefs, severity labels `P0`-`P3`, and the values `issues_found`, `clean`, `skipped`, and `blocked` unchanged.
+
+Use this shape:
+
+```md
+## <localized Review Scope heading>
+- <localized Comparison label>: <fixed ref, range, or file set>
+- <localized Intent label>: <authorities, missing, or ambiguous>
+- <localized Code label>: <issues_found | clean | skipped | blocked>
+- <localized Document label>: <issues_found | clean | skipped | blocked>
+- <localized Excluded label>: <paths and reasons, or none>
+
+## <localized Findings heading>
+### [P0-P3] <title>
+- <localized Artifact kind label>: <code | document | cross-artifact>
+- <localized Axis label>: <pipeline axis>
+- <localized Location label>: <path:line or precise section>
+- <localized Authority label>: <authority or observed invariant>
+- <localized Evidence label>: <conflicting behavior or text>
+- <localized Impact label>: <real consequence>
+- <localized Suggested action label>: <smallest correction; no edit>
+- <localized Confidence label>: <high | medium | low>
+
+## <localized Coverage heading>
+- <checked and unverified scope, including non-actionable missing coverage>
+
+## <localized Verdict heading>
+<blocked | findings | clean, with the smallest next action>
+```
+
+Omit Finding entries when none exist. `clean` means an applicable pipeline was reviewed with no actionable issue; `skipped` means no applicable artifacts; `blocked` means required scope or authority was unavailable. Deduplicate one underlying issue across pipelines, then order by severity and path. Use P0 for critical security/data/breakage, P1 for normal-path contract failure, P2 for a meaningful edge or maintenance risk, and P3 only for narrow actionable improvement.
+
+Return a report only. Do not edit files, apply fixes, change focus, create RSP artifacts, switch branches, stage, commit, push, open a PR, publish, delete, trigger external review, or approve. Later actions require separate explicit authority.

package/skills/rsp-shape/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: rsp-shape
+description: Shape or rigorously challenge unclear non-trivial work into one executable RSP Change or a justified shallow Change Group without implementing it.
+license: MIT
+metadata:
+  author: oevery
+  version: "2026.07.24.1"
+---
+
+# RSP Shape
+
+Do not implement the shaped work.
+
+Follow Core's response-versus-artifact language boundary.
+
+## Establish the boundary
+
+Read the request, authority, Core or fallback, Change and Brief, then only decisive evidence.
+
+A request to shape, create, or refine a Change grants artifact authority unless no-edit; advice does not. If creation focuses it, preserve the exact prior focus and restore it immediately unless selection was requested. Shaping grants no other authority to focus, implement, archive, edit durable truth, or mutate Git; preserve unrelated work.
+
+Return the request directly to implementation when it is tiny and concrete or the selected Change is already ready. Do not rewrite settled work for style or completeness.
+
+## Resolve material ambiguity
+
+Inspect the repository before asking. Ask only for an owner decision whose answer can change behavior, data, interfaces, compatibility, safety, ownership, migration, or acceptance. Ask the smallest useful question set and write only authorized answers into the Change.
+
+Read [deep clarification](references/deep-clarification.md) when the user explicitly asks for rigorous challenge, a high-risk dependent decision remains, or one bounded design question returns to Shape. Prefer the installed `rsp-design` capability; otherwise use its compact fallback against the same WorkRef.
+
+Never invent a product decision. When a material choice or mutation authority remains unresolved, leave the work open and report the single highest-impact blocker.
+
+## Choose the owner
+
+Read [complex shaping](references/complex-shaping.md) before choosing the owner when material clarification needs more than one round, several direct slices share one completion contract, or independently closable owners converge on terminal delivery.
+
+Prefer one ordinary Change. Use a shallow Group only when at least two direct children are independently implementable, verifiable, focusable, and archivable while sharing one goal or completion contract. A shared completion contract gates Group closure, not each child's archive unless that child declares the dependency. Keep membership in Brief `Slices`, exact prerequisites in child `Blockers`, and derived readiness in CLI output. Do not create another hierarchy or tracker.
+
+Follow the core RSP protocol for exact Change and Group structure. Keep one observable outcome per Change:
+
+- `Proposal`: outcome, scope, and non-goals;
+- `Spec`: observable requirements and acceptance scenarios;
+- `Design`: affected boundaries, constraints, and settled choices;
+- `Tasks`: executable implementation steps;
+- `Verify`: final decisive evidence proving the outcome;
+- `Blockers`: exact dependencies and unresolved external decisions, or `none`.
+
+Plan a new test only when it protects observable behavior or a real boundary, adds distinct future confidence, avoids duplicate or implementation-detail coverage, and costs proportionately. Otherwise prefer smallest sufficient evidence and keep probes temporary.
+
+A Change is a convergent current-plan/final-evidence snapshot, not an append-only execution log. Replace superseded evidence; keep process evidence in the response. Before archive, compress it to outcome, design, tasks, decisive verification, gaps, and risks.
+
+Use domain language. Mention AI or agents only as real product actors, consumers, interfaces, or constraints—not authors or execution narrators.
+
+## Apply the Shape Ready gate
+
+A Change is ready only when:
+
+- outcome, non-goals, and acceptance are concrete;
+- product and mutation authority are settled;
+- affected boundaries and material constraints are known;
+- no hidden assumption can change implementation or acceptance;
+- Tasks are executable without performing them;
+- Verify proves the result without process chronology; Blockers are truthful;
+- one Change or a justified shallow Group is the smallest sufficient owner.
+
+After authorized mutation, run the project focused RSP check when available. Return WorkRef, changed artifacts, validation, and the next implementation action or blocker.

package/skills/rsp-shape/references/complex-shaping.md

@@ -0,0 +1,30 @@
+# Complex shaping
+
+Read this reference only when material clarification needs more than one round, several direct slices share one completion contract, or independently closable owners converge on terminal delivery.
+
+## Close material decisions
+
+List unresolved owner decisions by implementation impact. Ask one to three related questions, write authorized answers into their owning Change sections, and reapply the Shape Ready gate. Repeat only while another material decision remains. If one cannot be settled, keep it in `Blockers` and return it as the next owner decision.
+
+Use an installed interview or grilling capability only when the work boundary is known, the remaining choice is high-risk, and the user selects deeper exploration. Consume its settled decisions afterward; it owns no RSP state.
+
+## Choose a complex owner
+
+Keep cohesive work in one Change when it has one consistency and verification boundary.
+
+Use a shallow Group when at least two direct children are independently implementable, verifiable, focusable, and archivable. The Brief explains the shared goal, constraints, slices, aggregate completion, and durable outcomes. Child Changes own implementation tasks, verification, and exact `requires` edges. Group completion gates closing the Brief; it does not prevent a child from archiving unless that child declares the dependency.
+
+Use an Overall Delivery Change when independently closable semantic owners converge on terminal versioning, packaging, migration, authorization, or publication. It remains an ordinary six-section Change:
+
+- Proposal, Spec, and Design name the terminal outcome, upstream owners, aggregate completion contract, and static ownership map;
+- Tasks and Verify contain only terminal delivery operations;
+- references point to upstream outcomes without copying their tasks, checks, progress, or live status;
+- exact prerequisites remain ordinary Change `Blockers`.
+
+A permission needed only for a later external task belongs in that task and its constraints. Promote it to an active `Blocker` only when it prevents the next executable work; do not block versioning, packaging, or other authorized preparation prematurely.
+
+Do not add a nested Group, delivery-map file, phase entity, or persisted wave plan. If one existing Change or Group already owns the complete outcome, return that owner unchanged.
+
+## Completion criterion
+
+Finish complex shaping when the smallest sufficient owner is selected, every direct slice or upstream owner has one clear boundary, dependencies live only in child or terminal Change `Blockers`, no live state is duplicated, and every executable Change passes the ordinary Shape Ready gate.

package/skills/rsp-shape/references/deep-clarification.md

@@ -0,0 +1,29 @@
+# Deep clarification
+
+Read this reference only when the user explicitly asks for rigorous challenge, or normal shaping leaves a high-risk decision whose dependent choices remain unresolved.
+
+## Establish the fact boundary
+
+Inspect the available code, tests, project instructions, Specs, and Decision Records before questioning the owner. Name the unresolved decision and the implementation consequence that makes it material.
+
+## RSP design return
+
+When `rsp-design` is available, it is the canonical domain or module design capability for an RSP-tracked question. Otherwise use an equivalent project-selected capability or Core's compact manual design fallback. Return one bounded design task containing:
+
+- the unresolved design question;
+- authoritative project inputs by path;
+- the expected existing artifact or decision output;
+- its permitted mutation boundary;
+- the same returning WorkRef.
+
+The selected capability owns only the design analysis, while existing project documents retain domain and architecture authority. Consume its settled result and evidence on return, then resume Shape against the same Change.
+
+## Traverse one decision at a time
+
+Ask exactly one owner decision per turn. Include a recommended answer grounded in inspected facts and the material tradeoff it resolves. After each answer, continue only along that decision's dependencies and derive available facts from the repository.
+
+When no material dependent decision remains, summarize the resulting behavior, boundaries, and acceptance contract, then ask the owner to confirm shared understanding. Keep all artifacts unchanged until that confirmation. After confirmation, write only authorized decisions into their existing RSP owners and reapply the Shape Ready gate.
+
+## Completion criterion
+
+Finish the deep branch when every material dependent decision is either owner-confirmed or recorded as one explicit blocker, the project design task has returned to the same WorkRef when used, and no artifact changed before shared understanding was confirmed.