📦 deps(thirdparty): update snapshots
This commit is contained in:
ci[bot]
@@ -0,0 +1,175 @@
|
||||
---
|
||||
name: maintain-tasks
|
||||
description: Task management for session continuity. Use when coordinating multi-step work, managing subagent assignments, or preserving intent across compaction. Triggers on "track tasks", "manage work", "coordinate agents", or when complex work requires sequencing.
|
||||
user-invocable: false
|
||||
---
|
||||
|
||||
# Task Management for Session Continuity
|
||||
|
||||
Tasks are your **working memory that survives compaction**. Use them to maintain intent, sequence, and coordination across the natural lifecycle of a session.
|
||||
|
||||
## Tasks vs Issue Trackers
|
||||
|
||||
| Tool | Purpose | Scope |
|
||||
|------|---------|-------|
|
||||
| **Tasks** | Session/project working memory | Current effort, active coordination |
|
||||
| **Linear/GitHub** | Team-visible project management | Cross-session, multi-person tracking |
|
||||
|
||||
Tasks are NOT a replacement for filing issues. They are your **local execution state** — what you're doing now, what comes next, who (which agent) is responsible.
|
||||
|
||||
**Sync pattern:**
|
||||
1. Pull work from Linear/GitHub into Tasks for execution
|
||||
2. Work through Tasks within the session
|
||||
3. Update Linear/GitHub at completion boundaries
|
||||
|
||||
## Why Tasks Survive Compaction
|
||||
|
||||
When context compacts, conversation history gets summarized. But Tasks persist in full:
|
||||
|
||||
- Task subjects and descriptions remain intact
|
||||
- Dependencies (`blockedBy`, `blocks`) preserved
|
||||
- Status (`pending`, `in_progress`, `completed`) preserved
|
||||
- **Subagent assignments preserved** (critical — see below)
|
||||
|
||||
This means after compaction, you can read TaskList and know exactly where you were, what's next, and who's responsible.
|
||||
|
||||
## Subagent Assignment (Critical)
|
||||
|
||||
**Always assign subagents explicitly in task subjects.**
|
||||
|
||||
After compaction, nuanced instructions like "have the reviewer check this" can lose fidelity. Explicit assignment survives:
|
||||
|
||||
```
|
||||
[engineer] Implement auth refresh endpoint
|
||||
[reviewer] Review auth implementation for security
|
||||
[tester] Validate auth flow end-to-end
|
||||
```
|
||||
|
||||
The `[agent-name]` prefix is not decoration — it's **recoverable intent**. After compaction, you can scan TaskList and immediately know which agent handles each task.
|
||||
|
||||
### Assignment Patterns
|
||||
|
||||
```
|
||||
# Explicit agent assignment
|
||||
[engineer] Build the feature
|
||||
[analyst] Research the approach
|
||||
[reviewer] Check for issues
|
||||
[tester] Validate behavior
|
||||
|
||||
# Background agents (include task ID for retrieval)
|
||||
[reviewer:background] Security audit (task-id: abc123)
|
||||
|
||||
# Resumable agents (include agent ID)
|
||||
[analyst] Continue research (resume: a7227ac)
|
||||
```
|
||||
|
||||
## Task Dependencies
|
||||
|
||||
Use `blockedBy` and `blocks` to encode sequence:
|
||||
|
||||
```
|
||||
Task 1: [analyst] Research auth patterns
|
||||
Task 2: [engineer] Implement auth flow (blockedBy: 1)
|
||||
Task 3: [reviewer] Review implementation (blockedBy: 2)
|
||||
Task 4: [tester] Validate auth (blockedBy: 3)
|
||||
```
|
||||
|
||||
After compaction, dependencies tell you what's actionable (no blockers) vs what's waiting.
|
||||
|
||||
## Required Discipline
|
||||
|
||||
### When Starting Work
|
||||
|
||||
1. **Check TaskList first** — understand current state
|
||||
2. **Create tasks for non-trivial work** — 3+ steps means use Tasks
|
||||
3. **Set status to `in_progress`** before beginning
|
||||
4. **Assign subagent explicitly** in the subject
|
||||
|
||||
### When Completing Work
|
||||
|
||||
1. **Mark completed immediately** — don't batch
|
||||
2. **Add discovered follow-ups** as new tasks
|
||||
3. **Check for unblocked tasks** — completing one may unblock others
|
||||
|
||||
### Before Compaction
|
||||
|
||||
As context fills, ensure Tasks reflect:
|
||||
- What's done (completed tasks)
|
||||
- What's active (single `in_progress` task)
|
||||
- What's discovered (new tasks from implementation)
|
||||
- What's blocked and why
|
||||
|
||||
## Task Structure
|
||||
|
||||
```
|
||||
Subject: [agent] Imperative action description
|
||||
Description:
|
||||
- Context needed to execute
|
||||
- Acceptance criteria
|
||||
- Any constraints or considerations
|
||||
ActiveForm: Present continuous for spinner ("Implementing auth flow")
|
||||
```
|
||||
|
||||
**Subject format:** `[agent-name] Verb the thing`
|
||||
- `[engineer] Implement JWT refresh logic`
|
||||
- `[reviewer] Audit auth module for vulnerabilities`
|
||||
- `[analyst] Research rate limiting approaches`
|
||||
|
||||
**Description includes:**
|
||||
- Enough context for the assigned agent to proceed independently
|
||||
- Clear done criteria
|
||||
- Dependencies or blockers if not captured in `blockedBy`
|
||||
|
||||
## Coordination Patterns
|
||||
|
||||
### Sequential Handoff
|
||||
|
||||
```
|
||||
1. [analyst] Research → creates findings
|
||||
2. [engineer] Implement → uses findings (blockedBy: 1)
|
||||
3. [reviewer] Review → checks implementation (blockedBy: 2)
|
||||
4. [tester] Validate → confirms behavior (blockedBy: 3)
|
||||
```
|
||||
|
||||
### Parallel Execution
|
||||
|
||||
```
|
||||
1. [engineer] Implement feature A
|
||||
2. [engineer] Implement feature B
|
||||
3. [tester] Integration tests (blockedBy: 1, 2)
|
||||
```
|
||||
|
||||
Tasks 1 and 2 can run in parallel; Task 3 waits for both.
|
||||
|
||||
### Iterative Refinement
|
||||
|
||||
```
|
||||
1. [engineer] Initial implementation
|
||||
2. [reviewer] Review round 1 (blockedBy: 1)
|
||||
3. [engineer] Address feedback (blockedBy: 2)
|
||||
4. [reviewer] Review round 2 (blockedBy: 3)
|
||||
```
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
| Anti-Pattern | Why It Fails | Better Approach |
|
||||
|--------------|--------------|-----------------|
|
||||
| No agent assignment | Lost after compaction | Always prefix with `[agent]` |
|
||||
| Vague subjects | Can't recover intent | Specific, actionable subjects |
|
||||
| Batching completions | State becomes stale | Mark done immediately |
|
||||
| Skipping for "quick" tasks | Consistency matters | If 3+ steps, use Tasks |
|
||||
| No dependencies | Unclear sequence | Encode with `blockedBy` |
|
||||
|
||||
## Rules
|
||||
|
||||
ALWAYS:
|
||||
- Assign subagent explicitly in task subject: `[agent] Task description`
|
||||
- Use dependencies to encode sequence
|
||||
- Mark `in_progress` before starting, `completed` when done
|
||||
- Check TaskList after compaction to recover state
|
||||
|
||||
NEVER:
|
||||
- Use Tasks as a replacement for Linear/GitHub issues
|
||||
- Leave multiple tasks `in_progress` simultaneously
|
||||
- Skip agent assignment ("the main agent will figure it out")
|
||||
- Batch task completions at end of work
|
||||
Reference in New Issue
Block a user