@oevery/rsp 3.3.0 → 4.1.0

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,28 +0,0 @@
-# Publication lifecycle
-
-Load this reference before finalizing an exact publication candidate or reconciling an observed publication.
-
-## Finalization gate
-
-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.
-
-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.
-
-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.
-
-## 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.08.21.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 an artifact path. 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-structural-audit/references/structural-lenses.md

@@ -1,41 +0,0 @@
-# Structural audit lenses
-
-Load this reference only after the audit boundary and authority are fixed. Select the smallest relevant set of lenses; do not turn them into a completion checklist.
-
-## Candidate selection in a broad boundary
-
-When the user supplies a broad repository boundary without a narrower lead, use repeated changes, recurring defects, or cross-owner correction history only to select the smallest candidate behavior chain. Churn is navigation evidence, not a Finding. Inspect the current owners and reachable path before applying any lens, and return `clean` when the selected chain has no concrete structural downside.
-
-## Ownership and sources of truth
-
-Trace where important state or data is created, validated, mutated, persisted, recovered, and consumed. Look for competing writers, duplicated authority, or a lifecycle whose transitions are split across owners that cannot enforce the same invariants. A cache, projection, generated artifact, or test fixture is not automatically a competing source of truth. Report only when a reachable path can diverge and the divergence has a concrete consequence.
-
-## Module and dependency direction
-
-Start from a direct consumer and list what it must know about the provider: policy, representation, ordering, failure behavior, configuration, and lifecycle. Look for dependency direction that forces an owner to understand another module's internals, or a boundary that leaks enough decisions to amplify ordinary changes. An import, large module, circular-looking name, or missing interface is not sufficient; establish actual caller burden or invalid-state exposure.
-
-For suspected shallow indirection, reason through removal before calling it redundant. If removal eliminates the apparent complexity, the layer may be pass-through. If required policy, invariants, or failure knowledge instead disperses into callers, the layer may be earning locality. Thinness alone proves neither result; retain a Finding only when the live chain also establishes a reachable trigger and concrete impact.
-
-## Production-path reachability
-
-Trace the smallest complete path from a real entry point to the behavior under examination. For an adapter, validator, normalizer, wrapper, or policy seam, name the direct production caller and its actual callee. Report a bypass only when the live consumer reaches a different path, and distinguish an unused seam from a seam used by another valid entry point. Do not treat API existence, registration, generated code, or an isolated passing test as proof of lifecycle integration.
-
-## Change amplification and repeated knowledge
-
-Use repository history only when it is available and necessary; otherwise trace one representative behavior across schemas, types, adapters, callers, configuration, tests, and documentation. Report amplification when one behavioral change requires independently maintained edits because ownership is fragmented. Similar text, generated output, deliberate boundary translation, and test fixtures are not duplication by themselves. Code reduction is never the objective.
-
-## Verification mismatch
-
-Map focused tests, assertions, or checks to the same production path and public behavior claimed by the implementation. Look for tests that exercise only an isolated seam while the live consumer bypasses it, or verification that cannot observe the relevant state transition or failure contract. Missing tests alone are not a structural finding; establish that existing evidence creates false confidence or leaves a material invariant unverified.
-
-## Finding gate and ranking
-
-Before retaining a finding, answer all of these from repository evidence:
-
-1. What exact entry point, owner, caller, or artifact anchors it?
-2. What reachable condition triggers the problem?
-3. What realistic user, operator, data, or change-cost impact follows?
-4. Which evidence confirms the full chain, and what remains unobserved?
-5. What is the smallest next owner: a user decision, shaping question, or one bounded design question?
-
-Discard the finding when any of the first three answers is speculative. Rank retained findings by impact and confidence, not ease of cleanup. Use P1 for a normal-path structural failure with significant correctness or data consequences, P2 for a meaningful edge or recurring change risk, and P3 only for a narrow actionable maintenance risk. Do not emit P0 from this general structural audit; route suspected critical security, safety, or data-loss work to the appropriate specialist or incident owner.

package/skills/rsp-tdd/SKILL.md

@@ -1,56 +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.08.17.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 and 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.
-
-## Admit the behavior and test seam
-
-Before RED, confirm that the selected Change, Spec, or project authority owns the observable behavior and that a real production path can reach the proposed seam. Name the consequence, one distinct plausible regression, why existing evidence misses it, and the expected maintenance cost. A test cannot create product authority; an imagined edge state, test-only consumer, wrapper hop, or source-string convention is not sufficient by itself.
-
-If the proposed test would require a new public contract, fallback, compatibility path, or handling for a state the production producer cannot emit, stop for the owning decision instead of encoding the assumption as RED. Explicit user, Change, or project test requirements remain authoritative.
-
-## 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.
-
-Do not widen the product contract merely to satisfy the test. If GREEN requires an unauthorized API, fallback, compatibility behavior, test-only hook, or unreachable-state branch, treat the test premise as invalid or return the missing owner decision; do not mutate production first and rationalize the contract afterward.
-
-## 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.