@oevery/rsp 3.2.0 → 4.0.0

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

@@ -1,77 +0,0 @@
----
-name: rsp-release-docs
-description: Draft, audit, finalize, or reconcile evidence-based changelogs, release notes, and migration notes for an explicit release operation.
-license: MIT
-metadata:
-  author: oevery
-  version: "2026.07.26.1"
----
-
-# RSP Release Docs
-
-Build one net-release evidence ledger and project it into repository-owned release surfaces. Git history locates evidence; it is not product truth.
-
-Follow Core's response-versus-artifact language boundary for all user-visible control narration; when the response language differs, keep exact canonical values only as secondary parenthesized or code-formatted tokens.
-
-## Establish authority
-
-Resolve user scope, audience, language, format, references, and mutation authority first; then nearest project instructions, release-tool configuration, target-artifact conventions, and prior published releases. Higher-precedence evidence wins. Ask one focused question only when an unresolved owner choice materially changes the public result.
-
-Read [convention discovery](references/convention-discovery.md) when repository, personal, tool, or historical conventions must be located or reconciled. Do not invent configuration or persist preferences without authority.
-
-A release identity is confirmed only by explicit user instruction or authoritative repository release configuration. Never infer it from semantic-version ordering, prior prereleases, commits, planned prose, or package-manager convention. Until confirmed, keep work version-neutral and do not mutate manifests, target changelog headings, exact-version commands, versioned note paths, or tag comparisons.
-
-Before continuing, name the range, confirmed version or draft state, audience, surfaces, language, link style, and allowed mutations.
-
-## Select one branch
-
-- **Audit:** inspect fixed release prose and return findings without editing.
-- **Draft:** collect and project evidence. While identity can change, keep the ledger transient or use an existing release-fragment owner. Once identity is confirmed, update only authorized surfaces. Formal releases include release notes; update a changelog only when the repository owns one or the user asks; include migration guidance whenever users must act.
-- **Finalize for publication:** require confirmed identity and range, completed implementation Change closeout, and an exact clean candidate. An explicit tag, hosted release, registry publication, or equivalent public request must pass this branch even after prose review. Bind `ready` to the exact release commit.
-- **Reconcile published release:** observe the published identity and external surfaces, repair only authorized mutable surfaces, and assign immutable discrepancies to a corrective version or owner. Never rewrite a published package or move a tag to manufacture consistency.
-
-Exactly one branch is active. Give every requested surface one disposition: draft, finalize, reconcile, audit only, not applicable, or blocked by a named decision.
-
-## Keep release coordination proportional
-
-A confirmed mechanical release does not require an RSP Change. Keep the ledger, command progress, authentication state, and publication handoff transient; manifests, changelog, release commit, tag, hosted release, and registry record own durable release history.
-
-Use an optional Release Change only when material version/range, migration, rollback, security, compatibility, cross-repository/team, multi-stage handoff, recovery, blocker, or acceptance decisions need a persistent owner. Do not create one for a checklist, verification transcript, or prose already owned by release surfaces.
-
-## Build evidence before prose
-
-Inspect the smallest sufficient set: base and target refs; commits and net diff; relevant PRs, issues, Changes, fragments, and release PRs; public API, CLI, configuration, packaging, migration, security, and operator behavior; release surfaces and configuration; fresh verification and known acceptance gaps.
-
-Use direct consumers and diffs for behavior, work artifacts and public docs for meaning, and commit metadata for navigation. Reconcile disagreements explicitly. Historical verification must name its observed revision or date.
-
-Read [evidence and surfaces](references/evidence-and-surfaces.md) before drafting the ledger, classifying statement lifetime, or deciding exclusions. Read [output contracts](references/output-contracts.md) before introducing a format, preparing a major/breaking release, or producing multiple surfaces.
-
-Every relevant commit and work item must map to a net outcome or explicit exclusion. Collapse implementation chronology, omit additions reverted within the range, fold prerelease fixes into final behavior, and exclude internal work unless it changes public behavior, packaging, compatibility, security, operations, or release integrity.
-
-## Project distinct surfaces
-
-- **Changelog:** concise cumulative notable outcomes using the existing categories, or Keep a Changelog categories as fallback. Put breaking changes and required action first.
-- **Release notes:** audience-specific narrative led by the most important outcomes, required action, evidenced compatibility and limitations, plus the full range link. Do not merely duplicate the changelog.
-- **Migration notes:** identify affected users, ordered actions, changed defaults or removed surfaces, compatibility window, validation, and known rollback/support. Use a separate guide when this would overwhelm the notes.
-
-Every claim must map to the ledger. Keep terminology aligned while respecting each surface's audience and lifetime.
-
-## Finalize the exact candidate
-
-Read [publication lifecycle](references/publication-lifecycle.md) before a publication handoff or post-publication reconciliation.
-
-Finalization inspects public release surfaces and package inventory at the exact candidate—not every internal workflow artifact present in the tag. Require version, date, changelog, notes, migration guidance, comparisons, manifests, package inventory, release checks, and lifecycle closeout to agree. Shipped prose must remain true before, during, and after publication; transient publication or authentication state belongs only in the handoff.
-
-When Git delivery is authorized, implementation Changes remain independently reviewable and versioned shipped surfaces are finalized in a separate release commit. Return the version, immutable candidate ref, required external actions, fresh checks, omissions, and `ready` or `not ready`. `ready` means internally eligible for a separately authorized operation; it is neither publication authority nor evidence of publication.
-
-## Protect authority and credentials
-
-This Skill never executes or grants authority for commit, tag, push, hosted release creation, registry publication, deployment, deletion, approval, or rewriting immutable history. Publication is a separate external operation.
-
-Treat one-time passwords, browser-auth URLs, device codes, tokens, and token-bearing query strings as credentials. Never retain their values in release prose, Changes, ledgers, logs, summaries, or responses. If a command would expose them to retained output, stop and let the authorized human authenticate in a trusted terminal; resume only with credential-free status.
-
-## Return an evidence-complete result
-
-Before returning, confirm consistent range and identity; ledger coverage or explicit exclusions; claims bounded by evidence; prominent breaking, migration, security, deprecation, and known-limit information; convention-compatible links, dates, headings, language, and terminology; publication-invariant shipped prose; transient state with its owner; credential-free retained output; and edits limited to authorized paths.
-
-Return the range, branch, changed or audited artifacts, coverage and exclusions, unresolved owner decisions, validation, handoff readiness when applicable, and whether any external action occurred.

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

@@ -1,65 +0,0 @@
-# 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, established target artifact, configured effective artifact language, nearest project instruction, 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, follow Core's response-versus-artifact boundary. An explicit surface-specific request wins. Otherwise preserve an existing target artifact's established language. For a new release artifact, use the configured effective artifact language, then the nearest project or release instruction, prior published releases, and finally the conversation language. Configuration changes never translate an existing release surface by themselves.
-
-## 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/evidence-and-surfaces.md

@@ -1,21 +0,0 @@
-# Evidence and surfaces
-
-Load this reference before drafting the release ledger, assigning statement lifetime, or deciding exclusions.
-
-## Evidence ledger
-
-Keep a transient table or equivalent notes with: evidence identifiers/links, net user or operator outcome, audience, breaking/deprecation/security/compatibility/migration impact, changelog and release-note dispositions, reference choice, and exclusion or uncertainty owner.
-
-The ledger is an analysis device, not a new project state store. Persist it only in an existing release-fragment system or explicitly authorized destination. It describes the released net state rather than commit chronology.
-
-## Surface lifetime
-
-- **Shipped surfaces:** package metadata and release communication captured by the tag or package, including README, changelog, repository notes, manifests, and migration guides. Internal workflow records keep their own artifact lifetime. Shipped statements must be publication-invariant: exclude “not yet published,” “available after publication,” pending authentication, unverified registry state, and comparisons ending at `HEAD`.
-- **Mutable public surfaces:** hosted release descriptions, safely mutable registry metadata, and other external records. Keep stable narrative aligned with shipped surfaces; add live verification only after observing it.
-- **Transient release state:** credentials, authentication, command progress, pending publication, and unverified availability. Keep it in an authorized tracker, temporary ledger, or response handoff—never shipped prose.
-
-When immutable published content is wrong, preserve it, explain the discrepancy on an authorized mutable surface, and name a corrective version or owner.
-
-## References
-
-Follow repository policy first. Otherwise add a version-level tag or comparison link, prefer PRs for implementation context, issues or tracked work for rationale and migration, and commits when no better semantic anchor exists or exact provenance is required. Links are optional per bullet and must be stable and public; do not expose private tracker identifiers.

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

@@ -1,97 +0,0 @@
-# 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.
-
-## 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.
-
-## 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-release-docs/references/publication-lifecycle.md

@@ -1,24 +0,0 @@
-# Publication lifecycle
-
-Load this reference before finalizing an exact publication candidate or reconciling an observed publication.
-
-## Finalization gate
-
-Require all of the following at the exact candidate:
-
-- target version agrees across manifests, changelog heading/date, release notes, migration guidance, and exact-version assertions;
-- the target changelog entry is not labeled `Unreleased`;
-- stable comparisons end at the target tag or immutable ref, not `HEAD`;
-- shipped surfaces contain no pending-publication, authentication, or unverified-live-state prose;
-- package inventory and release checks are fresh, with omissions named;
-- required implementation lifecycle closeout is in the candidate revision and its worktree relationship is explicit.
-
-Any missing evidence yields `not ready` with the failed gate and owner. A `ready` result identifies the version, immutable candidate ref, required external actions, checks, and omissions without executing them.
-
-## Reconciliation
-
-After publication, observe the tag target, hosted release, registry version/dist-tags, and exact-version consumer command where applicable. Compare them with the finalization handoff and shipped inventory. Update authorized mutable surfaces only from observed state. Mark unknown facts unverified and record immutable drift with a corrective version or owner; never move tags or rewrite packages.
-
-## Credential boundary
-
-Keep authentication values and URLs out of retained output. A human performs any credential-emitting interactive step in a trusted terminal; the handoff records only credential-free required/completed status.

package/skills/rsp-resolve-findings/SKILL.md

@@ -1,61 +0,0 @@
----
-name: rsp-resolve-findings
-description: Resolve one fixed rsp-review report for an RSP-tracked change. Use when the user or a qualified managed goal authorizes disposition, bounded fixes, fresh verification, re-review, or recovery; keep the reviewer report-only and never infer Git or publication authority.
-license: MIT
-metadata:
-  author: oevery
-  version: "2026.07.28.1"
----
-
-# RSP Resolve Findings
-
-Resolve one fixed review report without changing what the reviewer observed. Treat resolution as a bounded correction pass, not a retry loop or a second project lifecycle.
-
-Render headings, field labels, explanations, and conclusion prose in the language explicitly requested by the user; otherwise follow nearest project instructions, then the conversation language. Treat report and handoff shapes as semantic field order rather than fixed English wording: translate their human-facing labels when the output language differs. Preserve paths, commands, identifiers, WorkRefs, FindingRefs, severity labels, and the dispositions `accepted`, `rejected`, and `needs-clarification` unchanged; when their language differs from the response, retain those dispositions only as secondary exact tokens beside localized narration.
-
-## Fix scope and authority
-
-Require the review report, its fixed comparison or file set, the selected Change and sibling Group Brief when applicable, relevant project authority, and either explicit user permission or Core-confirmed original managed authority for proposed mutation. Read the current worktree and the smallest behavior chain needed to verify each Finding. Preserve unrelated modified, staged, and untracked work.
-
-Identify a Finding by its report order plus severity, title, and location. Stop if the report, comparison, Change, or Finding identity is missing or conflicting. A report grants investigation only: correction, verification, re-review, Git delivery, publication, deployment, approval, and external actions retain their own authority. Never infer Git or publication authority.
-
-## Disposition every finding
-
-Assign exactly one disposition and concise evidence to every input Finding:
-
-- `accepted`: current production or document evidence confirms the issue, the intended correction is authoritative, and the fix is inside the selected Change and mutation authority;
-- `rejected`: direct evidence disproves the issue or shows that its suggested action is not required by the selected authority; record the evidence and do not edit for it;
-- `needs-clarification`: an owner decision, authoritative requirement, reproducible trigger, or safe scope is missing; name the required input and do not edit for it.
-
-Do not accept feedback for politeness, reject it from intuition, or silently reinterpret an ambiguous Finding. When one correction covers multiple accepted Findings, retain each disposition and point them to the shared fix.
-
-## Fix accepted findings
-
-In one resolution pass, implement the smallest complete correction for accepted Findings only. Add or adjust focused tests when the corrected behavior or failure contract requires them. Do not modify `rsp-review`, the original report, or unrelated findings to make the result appear clean.
-
-After the last relevant edit, run fresh verification for the affected behavior and the selected Change. A failed, unavailable, stale, or omitted check cannot close an accepted Finding. If a check exposes another defect, return it as evidence; do not begin an automatic retry loop.
-
-Require a fresh fixed-scope re-review before claiming resolution. Return a re-review request containing the original comparison, selected authority, post-fix file set or immutable comparison, implementation summary, dispositions, and verification evidence. The re-review remains report-only. On resume with its report, correlate original Findings as resolved or remaining and return any new Finding as unresolved input to Core. Resolve Findings never self-loops. Only qualified Manage may classify an in-scope `accepted` Finding as `correction-needed` and re-enter another bounded pass under the original managed authority and its separate convergence limit; standalone work requires new authority.
-
-## Handoff and recovery
-
-When work stops before a clean re-review, return Core's compact artifact-scoped continuation with review state embedded in the shared fields:
-
-```md
-## <localized Review Resolution Handoff heading>
-- <localized WorkRef label>: <selected Change>
-- <localized Authority label>: <project, Change, fixed report, and comparison pointers>
-- <localized Current state label>: <review input, FindingRef dispositions, and re-review status>
-- <localized Changed artifacts label>: <reviewed and changed paths, or none>
-- <localized Fresh verification label>: <command and result, or pending reason>
-- <localized Blockers label>: <unresolved FindingRefs and required owner input, or none>
-- <localized Next action label>: <smallest bounded action and owner>
-```
-
-The handoff contains authoritative pointers, not project truth. Return it in the response unless the user explicitly authorizes a path; never create a hidden receipt or persistent run state. It is not durable truth or a second state store. Exclude secrets, full logs, and duplicated Change text.
-
-To recover, reopen every authority pointer, confirm the WorkRef and comparison still identify the intended scope, inspect current worktree drift, and revalidate claimed verification. Mark stale evidence pending instead of trusting the handoff. Continue only the named pass; host threads, agents, hooks, or proprietary resume features are optional and never required.
-
-## Return ownership
-
-Report the disposition table, changed artifacts, preserved unrelated work, fresh verification, re-review status, and the handoff when anything remains. Name `correction-needed` only when Core supplied a qualified managed continuation; it is not an external blocker or durable Change state. Resolution is complete only when every Finding has a supported disposition, every accepted Finding has a verified correction, the fresh fixed-scope re-review is clean, and no `needs-clarification` input remains. Never claim archive, commit, push, publication, deployment, or approval.

package/skills/rsp-structural-audit/SKILL.md

@@ -1,71 +0,0 @@
----
-name: rsp-structural-audit
-description: Audit one explicitly bounded repository or subtree for evidence-backed structural risks before implementation work is selected. Use for report-only discovery of ownership, dependency, production-path, change-amplification, or verification mismatches; do not use for security, performance, dependency, framework, style, or production-readiness audits.
-license: MIT
-metadata:
-  author: oevery
-  version: "2026.07.28.1"
----
-
-# RSP Structural Audit
-
-Discover the few structural risks worth considering next. Return a report only.
-
-## Trigger and input
-
-Use this Skill when the user wants to discover material structural risks in an existing codebase before a Change, fixed review scope, or bounded design question exists. Require one explicit repository or subtree boundary and honor narrower user questions and exclusions. An RSP Change is not required; if one is focused, use it only when it matches the requested scope.
-
-Read nearest project instructions and context first. Then inspect only the smallest useful chain of entry points, direct callers or consumers, state and data owners, relevant configuration, and focused tests. Treat implementation, tests, comments, and directory structure as evidence rather than product authority.
-
-Do not substitute this audit for security, performance, dependency, framework, style, production-readiness, or speculative cleanup work. Return that mismatch and the required specialist owner instead.
-
-## Authority
-
-The user owns the audit boundary and requested outcome. Project instructions, Specs, and decisions own established constraints. A focused Change may provide intent or scope but grants no additional mutation authority.
-
-This Skill owns only its response report. It never modifies project code, tests, configuration, documentation, RSP artifacts, focus, lifecycle state, Git state, or external systems. It does not create a Change, choose product intent, design a solution, apply a fix, or invoke another Skill.
-
-## Action and verification
-
-After scope and authority are fixed, read [structural audit lenses](references/structural-lenses.md) and select only the lenses relevant to evidence already encountered. Trace concrete owners and live paths; do not scan every directory or apply every lens mechanically.
-
-Qualify a finding only when exact repository evidence establishes a reachable trigger, a realistic impact, and the implicated ownership or behavior chain. Verify a seam-dependent finding by naming the direct production consumer and confirming whether its actual callee reaches or bypasses the seam. Compare focused tests or other verification evidence with that same live path when the finding depends on claimed coverage.
-
-Report the smallest unresolved shaping or design question as `Next owner`. Route solution alternatives, seam recommendations, and reversible probes to `rsp-design`; do not develop them inside this audit.
-
-Do not infer a finding from directory names, pattern matching, code size, framework taste, a generic checklist, or an isolated abstraction without a demonstrated downside. Prefer no finding to a weak finding. Stop inspecting when the requested boundary has enough evidence for at most five material findings, no qualifying finding remains, or further confidence requires authority or evidence outside the boundary.
-
-## Output
-
-Render headings, field labels, explanations, and conclusions 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, while preserving paths, severity labels, confidence values, and the result values `findings`, `clean`, and `scoped uncertainty`; when their language differs from the response, retain those values only as secondary exact tokens beside localized narration.
-
-Return findings ranked by material impact, then confidence. Emit at most five and use this shape:
-
-```md
-## Audit scope
-- Boundary: <repository or subtree>
-- Authority: <instructions, constraints, and material gaps>
-- Inspected: <entry points and smallest behavior chains>
-- Excluded: <explicit exclusions and unsupported specialist audits>
-
-## Findings
-### [P1-P3] <structural risk>
-- Lens: <ownership | dependency | production path | change amplification | verification>
-- Evidence: <exact paths and concrete chain>
-- Trigger: <reachable condition>
-- Impact: <real consequence>
-- Confidence: <high | medium | low>
-- Next owner: <smallest shaping or design question, or user decision>
-
-## Coverage
-- <checked paths, unresolved uncertainty, and unobserved runtime behavior>
-
-## Result
-<findings | clean | scoped uncertainty, with the smallest next action>
-```
-
-Use `clean` when the inspected boundary contains no evidenced structural risk. Use `scoped uncertainty` when missing authority, inaccessible evidence, or an unsafe runtime requirement prevents judgment; name exactly what is missing and its owner. Do not manufacture advice to fill the report.
-
-## Stop
-
-Stop before auditing when the boundary or owner intent is materially ambiguous. Stop during inspection when evidence requires credentials, an unsafe or destructive probe, production side effects, mutation, or material expansion beyond the explicit boundary. Return the evidence collected, the unverified claim, and one smallest next action. Never continue into shaping, design, implementation, review, archive, Git delivery, publication, deployment, or approval.

package/skills/rsp-tdd/SKILL.md

@@ -1,48 +0,0 @@
----
-name: rsp-tdd
-description: Drive one clear testable behavior owned by a selected RSP Change through observed RED, minimal GREEN, safe REFACTOR, and fresh verification. Use when test-first evidence is the selected next action; return unexplained failures to diagnosis and all results to the same Change.
-license: MIT
-metadata:
-  author: oevery
-  version: "2026.07.24.1"
----
-
-# RSP TDD
-
-Implement one clear behavior test-first and return evidence to its selected Change. Follow Core's response-versus-artifact language boundary for all user-visible control narration; when the response language differs, keep exact canonical values only as secondary parenthesized or code-formatted tokens.
-
-## Establish the cycle
-
-Require one selected, ready Change, clear observable behavior, test and production mutation authority, and an executable focused check. Read project authority, current worktree state, and the smallest owning production/test seam.
-
-Stop when behavior or acceptance is unclear, mutation authority is missing, an existing symptom has an unexplained cause, the execution environment is unavailable, or a baseline failure cannot be separated. Return the same Change, evidence, and one needed next action.
-
-## RED
-
-Add the smallest focused test at the real owning seam. Run it before production mutation and observe the expected missing or incorrect behavior.
-
-RED is not a syntax, fixture, environment, or unrelated baseline failure. A passing test disproves the premise; refine it or stop without production mutation. An unexplained failure returns to diagnosis, not a guessed regression test.
-
-## GREEN
-
-Make the minimum production change for GREEN, preserve scope, and rerun the same command. An unexplained failure returns to diagnosis without speculative widening.
-
-## REFACTOR
-
-Refactor only after GREEN for a concrete local improvement; rerun the focused check. Otherwise skip it.
-
-## Retain or remove the test
-
-Keep the test only when it protects observable behavior or a real boundary, adds distinct future confidence beyond existing checks, avoids implementation-detail coupling or duplicate coverage, and has proportionate maintenance cost. A user, Change, or project requirement to retain the test remains authoritative.
-
-Otherwise treat it as a disposable probe: remove it before completion, verify that no disposable fixture or helper remains, and run the cheapest decisive existing check against the final production state. A removed probe is process evidence, not final verification; when automation is insufficient, record applicable manual or environment evidence.
-
-## Verify and return
-
-After cleanup, run fresh required Change checks and narrow risk checks. Failure or unavailability cannot support completion. Update Tasks and Verify with final decisive evidence, omissions, and unresolved risk rather than a chronological test transcript; keep unresolved issues in Blockers.
-
-Return to the same selected Change with WorkRef, final state, artifacts, fresh checks, omissions, Tasks, Blockers, and one next action; do not create parallel lifecycle state or recursively invoke another Skill.
-
-When work remains, use Core's compact continuation fields in order: `WorkRef`, `Authority`, `Current state`, `Changed artifacts`, `Fresh verification`, `Blockers`, and `Next action`. Reopen authority, inspect drift, and refresh verification before resuming; continuation is not durable truth.
-
-Git staging, commit, push, publication, deployment, review, archive, and approval remain separate actions requiring their own authority.