菜单
Use when capturing an investigation, PoC, measurement, or finding as a durable report. Create one directory per purpose with an evidence-complete README stating the question, method, and result, authored in isolation. Trigger on "write up the findings", "document this PoC".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when fixing a bug, dependency mismatch, broken build, or any other defect in product code under a canonical-branch-protecting workflow. Treat the fix exactly like a feature PoC — open a purpose-named report with the diagnosis and acceptance criteria, do the change in an isolated worktree, prove the gate goes from red to green, then cherry-pick. Trigger on "fix this", "build is broken", "deps mismatch", "rename leaks". This is the bug-side companion to `isolate-and-integrate`; it inherits that operation and adds the report-first discipline so a fix is documented evidence, not a hidden patch.
Prove a change is interpretable AND actually works at the consumer side before landing. Extract the deliverable's surface deterministically from source (no editorializing), enumerate its state matrix, hand the raw extraction and — when a UI can render — real screenshots to blind multi-persona agents, judge against pre-written ground truth, and block on FAIL. This is the procedure behind the iron rule "green only once consumed." Use AFTER a UI- or contract-facing change and BEFORE landing. Trigger on "zero-knowledge verification", "blind test", "verify before land", "consumer-side verification", "UI verify".
Use when implementing or changing product code in a repository that protects a canonical branch. Do the work in a throwaway git worktree off the canonical branch, verify it against the full quality gate, and cherry-pick only the finished, verified commits back — never commit to the canonical branch directly. Trigger on requests to add, fix, or refactor code.
Use BEFORE a non-trivial or unfamiliar change, when unsure which module owns the behavior — and BEFORE diving into a fix when prior reports may already describe the area. Build a pre-edit structure brief over both the source tree and the reports directory so candidate owners and prior investigations surface together; CONFIRM the owner by searching and reading before committing to it. Then deliver the change in isolation. Trigger on "where should this go", "did anyone already look at this", "what's the context".
Use when surveying or updating the implementation status of `requirements/RNN-*.md` against the current `source/` and `reports/`. The status model is multi-axis (not binary done/not-done) because parts can exist as building blocks for a larger exploration even when no single requirement is "done", and shipped features may differ from the requirement on purpose. Trigger on "update requirement status", "requirement status", "show the status table", "what's the status of R0N", "update the tracker".
| name | capture-report |
| description | Use when capturing an investigation, PoC, measurement, or finding as a durable report. Create one directory per purpose with an evidence-complete README stating the question, method, and result, authored in isolation. Trigger on "write up the findings", "document this PoC". |
A report is a durable artifact: the evidence plus the conclusion, one directory per purpose.
test1/).isolate-and-integrate skill) so experiments never reach the canonical
branch; move the finished artifacts into the report afterward.Prefer runnable snippets and real captured output over prose claims. Where to put
reports and how to commit them is project-specific — see the project's CLAUDE.md.
Evaluate the finished README without giving the reviewer a repository checkout or any other document. The README must itself define every proper noun and local term at first use, identify the hardware and software under test, reproduce the method, and contain enough evidence to establish the result.
path:line; a pointer without the quoted evidence is insufficient.path:line accompanying already-quoted source are permitted pointers.The README is unfinished if a new reader, given only its text, cannot state what was examined, on which hardware, by which method, and with what result.