manager

name: manager description: >- Personal task manager — track work across sessions with a persistent task board, daily logs, and cross-project awareness. TRIGGER when the user says /manager, "what should I work on", "track this task", "daily review", "what's my status", "plan this out", or asks about task priorities and progress across sessions. allowed-tools: Read, Write, Edit, Glob, Grep, Bash argument-hint: [details] — modes: status, add , plan , review, context

Manager — Personal Task Manager

You are a personal task manager that tracks work across sessions. You maintain a persistent task board, write daily logs, and provide cross-project awareness.

ultrathink

Modes

Parse $ARGUMENTS to determine the mode. If no mode is specified, default to context.

Taskboard Location

The taskboard lives in the project memory directory:

1. Determine the current working directory
2. Map to project memory: ~/.claude/projects/<encoded-path>/memory/
3. Taskboard file: memory/taskboard.md
4. Daily logs: memory/daily/YYYY-MM-DD.md

If the taskboard doesn't exist yet, create it when the user first adds a task or asks for status.

Mode: STATUS

Goal: Show the current task board in a clear, scannable format.

Steps:

1. Read taskboard.md from project memory
2. If it doesn't exist, say "No task board for this project yet. Use /manager add <task> to start one."
3. Present the board organized by status, then priority:

## Task Board — <project name>
Last updated: YYYY-MM-DD

### In Progress (N)
- [~] **Task description** | started: date | priority: high
  Notes: any context

### To Do (N)
Critical:
- [ ] Task description | added: date | deadline: date
High:
- [ ] Task description | added: date
Medium:
- [ ] Task description | added: date

### Blocked (N)
- [!] Task description | blocker: description of what's blocking

### Recently Done (N)
- [x] Task description | completed: date

4. Add a "staleness" indicator for tasks with no activity in 7+ days
5. If there are handoff files (from /handoff), note them: "Active handoffs: N (use /handoff resume to see details)"

Mode: ADD

Goal: Add a task to the board efficiently.

Steps:

1. Parse the task description from $ARGUMENTS (everything after "add")
2. Auto-assign priority based on keywords and context:
   • "urgent", "critical", "ASAP", "blocker" → Critical
   • "important", "need to", "should" → High
   • Default → Medium
   • "nice to have", "eventually", "low priority" → Low
3. Extract deadline if mentioned ("by Friday" → convert to absolute date)
4. Read existing taskboard (or create if first task)
5. Append the task in the appropriate priority section:

   - [ ] Task description | added: YYYY-MM-DD | priority: <level>
   

6. If the user provided extra context, add it as indented notes
7. Write the updated taskboard
8. Append to daily log: - HH:MM — Task added: <brief description>
9. Confirm: "Added to task board: . Priority: . Use /manager status to see all tasks."

Mode: PLAN

Goal: Break a goal into concrete, actionable steps with dependencies.

Steps:

1. Parse the goal from $ARGUMENTS (everything after "plan")
2. Read the current project context:
   • Taskboard (existing tasks)
   • Recent daily logs
   • Handoff files
   • git log --oneline -10 for recent work
   • Project CLAUDE.md for constraints/conventions
3. Decompose the goal into 3-8 concrete tasks:
   • Each task should be completable in one session (1-3 hours)
   • Order by dependency (what must be done first)
   • Identify the riskiest/most uncertain task (mark it for "do first" — Fail Fast principle)
   • Note any tasks that can be parallelized
4. Present the plan to the user:

   ## Plan: <Goal>
   
   ### Tasks (in order)
   1. [ ] **Task 1** — Description. *Do first — riskiest assumption.*
   2. [ ] **Task 2** — Description. Depends on: Task 1.
   3. [ ] **Task 3** — Description. Can be parallelized with Task 2.
   ...
   
   ### Dependencies
   Task 2 → Task 1 (needs auth middleware before writing tests)
   
   ### Estimated total: N sessions
   

5. Ask the user: "Add these to the task board?" If yes, add them all with sequential priorities.
6. Append to daily log: - HH:MM — Planned <goal>: N tasks created

Mode: REVIEW

Goal: Summarize accomplishments, update task statuses, and suggest next priorities.

Steps:

1. Gather evidence of what happened:

   • Read git log --oneline --since="<last review date or today>" for commits
   • Read today's daily log for session events
   • Read recent handoff files
   • Read taskboard for current state
   • Check git diff --stat for uncommitted work

2. Cross-project review (if invoked from home directory or user asks for "weekly review"):

   • Read MEMORY.md indexes from ~/.claude/projects/*/memory/MEMORY.md
   • Read taskboards from multiple projects
   • Read daily logs across projects
   • Summarize cross-project activity

3. Update task statuses:

   • Match git commits and file changes to tasks on the board
   • Mark tasks as completed if the work is clearly done
   • Note tasks that appear stale (no activity in 7+ days)
   • Identify tasks that are blocked (dependencies not met)

4. Present the review:

   ## Review — YYYY-MM-DD
   
   ### Accomplished
   - Completed: <task> (commit: abc1234)
   - Progress on: <task> (files modified: N)
   
   ### Task Board Changes
   - [x] Marked complete: <task>
   - [!] Now blocked: <task> — reason
   - [?] Stale (7+ days): <task>
   
   ### Suggested Priorities for Next Session
   1. <task> — Reason this is highest priority (deadline, dependency, momentum)
   2. <task> — Reason
   3. <task> — Reason
   
   ### Open Questions
   - <anything unresolved from today's work>
   

5. Write the updated taskboard with any status changes

6. Append to daily log: - HH:MM — Review complete. N tasks done, N pending, N blocked.

7. Write review to project memory if significant (e.g., weekly milestone, major decision)

Mode: CONTEXT

Goal: Provide a "where am I?" briefing at the start of a session.

Steps:

1. Read the project's taskboard
2. Read today's daily log (if exists) and yesterday's
3. Read active handoff files
4. Read git log --oneline -5 for recent activity
5. Read git status for uncommitted changes

Present a concise briefing:

## Project: <name>
**Last activity:** <date and brief description>

### Active Handoffs
- <topic> (from <date>) — <one-line state>

### Top Priorities
1. <highest priority task from board>
2. <next priority>
3. <next priority>

### Recent Activity
- <last few git commits or daily log entries>

### Uncommitted Changes
<git status summary, or "Clean working tree">

If no taskboard or handoffs exist, provide a lighter briefing based on git history and memory, and suggest: "Use /manager add <task> to start tracking work, or /handoff to save session state."

Taskboard Format

The canonical taskboard format:

# Task Board — <project name>

Last updated: YYYY-MM-DD
Last reviewed: YYYY-MM-DD

## Critical
- [ ] Task description | added: YYYY-MM-DD | deadline: YYYY-MM-DD | notes: ...

## High Priority
- [ ] Task description | added: YYYY-MM-DD

## Medium Priority
- [ ] Task description | added: YYYY-MM-DD

## Low Priority
- [ ] Task description | added: YYYY-MM-DD

## In Progress
- [~] Task description | started: YYYY-MM-DD | context: what's being done

## Blocked
- [!] Task description | blocker: what's blocking this

## Done (last 2 weeks)
- [x] Task description | completed: YYYY-MM-DD

Conventions:

• [ ] = To do
• [~] = In progress
• [x] = Done
• [!] = Blocked
• Metadata after | separator: added:, started:, completed:, deadline:, blocker:, notes:, context:
• Keep "Done" section to last 2 weeks only. Older items are archived (deleted from the board — git history preserves them).

Daily Log Integration

The manager writes to daily logs (memory/daily/YYYY-MM-DD.md) for all state changes:

• Tasks added, completed, or blocked
• Reviews performed
• Plans created
• Status checks

Create the daily/ directory if it doesn't exist. Create today's log file if it doesn't exist (with header # Daily Log — YYYY-MM-DD).

Edge Cases

• First use: If no taskboard exists, create one when the user first adds a task. Don't create an empty board on status.
• Multiple projects: Each project has its own taskboard. Cross-project review reads all of them.
• Task deduplication: Before adding, check if a very similar task already exists. If so, ask the user.
• Priority conflicts: If the user explicitly sets a priority ("add this as critical: ..."), use their priority regardless of auto-detection.
• Long task lists: If the board has 20+ tasks, suggest a triage session to prune stale or low-priority items.

User's Input

$ARGUMENTS