メニュー
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.