菜单
Evidence before claims, always — run verification commands and confirm output before making any completion or success claims.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Recognizing context pressure before it degrades output quality.
Writing implementation plans — small testable steps, dependency ordering, upfront risk identification.
Generate Architecture Decision Records — use when asked to document a decision, create an ADR, record why we chose X, or capture architectural rationale.
Generate a structured changelog from git history — use when asked to create a changelog, release notes, or summarize what changed between versions/tags/branches.
How to write pikit workflow YAML files — steps, loops, branches, interpolation.
Deep research with Analysis of Competing Hypotheses — use when asked to do deep research, deeply investigate, validate claims, or when correctness is critical and the user wants rigorous analysis with disconfirmation testing.
| name | verification |
| description | Evidence before claims, always — run verification commands and confirm output before making any completion or success claims. |
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
If you haven't run the verification command in this response, you cannot claim it passes.
Before claiming ANY status:
Skip any step = the claim is unverified.
| Claim | Requires | NOT sufficient |
|---|---|---|
| "Tests pass" | Test command output showing 0 failures | Previous run, "should pass" |
| "Linter clean" | Linter output showing 0 errors | Partial check, extrapolation |
| "Build succeeds" | Build command exit 0 | Linter passing, "looks good" |
| "Bug fixed" | Original symptom test passes | "Code changed, should be fixed" |
| "Requirements met" | Line-by-line checklist verified | "Tests passing" |
| Excuse | Reality |
|---|---|
| "Should work now" | RUN the verification |
| "I'm confident" | Confidence is not evidence |
| "Linter passed" | Linter is not the test suite |
| "Partial check is enough" | Partial proves nothing |
Run command -> Read output -> State result with evidence
WRONG: "All tests should pass now."
RIGHT: "Ran `npm test` — 34/34 passing, 0 failures."
Existence does not equal implementation. Verify at all four levels:
| Level | Check | Method |
|---|---|---|
| 1. Exists | File is present at expected path | [ -f path ] |
| 2. Substantive | Content is real, not placeholder | No TODO/FIXME, no stub returns, no lorem ipsum |
| 3. Wired | Connected to the rest of the system | Imports resolve, routes registered, config referenced |
| 4. Functional | Actually works when invoked | Tests pass, endpoint responds, UI renders |
Levels 1-3 can be checked programmatically. Level 4 often requires running the system.
The stub-detect hook catches Level 2 failures at write time. A file full of stubs passes Level 1 but fails Levels 2-4.
No shortcuts. Run the command. Read the output. Then claim the result.