prototype-roadmap

---
name: prototype-roadmap
description: Plans the path from idea to a sellable hardware product: dev-kit bench measurement, works-like/looks-like prototypes, EVT, DVT, PVT and mass production, with gates, duration ranges, the critical path, long-lead purchases, bring-up checklists and test fixtures. Produces a dated roadmap and an SVG timeline. Use when the user asks "how long until I can sell this", "what are the next steps", "what is EVT/DVT", or needs a build plan or bring-up checklist.
---

# Prototype roadmap

Turn the design into a dated plan that a team can follow. Each stage has a deliverable and a gate. The plan shows the critical path and the date by which each long-lead part must be ordered. Write it to `hw/roadmap.md`.

Talk to the user in the user's language. Files are in English unless the user's project uses another language.

## Inputs

| File | What you take from it |
|---|---|
| `hw/brief.md` | launch target, quantities, markets, budget |
| `hw/state.json` | stage reached so far, gates already passed |
| `hw/bom.csv` | `lead_time_wk`, `stock_snapshot`, `lifecycle`; custom parts (cell, molded parts, flex) |
| `hw/power/` | whether the power budget is measured or only estimated |
| `hw/compliance.md` | certification durations and blocking items ("Schedule hooks") |
| `hw/cost/` | tooling and NRE lead times, MOQs |
| `hw/doability/review.md` | open risks that need an experiment before a commitment |

## Outputs

- `hw/roadmap/stages.json`: stages, dependencies, duration ranges, gates, milestones and long-lead items. The format is in `templates/stages.example.json`.
- `hw/roadmap/schedule.md` and `hw/roadmap/timeline.svg`: generated by `scripts/roadmap.py`.
- `hw/roadmap.md`: the plan, built from `templates/roadmap.md`, including the bring-up log.
- `hw/state.json`: the current stage and the next gate.

## Procedure

1. **Place the project.** Decide which stage it is in: idea, Stage 0, Stage 1, EVT-n, DVT, PVT or MP. Use what has actually been built and measured. Do not use how finished the CAD looks: a collision-free 3D model means the industrial design is frozen, not the engineering.

2. **Write the stages JSON.** Start from `templates/stages.example.json`, and remove the stages the product does not need. For example, a product with a catalogue cell has no custom-cell stage.
   - For each stage, give a `[best, worst]` duration in weeks, its dependencies (`depends_on`, optional `lag_weeks`, negative for overlap) and an exit gate. Take the gates from `references/stages.md`.
   - Use real lead times from `hw/bom.csv`, supplier quotes and `hw/compliance.md` where you have them. Tag each duration as verified or estimate.
   - Add a `long_lead` entry for every part whose lead time is 12 weeks or more, or whose stock is low, with the stage that first needs it.
   - Give each `long_lead` entry `qty_needed` and, when you have it, today's distributor stock: `"stock": {"on_hand": 9278, "source": "LCSC", "date": "YYYY-MM-DD"}`. When the order-by date from the factory lead time has passed but the stock covers `qty_needed`, the item is **buy now from stock**, not late. With too little stock or no stock data, it stays LATE and shows the shortfall.
   - Dependencies go in `depends_on`. The script rejects unknown stage keys, so a typo such as `after` fails loudly instead of silently starting the stage at week 0.

3. **Generate:**

   ```
   python3 ${CLAUDE_SKILL_DIR}/scripts/roadmap.py --stages hw/roadmap/stages.json --md hw/roadmap/schedule.md --svg hw/roadmap/timeline.svg
   ```

   Read the critical path, the "LATE" rows and the "in stock: buy now" rows. Look at the SVG before you embed it: stage names wrap between words, and milestone labels take separate lanes so they never cover each other. Test the script with `python3 ${CLAUDE_SKILL_DIR}/scripts/test_roadmap.py`.

4. **Check the order of commitments.** No custom cell, mold or board revision may start before the measurement that sizes it. If the plan has one, move it, or write down why the risk is accepted (`hw/decisions.md`).
   - The usual critical path: power measurement → cell decision → custom cell → UN 38.3 → certification → sale.
   - The final mold also waits for the cell envelope.

5. **Write `hw/roadmap.md`.** The answer comes first:
   - where the project is now;
   - the first legal sale, best and worst case, and what drives it;
   - what to order now;
   - the next gate.

   Then give the timeline, the per-stage plans, an empty bring-up log and the schedule risks.

6. **During EVT and later**, use `references/bringup-checklist.md` for each new board and log the results. Use `references/test-fixtures.md` to plan test access before routing, and fixtures before PVT.

7. **Hand off.**
   - `cost-and-sourcing` takes the NRE timing and the long-lead purchases.
   - `doability-review` takes the stage the project is in and the uncommitted measurements.
   - `product-presentation` takes `timeline.svg` and the answer-first block.

## Gate

The roadmap stage passes when:

- every stage has a deliverable, a duration range with an evidence tag and an exit gate;
- the critical path is identified, and no custom part starts before the measurement that sizes it (or the accepted risk is logged);
- every long-lead part has an order-by date, and late items are reported to the user;
- the first-legal-sale date is a range (best to worst), not a single optimistic date.

## Taste and pitfalls

- **Measure first.** The first engineering deliverable is often a measurement bench, not a PCB. Current measured on a dev kit with the real duty cycle sizes the battery, the memory and the enclosure.
- **The 3D model freezes the industrial design, not the engineering.** Expect 3–4 board revisions and 1–2 mold iterations before mass production. Do not call a design "final" before it has been powered, measured, dropped and certified.
- **Quote ranges, never single dates.** Teams that promise the best case to customers end up refunding pre-orders.
- **Order long-lead parts at once.** Order EVT and DVT quantities as soon as a part is chosen. Lead times of 16–26 weeks are normal for springs, drivers and connectors, and stock can vanish.
- **Certification is on the path, not after it.** In markets like Brazil, nothing with a radio can be sold before homologation, and that includes a small launch batch.
- **Design test access before routing:** test pads, an RF test strategy and a test mode in firmware.
- **Bring-up closes with numbers.** Every checklist line records a measured value and the instrument. "Seems fine" does not close a line.
- **Keep the roadmap honest.** When a gate fails, move the dates and tell the user. Do not shrink later stages to keep the launch date.

## References

- `references/stages.md`: what each stage builds, the questions it answers and its gate, plus the critical path, long-lead parts and the iterations to expect.
- `references/bringup-checklist.md`: step-by-step board bring-up, from before power to the system soak.
- `references/test-fixtures.md`: design for test and the production fixtures, with NRE ranges.
- `templates/stages.example.json`: an example plan for a fictional BLE fitness band.
- `templates/roadmap.md`: the output template.

• SKILL.md 7 KB
• references/bringup-checklist.md 4 KB
• references/stages.md 8 KB
• references/test-fixtures.md 2 KB
• scripts/roadmap.py 14 KB
• scripts/test_roadmap.py 4 KB
• templates/roadmap.md 2 KB
• templates/stages.example.json 3 KB