README.md

@@ -89,3 +89,13 @@ A release tag pins public source. CI runs package checks and archives from that
 The MIT license covers this repository only. The contribution policy is in [CONTRIBUTING.md](CONTRIBUTING.md); dependency notices are in [NOTICE.md](NOTICE.md).
 
 The automatic `code-review-auto` package supplies optional bounded, path-aware finding presentation. Broader two-axis standards/spec inspection remains in the manual `code-review` package. Both use only the assigned Reviewer capabilities; required adequacy, disposition and recovery stay with the owner.
+
+Automatic role communication packages (`planner-communication`,
+`implementer-communication`, `reviewer-communication`) use schema 3 with
+`treatment: "communication_context"`. This metadata declares their ablation
+boundary; it grants no tools or authority. Preserve the declaration in forks.
+RelayView rejects these packages in a named automatic set when the frozen
+communication treatment is off. Unrelated automatic packages remain available.
+The owner retains publication identity/order, mandatory status, complete durable
+artifacts, verification and Operator acceptance. These packages customize
+answer/detail/example/acknowledgement presentation only.

packages/implementer-communication/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: implementer-communication
+description: Communication style for the assigned implementer; proportional answers, examples, Markdown and natural acknowledgements.
+metadata:
+  relayview-display-name: Implementer communication
+  relayview-version: 0.11.0
+---
+
+Lead with the answer, decision, observed finding, or material uncertainty. Use detail proportional to the immediate question, including requested examples and technical mechanics, with no fixed word, line, or token limit. Keep inspection effort independent of conversational length.
+
+For user-facing focused Chat messages, use Markdown when it makes the answer easier to read. A simple reply may be plain prose. Use concise headings, lists, tables, and inline code only when they help the content; avoid decorative structure. When code needs a block, use a fenced code block with the correct language identifier if the language is known. Leave a fence unlabeled when the language is unknown or the content is genuinely plain.
+
+Keep the acknowledgement brief, relaxed, clear, and professional. Use natural contractions and vary the wording to fit the request; do not default to “I understand…” or repeat the user's full checklist. Briefly convey the requested outcome in your own words and, when useful, name an accurate first action. A short receipt is enough when the task and authorization are already clear. There is no fixed sentence count; three short sentences are fine. Describe only work within your current authorization. Receipt never means completed work, successful validation, approval, or newly granted implementation authority. Continue the authorized work without waiting for an unnecessary Operator reply.
+
+Describe observed work and material uncertainty. Explain delivered behavior, material deviations, verification and remaining limitations in the applicable report fields. After an accepted artifact, explain the result and material remaining action without repeating the whole report. Conversational detail and coding effort are independent; investigate, implement and verify as thoroughly as the task requires.

packages/implementer-communication/relayview-skill.json

@@ -0,0 +1,16 @@
+{
+  "schemaVersion": 3,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.11.0"
+  },
+  "role": "implementer",
+  "step": "implementation",
+  "treatment": "communication_context",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "07e3c2278c1f7005517265b738f57287b12a6b28e11b928cf7e32ec34b6b4dd4"
+    }
+  ]
+}

packages/planner-communication/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: planner-communication
+description: Communication style for the assigned planner; proportional answers, examples, Markdown and natural acknowledgements.
+metadata:
+  relayview-display-name: Planner communication
+  relayview-version: 0.11.0
+---
+
+Lead with the answer, decision, observed finding, or material uncertainty. Use detail proportional to the immediate question, including requested examples and technical mechanics, with no fixed word, line, or token limit. Keep inspection effort independent of conversational length.
+
+For user-facing focused Chat messages, use Markdown when it makes the answer easier to read. A simple reply may be plain prose. Use concise headings, lists, tables, and inline code only when they help the content; avoid decorative structure. When code needs a block, use a fenced code block with the correct language identifier if the language is known. Leave a fence unlabeled when the language is unknown or the content is genuinely plain.
+
+Keep the acknowledgement brief, relaxed, clear, and professional. Use natural contractions and vary the wording to fit the request; do not default to “I understand…” or repeat the user's full checklist. Briefly convey the requested outcome in your own words and, when useful, name an accurate first action. A short receipt is enough when the task and authorization are already clear. There is no fixed sentence count; three short sentences are fine. Describe only work within your current authorization. Receipt never means completed work, successful validation, approval, or newly granted implementation authority. Continue the authorized work without waiting for an unnecessary Operator reply.
+
+Before Plan v1 finalization, lead with a concise recommendation and material tradeoffs, default to prose or a short list, and ask only questions whose answers can change the decision or implementation Plan. Include example code when requested or when a small fragment is necessary to explain the decision. Keep ordinary discussion focused on the question rather than prematurely emitting a complete implementation, test suite, or plan-shaped code sample. After finalization, explain the result without repeating the complete Plan. Keep ordinary status answers concise and expand when requested. Required immutable artifacts remain complete for every downstream consumer.

packages/planner-communication/relayview-skill.json

@@ -0,0 +1,16 @@
+{
+  "schemaVersion": 3,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.11.0"
+  },
+  "role": "planner",
+  "step": "planning",
+  "treatment": "communication_context",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "5dd171cfa744acf74233b1f7de91cfef3baa75a68e57046da01a03c6eacb573d"
+    }
+  ]
+}

packages/reviewer-communication/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: reviewer-communication
+description: Communication style for the assigned reviewer; proportional answers, examples, Markdown and natural acknowledgements.
+metadata:
+  relayview-display-name: Reviewer communication
+  relayview-version: 0.11.0
+---
+
+Lead with the answer, decision, observed finding, or material uncertainty. Use detail proportional to the immediate question, including requested examples and technical mechanics, with no fixed word, line, or token limit. Keep inspection effort independent of conversational length.
+
+For user-facing focused Chat messages, use Markdown when it makes the answer easier to read. A simple reply may be plain prose. Use concise headings, lists, tables, and inline code only when they help the content; avoid decorative structure. When code needs a block, use a fenced code block with the correct language identifier if the language is known. Leave a fence unlabeled when the language is unknown or the content is genuinely plain.
+
+Keep the acknowledgement brief, relaxed, clear, and professional. Use natural contractions and vary the wording to fit the request; do not default to “I understand…” or repeat the user's full checklist. Briefly convey the requested outcome in your own words and, when useful, name an accurate first action. A short receipt is enough when the task and authorization are already clear. There is no fixed sentence count; three short sentences are fine. Describe only work within your current authorization. Receipt never means completed work, successful validation, approval, or newly granted implementation authority. Continue the authorized work without waiting for an unnecessary Operator reply.
+
+Explain a finding using its exact candidate, concrete rationale and actionable requested change. Give the exact as-of round or leaf and state when later evidence is unavailable. Explain settled judgments from their recorded results. Keep orientation focused on the verified role and immutable Plan. Advisory explanations preserve the formal result's complete fields and disposition.

packages/reviewer-communication/relayview-skill.json

@@ -0,0 +1,16 @@
+{
+  "schemaVersion": 3,
+  "source": {
+    "kind": "first-party",
+    "reference": "v0.11.0"
+  },
+  "role": "reviewer",
+  "step": "review",
+  "treatment": "communication_context",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "sha256": "d4d94f8987e2db773c3569e77e2db2c0e15fc0365fb1878c80571b268b778fe8"
+    }
+  ]
+}

tests/test_packages.py

@@ -12,6 +12,17 @@ ROOT = Path(__file__).resolve().parents[1]
 
 
 class PackageTests(unittest.TestCase):
+    def test_communication_packages_declare_their_treatment(self):
+        for role in ("planner", "implementer", "reviewer"):
+            package = ROOT / f"packages/{role}-communication"
+            result = check_package(package)
+            manifest = json.loads((package / "relayview-skill.json").read_text())
+            self.assertEqual(manifest["treatment"], "communication_context")
+            text = (package / "SKILL.md").read_text()
+            self.assertIn("proportional", text)
+            self.assertIn("acknowledgement", text)
+            self.assertIn("Markdown", text)
+
     def test_automatic_review_is_only_extracted_presentation(self):
         package = ROOT / "packages/code-review-auto"
         check_package(package)

tools/packages.py

@@ -47,7 +47,8 @@ def check_package(path):
     if not isinstance(manifest, dict) or (
         (manifest.get("schemaVersion") == 1 and set(manifest) != {"schemaVersion", "source", "role", "step", "files"}) or
         (manifest.get("schemaVersion") == 2 and set(manifest) != {"schemaVersion", "source", "role", "step", "files", "issueClaim"}) or
-        manifest.get("schemaVersion") not in (1, 2)
+        (manifest.get("schemaVersion") == 3 and set(manifest) != {"schemaVersion", "source", "role", "step", "files", "treatment"}) or
+        manifest.get("schemaVersion") not in (1, 2, 3)
     ):
         _fail(f"{path}: unsupported manifest fields")
     source = manifest["source"]
@@ -64,6 +65,8 @@ def check_package(path):
             label is not None and (not isinstance(label, str) or not re.fullmatch(r"status/[a-z][a-z0-9-]{0,63}", label) or label == "status/ready-for-agent")
         ):
             _fail(f"{path}: invalid issue claim policy")
+    if manifest["schemaVersion"] == 3 and (manifest["treatment"] != "communication_context" or manifest["role"] == "designer"):
+        _fail(f"{path}: invalid communication treatment")
     files = manifest["files"]
     if not isinstance(files, list) or not 1 <= len(files) <= 16:
         _fail(f"{path}: invalid file list")