agnostic-planning-skills

Master orchestrator for the Agnostic Planning Skills library. Use to discover and activate 11 language-agnostic skills and 4 personas for product planning, task breakdown, estimation, risk assessment, ticket generation, backlog prioritization, sprint planning, retrospectives, requirements clarification, GitHub issue management, and status reporting. Personas guide end-to-end workflows. prd, planning, tasks, tickets, estimation, risks, status, backlog, sprint, retrospective, tdd, agile, product management, requirements, clarification.

Scan dependency chains, single points of failure, ambiguous requirements, external dependencies, capacity, and technical uncertainty. Every risk must reference a specific task/requirement as evidence. Output a risk register with likelihood, impact, and mitigations. Use for risk assessment, what could go wrong, risk register.

Prioritize a backlog using RICE, MoSCoW, value-vs-effort, or WSJF. Rank items by impact and urgency, produce ordered backlog with scores and rationale. Use when prioritizing a backlog, ranking features, applying frameworks.

Generate a stakeholder status report from task data — never fabricate progress, mark unknowns as "needs update". Includes Executive Summary (health, key accomplishment, top concern) and standard sections. Use for status report, sprint update, weekly update, project status.

Use to create, track, or manage GitHub issues with automatic project board integration (V2 and Classic), milestone tracking, and stage lifecycle (todo → in-progress → in-review → done). Covers issue creation, status updates, project board moves, and completion workflows.

Draft a clear actionable PRD from a feature — focus on what/why, no code, save to /tasks/prd-SLUG.md. Use when the user wants a PRD, product requirements, plan a feature, write a spec.

Review a PRD for completeness, testability, clarity, feasibility, scope, dependencies, and edge cases — classify findings as Critical/Suggestion/Note, cite specific sections, and provide a verdict. Use when reviewing a PRD, PRD review, validate PRD, feasibility check.

Transform vague task descriptions into actionable specifications with user stories, acceptance criteria, and identified edge cases — NEVER write implementation code. Output requirements only. Use when clarifying, defining scope, refining vague requests.

Break a feature into implementation tasks — always create a feature branch first, detect test command and directories, write failing test → implement → pass (TDD), and save to /tasks/tasks-[name].md. Use for task list, implementation plan, feature breakdown, TDD tasks.

Draft and classify structured tickets with area prefixes and five-section format (Summary, Background, Acceptance Criteria, Dependencies, Technical Notes), plus a readiness checklist. Draft-only by default; create issues only after explicit user approval. Use when breaking a plan into tickets, creating Jira/GitHub issues, classifying work items.

Full delivery pipeline with hard gates at PRD approval (explicit sign-off required, loop back to create-prd on needs-revision before generating any tasks), sprint commitment (capacity ≤80% with defined sprint goal, do not exceed team velocity), and retrospective (every what-didn't gets an action item with owner and timeline, do not close without documented learnings); six sequential phases scope→plan→prioritize→sprint→execute→retrospect cannot be skipped or re-ordered, on timeout resume from last completed phase without re-running. Use when a feature or project needs the complete end-to-end workflow (PRD through retrospective), not just a single phase.

Product planning lifecycle with hard gates at scope confirmation (do not proceed to PRD draft without explicit user sign-off on the clarified scope), PRD approval (do not generate tasks before PRD is explicitly approved, iterate on feedback and re-draft until approved), task breakdown approval (do not generate tickets before task list is approved), and sprint placement (do not assume sprint capacity — ask for points per sprint and number of available sprints); six sequential phases discovery→PRD draft→review and revise→task estimation→ticket generation→sprint placement. Language-agnostic — works with any tech stack. Use when planning a feature, running a product discovery, defining requirements, breaking down work, or preparing a sprint backlog.

Technical PRD review evaluating every requirement for completeness feasibility and testability plus validating estimation quality (flag tasks with low confidence, identify architectural concerns and technical debt risks) and producing structured findings with severity classification Critical/Suggestion/Note — each finding MUST cite specific PRD evidence, do not review the idea review the document's quality, output a go/no-go recommendation with a technical risk report covering dependency chains, capacity concerns, and single points of failure. Language-agnostic — evaluates the plan, not the stack. Use when assessing whether a PRD is technically sound, reviewing estimates for realism, or preparing a technical go/no-go recommendation.

Orchestrates the execution tracking lifecycle across four hard-gated phases: estimates tasks with confidence levels, builds a risk register with owners and mitigations, sets up milestone tracking checkpoints, and generates stakeholder status reports. Language-agnostic. Use when tracking a sprint or project, assessing execution health, flagging blockers, or preparing a stakeholder update — especially where formal approval gates are needed before proceeding.

Generates a sprint retrospective from sprint data feedback and metrics — cover what went well what didn't and action items, group related feedback into themes, ensure every "what didn't" has at least one specific owned time-bound action item, use the retrospective template when available, include Owner Timeline and Linked Issue columns. Language-agnostic. Trigger words: retrospective, retro, sprint review, what went well, what didn't, improvement items, lessons learned, sprint retrospective.

Plans a sprint by selecting tickets from a prioritized backlog based on team capacity and historical velocity — start from top stop at ≤80% capacity, define a single sprint goal that all selected tickets support, use theoretical_capacity × 0.6 when no history or use the most recent sprint for declining trends, produce a table with Rank Ticket Estimate Confidence Notes, and use the capacity heuristics section when data is unavailable. Language-agnostic — works with any tracker or estimation framework. Trigger words: plan sprint, sprint planning, sprint goal, sprint capacity, what should we work on this sprint, sprint backlog.

Assigns relative effort estimates using story points (Fibonacci) t-shirt sizes or time ranges — never mix frameworks within a single table, include confidence level per task, use table format with ID Task Estimate Confidence Notes, and flag high-uncertainty items. Language-agnostic. Use when the user asks to estimate effort, size tasks, or assign story points to backlog items. Trigger words: estimate, story points, t-shirt size, effort, sizing, fibonacci.