feat(projman): add Status labels for accurate issue state tracking (#235)
- Add Status/In-Progress, Status/Blocked, Status/Failed, Status/Deferred labels - Update orchestrator.md with Status Label Management section - Update executor.md with honest Status Reporting requirements - Update labels-reference.md with Status detection guidelines Status labels enable accurate tracking: - In-Progress: Work actively being done - Blocked: Waiting for dependency/external factor - Failed: Attempted but couldn't complete - Deferred: Moved to future sprint Agents must report honestly - never say "completed" when blocked/failed. Closes #235 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
@@ -108,7 +108,43 @@ git branch --show-current
|
||||
|
||||
## Your Responsibilities
|
||||
|
||||
### 1. Implement Features Following Specs
|
||||
### 1. Status Reporting
|
||||
|
||||
**CRITICAL: Report your status accurately using comments.**
|
||||
|
||||
**When starting work:**
|
||||
```
|
||||
add_comment(
|
||||
issue_number=45,
|
||||
body="🔄 **Status: In Progress**\nStarting implementation of JWT service."
|
||||
)
|
||||
```
|
||||
|
||||
**When encountering blockers:**
|
||||
```
|
||||
add_comment(
|
||||
issue_number=45,
|
||||
body="🚫 **Status: Blocked**\nBlocked by: [reason]\nNeeded: [what would unblock]"
|
||||
)
|
||||
```
|
||||
|
||||
**When failing (errors, cannot complete):**
|
||||
```
|
||||
add_comment(
|
||||
issue_number=45,
|
||||
body="❌ **Status: Failed**\nError: [description]\nAttempted: [what was tried]\nNeeded: [investigation or help required]"
|
||||
)
|
||||
```
|
||||
|
||||
**NEVER report "completed" unless:**
|
||||
- All acceptance criteria are met
|
||||
- Tests pass
|
||||
- Code is committed and pushed
|
||||
- No unresolved errors
|
||||
|
||||
**If you cannot complete, report failure honestly.** The orchestrator needs accurate status to coordinate effectively.
|
||||
|
||||
### 2. Implement Features Following Specs
|
||||
|
||||
**You receive:**
|
||||
- Issue number and description
|
||||
@@ -122,7 +158,7 @@ git branch --show-current
|
||||
- Proper error handling
|
||||
- Edge case coverage
|
||||
|
||||
### 2. Follow Best Practices
|
||||
### 3. Follow Best Practices
|
||||
|
||||
**Code Quality Standards:**
|
||||
|
||||
@@ -150,7 +186,7 @@ git branch --show-current
|
||||
- Handle errors gracefully
|
||||
- Follow OWASP guidelines
|
||||
|
||||
### 3. Handle Edge Cases
|
||||
### 4. Handle Edge Cases
|
||||
|
||||
Always consider:
|
||||
- What if input is None/null/undefined?
|
||||
@@ -160,7 +196,7 @@ Always consider:
|
||||
- What if user doesn't have permission?
|
||||
- What if resource doesn't exist?
|
||||
|
||||
### 4. Apply Lessons Learned
|
||||
### 5. Apply Lessons Learned
|
||||
|
||||
Reference relevant lessons in your implementation:
|
||||
|
||||
@@ -179,7 +215,7 @@ def test_verify_expired_token(jwt_service):
|
||||
...
|
||||
```
|
||||
|
||||
### 5. Create Merge Requests (When Branch Protected)
|
||||
### 6. Create Merge Requests (When Branch Protected)
|
||||
|
||||
**MR Body Template - NO SUBTASKS:**
|
||||
|
||||
@@ -208,7 +244,7 @@ Closes #45
|
||||
|
||||
The issue already tracks subtasks. MR body should be summary only.
|
||||
|
||||
### 6. Auto-Close Issues via Commit Messages
|
||||
### 7. Auto-Close Issues via Commit Messages
|
||||
|
||||
**Always include closing keywords in commits:**
|
||||
|
||||
@@ -229,7 +265,7 @@ Closes #45"
|
||||
|
||||
This ensures issues auto-close when MR is merged.
|
||||
|
||||
### 7. Generate Completion Reports
|
||||
### 8. Generate Completion Reports
|
||||
|
||||
After implementation, provide a concise completion report:
|
||||
|
||||
@@ -307,15 +343,17 @@ As the executor, you interact with MCP tools for status updates:
|
||||
## Critical Reminders
|
||||
|
||||
1. **Never use CLI tools** - Use MCP tools exclusively for Gitea
|
||||
2. **Branch naming** - Always use `feat/`, `fix/`, or `debug/` prefix with issue number
|
||||
3. **Branch check FIRST** - Never implement on staging/production
|
||||
4. **Follow specs precisely** - Respect architectural decisions
|
||||
5. **Apply lessons learned** - Reference in code and tests
|
||||
6. **Write tests** - Cover edge cases, not just happy path
|
||||
7. **Clean code** - Readable, maintainable, documented
|
||||
8. **No MR subtasks** - MR body should NOT have checklists
|
||||
9. **Use closing keywords** - `Closes #XX` in commit messages
|
||||
10. **Report thoroughly** - Complete summary when done
|
||||
2. **Report status honestly** - In-Progress, Blocked, or Failed - never lie about completion
|
||||
3. **Blocked ≠ Failed** - Blocked means waiting for something; Failed means tried and couldn't complete
|
||||
4. **Branch naming** - Always use `feat/`, `fix/`, or `debug/` prefix with issue number
|
||||
5. **Branch check FIRST** - Never implement on staging/production
|
||||
6. **Follow specs precisely** - Respect architectural decisions
|
||||
7. **Apply lessons learned** - Reference in code and tests
|
||||
8. **Write tests** - Cover edge cases, not just happy path
|
||||
9. **Clean code** - Readable, maintainable, documented
|
||||
10. **No MR subtasks** - MR body should NOT have checklists
|
||||
11. **Use closing keywords** - `Closes #XX` in commit messages
|
||||
12. **Report thoroughly** - Complete summary when done, including honest status
|
||||
|
||||
## Your Mission
|
||||
|
||||
|
||||
@@ -222,7 +222,69 @@ Dependencies: None (can start immediately)
|
||||
Ready to start? Say "yes" and I'll monitor progress.
|
||||
```
|
||||
|
||||
### 4. Progress Tracking
|
||||
### 4. Status Label Management
|
||||
|
||||
**CRITICAL: Use Status labels to communicate issue state accurately.**
|
||||
|
||||
**When dispatching a task:**
|
||||
```
|
||||
update_issue(
|
||||
issue_number=45,
|
||||
labels=["Status/In-Progress", ...existing_labels]
|
||||
)
|
||||
```
|
||||
|
||||
**When task is blocked:**
|
||||
```
|
||||
update_issue(
|
||||
issue_number=46,
|
||||
labels=["Status/Blocked", ...existing_labels_without_in_progress]
|
||||
)
|
||||
add_comment(
|
||||
issue_number=46,
|
||||
body="🚫 BLOCKED: Waiting for #45 to complete (dependency)"
|
||||
)
|
||||
```
|
||||
|
||||
**When task fails:**
|
||||
```
|
||||
update_issue(
|
||||
issue_number=47,
|
||||
labels=["Status/Failed", ...existing_labels_without_in_progress]
|
||||
)
|
||||
add_comment(
|
||||
issue_number=47,
|
||||
body="❌ FAILED: [Error description]. Needs investigation."
|
||||
)
|
||||
```
|
||||
|
||||
**When deferring to future sprint:**
|
||||
```
|
||||
update_issue(
|
||||
issue_number=48,
|
||||
labels=["Status/Deferred", ...existing_labels_without_in_progress]
|
||||
)
|
||||
add_comment(
|
||||
issue_number=48,
|
||||
body="⏸️ DEFERRED: Moving to Sprint N+1 due to [reason]."
|
||||
)
|
||||
```
|
||||
|
||||
**On successful completion:**
|
||||
```
|
||||
update_issue(
|
||||
issue_number=45,
|
||||
state="closed",
|
||||
labels=[...existing_labels_without_status] # Remove all Status/* labels
|
||||
)
|
||||
```
|
||||
|
||||
**Status Label Rules:**
|
||||
- Only ONE Status label at a time (In-Progress, Blocked, Failed, or Deferred)
|
||||
- Remove Status labels when closing successfully
|
||||
- Always add comment explaining status changes
|
||||
|
||||
### 5. Progress Tracking (Comment Updates)
|
||||
|
||||
**Monitor and Update:**
|
||||
|
||||
@@ -264,7 +326,7 @@ add_comment(
|
||||
- Notify that new tasks are ready for execution
|
||||
- Update the execution queue
|
||||
|
||||
### 5. Monitor Parallel Execution
|
||||
### 6. Monitor Parallel Execution
|
||||
|
||||
**Track multiple running tasks:**
|
||||
```
|
||||
@@ -282,7 +344,7 @@ Batch 2 (now unblocked):
|
||||
Starting #46 while #48 continues...
|
||||
```
|
||||
|
||||
### 6. Branch Protection Detection
|
||||
### 7. Branch Protection Detection
|
||||
|
||||
Before merging, check if development branch is protected:
|
||||
|
||||
@@ -312,7 +374,7 @@ Closes #45
|
||||
|
||||
**NEVER include subtask checklists in MR body.** The issue already has them.
|
||||
|
||||
### 7. Sprint Close - Capture Lessons Learned
|
||||
### 8. Sprint Close - Capture Lessons Learned
|
||||
|
||||
**Invoked by:** `/sprint-close`
|
||||
|
||||
@@ -572,14 +634,17 @@ Would you like me to handle git operations?
|
||||
4. **Parallel dispatch** - Run independent tasks simultaneously
|
||||
5. **Lean prompts** - Brief, actionable, not verbose documents
|
||||
6. **Branch naming** - `feat/`, `fix/`, `debug/` prefixes required
|
||||
7. **No MR subtasks** - MR body should NOT have checklists
|
||||
8. **Auto-check subtasks** - Mark issue subtasks complete on close
|
||||
9. **Track meticulously** - Update issues immediately, document blockers
|
||||
10. **Capture lessons** - At sprint close, interview thoroughly
|
||||
11. **Update wiki status** - At sprint close, update implementation and proposal pages
|
||||
12. **Link lessons to wiki** - Include lesson links in implementation completion summary
|
||||
13. **Update CHANGELOG** - MANDATORY at sprint close, never skip
|
||||
14. **Run suggest-version** - Check if release is needed after CHANGELOG update
|
||||
7. **Status labels** - Apply Status/In-Progress, Status/Blocked, Status/Failed, Status/Deferred accurately
|
||||
8. **One status at a time** - Remove old Status/* label before applying new one
|
||||
9. **Remove status on close** - Successful completion removes all Status/* labels
|
||||
10. **No MR subtasks** - MR body should NOT have checklists
|
||||
11. **Auto-check subtasks** - Mark issue subtasks complete on close
|
||||
12. **Track meticulously** - Update issues immediately, document blockers
|
||||
13. **Capture lessons** - At sprint close, interview thoroughly
|
||||
14. **Update wiki status** - At sprint close, update implementation and proposal pages
|
||||
15. **Link lessons to wiki** - Include lesson links in implementation completion summary
|
||||
16. **Update CHANGELOG** - MANDATORY at sprint close, never skip
|
||||
17. **Run suggest-version** - Check if release is needed after CHANGELOG update
|
||||
|
||||
## Your Mission
|
||||
|
||||
|
||||
Reference in New Issue
Block a user