devflow-error-investigator

Skill: devflow-error-investigator

Pre-mortem with the wiki. Companion to devflow-debugging. While debugging walks the 4 phases (Investigation → Pattern → Hypothesis → Fix), this skill is the first move on the wiki side: pull every signal the project has accumulated about errors in this area before forming hypotheses.

When to use

• Unexpected exception, failing test, prod incident, "something broke that worked yesterday".
• Triggered FIRST, before devflow-debugging Hook 3 (Pattern phase).

Process

1. Call error_context_get

error_context_get({
  errorMessage: "<concise error string>",
  filePath: "<file where it occurred, if known>",
  // stackTrace + recentCommits optional
})

Returns six buckets: matchingRunbooks, affectedAdrs, recentFlowsInArea, warningPatterns, similarPastErrors, briefing.

2. Triage the response

For each bucket, decide:

• matchingRunbooks — read each. Apply if it still describes the situation. Iron Law: never blindly apply — always verify the runbook is still current (Hook 4 + DF-312 stale-detection).
• affectedAdrs — these are decisions that explicitly cover this file. The error might be an ADR violation. Read each.
• recentFlowsInArea — recent commits touched this file. Read their agentSummary for clues.
• warningPatterns — cross-cutting patterns that mention similar tags or terms. Often the most informative.
• similarPastErrors — done-flows whose summary mentions the same error string. The fix is probably already there.

3. Verdict

• Matched & applicable — apply the existing knowledge, ship the fix. Note the wiki entry in your agentSummary.
• Matched but stale — the wiki entry is outdated. Use knowledge_check_resolve({ resolutionType: 'extend' }) to update it as part of the fix.
• No match — this is a novel failure mode. Investigate freely, but ON THE WAY OUT, write a runbook (knowledge_check_resolve({ resolutionType: 'runbook' }) with the fix-recipe). Compounding!