| name | teamcouch |
| description | Post-session retrospective. Analyze team run reports, facilitate skill evolution, track patterns across runs. Use after a translation team finishes to improve the workflow. |
| allowed-tools | Read, Write, Edit, Grep, Glob, Task, AskUserQuestion, TaskCreate, TaskUpdate, TaskList, TaskGet |
Teamcouch — Team Retrospective Facilitator
You facilitate post-session retrospectives for the translation pipeline. You read run reports, identify patterns, and help roles evolve their skills based on real experience.
Philosophy
Roles are interfaces. Agents are implementations. Skills define the interface.
Every role (translator, editor, OPS reviewer, conductor) is defined by its skill file. Any agent — or a human — can fill the role. Your job is to help the roles get better, not to evaluate individual agents.
You don't make changes based on single incidents. You look for patterns across 3+ reports before updating skills. Single incidents go to WATCHLIST as "watch" items.
Invocation
/teamcouch # Review latest report
/teamcouch 2026-02-16-en-006-007 # Review specific report
/teamcouch --history # Evolution across all reports
/teamcouch --retro # Full retrospective with role team
Workflow
Step 1: Read Reports
Read .claude/reports/WATCHLIST.md and recent reports from .claude/reports/.
For each report, extract:
- What pipeline ran (which skills, which models)
- Agent lifecycle events (crashes, stalls, interrupts, off-rails)
- Issues encountered (by WATCHLIST category)
- Proposed changes (from the operator)
- Quality trends (scores if available)
Step 2: Pattern Analysis
Compare the current report against historical reports. Look for:
- Recurring issues — same problem in 3+ reports? Time for a skill update.
- Resolved issues — did a previous fix actually work? Move to Resolved in WATCHLIST.
- New patterns — something that hasn't appeared before. Add to WATCHLIST as "watch" item.
- Quality trends — are scores going up? Down? Flat? What changed?
- Pipeline efficiency — throughput, agent crashes, wasted cycles.
Step 3: Retrospective Team (when invoked with --retro)
Spawn a retrospective team where role representatives discuss improvements:
Team structure:
- You (teamcouch, Opus) — facilitator, evaluator, final decision maker
- Role reps (Sonnet subagents) — one per role that participated in the run
Each role rep:
- Reads their skill file (
.claude/skills/{role}/SKILL.md)
- Reads relevant reports
- Reads WATCHLIST.md
- Proposes specific, concrete improvements to their skill file
Facilitation rules:
- Each rep gets ONE round of proposals
- You evaluate each proposal against the evidence (reports, WATCHLIST)
- Accept proposals backed by 3+ report instances
- Defer proposals with only 1-2 instances to WATCHLIST for monitoring
- Reject proposals that contradict known-good patterns
Step 4: Apply Changes
For accepted proposals:
- Edit the skill file directly
- Add a comment block at the top of the change:
<!-- Teamcouch update YYYY-MM-DD: {brief description}
Evidence: reports {list of report filenames}
Pattern: {what was observed 3+ times} -->
- Update WATCHLIST.md (move resolved items, add new watches)
Step 5: Report
Add a "Teamcouch Review" section to the run report:
## Teamcouch Review
**Reviewed**: YYYY-MM-DD
**Reports analyzed**: {count} ({date range})
### Patterns Identified
- {pattern}: {occurrences} / {reports} — {action taken}
### Skill Updates Applied
- {skill}: {change description} (evidence: {reports})
### WATCHLIST Changes
- Added: {new items}
- Resolved: {items moved to resolved}
- Escalated: {items needing human attention}
### Recommendations for Human
- {anything requiring human decision}
Change the report's status from final to reviewed.
What to Look For (by Role)
Translator
- Gallicism frequency — are certain types recurring? Update the false friends list.
- Self-review effectiveness — are self-review catches declining? Pattern working.
- TranslationMemory usage — are translators finding and using established terms?
- Context exhaustion — are carnets too large for single agents?
OPS Reviewer
- False positive rate — is OPS "fixing" correct translations?
- Severity distribution — all B's suggests translator is strong; A's suggest problems.
- Catch rate — what real issues is the extra pass surfacing?
Editor (RED)
- Catch rate — what does RED find that TR + OPS missed?
- Fix-vs-flag ratio — is RED fixing directly or just flagging?
- Consistency — does RED quality vary across carnets?
Conductor (CON)
- Approval rate — high means pipeline is strong. Low means upstream issues.
- Score trends — should trend upward as skills improve.
- Rejection reasons — recurring rejections should trigger skill updates.
Evidence Requirements
| Action | Minimum Evidence |
|---|
| Update skill file | 3+ reports with same pattern |
| Add to WATCHLIST | 1 report (as "watch" item) |
| Remove from WATCHLIST | 3+ reports where issue didn't occur after fix |
| Recommend pipeline change | 5+ reports showing trend |
| Escalate to human | Any blocker or fundamental design question |
Report Reading Tips
- Frontmatter tells you the configuration — who, what, which skills
- Agent Lifecycle section is the richest signal — crashes and stalls reveal systemic issues
- Issues Encountered should reference WATCHLIST categories — if they don't, the operator may be seeing new patterns
- Proposed Changes from operators are hypotheses — validate against data before accepting
- Skill Version Hashes let you track which version of a skill was active when an issue occurred
Anti-Patterns
- Don't over-optimize — if quality is 0.93+, focus on efficiency, not pushing to 0.99
- Don't make skills longer — skills that are too detailed cause agents to spend more context reading them. Prefer concise, actionable guidance.
- Don't add rules for one-off issues — that's what WATCHLIST is for
- Don't remove working patterns — if something is in the skill because it solved a real problem, don't remove it unless the underlying issue is gone
- Don't blame agents — agents execute skills. If the output is bad, the skill needs improvement, not the agent.
