retro

name	retro
description	Post-fellowship retrospective analysis. Collects gate history, palantir alerts, and quest metrics to surface patterns and interactively recommend configuration improvements.

Retro — Post-Fellowship Retrospective

Overview

Analyzes a completed fellowship's history to surface patterns and interactively offer configuration improvements. Reads gate events, palantir alerts, and git metrics across all quest worktrees, then presents findings and walks through actionable recommendations one by one.

When to Use

• Manual: invoke /retro after a fellowship completes or is disbanded
• Suggested: Gandalf suggests running /retro during the disband flow (not enforced)

Process

Step 1: Locate Fellowship Data

1. Find the git root directory
2. Read ~/.claude/fellowship.json to check for a custom dataDir setting. If absent, use the default data directory (.fellowship/).
3. Read fellowship-state.json from the resolved data directory to enumerate all quest worktrees and their metadata
4. If no fellowship state file exists, report "No fellowship state found — nothing to analyze" and stop

Step 2: Collect Data

For each quest worktree listed in fellowship-state.json:

1. Gate events: Read quest-herald.jsonl from the worktree's data directory via the Read tool. Each line is a JSON object with timestamp, quest, type, phase, and detail fields. Collect all entries of type gate_approved, gate_rejected, gate_submitted, and phase_transition.

2. Quest state: Read quest-state.json from the worktree's data directory. Record the final phase, quest_name, and whether the quest completed.

3. Quest tome: Read quest-tome.json from the worktree's data directory if it exists. Record gate history (approved/rejected counts per phase), phases completed with durations, and files touched.

4. Git metrics: Run these Bash commands for each worktree:

   • git -C {worktree} log --oneline | wc -l — commit count
   • git -C {worktree} diff --stat "$(git -C {worktree} rev-list --max-parents=0 HEAD | tail -n1)"..HEAD 2>/dev/null || echo "0 files changed" — change summary

5. Palantir alerts: Read palantir-alerts.jsonl from the resolved data directory at the git root if it exists. Each line is a JSON object with timestamp, type (stuck/drift/conflict/health/bulletin), and detail. Standard alerts include quests; bulletin alerts include source_quest, target_quest, topic, and discovery instead.

6. Autopsies: Scan the autopsies/ subdirectory within the resolved data directory. Each .json file is a structured failure record with quest, phase, trigger, files, modules, what_failed, and resolution fields. Collect all entries.

Step 3: Analyze

Compute the following from collected data:

Summary metrics:

• Total quests completed vs failed (phase != "Complete")
• Total gate events: approved, rejected, submitted
• Rejection rate by phase (e.g., "Plan: 2/3 rejected, Research: 0/3 rejected")

Phase patterns:

• Which phases have the highest rejection rates
• Which quests spent the longest time in each phase (from tome phase durations)
• Phases where all gates were approved (candidates for auto-approve)

Warden violations:

• Check tome gate history for any rejection reasons mentioning convention or warden issues

Palantir alert summary:

• Count by type (stuck, drift, conflict, health, bulletin)
• Which quests were flagged most frequently

Autopsy patterns:

• Count autopsies by trigger (recovery, rejection, abandonment)
• Modules/files with multiple autopsies (hot spots for failure)
• Common tags across autopsies (recurring themes)

Step 4: Present Results

Output the analysis in this format:

Fellowship Retrospective: {fellowship_name}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Quests: {completed} completed, {failed} failed
Gates: {total} total, {rejected} rejected ({rejection_details})
Palantir alerts: {alert_summary}
Autopsies: {autopsy_count} ({trigger_breakdown})

Observations:
- {observation_1}
- {observation_2}
- {observation_3}

Recommendations:
1. {recommendation_1}
2. {recommendation_2}
3. {recommendation_3}

Observation examples:

• "Plan gates rejected 2/3 times — plans needed more research context"
• "quest-ui-login spent longest in Research — task may have been under-specified"
• "No warden violations — conventions well-established"
• "2 file conflict alerts — consider splitting shared files across quests"
• "auth module has 4 autopsies — consider documenting its quirks in CLAUDE.md"
• "3 recovery autopsies in Implement — plans may need more detail"

Recommendation examples:

• Auto-approve phases with 0% rejection rate
• Keep manual gates that have high rejection rates (proving their value)
• Suggest templates for recurring quest patterns
• Adjust palantir settings if alerts were excessive or insufficient

Step 5: Interactive Recommendations

Walk through each recommendation one at a time. For each:

1. Present the recommendation with current and proposed values:

Recommendation N: {description}
Currently: {current_value}
Proposed: {proposed_value}

Apply? (y/n)

2. Use AskUserQuestion with y/n choices

3. On accept: Read ~/.claude/fellowship.json (create if it doesn't exist). Apply the change to the appropriate config key. Write the file back. Report what was changed.

4. On reject: Move to the next recommendation without changes.

5. After all recommendations are presented, summarize what was applied:

Applied {n} of {total} recommendations:
- {applied_1}
- {applied_2}

Config updated at ~/.claude/fellowship.json

If no recommendations were accepted, say "No changes applied."

Key Principles

• Read-only analysis. The retro skill only reads worktree data — it never modifies quest state, worktrees, or git history.
• Config changes only on explicit accept. Each recommendation requires individual user confirmation before applying.
• Graceful degradation. If some data sources are missing (no palantir alerts, no tome, worktree deleted), analyze what's available and note what was missing.
• Terminal output only. No saved retro files — keeps it lightweight and ephemeral.