task-management

name: task-management description: How to maintain project task docs and handle "whats next" requests. Read this when the user asks whats next or at conversation start.

Task Management Workflow

🚨 MANDATORY: Update TASKS.md After Every Feature

After EVERY git commit that completes or adds a feature, IMMEDIATELY update .docs/TASKS.md:

1. Mark completed tasks as [x] with strikethrough and ✅ DONE
2. Add any new tasks that emerged from the work
3. Update architecture notes if the system changed

This is NOT optional. Do it right after git commit, before moving to the next task. Forgetting this breaks the entire task pipeline for future conversations.

When the user asks "whats next"

1. Read ALL .docs/TASKS.md files across active projects (starwar, geeksy-pumpfun-plugin, etc.)
2. Pick the highest-impact task — prioritize 🔴 Fix > 🟡 Improve > 🟢 Features
3. Check for uncommitted work first — if the active repo is dirty, commit it before doing anything else.
4. Just do it — don't ask permission, don't only describe the next step, and don't stop at a recommendation. Start implementing immediately.
5. Announce what you're doing in 1-2 lines, then start coding.

Task Doc Format

Every project should have a .docs/TASKS.md with this structure:

# Project Tasks & Ideas

## 🔴 Priority: Fix
- [ ] **Bug name** — Brief description of what's broken.

## 🟡 Priority: Improve  
- [ ] **Feature name** — What exists and what needs improvement.
- [x] ~~**Done feature**~~ — ✅ DONE. Brief note on what was done.

## 🟢 Priority: Features
- [ ] **New feature** — Description of desired behavior.

## 📝 Architecture Notes
- Key files, APIs, config locations, process names
- How to run, deploy, test

## ⚠️ Security Reminders
- What NOT to commit, expose, or put in public repos

When to Update Task Docs

• After completing a task: Mark it [x] with strikethrough and ✅ DONE
• ALWAYS add follow-up tasks: When you finish a task, immediately add any logical next steps as new unchecked tasks in the same TASKS.md. NEVER leave a project with zero open tasks — there's always something to improve, deploy, test, or build next. This is critical because new conversations rely on TASKS.md to know what to work on.
• When discovering bugs: Add to 🔴 Fix section
• When user mentions ideas: Add to appropriate section
• At end of conversation: Review and update all project task docs with current state
• When architecture changes: Update 📝 Notes section

The Golden Rule: Never Leave an Empty Backlog

When all tasks in a project are done, you MUST add new tasks before finishing. Think about:

• What would a senior developer suggest as next steps?
• Are there deployment/production tasks?
• Performance improvements?
• Testing gaps?
• UI polish or UX improvements?
• Documentation needs?

Add at least 2-3 concrete, actionable tasks. Do NOT just suggest them verbally to the user — write them into TASKS.md so the next conversation picks them up automatically.

Hidden Docs Location

• Each project has .docs/ directory (gitignored) OR docs/ directory
• Contains: TASKS.md, architecture notes, deployment info
• These persist across conversations — always read them first

At Conversation End

Before the user reloads or starts a new conversation:

1. Update all .docs/TASKS.md files with completed work and new discoveries
2. Add follow-up tasks for anything completed — never leave an empty backlog
3. Check for undocumented ideas the user mentioned during the session
4. Note any blockers or things that need user input
5. Verify running processes are stable (bgrun status)

Finding Task Docs

• Look for .docs/TASKS.md or docs/TASKS.md in each active workspace the user has open
• Scan all workspace roots listed in the user metadata
• If a project doesn't have a TASKS.md, create one after doing meaningful work on it