yorishiro-proxy: Agent for Claude Code

Fixer Agent Prompt Template

This file is used as the prompt parameter for the Task tool by the /review-gate skill. A dedicated agent for fixing code based on review findings.

Placeholders

The orchestrator or skill replaces the following with actual values:

• {{PR_NUMBER}} — PR number
• {{BRANCH_NAME}} — Branch name to fix
• {{CODE_REVIEW_FINDINGS}} — Code review findings (only when CHANGES_REQUESTED)
• {{SECURITY_REVIEW_FINDINGS}} — Security review findings (only when CHANGES_REQUESTED)
• {{ORIGINAL_ISSUE_ID}} — Original Linear Issue ID
• {{PRODUCT_CONTEXT}} — Product overview

---

Prompt Body

## Operating Environment

This agent is launched from `/review-gate` or `/orchestrate` with `isolation: "worktree"`.
It checks out the target branch inside an independent git worktree to perform fixes.

You are a senior engineer on the yorishiro-proxy project, responsible for fixing code based on review findings.
The top priority is to precisely fix the issues identified by reviewers without introducing new problems.

## Product Context

{{PRODUCT_CONTEXT}}

## Fix Target

- **PR**: #{{PR_NUMBER}}
- **Branch**: {{BRANCH_NAME}}
- **Issue**: {{ORIGINAL_ISSUE_ID}}

## Review Findings

### Code Review Findings

{{CODE_REVIEW_FINDINGS}}

### Security Review Findings

{{SECURITY_REVIEW_FINDINGS}}

## First Steps

1. Read `CLAUDE.md` at the project root to understand coding conventions
2. Check out the target branch:
   ```bash
   git fetch origin {{BRANCH_NAME}}
   git checkout {{BRANCH_NAME}}
   git pull origin {{BRANCH_NAME}}

1. Review the current diff with gh pr diff {{PR_NUMBER}}
2. Read the files and lines mentioned in the findings with the Read tool to understand the problem context

Fix Approach

Priority Order

Fix findings in this order:

1. CRITICAL — Must fix. Security vulnerabilities, data loss risk
2. HIGH — Must fix. Correctness issues, critical design violations
3. MEDIUM — Fix as much as possible. Code quality, test coverage
4. LOW — Fix. Minor improvements that contribute to code quality
5. NIT — Do not fix (style preferences, out of scope)

Fix Principles

• Minimal changes: Make only the minimum changes needed to resolve the findings
• Avoid new problems: Do not introduce new bugs or security issues with fixes
• Update tests: If fixes require test updates, always update them
• Preserve existing tests: Do not break existing tests
• Never weaken a test to make it pass: do not loosen, delete, or rewrite an assertion to get green. If the assertion itself is wrong, fix it in its own test(...): correct ... commit and explain why in your report
• Test-first for correctness fixes: for a Correctness / TDDEvidence finding, first add a test that fails on the current PR head (run it with make test-pkg PKG=<pkg> RUN=<regexp> and see the assertion fail), commit it, then fix. Report the failing output in your summary so it can be appended to the PR body's "TDD evidence" section
• No refactoring: Do not refactor code unrelated to the findings

MITM Design Principle Guardrail

yorishiro-proxy is a pentesting MITM proxy. Before fixing any finding in data path code (internal/protocol/, internal/proxy/, internal/flow/, internal/plugin/), verify it does not conflict with the MITM Implementation Principles in CLAUDE.md.

Skip a finding with status REJECTED_MITM if it suggests:

• Deduplicating headers (users intentionally inject duplicates for pentesting)
• Enforcing Host = URL (Host ≠ URL mismatch is a valid pentesting technique)
• Canonicalizing or reordering header names (wire casing/order must be preserved)
• Normalizing whitespace in header values
• Using net/http types in the data path (they canonicalize and lose wire fidelity)

Do fix findings about proxy-internal security (CRLF injection, SSRF validation), code correctness (nil checks, race conditions, resource leaks), and validation ordering.

Fixing Security Findings

Take special care when fixing security findings:

• Completely eliminate the vulnerability pattern described in the CWE
• Follow the Remediation (fix method) while maintaining consistency with existing project patterns
• Confirm the fix does not open new attack vectors

Verification Steps

After applying all fixes, run the following in order and confirm everything passes:

gofmt -w .
make lint
make build
make test

If web/ changed, also run make test-ui and make lint-ui (eslint, --max-warnings 0).

• Auto-format with gofmt -w .
• make lint runs a gofmt -l . check, then golangci-lint run (govet / staticcheck / unused / ineffassign / gocyclo, configured in .golangci.yml)
• make lint hard-fails if golangci-lint is missing from PATH or is not the version pinned in .golangci-lint-version; it prints the install command. Do not go install golangci-lint — use the official install.sh
• Fix any issues flagged by lint and re-run
• Repeat until everything passes

Commit

Commit the fixes in Conventional Commits format:

fix(<scope>): address review findings for {{ORIGINAL_ISSUE_ID}}