## Harness Router (auto-injected by `harness-toolkit init`) When the user describes a requirement, feature request, bug fix, refactor, or task in natural language WITHOUT explicitly typing a slash command (`/step-N`, `/harness-*`, `/diagnose`, `/triage`, etc.), you MUST first invoke the `harness-router` skill via the Skill tool before doing anything else. `harness-router` first classifies intent from the raw prompt, then routes: - Debug language (bug / 报错 / failing / crash / regression / 挂了 / 崩溃 / 不工作) → `/diagnose` skill (debug wins over session state). - Triage language (事故 / 复盘 / incident) → `/triage` skill. - Status query (进度 / 到哪一步了 / pipeline 状态) → `/harness-status` skill. - Handoff (交接 / handoff / 移交) → `/handoff` skill. - Security audit (漏洞 / 安全审计 / vulnerability) → `/security-review` skill. - Review request (评审 / code review / 看一下 diff) → `/code-review` skill, or `/code-review-5axis` (five-axis + Chesterton's Fence + Beyoncé Rule) for refactors / migrations / cross-module changes where deletion-caution and test-coverage discipline matter. - Release request (发版 / 发布 / ship / 打包发布) → `/release-pack` skill. - Test request (写测试 / 单测 / 覆盖率 / 加测试) → `/tdd` skill. - Prototype / spike (原型 / 调研 / 验证方案) → `/prototype` skill. - Architect design (架构设计 / 评估架构 / 架构选型) → `/arch-roundtable` skill. - Quick-edit (typo / 改一下 / 把 X 改成 Y / 改个常量) → direct Edit, no pipeline (skip PRD, decision tree, and gates). - Architecture-driven delivery (架构驱动开发 / 图先于码 / 显式 `/arch-driven`) → `/arch-driven` skill. **Explicit invocation only** — harness-router does NOT auto-route into it from natural language. Use when the change touches 2+ modules or alters a contract and the user wants sign-off gates before and after code. - Requirement (add / implement / 新增 / 实现 / 重构 / 优化 / 修改) → harness step pipeline: - No active session → `/step-1-req-clarify` (which auto-advances to step-2 and beyond per its own auto-chain logic). - Active session → resume at `currentStep`. - Discover (default fallback when no lane matches confidently) → output inline 16-skill catalog (smoke-test / integration-verify / improve-codebase-architecture / compile-spec / task-decomposition / to-prd / to-issues / write-a-skill / code-scan-6dim / packaging / grill-with-docs / caveman / zoom-out / architecture-models-4plus1 / smoke-record / deploy-test) and let the LLM pick, or fall back to step-1 if the message reads as a fresh requirement. Do not paraphrase or summarize the user's raw requirement before handing off — step-1's `extract_dimensions` needs the original wording. This block is idempotent: `harness-toolkit init` detects the sentinel comments and will not append a second copy. Remove the whole block (including the `` and `` lines) to re-inject on the next init. ## Karpathy 10 Principles (code generation charter) Whenever generating or modifying code in this repo, follow these ten rules. They are not optional even when the harness pipeline or a sub-agent takes over — they are the baseline for "code you will not rewrite". 1. **Read before you write.** The #1 cause of bad LLM code is writing without reading. Before generating, actually *read* (not skim) the file you're editing, its neighboring implementations, the imports at the top (if the project uses `fetch` everywhere, don't pull in `axios`), and the existing tests. Match what's already there. 2. **Think before you write.** Surface your assumptions. "Add auth" could mean session / JWT / OAuth / something else — don't silently pick one. State trade-offs. When multiple approaches exist, give 2-3 with a recommendation. If you're confused, stop and ask — don't paper over a gap in understanding with plausible-looking code. 3. **Keep it simple.** Write the least code that solves *this specific problem*, not the least code that could theoretically solve everything. Resist four over-engineering urges: premature abstraction, imagined error handling, unnecessary configurability, flexibility with no user. If the only reason for an abstraction is "in case we need it later", it's over-engineering. 4. **Surgical changes.** Smallest diff possible — every line goes into git blame and gets reviewed. Don't touch what you weren't asked to touch. Match existing style (file uses `var`, you use `var`). Don't run prettier on untouched code. Look at the diff and ask: can every line be justified by the task itself? If not, roll it back. 5. **Verify.** "Code works" and "you think it works" are separated by a test. For a bug fix, write a failing repro test first, watch it red, fix, watch it green. Test behavior, not implementation (asserting a constructor assigned a property is meaningless). If something can't be tested, say why — that's a design signal, not a license to skip. 6. **Goal-driven.** Have a clear success criterion before starting. Translate "add validation" into "return 400 with a reason when email is missing or invalid, with tests for both cases". For multi-step tasks, post the plan before executing. 7. **Debug.** When something doesn't work, don't guess — investigate. Read the full error message and stack trace (the LLM failure mode is glancing at the error type and starting to "fix"). Reproduce before fixing. Change one thing at a time. Don't paper over a crash with a null check before understanding the root cause — the crash goes away, the bug stays, and resurfaces elsewhere later. 8. **Dependencies.** Every dependency is code you don't control but permanently carry. First ask: can an existing dependency do it? (Have `axios` → don't add `node-fetch`.) Then ask: can the standard library do it? (`crypto.randomUUID()` exists → don't add `uuid`.) If you really must add one, say why — don't slip it into `package.json` silently. 9. **Communicate.** Say what you did and why, don't just dump code. If the implementation has a risk you noticed, surface it. Express uncertainty precisely — "I'm not sure this library supports streaming" is useful; "I think it should work" is not. Commit messages must be specific — "Fix bug" is useless; "Fix null pointer in user lookup when email contains uppercase chars" is useful. 10. **Failure modes.** Named traps to catch yourself in: **kitchen-sink** (asked for one feature, you refactored half the library), **wrong abstraction** (built a generic solution for a one-off problem), **silent decisions** (locked a schema/API shape without flagging it), **happy path only**, **knowledge hallucination** (confidently using a non-existent API), **style drift**, **runaway refactor**. When you catch yourself doing these — stop. ## Lessons learned (project-specific skill pointers) These skills were extracted from real debugging sessions. Invoke them by name when their triggers match: - **`restart-dev-server`** — when a test hangs after editing code, when dev server HMR misses `.html`/`.scss` edits, when Windows `taskkill /PID` misbehaves in Git Bash, or when the user asks to restart the dev server. Covers finding listener PID via `netstat`, killing the whole tree via `cmd //c "taskkill /F /T"`, polling for port-ready, and verifying served bundle contains new symbols before re-running tests. - **`angular-cd-wedge`** — when reviewing `*ngFor="let x of method(...)"` patterns, when a component's mode switch causes the browser to hang, or when a Playwright test reports `Target page closed` after triggering CD. Covers prevention rules (R1-R6), debugging phases (build feedback loop → reproduce → hypothesize → instrument → fix → cleanup → sweep), and the canonical memoize + trackBy fix pattern.