- Remove Wiki.js MCP server entirely - Add wiki, milestone, and dependency tools to Gitea MCP server - Add parallel execution support based on dependency graph - Add mandatory pre-planning validations (org check, labels, docs/changes) - Add CLI blocking rules to all agents (API-only) - Add standardized task naming: [Sprint XX] <type>: <description> - Add branch naming convention: feat/, fix/, debug/ prefixes - Add MR body template without subtasks - Add auto-close issues via commit keywords - Create claude-config-maintainer plugin for CLAUDE.md optimization - Update all sprint commands with new tools and workflows - Update documentation to remove Wiki.js references New MCP tools: - Wiki: list_wiki_pages, get_wiki_page, create_wiki_page, create_lesson, search_lessons - Milestones: list_milestones, get_milestone, create_milestone, update_milestone - Dependencies: list_issue_dependencies, create_issue_dependency, get_execution_order - Validation: validate_repo_org, get_branch_protection, create_label Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
7.3 KiB
description
| description |
|---|
| Complete sprint and capture lessons learned to Gitea Wiki |
Close Sprint and Capture Lessons Learned
This command completes the sprint and captures lessons learned to Gitea Wiki. This is critical - after 15 sprints without lesson capture, repeated mistakes occurred (e.g., Claude Code infinite loops 2-3 times on similar issues).
Why Lessons Learned Matter
Problem: Without systematic lesson capture, teams repeat the same mistakes:
- Claude Code infinite loops on similar issues (happened 2-3 times)
- Same architectural mistakes (multiple occurrences)
- Forgotten optimizations (re-discovered each time)
Solution: Mandatory lessons learned capture at sprint close, searchable at sprint start.
Sprint Close Workflow
The orchestrator agent will guide you through:
-
Review Sprint Completion
- Use
list_issuesto verify all issues are closed or moved to backlog - Check milestone completion status
- Check for incomplete work needing carryover
- Review overall sprint goals vs. actual completion
- Use
-
Capture Lessons Learned
- What went wrong and why
- What went right and should be repeated
- Preventable repetitions to avoid in future sprints
- Technical insights and gotchas discovered
-
Tag for Discoverability
- Apply relevant tags: technology, component, type of lesson
- Ensure future sprints can find these lessons via search
- Use consistent tagging for patterns
-
Save to Gitea Wiki
- Use
create_lessonto save lessons to Gitea Wiki - Create lessons in project wiki under
lessons-learned/sprints/ - Make lessons searchable for future sprints
- Use
-
Git Operations
- Commit any remaining work
- Merge feature branches if needed
- Clean up merged branches
- Tag sprint completion
-
Close Milestone
- Use
update_milestoneto close the sprint milestone - Document final completion status
- Use
MCP Tools Available
Gitea Tools:
list_issues- Review sprint issues (completed and incomplete)get_issue- Get detailed issue information for retrospectiveupdate_issue- Move incomplete issues to next sprint
Milestone Tools:
get_milestone- Get milestone statusupdate_milestone- Close milestone
Lessons Learned Tools (Gitea Wiki):
create_lesson- Create lessons learned entrysearch_lessons- Check for similar existing lessonslist_wiki_pages- Check existing lessons learnedget_wiki_page- Read existing lessons
Lesson Structure
Lessons should follow this structure:
# Sprint X - [Lesson Title]
## Context
[What were you trying to do? What was the sprint goal?]
## Problem
[What went wrong? What insight emerged? What challenge did you face?]
## Solution
[How did you solve it? What approach worked?]
## Prevention
[How can this be avoided or optimized in the future? What should future sprints know?]
## Tags
[Comma-separated tags for search: technology, component, type]
Example Lessons Learned
Example 1: Technical Gotcha
# Sprint 16 - Claude Code Infinite Loop on Validation Errors
## Context
Implementing input validation for authentication API endpoints.
## Problem
Claude Code entered an infinite loop when pytest validation tests failed.
The loop occurred because the error message didn't change between attempts,
causing Claude to retry the same fix repeatedly.
## Solution
Added more descriptive error messages to validation tests that specify
exactly what value failed and why. This gave Claude clear feedback
to adjust the approach rather than retrying the same fix.
## Prevention
- Always write validation test errors with specific values and expectations
- If Claude loops, check if error messages provide unique information per failure
- Add a "loop detection" check in test output (fail after 3 identical errors)
## Tags
testing, claude-code, validation, python, pytest, debugging
Example 2: Architectural Decision
# Sprint 14 - Extracting Services Too Early
## Context
Planning to extract Intuit Engine service from monolith.
## Problem
Initial plan was to extract immediately without testing the API boundaries
first. This would have caused integration issues discovered late.
## Solution
Added a sprint phase to:
1. Define clear API contracts first
2. Add integration tests for the boundaries
3. THEN extract the service
Delayed extraction by one sprint but avoided major rework.
## Prevention
- Always define API contracts before service extraction
- Write integration tests FIRST, extraction SECOND
- Don't rush architectural changes - test boundaries first
## Tags
architecture, service-extraction, refactoring, api-design, planning
Tagging Strategy
Use consistent tags for discoverability:
By Technology:
python,javascript,docker,postgresql,redis,vue,fastapi
By Component:
backend,frontend,api,database,auth,deploy,testing,docs
By Type:
bug,feature,refactor,architecture,performance,security
By Issue:
claude-code,validation,testing,debugging,deployment,configuration
By Pattern:
infinite-loop,edge-case,integration,boundaries,dependencies
Orchestrator's Role
The orchestrator agent will:
- Ask probing questions about the sprint
- Identify preventable mistakes vs. expected challenges
- Structure lessons in the proper format
- Suggest appropriate tags
- Create lessons in Gitea Wiki using
create_lesson - Ensure lessons are discoverable for future sprints
- Handle git operations and milestone closure
Example Sprint Close Session
User: /sprint-close
Orchestrator: Let's close the sprint and capture lessons learned.
First, let me review the sprint completion...
[Uses list_issues to check sprint status]
Sprint 18 Summary:
- 8 issues planned
- 7 completed (87.5%)
- 1 moved to backlog (#52: Deploy auth service - blocked by infra)
Great progress! Now, let's capture lessons learned.
What challenges did you face this sprint?
User: Claude Code got stuck in a loop when pytest validation tests failed
Orchestrator: That's a valuable lesson - this prevents future frustration.
Let me ask some clarifying questions:
1. What caused the loop? (Same error message repeated?)
2. How did you break out of it?
3. What would prevent this in future sprints?
[After gathering details]
I'll create this lesson with tags: testing, claude-code, validation, python, pytest, debugging
[Uses create_lesson to save to Gitea Wiki]
Lesson created: "Sprint 18 - Claude Code Infinite Loop on Validation Errors"
Saved to Gitea Wiki with appropriate tags.
Any other lessons from this sprint?
User: Yes, we discovered that JWT token refresh needs special handling
Orchestrator: Excellent - let's capture that too...
[Continues capturing lessons]
All lessons captured! They'll be searchable when planning future sprints.
Would you like me to handle git operations?
- Commit any remaining changes
- Merge feature branches to development
- Tag sprint completion (v0.18.0)
- Clean up merged branches
- Close milestone
[Y/n]
Getting Started
Simply run /sprint-close when your sprint is complete. The orchestrator will guide you through:
- Sprint review
- Lessons learned capture
- Gitea Wiki updates
- Git operations
- Milestone closure
Don't skip this step! Future sprints will thank you for capturing these insights.