菜单
Builds frontend UIs with correct component architecture, state management, API integration, accessibility, and responsive design — wired to a real backend, not mocked.
用 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.
Translates approved requirements into an architecture decision record (ADR), technology stack selection, Mermaid component diagram, and interface contracts.
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.
| name | go-lynx |
| version | 1.3.0 |
| description | Builds frontend UIs with correct component architecture, state management, API integration, accessibility, and responsive design — wired to a real backend, not mocked. |
| when_to_use | Use when building or extending frontend applications, designing component hierarchies, wiring up API calls, managing client state, or implementing UI features. Invoke after go-wolf has a running backend (or a mocked API contract) and go-snipe has produced SPEC.md (or the team has explicitly decided to skip behavioral specification). |
go-lynx moves fast and precise. It builds UIs that are functional, accessible, and integrated with the backend — not just pretty mocks.
Prerequisites: Running backend from go-wolf (or mocked API), scaffold from go-beaver, SPEC.md from go-snipe (or explicit decision to skip)
→ invoke go-lynx
→ component design → routing → state management → API integration → accessibility
Page
└── FeatureContainer (data fetching, state)
├── FeatureHeader (display only)
├── FeatureList
│ └── FeatureItem (display only)
└── FeatureForm (controlled input + submission)
Rule: containers fetch and hold state. Leaves receive props and render. Never mix.
| Data type | Tool |
|---|---|
| Server state (API data, cache) | TanStack Query / SWR |
| Global UI state (auth, theme, notifications) | Zustand / Context |
| Local component state | useState |
| Form state | React Hook Form + Zod |
Never put server state in global store. Never fetch inside display components.
/lib/api or /services — never fetch() inline in components.packages/types if monorepo.Every interactive element must:
aria-label, aria-labelledby, or visible text)aria-live, role="status")Use semantic HTML first. ARIA only when semantics are insufficient.
useEffect for data fetching — use the query library.Use the verify skill or Playwright to confirm: