Validates completed work against defined acceptance criteria. Use after completing a task that has specific success criteria defined in issues, specs, or task descriptions.
日本語の概要は準備中です。原文の説明を表示しています。
Researches real projects, papers, and documented failures before proposing a new feature, architecture, or technology choice. Use for design decisions with multiple valid approaches, not for implementing an existing spec or fixing a known bug.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Other people's documented failures count as observed failure. Before proposing a design, find out how others solved the same problem and where it broke for them.
vibe-decision-journal first)Frame the question — What exactly is being decided? What are the hard constraints (scale, latency, cost, team skills, existing stack)?
Decompose into sub-problems that can be researched independently.
Research each sub-problem using whatever web search or research tool the harness provides. Run sub-problems in parallel (subagents) when the harness supports it. For each, find:
| Requirement | Minimum |
|---|---|
| Real projects or production systems | 2+, with a link |
| Paper, post-mortem, or engineering write-up | 1+, with a link and year |
| Mechanism | How it actually works, not marketing copy |
| Known failures | What went wrong for others, and under what conditions |
| Fit | How it maps to our constraints, specifically |
Verify before citing — Every source must be something you actually opened in this session. Don't quote adoption numbers (stars, downloads, users) from memory; either read them from the source or leave them out. If search is unavailable, say so and label the output "from prior knowledge, unverified."
Synthesize — Compare the options side by side, with the imported failures up front.
Recommend — Base the recommendation on the evidence and state your confidence. Name the condition that would change your mind.
Record — Log the decision and the rejected alternatives with vibe-decision-journal.
| Thought | Reality |
|---|---|
| "I already know the best approach" | You know one approach. Research finds the others. |
| "This is too niche for research" | If someone built it, someone documented where it failed. |
| "Research will slow us down" | A rewrite is slower. |
| "Everyone uses X" | Popularity is not fitness for your constraints. |
| "I'll cite what I remember" | Unverified citations are the most common way research output goes wrong. |
| Criteria | Option A | Option B | Option C |
|---|---|---|---|
| Mechanism | |||
| Known failures | |||
| Fit with constraints |
[Evidence-based recommendation, confidence level, and what would change it]
[Links actually opened, one line each on what they showed]
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Validates completed work against defined acceptance criteria. Use after completing a task that has specific success criteria defined in issues, specs, or task descriptions.
日本語の概要は準備中です。原文の説明を表示しています。
Generates edge case, failure mode, and spec-driven test cases. Covers boundary values, nil inputs, concurrency, resource exhaustion, malformed data, and requirement-linked traceability tests. Use after happy-path tests exist and before claiming coverage is complete, when requirements lack tests, or before a security review.
日本語の概要は準備中です。原文の説明を表示しています。
Catches shortcuts and reward hacking — weakening or deleting tests to make them pass, hard-coding expected outputs, silently dropping requirements, or claiming work is done without running it. Use before declaring a task complete and whenever a test or requirement feels like it's in the way.
日本語の概要は準備中です。原文の説明を表示しています。
Safely integrates commits from parallel agent branches using sequential cherry-pick. Use after parallel work completes in isolated branches or worktrees.
日本語の概要は準備中です。原文の説明を表示しています。
Audits tests for concurrency safety — race conditions, shared mock state, cleanup ordering. Use when writing tests that involve goroutines, async operations, or shared mutable state.
日本語の概要は準備中です。原文の説明を表示しています。
Enforces tiered test coverage standards with three dimensions — line coverage by tier, spec-to-test traceability, and spec-to-code implementation mapping. Use before claiming code is complete.
日本語の概要は準備中です。原文の説明を表示しています。