메뉴
Diagnose bugs, errors, and issues with root cause analysis. Use when asked to diagnose, debug, investigate, or find root cause of any problem — whether a wipnote bug ID, error message, unexpected behavior, or delegation audit.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | diagnose |
| description | Diagnose bugs, errors, and issues with root cause analysis. Use when asked to diagnose, debug, investigate, or find root cause of any problem — whether a wipnote bug ID, error message, unexpected behavior, or delegation audit. |
| user_invocable | true |
General-purpose diagnostic skill for investigating bugs, errors, and unexpected behavior.
/wipnote:diagnose <bug-id> # Investigate a specific bug
/wipnote:diagnose <error or symptom> # Investigate an error or behavior
/wipnote:diagnose --delegation # Audit delegation compliance (legacy mode)
Trigger on:
bug-5126e3cfAll diagnostic work must be attributed:
wipnote bug start <bug-id> before investigatingwipnote bug create "Error: description" --track <trk-id> then start itwipnote help for available commandsIf given a bug ID (matches bug-*):
wipnote bug start <bug-id>wipnote bug show <bug-id>If given an error message or symptom:
wipnote bug create "<summary>" --track <trk-id> then wipnote bug start <id>If --delegation flag:
If no arguments:
wipnote recommend --top 3Dispatch use @researcher with a structured prompt:
## Bug: <bug-id> — <title>
### Symptom
<description from bug or user>
### Investigation Steps
1. Search codebase for relevant code paths
2. Read the source files involved
3. Identify the root cause with file paths and line numbers
4. Check if the issue affects other cases beyond the reported one
5. Query SQLite or run CLI commands to verify current state
6. Propose a fix (describe what to change, don't implement)
### Report Format
- **Root cause**: What's wrong and where (file:line)
- **Blast radius**: Does this affect other cases?
- **Suggested fix**: What code change resolves it
- **Verification**: How to confirm the fix works
After the agent reports back, present findings to the user in this format:
## Diagnosis: <bug-id>
**Root cause:** <one-line summary>
**Location:** `<file>:<line>`
**Blast radius:** <scope of impact>
### Details
<agent's detailed findings>
### Suggested Fix
<what to change>
### Next Steps
- [ ] Implement fix
- [ ] Run tests: `go test ./...`
- [ ] Verify: <specific verification command>
When --delegation is specified, audit the current session's delegation compliance:
wipnote status
sqlite3 "$(wipnote status | awk '/^DB:/{sub(/^DB:[[:space:]]*/, ""); print; exit}')" "
SELECT tool_name, COUNT(*) as count
FROM agent_events
WHERE session_id = (SELECT session_id FROM agent_events ORDER BY timestamp DESC LIMIT 1)
GROUP BY tool_name ORDER BY count DESC;
"
Compute score: delegations / (delegations + direct_impl + git_writes) * 100
Present report:
## Delegation Diagnostic
### Score: X% (N/M actions delegated)
### Gaps Found
| Time | Tool | Action | Should Use |
|------|------|--------|------------|
| ... | ... | ... | ... |
### Recommendations
1. ...
wipnote orchestration patterns for AI-assisted development. Use when working on code in an wipnote project — provides delegation patterns, model selection, quality gates, and work tracking guidance. Activate when planning work, delegating to agents, debugging, building features, or managing tasks.
wipnote orchestration patterns for AI-assisted development. Use when working on code in an wipnote project — provides delegation patterns, model selection, quality gates, and work tracking guidance. Activate when planning work, delegating to agents, debugging, building features, or managing tasks.
wipnote orchestration patterns for AI-assisted development. Use when working on code in an wipnote project — provides delegation patterns, model selection, quality gates, and work tracking guidance. Activate when planning work, delegating to agents, debugging, building features, or managing tasks.
Plan development work using a triage-gated, blocks-first interview. Classify scope as trivial/standard/complex, then run 0/3/4 staged interview rounds through the current harness native ask-user tool when available, or plain conversation when it is not. Each stage elicits the VISUAL block first (file-tree, api-endpoint, data-model, wireframe/diagram) and derives the prose slice fields (what/why/done_when) from it — blocks are authored inline as the YAML is built, not in a post-pass. Produces slice-card YAML with grounded visual blocks and visible research provenance for external claims; pauses for human review; promotes approved slices to features. Use when asked to plan, create a development plan, or build a feature with design clarity first.
SECONDARY enrichment path — add or revise structured visual blocks (data-model, api-endpoint, file-tree, wireframe, diagram, tabs) on an EXISTING wipnote plan. Use for legacy plans drafted before blocks-first existed, or for ad-hoc later block additions/revisions — NOT for primary planning. New plans get blocks authored inline during the wipnote:plan interview (blocks-first); only reach for this skill when a plan already exists and needs blocks added or changed after the fact. Reads the live block catalog from wipnote plan blocks, adds grounded blocks to slices, regenerates the plan HTML, and links to the dashboard.
Generate a grounded visual recap for a work item, git range, or session. Runs wipnote recap to produce a self-contained HTML artifact grounded in the real diff, reads the artifact, writes an outcome narrative (secrets redacted), and links to the dashboard recap URL. Use when asked to recap, summarize, or visualize completed work.