메뉴
Solo dev sprint planning and task management with Plane. Use when planning sprints, sizing tasks, managing the backlog, or structuring work for ADHD productivity patterns. Not Agile — solo dev workflow.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Declare what the system should be before writing code. Use when building new features, redesigning feature areas, or making significant changes that need a declaration of intent. Guides the declaration chain from findings through plans.
Wear the QA hat — think about quality the way a 15-year senior QA thinks. Use when building features, reviewing work, validating output, or when anything feels "done" but hasn't been proven to work. Prevents the gap between "it runs" and "it works."
Evidence-first research with mandatory citations and source evaluation. Use when gathering information for decisions, comparing approaches, investigating unknowns, or any task requiring verified evidence from multiple sources. Invoke at the START of research, not when writing up results.
Check and invoke available skills before starting work. Invoke at the start of any task to ensure relevant skills are loaded.
Effective Mermaid diagrams. Use when creating markdown documents with human audiences.
Guides effective documentation creation. Activates relevant guidance for north-star, gestalt, reference, research, design, plan, flow, findings, concepts, or process documents. Prevents cascading harm from wrong information.
| name | sprint-manager |
| description | Solo dev sprint planning and task management with Plane. Use when planning sprints, sizing tasks, managing the backlog, or structuring work for ADHD productivity patterns. Not Agile — solo dev workflow. |
| zones | {"knowledge":35,"process":30,"constraint":15,"wisdom":20} |
Agile is for teams. You need the planning, not the ceremony.
Invariant A sprint for one person is a commitment device, not a process artifact. It answers: "what will I build this week?"
Example Monday: pick 3-5 tickets sized S or M. Friday: review what got done. No standup, no retro, no velocity tracking. Just: did the things I planned get built? //BOUNDARY: If a sprint becomes a source of guilt rather than focus, shorten it or simplify it. The sprint serves you, not the other way around.
Depth
Invariant If a task can't be completed in a single work session, it's too big. Break it down.
Example Too big: "Implement player movement." Right size: "Player moves left/right with arrow keys." Even smaller: "Player sprite renders on screen." //BOUNDARY: Some tasks genuinely span sessions (art creation, complex systems). Mark these explicitly as multi-session and define session-sized checkpoints.
Depth
Workspace: Game Dev
├── Project: [Game Name] ← the game itself
├── Project: Learning ← boot.dev courses, tutorials
└── Project: Infrastructure ← k8s, tools, pipeline
Keep it simple. More states = more overhead.
| State | Meaning |
|---|---|
| Backlog | Captured but not committed to |
| Sprint | Committed for this sprint |
| In Progress | Actively working on it |
| Done | Meets the definition of done |
That's four states. Resist adding more. "Blocked," "In Review," and "QA" are team concepts. If you're blocked, add a comment and move on. If it needs review, review it yourself and mark done.
Labels serve two purposes: filtering and energy matching.
| Label Category | Values | Purpose |
|---|---|---|
| Size | S, M, L | Sprint planning capacity |
| Energy | high-energy, low-energy | Match to session type (see adhd-coach) |
| Domain | gameplay, art, audio, engine, tools, learning | Filter by what you're working on |
Use modules to group related issues that span multiple sprints:
Modules give you a cross-sprint view of feature progress.
Pick a consistent day to plan and a consistent day to review. Monday/Friday works for a standard week; adjust to match your actual schedule. The rhythm matters more than the specific days.
A healthy backlog is small and current. An unhealthy backlog is a graveyard of good intentions.
A decision-journal entry often creates tickets:
Create these tickets when the decision is recorded. They're the bridge between deciding and doing.
When helping with sprint management:
Creating tickets:
Sprint planning:
When the user wants to add mid-sprint:
Sprint review:
adhd-coach skill — Energy patterns and session shapes for task matchingdecision-journal skill — Decisions that create sprint ticketsreferences/ticket-templates.md — Templates for common ticket typesPlan the week. Build the thing. Celebrate what got done.