Project Initiation Assistant

Turn a one-hour discovery meeting into a development-ready backlog in minutes. This skill is the conductor: it runs a five-stage pipeline and hands each stage to a focused component skill. Think of it as the recipe that tells Claude which tool to reach for and in what order.

When to run the full pipeline

Run the whole pipeline when the user gives you a fresh requirement input (meeting notes, a requirement document, an RFP, or a call transcript) and wants to start a project. If they only want one artifact (say, "just write the PRD"), jump straight to that stage — the stages are designed to work independently as well as together.

The pipeline

Requirement input (notes | doc | transcript)
        │
        ▼
[1] Requirement Analyzer      → structured requirement brief
        │
        ▼
[2] PRD Generator             → Project Vision + PRD
        │
        ▼
[3] User Story Generator      → Epics + user stories + acceptance criteria
        │
        ▼
[4] Backlog Estimation        → story points, priority, complexity
        │
        ▼
[5] Sheet Tracker Creator     → populated, shared tracker + link
        │
        ▼
Development-ready backlog

Each arrow passes a structured hand-off object to the next stage. Keep these hand-offs in memory (or in a scratch file) so nothing is lost between stages — the whole point of this skill is that the user does not have to re-explain anything.

How to run it

Follow the stages in order. At each stage, consult the matching component skill for the detailed method; this file only coordinates.

1. Analyze requirements — Use the requirement-analyzer skill. Extract goals, stakeholders, functional and non-functional requirements, constraints, assumptions, and open questions. If critical information is missing (no client name, no objective), collect open questions but keep going — flag gaps rather than stalling.
2. Generate the PRD — Use the prd-generator skill. Feed it the requirement brief from stage 1. Output a Project Vision statement and a full PRD.
3. Generate epics and stories — Use the user-story-generator skill. Convert the PRD's functional requirements into epics, then INVEST user stories with Given/When/Then acceptance criteria. Give every epic and story a stable ID (EP-01, US-01) so later stages and the tracker can reference them.
4. Estimate the backlog — Use the backlog-estimation-assistant skill. Assign each story a Fibonacci story-point value, a MoSCoW-derived priority, and a complexity rating, each with a one-line justification.
5. Build the tracker — Use the sheet-tracker-creator skill. Assemble the backlog into the tracker schema and create the spreadsheet. Prefer a live Google Sheet via a connected Google Drive/Sheets MCP; fall back to a local .xlsx if no MCP is available. Return the shareable link.

Output contract

At the end, present the user with, in this order:

1. A one-paragraph Project Vision.
2. A link to (or file for) the project tracker with four sheets: Project Overview, Epics, User Stories, Risks.
3. A short summary: number of epics, number of stories, total story points, and any open questions that still need a human answer.

Do not bury the tracker link at the bottom of a long report — it is the headline deliverable.

Design notes

• Composability. Each stage is a standalone skill. If the user already has a PRD, skip straight to stage 3. Do not force the full pipeline when only part is needed.
• Traceability. Carry IDs through every stage (requirement → epic → story → tracker row) so a reader can trace any backlog item back to the original requirement. This is what makes the output audit-friendly for QA and PM review.
• Graceful degradation. Missing inputs produce flagged open questions, never a hard stop. A partial backlog with clear gaps beats no backlog.

See references/pipeline.md for the hand-off data shapes between stages and a full worked example.