after-task
Mandatory knowledge capture after completing work. Documents solution in Graphiti and tracks effectiveness for system improvement.
When & Why to Use This Skill
The 'after-task' skill is a mandatory knowledge capture framework designed to bridge the gap between task completion and long-term institutional memory. It automates the documentation of technical solutions, architectural decisions, and 'gotchas' into a structured knowledge graph (Graphiti). By enforcing a post-work reflection phase, it prevents knowledge loss, reduces technical debt, and creates a self-improving feedback loop that makes future development cycles exponentially faster and more reliable.
Use Cases
- Post-Bug Fix Analysis: Documenting the root cause of complex bugs and specific workarounds to ensure the same issue doesn't resurface in future sprints.
- Feature Implementation Archiving: Recording the high-level approach and specific file modifications after completing a spec to provide context for future refactoring or PR reviews.
- Architectural Decision Tracking: Capturing the rationale behind major refactors, such as state machine changes, to maintain system integrity as the team scales.
- Agent Performance Optimization: Tracking the effectiveness of various MCP tools used during a task to help the orchestrator improve tool recommendations for future sessions.
- Knowledge Handoff: Creating a searchable repository of 'Key Learnings' and 'Gotchas' that serves as an automated onboarding and reference guide for other developers.
| name | after-task |
|---|---|
| description | Mandatory knowledge capture after completing work. Documents solution in Graphiti and tracks effectiveness for system improvement. |
@after-task - Knowledge Capture
Use AFTER:
- Spec completed and tests passing
- Pre-push hook succeeded
- Before creating PR or merging
- Complex bug fixed
- Major refactoring done
MANDATORY - Don't skip this! Future you will thank you.
What It Does
1. Document solution in Graphiti (group_id="screengraph")
- Problem statement
- Solution approach
- Key learnings and gotchas
- Files modified
- Related specs/bugs
2. Optional: Track MCP effectiveness
- Which MCPs were actually used
- What worked well
- What could be better
Token cost: ~600 tokens
Frequency: Once per spec/major-task
ROI: Future specs benefit = exponential improvement
Execution
Mandatory: Document in Graphiti
add_memory({
name: "[Spec/Bug Number]: [Short Title]",
episode_body: `
[Tags: domain, type, technology]
**Problem**: [What we were trying to solve]
**Solution**: [High-level approach, not code details]
**Key Learnings**:
- [Learning 1]
- [Learning 2]
**Gotchas**:
- [Gotcha 1 with workaround]
- [Gotcha 2 with workaround]
**Files Modified**:
- [file 1]
- [file 2]
**Tests Added**:
- [test file 1]
**Related**: [Spec-XXX, BUG-YYY, FR-ZZZ]
**Date**: [YYYY-MM-DD]
`,
group_id: "screengraph",
source: "text"
});
Optional: Track MCP Effectiveness
track_effectiveness({
task: "[Original task description]",
mcps_used: ["graphiti", "encore-mcp", "svelte"],
outcome: "helpful", // or "partially_helpful" or "not_helpful"
feedback: "[What worked well or what was missing]"
});
This helps the orchestrator learn and improve recommendations!
Template for Common Scenarios
Completed Spec
add_memory({
name: "Spec-001: Automate Appium Lifecycle",
episode_body: `
[Tags: spec, backend, appium, devops, lifecycle]
**Problem**: Manual Appium server management was error-prone and time-consuming
**Solution**:
- Created lifecycle management service
- Automated start/stop/health-check
- Integration with agent setup flow
**Key Learnings**:
- Appium sessions need explicit health monitoring
- Port conflicts must be detected before starting
- Process management requires PID tracking
**Gotchas**:
- Appium doesn't expose ready signal (must poll /status)
- Zombie processes if not cleaned up properly
- Port 4723 conflicts with other Appium instances
**Files Modified**:
- backend/appium/lifecycle.service.ts
- backend/agent/nodes/setup/EnsureDevice/node.ts
- .cursor/commands/backend/Taskfile.yml
**Tests Added**:
- backend/appium/tests/lifecycle.test.ts
**Related**: Spec-001
**Date**: 2025-11-13
`,
group_id: "screengraph",
source: "text"
});
Bug Fixed
add_memory({
name: "BUG-015: Agent Stalls on Privacy Consent Dialog",
episode_body: `
[Tags: bug, backend, agent, appium, dialogs]
**Problem**: Agent hung when app showed privacy consent modal
**Solution**:
- Added pre-flight dialog detection
- User prompted to handle consent manually
- Check runs before policy execution starts
**Key Learnings**:
- First-run experience often has modals
- Can't automate all user interactions
- Human-in-loop pattern works well
**Gotchas**:
- Different apps have different consent flows
- Some dialogs block entire UI hierarchy
- Must check BEFORE starting automation
**Files Modified**:
- backend/agent/nodes/setup/EnsureDevice/device-check.ts
**Related**: BUG-015, Spec-001
**Date**: 2025-11-13
`,
group_id: "screengraph",
source: "text"
});
Refactoring
add_memory({
name: "Refactor: Agent State Machine to Single Sink Pattern",
episode_body: `
[Tags: refactor, backend, agent, architecture]
**Problem**: Multiple terminal states added complexity
**Solution**:
- Single "completed" state
- stopReason field captures why (success/error/canceled)
- Frontend uses stopReason for UI decisions
**Key Learnings**:
- Simpler state machines are easier to debug
- stopReason pattern is flexible
- Database schema aligned with code
**Gotchas**:
- Must migrate existing runs to new pattern
- Frontend needs update to check stopReason
**Files Modified**:
- backend/agent/machine/AgentMachine.ts
- backend/db/migrations/008_single_sink.up.sql
- frontend/src/routes/runs/[runId]/+page.svelte
**Related**: Architecture decision docs
**Date**: 2025-11-05
`,
group_id: "screengraph",
source: "text"
});
Integration Points
After Pre-Push
# Pre-push succeeded
git push origin feature-X
# Now document (BEFORE creating PR)
@after-task [completed spec/task]
# Review documentation template
# Fill in learnings
# Add to Graphiti
After PR Merge
# PR merged to main
# Document if not done already
@after-task [completed work]
Quality Standards
Good documentation includes:
- ✅ Clear problem statement
- ✅ High-level solution (not code details)
- ✅ Specific gotchas with workarounds
- ✅ ALL files modified
- ✅ Related specs/bugs linked
- ✅ Proper tags for categorization
Bad documentation:
- ❌ Just code snippets
- ❌ No gotchas mentioned
- ❌ Vague problem statement
- ❌ Missing file references
- ❌ No tags
Why This is Mandatory
If you skip @after-task:
- ❌ Knowledge is lost
- ❌ Next person hits same gotchas
- ❌ Patterns aren't discovered
- ❌ System doesn't improve
If you run @after-task:
- ✅ Knowledge compounds
- ✅ Future specs are faster
- ✅ Gotchas documented once, avoided forever
- ✅ System gets exponentially smarter
Future you will thank present you.
Enforcement
From founder_rules.mdc:
**After Completing Task:**
1. ✅ Document solution via Graphiti
2. ✅ Include: problem, solution, gotchas, files
3. ✅ Use tags for organization
This isn't optional. It's how the system improves.
Purpose: Capture institutional knowledge so future work benefits from past work. The self-improvement loop closes here.