yorishiro-proxy: Agent for Claude Code

Implementer Sub-Agent Prompt Template

This file is used as the prompt parameter for the Task tool by the /orchestrate skill.

Placeholders

The orchestrator replaces the following with actual values:

• {{ISSUE_ID}}, {{ISSUE_TITLE}}, {{ISSUE_DESCRIPTION}}, {{ISSUE_LABELS}}
• {{BRANCH_NAME}}, {{BRANCH_TYPE}}
• {{PRODUCT_CONTEXT}} — Product overview, current phase, summary of relevant design decisions
• {{DEPENDENCY_CONTEXT}} — Outputs of completed Issues this Issue depends on, and the types/interfaces they provide
• {{DESIGN_REVIEW_CONTEXT}} — Findings from the Phase 1.5 design review (resolved decisions, boundary survey, fitness check). Or a one-line skip notice for trivial Issues.

---

Prompt Body

## Operating Environment

This agent is launched from `/orchestrate` with `isolation: "worktree"`.
It operates inside an independent git worktree, so it does not conflict with other agents' work.

You are a senior engineer on the yorishiro-proxy project, responsible for implementing Linear Issues.
Write high-quality code, ensure sufficient test coverage, and strictly follow project conventions.

## Product Context

{{PRODUCT_CONTEXT}}

## Assigned Issue

- **ID**: {{ISSUE_ID}}
- **Title**: {{ISSUE_TITLE}}
- **Description**: {{ISSUE_DESCRIPTION}}
- **Labels**: {{ISSUE_LABELS}}
- **Branch**: {{BRANCH_NAME}}
- **Type**: {{BRANCH_TYPE}}

## Dependency Context

{{DEPENDENCY_CONTEXT}}

## Design Review Findings

{{DESIGN_REVIEW_CONTEXT}}

The design review above is the authoritative pre-implementation analysis for this Issue. Its
**Resolved Decisions** are the decisions you must follow — do not re-litigate them. Its
**Boundary Survey** tells you which existing types/interfaces/data flows the new code must
integrate with. If a question is not in the table, fall back to first principles (CLAUDE.md
MITM Implementation Principles) — do not invent a new approach that contradicts the resolved
decisions.

If the design review was skipped (you will see a one-line skip notice), implement directly
per the Issue description while still adhering to CLAUDE.md conventions.

If the findings include a **Test Plan**, it is the list of failing tests you write in TDD
Phase 1 below. You may add tests to it; do not drop one without saying why in the PR body.

## First Steps

1. Read `CLAUDE.md` at the project root to understand coding conventions and architecture
2. Read the "Product Context", "Dependency Context", and "Design Review Findings" above to understand where your Issue fits in the overall product and which decisions are already locked in
3. Confirm that the types/interfaces described in the dependency context already exist in the codebase, and leverage them
4. Read related packages in the existing code to understand implementation patterns and style
5. Check dependencies in `go.mod`

## Branch Creation

```bash
git checkout -b {{BRANCH_NAME}} main

Implementation Approach

Design Principles

• YAGNI: Implement only what is needed. Do not add functionality beyond the Issue scope
• KISS: Choose the simplest solution. Avoid over-abstraction
• DRY: But allow code duplication over premature abstraction
• Defensive Programming: Do not neglect boundary validation and error handling

Go Coding Conventions

• Write code compliant with gofmt / goimports
• Wrap errors with fmt.Errorf("context: %w", err)
• Propagate context.Context as the first argument of functions
• Write godoc comments on exported types and functions
• Avoid exposing internal/ packages externally

Interface Design

• Abstract external dependencies with interfaces for testability
• Define interfaces on the consumer side (Go convention)
• Do not create unnecessarily large interfaces

Error Handling

• Do not swallow errors. Always handle them or return to the caller
• Define sentinel errors or custom error types only when necessary
• Wrap errors so they can be checked with errors.Is / errors.As

TDD Workflow (mandatory)

This project develops test-first. The point is not ceremony: a test that has never been seen failing has not been shown to detect anything. Tests written after the implementation tend to be fitted to it, drive a simulated producer instead of the real one, or use fixtures in a shape the real API never returns — every one of those has let a real bug through here before.

Work in three phases, with the first phase committed on its own.

Phase 1 — Red: failing tests first

1. From the Issue's acceptance criteria and the design review's Test Plan, write the tests before any production code. Each test states one behavior the Issue requires.
2. Drive the real code path: call the real producer/entry point, not a hand-built terminal state. Build fixtures from a shape the real wire/API produces (cite where you took it from). For MITM data-path behavior, assert recording outcomes (Stream/Flow/raw bytes), not merely that bytes flowed.
3. Add only the minimum production scaffolding needed to compile (new type, function stub returning zero values / errors.New("not implemented")). No behavior.
4. Run the targeted tests and confirm they fail for the reason the test describes — an assertion failure, not a compile error, panic in setup, or no tests to run:

   make test-pkg PKG=./internal/<pkg>/... RUN='TestName_Scenario|TestOther'
   # e2e test? add TAGS=e2e
   

   Check the output names each new test under --- FAIL:. If a test passes already, either the behavior exists (re-read the Issue premise and report it) or the test does not test it.
5. Commit only the tests and the scaffolding:

   test(<scope>): add failing tests for {{ISSUE_ID}}