Debug-skill troubleshooting end-to-end with plan-checker and agent

Punctual bugs are resolved with solo debugging skill. Bugs that invalidate design decisions during an execute-phase require more: solo debugging to investigate, plan-checker GSD to verify that the fix does not break the remaining plan, agent orchestration to execute derived changes. This cluster shows the end-to-end pattern with a real example from the portfolio.

Independence Disclaimer: I am not affiliated with Obra, qrx, or Anthropic. The pattern described is the one I have consolidated after having made a "perfect fix" disaster that invalidated 2 future phases of an unfinished phase.

The problem: cascading bug that invalidates the plan

Example from the portfolio (real synthesis). During Wave 3 of a past phase, the backend executor produces an error: the endpoint that was supposed to return the list of results returns 500 in a production-like environment. The bug appears to be precise.

Investigation of skill debugging reveals: the cause is a transitive dependency unmanaged on a library. The fix requires:

1. Replace the library.
2. Rewrite the adapter that she used.
3. Update two future plans of the same phase (Wave 4, 5) that assumed the original library.

If you only do steps 1 and 2 (fix punctuation precisely), step 3 explodes when Wave 4 starts. You need to manage the consequences preemptively.

The end-to-end pattern in 5 steps

1. Debugging skillsInvestigation structured, scientific method loop, checkpoint pattern. Cause identified + proposed fix.
2. Prefix analysisBefore applying the fix, identify consequences. Which other plans touch the same files? Which decisions of CONTEXT are invalidated?
3. Re-run of the plan checkerRun a plan checker with the proposed fix included in the revision. Verify that the fix does not break any other plans still to be executed.
4. Apply fix + agent orchestrationApply fix. Optionally spawn parallel agents for derived modifications (rewrite adapter, update future plan).
5. Post-fix verificationRe-run the test suite and verify that there is no regression. Update STATE.md with the changes.

Real example: bug in i18n hreflang that required a cascade fix

Taking the example of cluster 9202 (Debugging skill) and expanding with end-to-end, Bug: GSC reports over 999 URLs with incorrect canonical links (sv → en bundle). Skill debugging has identified the cause: 11 languages runtime require an EN bundle under a local path-specific path.

Cascade consequences:

1. Technical Fix: Chrome Runtime Transloco for 11 Languages.
2. Future-impact plans: 3 phase 17 plans (Search Console Fix) assumed correct hreflang as the baseline.
3. Context decision impacted: D-04 i18n hybrid (7 AOT + 11 runtime) was supposed to be documented as "adopted" before the next Wave.

End-to-end workflow followed:

1. Skill debugging (40 min): causa identificata
2. Pre-fix analysis (15 min): trovati 3 plan impattati + 1 decisione CONTEXT
3. Plan-checker iter 2 mirato (10 min):
   - verifica che adozione chrome runtime non rompa Plan 17-01, 17-02, 17-03
   - update CONTEXT.md con D-04 in "decided"
4. Apply fix (45 min): chrome runtime + i18n bulk re-translate 11 lingue
5. Post-fix verification (15 min): hreflang test green, build deploy successful

Total: ~2h 5min wall-clock

Without the end-to-end pattern I would have applied fix steps 1 and 2 (~45 minutes) and left step 3 to explode on the next wave (~+2-4 hours of post-facto debug cascade).

When integration is worth it

Three situations where the end-to-end pattern is justified:

1. Bug found during execution With at least one plan Future in the same phase still to be executed. High cascade risk.
2. Bug that invalidates a decision in CONTEXT.mdThe decision was based on an incorrect assumption; it needs to be updated before the downstream plan is re-executed.
3. Bug that changes the threat model Security Review New threat = update threat_model in active plans.

For precise bugs (no cascading), solo debugging is enough. Don't bring up the plan-checker unless there's a risk of cascade.

When the pattern is overkill

1. Isolated bug found in a standalone module with no cross-plan dependencies.
2. There is a bug in the script utility, no impact on feature production.
3. Bug found in PR review (human review phase already closed, handle it in PR feedback).

Anti-pattern: fix punctual without considering cascades

The worst error I made. The bug was discovered in Wave 2 and fixed within 30 minutes. Three days later, Wave 4 started and failed because the plan assumed the old pattern. Emergency re-planning, plan-checker iteration 3 (rare), "fix-fix" commit that has caused the Git history to be confusing.

Mitigation: routine post-investigation. Even if it seems punctual, 30 seconds of checking on future plans ("do they touch the same files? do they use this library?") can save disasters.

Anti-pattern: plan checker on every bug fix

The opposite: invoking a plan-checker re-run for every typo fix costs nothing but takes 10 minutes of overhead.

Heuristic: run the plan checker only if prefix analysis reveals potential cascade. For precise bugs, skip.

Coordination among the three components

Skill debugging, plan-checker GSD, and agent orchestration live in separate systems but coordinate through files:

• Debugging skills for production I don't see any Italian text to translate. Please provide the text you'd like me to translate, and I'll be happy to assist you. textual + identifies files to be modified.
• Plan checker reads active plans and the proposed fix, evaluates cascades.
• Agent orchestration spawn executor mirated for derived modifications.
• Everything is committed to Git, auditable trail available.

Partial rollback of previous plan

Advanced case: The bug is in a plan already committed of Wave's previous version. Partial rollback required.

1. Git revert on specific commits (atomic per plan = atomic per revert).
2. Skill debugging plus plan checker plus agent produce a substitute fix.
3. Re-apply new plan like delta above reverse.
4. Update STATE.md to reflect the history (revert + fix).

On my portfolio I have used this pattern 2 times in 12 months. Rare, but crucial that it works when needed.

Typical session: total time

• End-to-end pattern (cascade risk low): 60-90 minutes.
• End-to-end pattern (high cascade risk, 2-3 impacted plans): 2-4 hours.
• End-to-end pattern with partial rollback: 3-6 hours.

What I learned writing this article

The main lesson is: The separate systems that communicate through files are powerfulSkill debugging does not know GSD; GSD does not know skill debugging. But all three work on the same repository, and the file is the common contract. The end-to-end pattern emerges from how you use the systems, not from how they are internally designed.

According to insight: the discipline of pre-fix analysis is the single change that saved me more hours. Thirty seconds of "who touches these files? what decisions impact?" before applying a fix captures most of the cascade disasters.

Avoided pattern

• Precise punctuation without analysis cascadeRoutine post-investigation 30 seconds is discipline that always pays.
• Re-run plan check on every bugHeuristic: only if concrete cascade risk exists.

A story worth sharing

Placeholder Section If you have experience with cascading bugs handled well (or catastrophically), write to me at federico@federicocalo.dev.

Previous cluster: Cost Optimization Next cluster (last): Integration of Superpowers + GSD →