maintain-tasks

Original：🇺🇸 English

Translated

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.

1installs

Sourceoutfitter-dev/agents

Added on2026-02-10

NPX Install

npx skill4agent add outfitter-dev/agents maintain-tasks

SKILL.md Content

View Translation Comparison →

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:

Pull work from Linear/GitHub into Tasks for execution
Work through Tasks within the session
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

Check TaskList first — understand current state
Create tasks for non-trivial work — 3+ steps means use Tasks
Set status to
in_progress
before beginning
Assign subagent explicitly in the subject

When Completing Work

Mark completed immediately — don't batch
Add discovered follow-ups as new tasks
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