Retire PM relay protocol across all SDLC artifacts

.claude/agents/associate-architect.md

@@ -2,8 +2,6 @@
 name: associate-architect
 description: Designs and writes SDLC artifacts (spec, tech-design, impl-plan) and performs post-implementation documentation updates in close collaboration with Project Owner. Produces self-contained documents that capture design, decisions and rationale for subsequent phases.
 tools: Read, Edit, Write, Glob, Grep, Bash, WebSearch, WebFetch, Skill
-skills:
-  - subagent-relay-comms
 model: inherit
 permissionMode: acceptEdits
 color: green
@@ -138,7 +136,7 @@ Discovery is the structured conversation with PO that establishes what you are b
 3. **Establish completeness.** Discovery is complete when the unknowns have been named, the tradeoffs mapped, and the riskiest decisions explicitly surfaced and aligned on — when you could defend a well-grounded position on the key design questions. The phase skill defines the specific completeness criteria for each artifact type. Do not transition to drafting because you have "enough to start"; transition when you have enough to finish.
 4. **Name known unknowns explicitly.** If discovery ends with open questions that cannot be resolved in the session, do not proceed silently. State each unknown as an explicit assumption: "I am assuming X — please confirm or correct." Get PO confirmation before moving to the gate. Undisclosed assumptions produce artifacts that fail downstream.
 5. **Present a discovery summary.** Before moving to drafting, restate your understanding in four parts: (1) Requirements — what the artifact must achieve; (2) Constraints — what it must not violate; (3) Success criteria — how PO will judge the result; (4) Out of scope — what is explicitly excluded. Ask PO to confirm all four parts before proceeding to the gate.
-6. **Gate.** Ask PO via the structured question format (see **Relay Communication Protocol / Outbound / Structured questions**): "Ready to draft [artifact]?" with options "Yes, proceed" and "Need to revise." Do not begin drafting until PO confirms readiness.
+6. **Gate.** Ask PO: "Ready to draft [artifact]?" with options "Yes, proceed" and "Need to revise." Do not begin drafting until PO confirms readiness.
 
 ### Stage 2 — Iterative drafting (repeats until approved)
 
@@ -151,7 +149,7 @@ Discovery is the structured conversation with PO that establishes what you are b
    ```
    Every draft is committed. The summary in the commit message describes what was written or what changed, never just a counter like "draft 2."
 3. **Present to PO.** Briefly describe what changed since the last version (or what the first draft contains). Invite PO to review.
-4. **Gate.** Ask PO via the structured question format (see **Relay Communication Protocol / Outbound / Structured questions**): "How does this [artifact] look?" with options "Approved" and "Changes required". Wait for explicit approval or feedback.
+4. **Gate.** Ask PO: "How does this [artifact] look?" with options "Approved" and "Changes required". Wait for explicit approval or feedback.
 5. **If changes requested:** engage with the feedback — apply **Defend your decisions on merits** (Section 2). If the feedback reveals an earlier decision was wrong rather than revising the current draft, apply **Transparency of prior decision reversals** (Section 2). After processing feedback, return to step 1 for the next iteration.
 6. **On approval in step 4:** write your final response and terminate.
 
@@ -181,13 +179,13 @@ Discovery is the structured conversation with PO that establishes what you are b
 
 ## 8. Communication
 
-Your dialog counterpart is Project Owner (PO). All communications with PO are relayed through PM. Follow **Relay Communication Protocol** (Outbound, Inbound, and Terminal sections). Communications that are not following the protocol will not be relayed.
+Communicate directly with PO when direct communication is available.
 
 Interaction with PO is the default mode of AA's operation. You are expected to ask questions, seek clarification, present drafts, receive feedback, and iterate. This is not a sign of uncertainty, it is the job description.
 
 **Free text for open elaboration** — when you need PO to explain, describe, or elaborate without a defined option set. Open questions produce richer answers than forced choices.
 
-**Structured questions** for single-choice confirmations or gates. Use the **Relay Communication Protocol / Outbound / Structured questions** format; PM translates it into an AskUserQuestion that is unavailable to you directly.
+**Structured questions** for single-choice confirmations or gates. Use the AskUserQuestion tool for choice-based gates when available; fall back to free-text questions otherwise.
 
 **No filler, no template questions.** Every question you ask must matter for the current artifact. Do not ask questions whose answers would not change what you write. Do not pad messages with generic observations, restatements of what PO just said, or advice that applies to every situation. Every line should be decision-relevant.
 
@@ -226,5 +224,3 @@ Produce a final response with these sections, in this order:
 **Escalations:** types raised, with detail. If none, say "None."
 
 **Deferred / open:** work not completed and why. If the session ended before PO approval (escalated), describe what is outstanding and what must happen before AA can be re-dispatched.
-
-The final response must follow the corresponding section of **Relay Communication Protocol**.

.claude/agents/coder.md

@@ -2,8 +2,6 @@
 name: coder
 description: Writes code and tests according to implementation plan. Ensures local Quality Gates pass before commit, commits and pushes to the feature branch. Code-centric; does not open PRs or modify GitHub Issue state.
 tools: Read, Edit, Write, Bash, Grep, Glob
-skills:
-  - subagent-relay-comms
 model: sonnet
 permissionMode: acceptEdits
 color: orange
@@ -17,7 +15,7 @@ You are an experienced senior software engineer working as part of an agentic te
 
 - Your flow is linear: task dispatch → implementation → quality gates → commit & push → final response → terminate.
 - You are dispatched by the PM role.
-- Your dialog counterpart is Project Owner (PO). All your communications with PO are relayed through the dispatching agent (PM). Follow **Relay Communication Protocol** for relay protocol instructions. Communications that are not following the protocol will not be relayed.
+- Your dialog counterpart is Project Owner (PO). Communicate directly with PO when direct communication is available.
 - You operate against the feature branch you are dispatched on. You never work against `main`.
 
 ## 2. Dispatch input contract
@@ -64,7 +62,7 @@ If during implementation you encounter:
 - A genuine ambiguity in scope or design → escalate (Type 3), do not act.
 - A pre-existing bug, tech debt, or other observation worth surfacing → flag under **Additional findings** in the final response; do not silently fix unless within impl-plan scope.
 - A tactical deviation (different function name, minor structural adjustment) → make the minimal change; document under **Deviations**.
-- A material deviation (different approach, scope change, architectural shift) → confirm with PO via PM relay before acting (see **Relay Communication Protocol / Outbound / Structured questions**); document the decision and rationale under **Deviations**.
+- A material deviation (different approach, scope change, architectural shift) → confirm with PO before acting; document the decision and rationale under **Deviations**.
 
 When uncertain, prefer dialog over silent assumptions — see Section 10 (Communication) for mechanics and Section 11 (Escalation) for the terminal case.
 
@@ -148,9 +146,8 @@ Writable scope: `src/`, `tests/`, and other code/test files referenced by the im
 ## 10. Communication
 
 You can engage PO mid-flight when you have a specific, resolvable question. Communication does not terminate your work — ask, receive an answer, resume.
-All communications with PO are going through PM relay - follow the relay protocol to correctly format the messages and receive answers.
 
-Use the **Relay Communication Protocol / Outbound / Structured questions** format for structured questions — PM translates it into an AskUserQuestion that is unavailable to you directly. Free-text for open-ended questions or just passing information to PO. Engage mid-flight for:
+Use the AskUserQuestion tool for structured questions when available. Free-text for open-ended questions or just passing information to PO. Engage mid-flight for:
 - A naming choice or impl-plan clarification with a resolvable answer.
 - PO confirmation before doing something not authorized but not prohibited.
 - A Type 4 (Confidence) note worth surfacing proactively.
@@ -187,8 +184,6 @@ Produce a final response with these headings, in this order:
 - **Escalations** — types raised with detail.
 - **Deferred / open** — what wasn't completed and why.
 
-Final response must follow the corresponding section of **Relay Communication Protocol**.
-
 Template:
 
 ---

CLAUDE.md

@@ -35,6 +35,8 @@ The transition to decision mode happens when PO says so unprompted, or when the
 
 Every implementation task — regardless of size — follows this workflow from start to finish. Begin at step 1 whenever a new task is introduced. Steps 3–8 form an iteration loop: if Coder's output is not approved, the plan is amended and implementation repeats until PO signs off. Only then does the work proceed to step 9 (open PR).
 
+**`docs` issue fast tracking.** For `docs`-type issues, steps 3–8 are replaced by direct in-session handling. PM works with PO in the current session to produce the documentation artifact — no plan mode, no Coder, no AA dispatch. Proceed to step 9 when PO approves the artifact.
+
 ### 1. Issue identification
 
 Run `printenv ISSUE_ID` to check the issue number, then confirm with PO. PO can provide a different number. If no issue exists yet, use the `/new-issue` skill to create one.
@@ -80,11 +82,11 @@ gh issue comment {issue-id} --body-file {path-to-plan-file}
 
 ### 5. Implement
 
-Dispatch the Coder agent (name for `Agent` tool: `coder`) with: issue id, issue title, issue type, path to the plan file (instruct Coder to treat it as `impl-plan.md`), and any additional context or instructions from the conversation. See **PM Relay Protocol** below for outbound relay mechanics during dispatch.
+Dispatch the Coder agent (name for `Agent` tool: `coder`) with: issue id, issue title, issue type, path to the plan file (instruct Coder to treat it as `impl-plan.md`), and any additional context or instructions from the conversation.
 
 ### 6. Post outcome
 
-Immediately after Coder terminates — before asking PO anything — post Coder's verbatim (no rewording, no reformatting, no condensing) structured final response as a comment to the issue. Strip the `#PO:` prefix per **Terminal response handling** below:
+Immediately after Coder terminates — before asking PO anything — post Coder's verbatim (no rewording, no reformatting, no condensing) structured final response as a comment to the issue:
 
 ```bash
 gh issue comment {issue-id} --body "..."
@@ -94,7 +96,7 @@ gh issue comment {issue-id} --body "..."
 
 ### 7. Review
 
-Surface full structured final response to PO verbatim — no rewording, no reformatting, no condensing. Ask PO for approval or rejection of Coder's work outcome. See **Terminal response handling** below for relay mechanics.
+Surface full structured final response to PO verbatim — no rewording, no reformatting, no condensing. Ask PO for approval or rejection of Coder's work outcome.
 
 ### 8. Iterate
 
@@ -110,68 +112,6 @@ Verify all commits are pushed (`git push` if needed — Coder pushes as part of
 gh pr create --title "..." --body "..."
 ```
 
-## PM Relay Protocol
-
-When dispatching subagents (AA, Coder) via the Agent tool and SendMessage, you (PM) act as the transparent relay between the subagent and the human PO. Follow these rules.
-
-### Agent reference
-
-| Agent | `Agent` tool | Short name | Full name | Color | Emoji |
-|---|---|---|---|---|---|
-| AA | `associate-architect` | AA | Associate Architect (AA) | green | 🟢 |
-| Coder | `coder` | Coder | Coder | orange | 🟠 |
-| PM (you) | — | PM | Project Manager (PM) | blue | 🔵 |
-
-### Outbound — subagent to PO
-
-- **Always** strip the `#PO:` prefix from subagent messages before showing to PO.
-- Present subagent content with an emoji header on a separate line identifying the origin. Use the emojis from the agent reference table above.
-- Header format: `<emoji> #<Full Name>:` on its own line, followed by the verbatim subagent content. Examples:
-  ```
-  🟢 #Associate Architect (AA):
-  Okay, proceeding with the analysis.
-  ```
-  ```
-  🟠 #Coder:
-  Tests fixed, let me check other Quality Gates.
-  ```
-  ```
-  🔵 #Project Manager (PM):
-  AA completed its work on `spec.md`. Should we proceed to the next phase?
-  ```
-- Relay subagent messages verbatim — do not reword, reformat, or condense.
-- Use a transit marker when routing a PO response back to a subagent. After using SendMessage to send PO's response to subagent, show this to PO:
-  ```
-  🔵 #Project Manager (PM): Sending your response to <subagent emoji> #<subagent full name>...
-  ```
-  For example:
-  ```
-  🔵 #Project Manager (PM): Sending your response to 🟢 #Associate Architect (AA)...
-  ```
-
-### Structured questions handling
-
-When a subagent message contains a `--QUESTION--` / `--OPTIONS--` / `--ENDQUESTION--` block:
-1. Present the preceding free-form context to PO with the subagent header and removing the `#PO:` prefix.
-2. Extract the question and options, create an AskUserQuestion for PO.
-3. Upon PO answer, relay the choice back to the subagent as `#PO: <answer>`.
-
-### Terminal response handling
-
-When a subagent terminates (completes or escalates), its final response arrives with a `#PO:` prefix. PM:
-1. Strips the `#PO:` prefix.
-2. Presents the response with an origin header (same as any outbound message — `<emoji> #<Full Name>:`).
-3. Relays the response verbatim to PO.
-
-After relaying, PM analyzes the subagent's outcome to determine next steps per the SDLC workflow. No further communication with that subagent session is possible — PM handles everything from this point.
-
-### Inbound — PO to subagent
-
-- Split PO messages by `#<shortname>:` markers. Route each part independently.
-- No marker or `#PM:` → message is for PM. Handle on your own per your instructions.
-- `#AA:` / `#Coder:` → forward verbatim via SendMessage with `#PO:` prefix added.
-- Validate the target subagent matches the active one. If PO addresses an inactive subagent, revert to PO and explain the mismatch.
-
 ## Reference
 
 - `docs/architecture.md` — system architecture