Merge pull request 'Show Reviewer named skill set in README' (#7) from ISSUE-6 into main

Reviewed-on: #1

.gitea/workflows/check.yml

@@ -12,7 +12,7 @@ jobs:
           github-server-url: https://tea.kyle-merritt.com
       - run: python3 --version
       - run: python3 -m unittest discover -s tests -v
-      - run: python3 -m tools.packages check packages/planner-scope
+      - run: for package in packages/*; do python3 -m tools.packages check "$package"; done
       - run: python3 -m tools.packages check examples/starter-planner
-      - run: python3 -m tools.packages pack packages/planner-scope dist/planner-scope.zip
+      - run: for package in packages/*; do python3 -m tools.packages pack "$package" "dist/${package##*/}.zip"; done
       - run: python3 -m tools.packages pack examples/starter-planner dist/starter-planner.zip

NOTICE.md

@@ -2,6 +2,54 @@
 
 The instruction packages and authoring tools in this repository are licensed under the MIT License in [LICENSE](LICENSE). Include that license and copyright notice when redistributing a package or fork.
 
-This release has no third-party runtime dependencies, vendored assets, or third-party package notices. Python's standard library runs the authoring checks and is not bundled into a skill package.
-
 The RelayView owner, its private prompts, and its separate open trust modules are outside this repository and its MIT grant.
+
+The optional role guidance is written for RelayView from the owner's personal skill collection. Several source skills trace to Matt Pocock's skills at revision `c55ee46073ed923f86ce59a5eb3b6d895095d1b7`; the `c4-diff` source skill traces to Jo Van Eyck's skills at revision `f2de8f7042a5125116ed27627fc7320b73048469`. Their MIT copyright and permission notices are preserved below. No plugin text, code, or assets are redistributed. This release has no third-party runtime dependencies or vendored executable assets. Python's standard library runs the authoring checks and is not bundled into a skill package.
+
+## Matt Pocock source-skill notice
+
+MIT License
+
+Copyright (c) 2026 Matt Pocock
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+
+## Jo Van Eyck source-skill notice
+
+MIT License
+
+Copyright (c) 2026 Jo Van Eyck
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

README.md

@@ -6,10 +6,49 @@ Public source for RelayView-maintained instruction-only role skills and an illus
 
 | Directory | Status | Role / step | Version |
 | --- | --- | --- | --- |
-| `packages/planner-scope` | Maintained default | Planner / planning | 0.1.0 |
+| `packages/planner-scope` | Maintained default | Planner / planning | 0.2.0 |
+| `packages/implementer-handoff` | Maintained default | Implementer / implementation | 0.2.0 |
+| `packages/codebase-design` | Optional guidance | Planner / planning | 0.3.0 |
+| `packages/grill-me` | Optional guidance | Planner / planning | 0.3.0 |
+| `packages/grilling` | Optional guidance | Planner / planning | 0.3.0 |
+| `packages/to-questionnaire` | Optional guidance | Planner / planning | 0.3.0 |
+| `packages/research` | Optional guidance | Planner / planning | 0.3.0 |
+| `packages/improve-codebase-architecture` | Optional guidance | Planner / planning | 0.3.0 |
+| `packages/diagnosing-bugs` | Optional guidance | Implementer / implementation | 0.3.0 |
+| `packages/domain-modeling` | Optional guidance | Implementer / implementation | 0.3.0 |
+| `packages/migrate-to-shoehorn` | Optional guidance | Implementer / implementation | 0.3.0 |
+| `packages/pr` | Optional guidance | Implementer / implementation | 0.3.0 |
+| `packages/prototype` | Optional guidance | Implementer / implementation | 0.3.0 |
+| `packages/scaffold-exercises` | Optional guidance | Implementer / implementation | 0.3.0 |
+| `packages/shared-abstraction-refactor` | Optional guidance | Implementer / implementation | 0.3.0 |
+| `packages/split-large-files` | Optional guidance | Implementer / implementation | 0.3.0 |
+| `packages/tdd` | Optional manual guidance | Implementer / implementation | 0.3.0 |
+| `packages/tdd-auto` | Optional automatic guidance | Implementer / implementation | 0.3.1 |
+| `packages/writing-for-agents` | Optional guidance | Implementer / implementation | 0.3.0 |
+| `packages/code-review` | Optional guidance | Reviewer / review | 0.3.0 |
+| `packages/c4-diff` | Optional guidance | Reviewer / review | 0.3.0 |
 | `examples/starter-planner` | Illustrative starter; not a production default | Planner / planning | 0.1.0 |
 
-Only named releases of maintained defaults receive RelayView compatibility testing and maintenance. User forks are maintained by their publishers. This release uses the instruction package schema version 1 admitted by RelayView's Community MVP. It contains only `SKILL.md`, declared `.md`/`.txt` resources, and `relayview-skill.json` within each package. Scripts, executable files, undeclared files, and requested permissions fail checks and owner admission. There is no fixed release calendar: maintained packages are versioned when their content or compatibility changes. A breaking owner contract requires a new compatible maintained release before the product depends on it.
+Only named releases of maintained packages receive RelayView compatibility testing and maintenance. Optional guidance requires explicit role assignment; the two original defaults remain available. User forks are maintained by their publishers. This release uses the instruction package schema version 1 admitted by RelayView's Community MVP. It contains only `SKILL.md`, declared `.md`/`.txt` resources, and `relayview-skill.json` within each package. Scripts, executable files, undeclared files, and requested permissions fail checks and owner admission. There is no fixed release calendar: maintained packages are versioned when their content or compatibility changes. A breaking owner contract requires a new compatible maintained release before the product depends on it.
+
+## A named set in RelayView
+
+A named set groups admitted packages for one role and workflow step. In **Settings → Skills**, the Reviewer has **Reviewer inspection on request** selected as its manual set. Its saved and effective choices match, so future Reviewer sessions capture these two skills for manual invocation. The automatic selector remains at its configured default, which is empty in this example.
+
+![RelayView Settings Skills Reviewer card with the manual set Reviewer inspection on request saved and effective, containing Code review followed by Component diff](docs/images/reviewer-manual-skill-set.png)
+
+The screenshot's ordered manual members come from this excerpt under `trustedSkills.sets` in the owner configuration. Both member IDs must also be admitted in `trustedSkills.catalog`; defining a set makes it available, while selecting and saving it makes it effective for future sessions.
+
+```yaml
+- id: reviewer-inspection
+  name: Reviewer inspection on request
+  role: reviewer
+  step: review
+  invocationMode: manual
+  members: [code-review, c4-diff]
+```
+
+The two maintained defaults are original RelayView packages. Some optional guidance adapts earlier MIT-licensed skills; see the [third-party notices](NOTICE.md).
 
 ## Fork the starter
 
@@ -21,9 +60,11 @@ python -m tools.packages check examples/starter-planner
 python -m tools.packages pack examples/starter-planner dist/starter-planner.zip
 ```
 
-Replace `examples/starter-planner` in the last two commands with your package directory. The `pack` command writes a reproducible ZIP and prints its SHA-256. The check returns the owner's package identity digest. Both use only Python 3's standard library and this repository's source. Include `LICENSE` and `NOTICE.md` when redistributing the package.
+Replace `examples/starter-planner` in the last two commands with your package directory. The `pack` command writes a reproducible ZIP containing the package, `LICENSE`, and `NOTICE.md`, then prints its SHA-256. The check returns the owner's package identity digest. Both use only Python 3's standard library and this repository's source. Preserve the license and notice when redistributing the package or fork.
 
-To import a user fork, place its closed package directory under the owner's configured trusted root, use Settings → Skills to import the relative `SKILL.md` path under a new unique ID, and assign it to the matching future role step. Saving a new assignment takes effect after owner restart; existing sessions retain their captured bytes. The Settings catalog displays source, version, digest, role, step, and pending versus effective assignment. The owner's admission remains authoritative even when these local checks pass.
+To use a user fork, place its closed package directory under the owner's configured trusted root and use Settings → Skills to import the relative `SKILL.md` path under a new unique ID. Import validates and records the package; it does not assign it. Add that ID to a role-compatible named set in the owner configuration and restart the owner to load the set. Then select the set for the matching role in Settings → Skills and save. That selection takes effect for future sessions immediately; existing sessions retain their captured bytes. The Settings catalog displays source, version, digest, role, step, and pending versus effective assignment. The owner's admission remains authoritative even when these local checks pass.
+
+To use a maintained default, copy its release package under the same trusted root, admit its `SKILL.md` through the owner catalog, then select it for its declared role in Settings. Settings import accepts user-source packages; configure first-party packages in the owner catalog. Select a fork with `source.kind: user` and a distinct ID to replace that role's future assignment. Planner guidance uses existing read and planning tools; Implementer guidance uses existing implementation and reporting tools. Neither selection changes a role's tools, credentials, lifecycle stages, validation requirements, Gitea effects, review, merge, or Human acceptance. The owner keeps the existing Gitea task workflow.
 
 ## Release identity
 

packages/c4-diff/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: c4-diff
+description: Explain structural changes in an owner-pinned code diff with traceable before and after component maps.
+disable-model-invocation: true
+metadata:
+  relayview-display-name: Component diff
+  relayview-version: 0.3.0
+---
+
+# Component diff review
+
+Use only when the assigned review calls for architectural change analysis. Inspect the exact base and candidate commits pinned by the owner. Map changed source components and their immediate neighbors at both versions; treat a rename as a changed component when identity is preserved. Include a node or edge only when a source path and symbol support it. Classify added, removed, changed, and unchanged relationships, and distinguish structural change from call-order or formatting changes.
+
+Return a compact before/after/diff description or Mermaid component diagrams within the review response, with an evidence path for each changed node and edge. If there is no structural change, say so. Do not fetch refs, write diagram artifacts, run the original diagram script, or alter review state. Ask the owner to resolve a missing or ambiguous commit identity.

packages/c4-diff/relayview-skill.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.0"
+  },
+  "role": "reviewer",
+  "step": "review",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "f1746262e65a8a3de9223a8c42a30b354a6718fea3819079cd13597a258da567"
+    }
+  ]
+}

packages/code-review/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: code-review
+description: Review the owner-pinned candidate against repository standards and the admitted Plan on separate evidence axes.
+disable-model-invocation: true
+metadata:
+  relayview-display-name: Code review
+  relayview-version: 0.3.0
+---
+
+# Two-axis code review
+
+Review only the candidate and commit identity supplied by the owner. Keep standards and Plan fidelity separate. For standards, cite the exact repository rule and changed hunk; identify possible design smells as judgment calls, never as rule violations. A documented local standard takes precedence over a general heuristic. For Plan fidelity, identify missing or partial requirements, unrequested behavior, and behavior whose implementation contradicts the accepted Plan. Cite the Plan clause and code evidence for each finding.
+
+Report both axes even if one has no findings. Distinguish evidence, inference, and uncertainty; skip issues already enforced by tooling unless the enforcement itself failed. Do not edit the candidate, create subagents, choose a new base, change the acceptance state, or request a new review run. The owner controls review scheduling, exact-head binding, and the response to findings.

packages/code-review/relayview-skill.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.0"
+  },
+  "role": "reviewer",
+  "step": "review",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "c2b05163e738e59573b96f723d5340f56304299bcdf251e38b2d2afb4eda2b5a"
+    }
+  ]
+}

packages/codebase-design/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: codebase-design
+description: Examine module interfaces and seams while drafting a repository Plan.
+metadata:
+  relayview-display-name: Codebase design
+  relayview-version: 0.3.0
+---
+
+# Codebase design for Planner
+
+Use this guidance while deciding the implementation boundary of an assigned Plan. Read the repository's current architecture, relevant code and tests before proposing a module change. Use the [module guide](module-guide.md) to compare interfaces and identify the smallest seam that can carry the requested behavior.
+
+Describe the existing interface, the behavior hidden behind it, and the caller obligations that a change would add or remove. Compare at least two plausible designs in the Plan when the seam is consequential. Record a recommendation with the trade-off and a testable observation, rather than treating a preferred abstraction as verified behavior.
+
+Submit the result through the assigned planning interface. Keep code edits, branch operations, subagent scheduling, and workflow transitions with their existing owner-controlled roles and stages.

packages/codebase-design/module-guide.md

@@ -0,0 +1,8 @@
+# Module guide
+
+- A module is a unit with an interface and an implementation; its interface includes invariants, ordering, errors, configuration, and performance obligations as well as types.
+- Prefer depth: useful behavior behind a small interface. Assess what callers must learn and where future changes will concentrate.
+- A seam is where the interface lives. Name the dependency that varies there and the concrete adapters that justify it; do not add a speculative port for one fixed implementation.
+- Test proposed behavior through the interface visible to callers. Identify the existing tests that would stay meaningful after an internal refactor.
+- Classify dependencies as in-process, locally substitutable, owned remote, or external before recommending an adapter or verification seam.
+- State what each candidate hides, what it exposes, and how an implementer can prove the selected behavior. A diagram or example may clarify a design, but it is not verification evidence.

packages/codebase-design/relayview-skill.json

@@ -0,0 +1,19 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.0"
+  },
+  "role": "planner",
+  "step": "planning",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "8633b139187c3ba62e75338f3792ef6d7a445559b792cfb4926cb722609c161a"
+    },
+    {
+      "path": "module-guide.md",
+      "sha256": "7bb0fa0d1a54dce4469e0ceedade86e2efe1e4cd11cac6f1276ed7fb6dca06f5"
+    }
+  ]
+}

packages/diagnosing-bugs/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: diagnosing-bugs
+description: Build a reproducible feedback loop before fixing an assigned defect.
+metadata:
+  relayview-display-name: Diagnose bugs
+  relayview-version: 0.3.0
+---
+
+# Diagnose within implementation
+
+Begin with the user's exact symptom and the assigned candidate. Build the smallest runnable check that can fail on that symptom using the Implementer's existing tools and workspace. Run it and preserve the observed red result. If the environment cannot reproduce it, report what was tried and request the missing evidence rather than inventing a cause.
+
+Minimize the reproducer. Rank several falsifiable hypotheses, then vary one cause at a time using bounded instrumentation. Redact credentials and private data from every quoted log. For a performance regression, measure the baseline and the changed path with the same fixture.
+
+At the repository's agreed test seam, turn the reproducer into a regression check, observe failure, apply the smallest fix, and observe success. Rerun the original symptom check, remove temporary instrumentation, and report the confirmed cause and exact checks. Validation and review status remain owner-observed facts; this guidance does not mark a gate complete.

packages/diagnosing-bugs/relayview-skill.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.0"
+  },
+  "role": "implementer",
+  "step": "implementation",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "41c5d0ccb48b19aef95e19103f3c7721b9c3ddf2e8bdf3ff2c429a26853b18ae"
+    }
+  ]
+}

packages/domain-modeling/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: domain-modeling
+description: Reconcile verified domain vocabulary and accepted decisions during implementation.
+metadata:
+  relayview-display-name: Domain modeling
+  relayview-version: 0.3.0
+---
+
+# Domain documentation in implementation
+
+Read the repository's domain glossary and documentation rules before changing a model. When the assigned implementation reveals ambiguous or conflicting terms, compare the proposed meaning with current code, tests, and the accepted Plan. Raise an unresolved decision through the assigned Human communication path; do not turn a guess into an authoritative term.
+
+After a term or consequential design decision is accepted and verified, update the repository's existing glossary or decision record within the assigned worktree. Keep glossary entries about domain meaning rather than implementation mechanics. Record an ADR only for a hard-to-reverse, surprising trade-off whose decision authority and alternatives are known. Keep run-specific test evidence with the issue or review handoff.
+
+This skill changes repository documentation as part of the Implementer's assigned candidate. It does not revise the immutable Plan, create a new workflow checkpoint, or declare review and validation complete.

packages/domain-modeling/relayview-skill.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.0"
+  },
+  "role": "implementer",
+  "step": "implementation",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "8a4d491493655b19feeb799af625ccef1f9064f203f3e38f57ccd7e547c28be6"
+    }
+  ]
+}

packages/grill-me/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: grill-me
+description: Ask one deliberate question at a time to clarify an assigned Plan.
+disable-model-invocation: true
+metadata:
+  relayview-display-name: Grill me
+  relayview-version: 0.3.0
+---
+
+# One-question planning interview
+
+When the Human explicitly invokes this skill during planning, map the unresolved decisions affecting the assigned task. Check the repository and current Plan context for facts before asking. Ask one consequential question at a time, with a recommended answer and its consequence. Wait for the Human's answer before advancing to a dependent question.
+
+Keep a visible list of settled decisions and remaining branches. Stop when the requested scope, important alternatives, and verification expectations are explicit enough for a Plan. Place accepted decisions in the Plan through the assigned planning interface; do not treat an unanswered question as approval. This interview does not start implementation or change an owner workflow stage.

packages/grill-me/relayview-skill.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.0"
+  },
+  "role": "planner",
+  "step": "planning",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "36895ad26a065b073d3d823557d83b62bd7bb771e74e65e4f246f4e08b52bb16"
+    }
+  ]
+}

packages/grilling/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: grilling
+description: Interview a Planner's Human about independent decision branches in rounds.
+disable-model-invocation: true
+metadata:
+  relayview-display-name: Grilling
+  relayview-version: 0.3.0
+---
+
+# Planning decision rounds
+
+When the Human explicitly invokes this skill, draw the decision tree for the assigned Plan. Resolve repository facts with the Planner's assigned read tools. Identify the current frontier: questions whose prerequisites are already settled. Ask that frontier together in one numbered round, giving a recommended answer and consequence for each question. Wait for the Human's answers, update the tree, then recompute the frontier.
+
+Keep dependent questions for later rounds. State when a branch remains unresolved; silence is not a decision. Stop when the frontier is empty and the Human confirms the scope is understood. Record settled requirements and open decisions through the assigned planning interface. Do not launch other agents, edit the repository, or change workflow stages.

packages/grilling/relayview-skill.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.0"
+  },
+  "role": "planner",
+  "step": "planning",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "1c88593633482d44022eac49de217fc16c8f102067549ba819f1b1ca1728307e"
+    }
+  ]
+}

packages/implementer-handoff/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: implementer-handoff
+description: Reconcile verified implementation documentation and prepare review content during implementation.
+metadata:
+  relayview-display-name: Implementer handoff
+  relayview-version: 0.2.0
+---
+
+# Implementer handoff
+
+During the assigned implementation step, keep the repository's current-behavior documentation aligned with the code and checks you actually completed. Read the project's documentation rules and the relevant existing contract before editing it. Use the [handoff guide](handoff.md) for the documentation disposition and review content.
+
+Prepare a concise, attributable review handoff when the assigned workflow gives you a place to submit one. Identify the exact candidate, focused checks and their observed results, any manual evidence and its observer, unresolved limitations, and the documentation disposition. A command attempted is not a check passed; report failures and stale evidence explicitly.
+
+Use only the Implementer's assigned tools and owner interfaces. The owner verifies validation, review, provider effects, and stage readiness; your prose is a report for that process. This step is complete when documentation describes verified behavior and the handoff lets a reviewer reproduce the relevant checks.

packages/implementer-handoff/handoff.md

@@ -0,0 +1,14 @@
+# Handoff guide
+
+## Documentation
+
+- Update the current-behavior contract only for behavior verified on the candidate. Keep proposed work clearly proposed.
+- Record one disposition: `updated`, `not_required` with a concrete reason, `deferred`, or `blocked`.
+- Put run-specific logs, screenshots, and command results in the review handoff, not the enduring contract, unless the contract explicitly depends on one identified run.
+
+## Review content
+
+- Summarize the user-visible change and its bounded impact.
+- Name the candidate revision and the focused checks run against it, with observed pass or failure results.
+- Give a reviewer executable steps and expected observations for any behavior that automated checks cannot establish.
+- State remaining uncertainty and recovery steps. Attribute provider or Human observations to their actual source.

packages/implementer-handoff/relayview-skill.json

@@ -0,0 +1,19 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.2.0"
+  },
+  "role": "implementer",
+  "step": "implementation",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "bfeafa2d7780fe2c0bb4206ab9a03acd12804347ceb0f3ffb3e06e1be514c852"
+    },
+    {
+      "path": "handoff.md",
+      "sha256": "303c3e792cf0e8da6215e6eeb69f5a2f1f2bd0b67db016160d9e83a970ad95d3"
+    }
+  ]
+}

packages/improve-codebase-architecture/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: improve-codebase-architecture
+description: Assess assigned module-deepening opportunities as read-only planning options with evidence and tradeoffs.
+disable-model-invocation: true
+metadata:
+  relayview-display-name: Architecture opportunities
+  relayview-version: 0.3.0
+---
+
+# Architecture opportunity assessment
+
+Use when the planning assignment asks for a bounded architecture assessment. Read the target's domain vocabulary, applicable decisions, and relevant source. Identify where an interface exposes too much complexity, where behavior that changes together has been scattered, or where a module seam makes verification difficult. Apply the deletion test: would removing an apparent abstraction concentrate complexity rather than merely move it?
+
+For each candidate, cite the affected files, current friction, proposed responsibility boundary, effect on locality and test seams, conflict with any existing decision, and a confidence level. Prefer recently active or explicitly named areas. Present options in the planning response and leave unresolved interface choices explicit. Do not spawn exploration agents, generate or open an HTML report, edit domain documents, or initiate a follow-up interview; the owner governs those activities.

packages/improve-codebase-architecture/relayview-skill.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.0"
+  },
+  "role": "planner",
+  "step": "planning",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "07b2c9f88207a541c493c85fe7faa6d4b3d04eadbcf7ab592f9e5a4187692ee9"
+    }
+  ]
+}

packages/migrate-to-shoehorn/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: migrate-to-shoehorn
+description: Replace suitable TypeScript test assertions with an admitted partial-fixture helper.
+disable-model-invocation: true
+metadata:
+  relayview-display-name: Migrate to shoehorn
+  relayview-version: 0.3.0
+---
+
+# TypeScript test fixture migration
+
+Use this procedure only for an assigned change to TypeScript tests. Inspect the affected assertions and the project's dependency policy before editing. If `@total-typescript/shoehorn` is not installed, use the Implementer's admitted dependency-acquisition path; if that path is unavailable, report the missing prerequisite. Do not install through an unapproved network command.
+
+Replace a partial object assertion with `fromPartial` when the supplied properties should still type-check. Use `fromAny` only for an intentional invalid-input test, and make that purpose visible in the test. Preserve complete fixtures when they express the behavior better. Keep production code free of the helper.
+
+Run focused tests and type checking on the changed test area. State which assertions changed and whether the tests still exercise the intended failure and success paths. This migration does not weaken a behavior contract or count as owner-verified validation by itself.

packages/migrate-to-shoehorn/relayview-skill.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.0"
+  },
+  "role": "implementer",
+  "step": "implementation",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "56b0d3f5ea1cbf8603201d4f5563e6f582561fe58c5679ed428dc7c29d31e461"
+    }
+  ]
+}

packages/planner-scope/SKILL.md

@@ -1,13 +1,15 @@
 ---
 name: planner-scope
-description: Check a Planner's issue scope and evidence before drafting a Plan.
+description: Check assigned issue scope, neighboring work, and verification before drafting a Plan.
 metadata:
   relayview-display-name: Planner scope
-  relayview-version: 0.1.0
+  relayview-version: 0.2.0
 ---
 
 # Planner scope
 
-When drafting the assigned Plan, identify the requested behavior, its boundary, dependencies, and the evidence needed to verify it. Read the task's authoritative project context and relevant neighboring work before deciding scope. Use the [scope guide](scope.md) to keep assumptions and open decisions visible in the Plan.
+When drafting the assigned Plan, identify the requested behavior, its boundary, dependencies, and the evidence needed to verify it. Read the task's authoritative project context, corresponding code and tests, and relevant neighboring work before deciding scope. Use the [scope guide](scope.md) to keep assumptions and open decisions visible in the Plan.
 
-Work within the Planner's assigned tools and read access. Send the Plan through the owner's existing planning interface. Instructions here provide guidance; owner-controlled workflow stages and checks remain the source of execution authority.
+If the owner supplies an admitted work-item identity, use the assigned read tools to inspect it. Preserve source attribution; an issue description is a request, not evidence that its proposed behavior exists. Where tracker access is unavailable, state the missing context instead of guessing a work-item identity.
+
+Write the Plan through the owner's assigned planning interface. The Plan is ready when each requested outcome has an implementation boundary and a checkable success or recovery observation. Owner-controlled workflow stages and checks determine execution authority.

packages/planner-scope/relayview-skill.json

@@ -2,18 +2,18 @@
   "schemaVersion": 1,
   "source": {
     "kind": "first-party",
-    "reference": "v0.1.0"
+    "reference": "v0.2.0"
   },
   "role": "planner",
   "step": "planning",
   "files": [
     {
       "path": "SKILL.md",
-      "sha256": "5c52e8c6183472c03f039475c6df9ce1fadf7aecd06a846ad74d7a741f5f95e0"
+      "sha256": "31399ba322d8a4d3ed9814e7fd5d54883b4773c5b7dc3a241b8e14f8f7c16072"
     },
     {
       "path": "scope.md",
-      "sha256": "a59376ba22a7c1eacf5af03533908badb36a00154adc894b5454bf4dbcb850ec"
+      "sha256": "fc365d5f5c90f878992204235f32b1148aa4934a31f8c10eb063292fb64cf248"
     }
   ]
 }

packages/planner-scope/scope.md

@@ -2,6 +2,7 @@
 
 - State the user-visible outcome and the exact part of the system affected.
 - Name prerequisites and neighboring work that change the boundary.
+- Cite the current contract, code, or test that supports each existing-behavior claim.
 - Distinguish verified current behavior from a proposal.
 - Identify one observable success path and one meaningful failure or recovery path.
 - Record uncertainty as an open decision; do not turn silence into approval.

packages/pr/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: pr
+description: Prepare a reviewable pull-request description for an implemented candidate.
+disable-model-invocation: true
+metadata:
+  relayview-display-name: PR content
+  relayview-version: 0.3.0
+---
+
+# Prepare review content
+
+When the assigned implementation needs a pull-request description, draft text from the current candidate and evidence actually observed. Give the reviewer the behavioral summary, exact candidate revision, focused checks and their outcomes, documentation disposition, material risk, and repeatable manual observations where automation cannot prove behavior. Link to source files or artifacts whose identity you verified.
+
+State failures, limitations, and stale checks plainly. Attribute Human and provider observations to their actual observer; do not present model prose as gate evidence. Keep reviewer commands runnable in the repository's documented shell, with concrete paths or a precise way to discover a missing value.
+
+Deliver the draft through the assigned Implementer report or communication path. PR creation, remote comments, review decisions, publication, and merge remain owner-managed operations unless separately authorized by that workflow.

packages/pr/relayview-skill.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.0"
+  },
+  "role": "implementer",
+  "step": "implementation",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "86f5c76f96b1f7a4258d21ecd0aeb9ee39cf95fb45eb90e2ee6b172ca460e47a"
+    }
+  ]
+}

packages/prototype/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: prototype
+description: Build a disposable local prototype to answer one implementation question.
+disable-model-invocation: true
+metadata:
+  relayview-display-name: Prototype
+  relayview-version: 0.3.0
+---
+
+# Bounded implementation prototype
+
+Name one question the assigned implementation cannot settle by inspection alone: a state transition, algorithm, or visual interaction. Make a small disposable prototype inside the owner-assigned worktree using tools already admitted to the Implementer. Use local fixtures and avoid external services unless the task's existing environment admits them. Make the relevant state or variant visible so the answer can be observed.
+
+Run a small set of cases that could disprove the idea. Record the question, setup, observations, and resulting choice in the implementation handoff. Move only validated behavior into the real candidate and remove disposable scaffolding before reporting a clean candidate. If the prototype itself needs to remain as evidence, request an owner-managed artifact path; do not create or switch Git branches or publish a separate worktree from this skill.

packages/prototype/relayview-skill.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.0"
+  },
+  "role": "implementer",
+  "step": "implementation",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "319fe249629788f51b3c8738ded5a1c88336534ad96fa43e7c80a554f09ef586"
+    }
+  ]
+}

packages/research/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: research
+description: Ground assigned planning questions in traceable primary sources using only admitted read tools.
+disable-model-invocation: true
+metadata:
+  relayview-display-name: Primary-source research
+  relayview-version: 0.3.0
+---
+
+# Primary-source research
+
+Use for a research question assigned within the planning step. Start with the repository's authoritative documents and source. For external facts, use only read or research tools that the owner has admitted to this session and respect their budget and egress policy. Prefer the official specification, documentation, or source repository that owns a claim. Record a source location and the observed version or date when behavior may change; label inferences and unresolved facts.
+
+Put concise findings and citations in the planning response so the Plan can use them. Do not spawn a background agent, save a research file, fetch through an unassigned channel, or treat research as an owner-approved design decision. If evidence cannot be obtained within the assigned access, state the gap.

packages/research/relayview-skill.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.0"
+  },
+  "role": "planner",
+  "step": "planning",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "78a832c0bae3d3829afcf78c5cee19a08f0a624e0775b29db5e33c038b725d53"
+    }
+  ]
+}

packages/scaffold-exercises/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: scaffold-exercises
+description: Build exercise stubs in an assigned course repository using its local structure.
+disable-model-invocation: true
+metadata:
+  relayview-display-name: Scaffold exercises
+  relayview-version: 0.3.0
+---
+
+# Exercise scaffolding
+
+Use this skill only when the assigned repository is an exercise course and the Plan calls for new sections or exercises. Read that repository's naming, variant, and lint rules before creating files. Map each requested exercise to its numbered section and variant folders, such as problem, solution, or explainer, using the existing convention. Give every created variant a meaningful nonempty readme; add code files only when the variant needs them.
+
+Create or rename files within the owner-assigned implementation worktree. Run the repository's focused exercise linter and any checks named by the Plan, then correct failures. Report the created structure and observed checks. Do not assume the example `ai-hero-cli` command applies to another repository, and do not publish, merge, or change issue state through this skill.

packages/scaffold-exercises/relayview-skill.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.0"
+  },
+  "role": "implementer",
+  "step": "implementation",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "a2714d0a09f737b48e8f581f21a5cd7f9ab946e8dca072cfc813ef61c3f1dc18"
+    }
+  ]
+}

packages/shared-abstraction-refactor/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: shared-abstraction-refactor
+description: Find stable repeated patterns in the assigned implementation scope and promote only justified shared abstractions.
+disable-model-invocation: true
+metadata:
+  relayview-display-name: Shared abstraction refactor
+  relayview-version: 0.3.0
+---
+
+# Shared abstraction refactor
+
+Use when the assigned Plan calls for a bounded duplication scan or refactor. Read the relevant repository guidance and existing shared surfaces. Search the target paths first, then compare representative uses to determine whether they carry the same meaning. Classify each candidate as reuse an existing abstraction, promote a new one, leave local, or defer.
+
+For an implementation assignment, move only a stable shared concept with a specific name and clear ownership. Update its callers and focused tests, then run the checks required by the Plan. For a scan assignment, return candidates and evidence without editing. Do not widen the assigned scope or create a generic `utils`, `common`, or `misc` bucket merely to remove repeated lines.

packages/shared-abstraction-refactor/relayview-skill.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.0"
+  },
+  "role": "implementer",
+  "step": "implementation",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "a7906eb68c07ac53cf74525ba02984056c78f205fc6815049959c150c0b1a188"
+    }
+  ]
+}

packages/split-large-files/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: split-large-files
+description: Split assigned oversized files along cohesive responsibilities while preserving their public interface.
+disable-model-invocation: true
+metadata:
+  relayview-display-name: Split large files
+  relayview-version: 0.3.0
+---
+
+# Split large files
+
+Use only for the file or subsystem named by the Plan. Map its responsibilities, public interface, related tests, and the symbols that are commonly changed together. Propose a split only when descriptive file names would help a human locate those responsibilities more than the extra imports and cross-file hops would hurt locality. A line count alone is insufficient.
+
+For each proposed extraction, identify its responsibility, new path, moved symbols, import direction, circular-dependency risk, and the existing caller path. Keep cohesive behavior together. Avoid arbitrary line cuts, equal-size partitions, one-file-per-function layouts, and vague utility buckets.
+
+When the Plan authorizes implementation, preserve the existing public interface and import paths unless it explicitly calls for an interface change. Move the approved responsibilities, adjust callers and tests, and run focused verification. If the requested boundary is ambiguous, report the proposed map to the owner rather than expanding the assignment.

packages/split-large-files/relayview-skill.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.0"
+  },
+  "role": "implementer",
+  "step": "implementation",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "6cca9cdf43e97778b9ea763d0f7f9faed575583150cdbe88796072c78f8c685b"
+    }
+  ]
+}

packages/tdd-auto/SKILL.md

@@ -0,0 +1,13 @@
+---
+name: tdd-auto
+description: Test-driven development for an assigned implementation Plan; use red, green, and focused verification at its agreed test seams.
+metadata:
+  relayview-display-name: Test-driven development
+  relayview-version: 0.3.1
+---
+
+# Test-driven development
+
+Use the test seams and behavior specified by the immutable Plan. Read the target repository's domain language and test conventions. If the Plan leaves a consequential seam unclear, report that gap to the owner; do not create a new acceptance boundary by silently choosing one.
+
+At each seam, write one test that fails for the missing behavior and observe the failure. Implement the smallest production slice that makes it pass. Repeat for the next behavior, then run the focused checks required by the Plan. Assert observable behavior through public interfaces, using expected values independent of the implementation. Avoid private-method assertions, tautological expectations, and a batch of tests for behavior not yet explored. Record the red and green evidence in the implementation handoff.

packages/tdd-auto/relayview-skill.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.1"
+  },
+  "role": "implementer",
+  "step": "implementation",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "cf4f0cd039dc283caabc3238e3d084c2d59a3f8c8ba030595e9ea80e2b1338e6"
+    }
+  ]
+}

packages/tdd/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: tdd
+description: Implement an assigned behavior at the Plan's agreed test seam using red, green, and focused verification.
+disable-model-invocation: true
+metadata:
+  relayview-display-name: Test-driven development
+  relayview-version: 0.3.0
+---
+
+# Test-driven development
+
+Use the test seams and behavior specified by the immutable Plan. Read the target repository's domain language and test conventions. If the Plan leaves a consequential seam unclear, report that gap to the owner; do not create a new acceptance boundary by silently choosing one.
+
+At each seam, write one test that fails for the missing behavior and observe the failure. Implement the smallest production slice that makes it pass. Repeat for the next behavior, then run the focused checks required by the Plan. Assert observable behavior through public interfaces, using expected values independent of the implementation. Avoid private-method assertions, tautological expectations, and a batch of tests for behavior not yet explored. Record the red and green evidence in the implementation handoff.

packages/tdd/relayview-skill.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.0"
+  },
+  "role": "implementer",
+  "step": "implementation",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "ab633f2670c8d9027301fa985b048ad469b086ed74b1659df8955f2eab9b3a9c"
+    }
+  ]
+}

packages/to-questionnaire/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: to-questionnaire
+description: Draft questions for an outside expert when the assigned Plan needs missing facts.
+disable-model-invocation: true
+metadata:
+  relayview-display-name: Planning questionnaire
+  relayview-version: 0.3.0
+---
+
+# Planning questionnaire
+
+When the Human explicitly invokes this skill, identify the facts or decisions the assigned Plan cannot resolve from the repository or admitted sources. Ask who can supply the missing knowledge and what decision their answer will support. Draft a concise questionnaire in the Planner conversation for the Human to send through their chosen channel.
+
+Put the highest-value questions first. Give each question one topic and enough context for an outside recipient to answer without seeing the task history. Include a place to state uncertainty or partial answers. Record the unanswered items as open Plan decisions; incorporate answers only after the Human provides them. Drafting the text neither sends it nor advances the workflow.

packages/to-questionnaire/relayview-skill.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.0"
+  },
+  "role": "planner",
+  "step": "planning",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "1ccb2b78ffade9faec27b83427a0e3d8fa7f54109b436578f1d79e0ac22d4fe5"
+    }
+  ]
+}

packages/writing-for-agents/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: writing-for-agents
+description: Write assigned agent-facing repository guidance with precise triggers, scope, and verification.
+disable-model-invocation: true
+metadata:
+  relayview-display-name: Writing for agents
+  relayview-version: 0.3.0
+---
+
+# Writing for agents
+
+Use when the Plan assigns an edit to a repository skill, `AGENTS.md`, or another agent-facing document. Inspect the existing instruction hierarchy and the target document's readers before editing. Keep each pointer short: state what document it leads to and the distinct conditions that require reading it. Put detailed instructions in the target document rather than repeating them in every pointer.
+
+State the agent's allowed decision, required inputs, observable output, and escalation condition. Use concrete paths and examples only when they are stable in the assigned repository. Keep rules at the narrowest scope that reaches every intended reader; avoid contradictory duplicates. Check that each imperative can be followed with the role's actual tools and permissions. For RelayView skill packages, keep the package instruction-only and single-role; never use text to grant tools, credentials, workflow transitions, or another role's authority. Run the relevant validation and report any instruction conflict to the owner.

packages/writing-for-agents/relayview-skill.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.3.0"
+  },
+  "role": "implementer",
+  "step": "implementation",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "3a2fd1e3253a7373648f333456d1383c161203467ed89526a8129639806f377e"
+    }
+  ]
+}

tests/test_packages.py

@@ -3,6 +3,7 @@ import hashlib
 import shutil
 import tempfile
 import unittest
+import zipfile
 from pathlib import Path
 
 from tools.packages import PackageError, check_package, package_archive
@@ -11,14 +12,78 @@ ROOT = Path(__file__).resolve().parents[1]
 
 
 class PackageTests(unittest.TestCase):
+    def test_tdd_is_available_to_owner_started_implementers(self):
+        package = ROOT / "packages/tdd-auto"
+        skill = (package / "SKILL.md").read_text()
+        frontmatter = skill.split("---", 2)[1]
+        self.assertIn("name: tdd-auto", frontmatter)
+        self.assertNotIn("disable-model-invocation: true", frontmatter)
+        self.assertIn("relayview-version: 0.3.1", frontmatter)
+        manifest = json.loads((package / "relayview-skill.json").read_text())
+        self.assertEqual(manifest["source"], {"kind": "first-party", "reference": "v0.3.1"})
+        check_package(package)
+        self.assertIn("disable-model-invocation: true", (ROOT / "packages/tdd/SKILL.md").read_text())
+
+    def test_migrated_role_guidance_has_one_declared_role_step(self):
+        expected = {"codebase-design": ("planner", "planning"), "grill-me": ("planner", "planning"),
+                    "grilling": ("planner", "planning"), "to-questionnaire": ("planner", "planning"),
+                    "diagnosing-bugs": ("implementer", "implementation"),
+                    "domain-modeling": ("implementer", "implementation"),
+                    "migrate-to-shoehorn": ("implementer", "implementation"),
+                    "pr": ("implementer", "implementation"), "prototype": ("implementer", "implementation"),
+                    "scaffold-exercises": ("implementer", "implementation"),
+                    "shared-abstraction-refactor": ("implementer", "implementation"),
+                    "split-large-files": ("implementer", "implementation"),
+                    "tdd": ("implementer", "implementation"),
+                    "writing-for-agents": ("implementer", "implementation"),
+                    "code-review": ("reviewer", "review"),
+                    "c4-diff": ("reviewer", "review"),
+                    "research": ("planner", "planning"),
+                    "improve-codebase-architecture": ("planner", "planning")}
+        for name, role_step in expected.items():
+            with self.subTest(name=name):
+                package = ROOT / "packages" / name
+                manifest = json.loads((package / "relayview-skill.json").read_text())
+                self.assertEqual((manifest["role"], manifest["step"]), role_step)
+                check_package(package)
+
     def test_release_package_and_starter_are_valid(self):
-        for path in (ROOT / "packages/planner-scope", ROOT / "examples/starter-planner"):
+        for path in sorted((ROOT / "packages").iterdir()) + [ROOT / "examples/starter-planner"]:
             check_package(path)
             with tempfile.TemporaryDirectory() as directory:
                 first = package_archive(path, Path(directory) / "one.zip")
                 second = package_archive(path, Path(directory) / "two.zip")
                 self.assertEqual(first, second)
 
+    def test_maintained_guidance_covers_distinct_role_steps(self):
+        expected = {
+            "planner-scope": ("planner", "planning", "scope.md", "Plan"),
+            "implementer-handoff": ("implementer", "implementation", "handoff.md", "documentation"),
+        }
+        for name, (role, step, resource, marker) in expected.items():
+            with self.subTest(name=name):
+                package = ROOT / "packages" / name
+                manifest = json.loads((package / "relayview-skill.json").read_text())
+                self.assertEqual((manifest["role"], manifest["step"]), (role, step))
+                self.assertEqual(manifest["source"], {"kind": "first-party", "reference": "v0.2.0"})
+                self.assertIn(resource, [item["path"] for item in manifest["files"]])
+                self.assertIn(marker, (package / "SKILL.md").read_text() + (package / resource).read_text())
+
+    def test_user_fork_is_distinct_under_same_role_limits(self):
+        with tempfile.TemporaryDirectory() as directory:
+            package = Path(directory) / "implementer-handoff"
+            shutil.copytree(ROOT / "packages/implementer-handoff", package)
+            original = check_package(package)
+            resource = package / "handoff.md"
+            resource.write_text(resource.read_text() + "\n- Prefer the team's concise PR summary format.\n")
+            manifest_path = package / "relayview-skill.json"
+            manifest = json.loads(manifest_path.read_text())
+            manifest["source"] = {"kind": "user", "reference": "team-fork-1"}
+            next(item for item in manifest["files"] if item["path"] == "handoff.md")["sha256"] = hashlib.sha256(resource.read_bytes()).hexdigest()
+            manifest_path.write_text(json.dumps(manifest))
+            self.assertNotEqual(check_package(package), original)
+            self.assertEqual((manifest["role"], manifest["step"]), ("implementer", "implementation"))
+
     def test_rejects_scripts_and_undeclared_files(self):
         with tempfile.TemporaryDirectory() as directory:
             package = Path(directory) / "planner-scope"
@@ -70,6 +135,31 @@ class PackageTests(unittest.TestCase):
             with self.assertRaises(PackageError):
                 check_package(package)
 
+    def test_rejects_owner_incompatible_frontmatter_values(self):
+        for old, new in (
+            ("metadata:\n", "disable-model-invocation: yes\nmetadata:\n"),
+            ("description: Check assigned issue scope, neighboring work, and verification before drafting a Plan.", "description: "),
+        ):
+            with self.subTest(new=new), tempfile.TemporaryDirectory() as directory:
+                package = Path(directory) / "planner-scope"
+                shutil.copytree(ROOT / "packages/planner-scope", package)
+                skill = package / "SKILL.md"
+                skill.write_text(skill.read_text().replace(old, new))
+                manifest = package / "relayview-skill.json"
+                data = json.loads(manifest.read_text())
+                next(item for item in data["files"] if item["path"] == "SKILL.md")["sha256"] = hashlib.sha256(skill.read_bytes()).hexdigest()
+                manifest.write_text(json.dumps(data))
+                with self.assertRaises(PackageError):
+                    check_package(package)
+
+    def test_archive_carries_license_and_notice(self):
+        with tempfile.TemporaryDirectory() as directory:
+            archive_path = Path(directory) / "planner-scope.zip"
+            package_archive(ROOT / "packages/planner-scope", archive_path)
+            with zipfile.ZipFile(archive_path) as archive:
+                self.assertEqual(archive.read("LICENSE"), (ROOT / "LICENSE").read_bytes())
+                self.assertEqual(archive.read("NOTICE.md"), (ROOT / "NOTICE.md").read_bytes())
+
 
 if __name__ == "__main__":
     unittest.main()

tools/packages.py

@@ -117,9 +117,17 @@ def check_package(path):
             _fail(f"{path}: unsupported skill metadata")
     if len(top_keys) != len(set(top_keys)) or set(top_keys) - {"name", "description", "metadata", "disable-model-invocation"} or len(nested_keys) != len(set(nested_keys)) or set(nested_keys) != {"relayview-display-name", "relayview-version"}:
         _fail(f"{path}: unsupported skill metadata")
+    values = dict(line.split(": ", 1) for line in frontmatter.splitlines() if not line.startswith("  ") and ": " in line)
+    if "disable-model-invocation" in values and values["disable-model-invocation"] not in ("true", "false"):
+        _fail(f"{path}: disable-model-invocation must be a boolean")
     expected_name = path.name
     if not re.search(rf"(?m)^name: {re.escape(expected_name)}$", frontmatter) or not re.search(r"(?m)^description: .+$", frontmatter) or not re.search(r"(?m)^  relayview-display-name: .+$", frontmatter) or not re.search(r"(?m)^  relayview-version: [0-9]+\.[0-9]+\.[0-9]+$", frontmatter):
         _fail(f"{path}: missing or incompatible skill metadata")
+    if not re.fullmatch(r"[a-z0-9]+(?:-[a-z0-9]+)*", expected_name) or len(expected_name) > 64 or len(values["description"]) > 1024:
+        _fail(f"{path}: skill name or description exceeds owner bounds")
+    display_name = next(line.split(": ", 1)[1] for line in frontmatter.splitlines() if line.startswith("  relayview-display-name: "))
+    if len(display_name) > 128:
+        _fail(f"{path}: display name exceeds owner bounds")
     digest = hashlib.sha256(b"relayview-instruction-package-v1\0" + _frame(raw_manifest))
     for name in sorted(declared):
         digest.update(_frame(name.encode("utf-8")))
@@ -132,12 +140,13 @@ def package_archive(path, destination):
     check_package(path)
     destination.parent.mkdir(parents=True, exist_ok=True)
     with zipfile.ZipFile(destination, "w", compression=zipfile.ZIP_STORED) as archive:
-        for file in sorted(path.rglob("*")):
-            if file.is_file():
-                name = f"{path.name}/{file.relative_to(path).as_posix()}"
-                info = zipfile.ZipInfo(name, date_time=(1980, 1, 1, 0, 0, 0))
-                info.external_attr = 0o100644 << 16
-                archive.writestr(info, file.read_bytes())
+        root = Path(__file__).resolve().parents[1]
+        files = [(name, root / name) for name in ("LICENSE", "NOTICE.md")]
+        files += [(f"{path.name}/{file.relative_to(path).as_posix()}", file) for file in sorted(path.rglob("*")) if file.is_file()]
+        for name, file in files:
+            info = zipfile.ZipInfo(name, date_time=(1980, 1, 1, 0, 0, 0))
+            info.external_attr = 0o100644 << 16
+            archive.writestr(info, file.read_bytes())
     return hashlib.sha256(destination.read_bytes()).hexdigest()