Diagnose root causes of AI coding session drift and rework

Analyze Project is a forensic root-cause analyzer for Antigravity coding sessions, producing a report that explains not just what happened but why, who or what caused it, and what should change next time. It classifies each session's primary intent first (DELIVERY, DEBUGGING, REFACTOR, RESEARCH, EXPLORATION, AUDIT_ANALYSIS) so exploratory sessions are not judged by delivery-session standards, then discovers conversations in the user's Antigravity brain/ directory and extracts evidence from each: task.md, implementation_plan.md, walkthrough.md, metadata JSON, versioned .resolved.0...N snapshots, and timestamps, treating .resolved.N counts as iteration signals rather than proof of failure. Scope change is split into three categories - human-added scope (new asks beyond the original task), necessary discovered scope (work required to complete the original task correctly), and agent-introduced scope (likely unnecessary work the agent added on its own) - and each session's rework is classified into one primary shape such as clean execution, early replan then stable finish, progressive scope expansion, reopen/reclose churn, late-stage verification churn, or abandoned mid-flight. For every non-clean session it assigns a primary root cause - SPEC_AMBIGUITY, HUMAN_SCOPE_CHANGE, REPO_FRAGILITY, AGENT_ARCHITECTURAL_ERROR, VERIFICATION_CHURN, or LEGITIMATE_TASK_COMPLEXITY - each requiring evidence, a reason stronger alternative causes were rejected, and a confidence level (high = direct artifact/timestamp evidence, medium = multiple supporting signals, low = plausible inference only). A 0-100 severity score sums completion failure (up to 25, abandoned sessions score the max), replanning intensity, scope instability, rework shape, prompt-sufficiency deficit, root-cause impact, and hotspot recurrence.

Use it for a postmortem on AI-assisted coding sessions, especially where scope drift or repeated rework occurred, when root-cause analysis needs to separate user/spec issues from agent mistakes, repo friction, or validation gaps, or when evidence-backed recommendations for future prompts or repo health are needed. Every diagnosis it makes follows a strict evidence precedence - artifact contents over timestamps over metadata summaries over inference - and weak evidence is stated as weak rather than dressed up as certainty.

Input is the set of Antigravity conversation folders, optionally filtered by a keyword or path. It scores the opening prompt itself on a 0-2 scale across six traits - clarity, boundedness, testability, architectural specificity, constraint awareness, and dependency awareness - to separate prompt-driven friction from agent- or repo-driven friction, without punishing a narrow prompt by default. It also runs comparative cohort analysis: first-shot successes vs re-planned sessions, completed vs abandoned, high vs low prompt sufficiency, narrow-scope vs high-scope-growth, short vs long sessions, and low-friction vs high-friction subsystems, extracting what differs materially between each pair rather than just restating averages. Output is a structured report: an executive summary, root-cause breakdown, prompt-sufficiency analysis, scope-change analysis, rework-shape analysis, friction hotspots (files/subsystems that repeatedly correlate with struggle), first-shot successes, non-obvious findings, a severity triage, evidence-backed recommendations, and a per-conversation breakdown. When appropriate it can also update a local project-health or memory artifact with recurring failure modes and fragile subsystems, generate a separate prompt_improvement_tips.md from high-sufficiency and first-shot-success sessions, and suggest missing skills or workflows when the same subsystem or task sequence repeatedly causes struggle.

None beyond the local Antigravity brain/ directory and its session artifacts - task.md, implementation_plan.md, walkthrough.md, metadata JSON, and their versioned .resolved.N snapshots. No external service calls are made.

Teams or individuals running many AI-assisted coding sessions who want to know, with evidence rather than a vibe, whether repeated rework comes from vague prompts, agent mistakes, a fragile repo, or genuinely hard tasks - and what specifically to change about prompts, task scoping, or repo structure to reduce it on the next session.