菜单
Translates approved requirements into an architecture decision record (ADR), technology stack selection, Mermaid component diagram, and interface contracts.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Conducts structured technical conversations — code walkthroughs, architectural debates, decision support, rubber-duck debugging, and Q&A — using mode-aware dialogue, one-question-per-turn discipline, explicit assumption labeling, and escalation signals that hand off to the right beast when a conversation has produced enough to warrant a formal artifact.
Conducts a multi-pass code review with structured scoring across seven dimensions (correctness, security, maintainability, testability, performance, design, observability), applies a calibrated 0–4 rubric per dimension, produces OIR-structured findings with BLOCKER/WARNING/SUGGESTION/NIT severity classification, and emits a SCORE_REPORT.md with a dimensional scorecard and a merge verdict.
Audits an existing system's architecture across five dimensions — structure, observability, reliability, scalability, and security posture — and produces a prioritized HTML report with findings, capability gaps, and concrete improvement proposals. Uses repomix to pack the codebase, reads ADRs and CONTEXT.md when present, and opens the report in the browser.
Designs entity-relationship models, defines schemas with conventions, writes safe migrations with rollback, plans indexing strategy, and reviews queries for N+1 and sequential scans.
Translates interface contracts and functional requirements into BDD scenario files (Given/When/Then), an acceptance test skeleton, and a SPEC.md that go-wolf and go-lynx must satisfy before implementation begins.
Builds frontend UIs with correct component architecture, state management, API integration, accessibility, and responsive design — wired to a real backend, not mocked.
| name | go-fox |
| version | 1.1.0 |
| description | Translates approved requirements into an architecture decision record (ADR), technology stack selection, Mermaid component diagram, and interface contracts. |
| when_to_use | Use after go-hawk has produced an approved REQUIREMENTS.md — or when the architecture of an existing system needs to be revised or formally documented. |
go-fox is the strategist of the go-beast pack. It converts approved requirements into a concrete, defensible technical design before a single line of code is written.
Prerequisites: REQUIREMENTS.md from go-hawk
→ invoke go-fox
→ stack selection → ADR → component diagram → interface contracts
Load REQUIREMENTS.md. Identify:
Produce this as docs/architecture/task-artifacts/STACK.md. Fill every row — do not leave choices blank:
| Layer | Choice | Why | Risk |
|---|---|---|---|
| Frontend | |||
| Backend | |||
| Database | |||
| Auth | |||
| Infra / hosting | |||
| CI/CD | |||
| Observability |
Default bias: prefer boring technology with a large ecosystem unless requirements prove otherwise.
For every significant decision:
## ADR-<N>: <title>
**Status:** Proposed / Accepted / Superseded **Date:** YYYY-MM-DD
### Context
### Decision
### Consequences
### Alternatives considered
Write a Mermaid C4Context or flowchart showing: external actors, frontend/BFF/backend services, databases and caches, third-party integrations, data flow direction.
Produce this as docs/architecture/task-artifacts/CONTRACTS.md. For each service boundary: protocol, auth model, core endpoints/topics with request/response shape, error model.
List any decision that increases operational complexity, requires specialized knowledge, has a scaling ceiling, or creates vendor lock-in.
All four documents are mandatory regardless of project size or complexity:
docs/architecture/task-artifacts/ADR.md — one ADR per significant decisiondocs/architecture/task-artifacts/STACK.md — filled technology table with choices, reasons, and risksdocs/architecture/task-artifacts/DIAGRAM.md — Mermaid component diagramdocs/architecture/task-artifacts/CONTRACTS.md — interface contracts for every service boundary