Product Engineering
Route, then defer. Decide which skill owns the request, read that skill's SKILL.md,
and follow it completely. Never do the work from this file's summaries.
Route by the deliverable
Ask what should exist when the work is done:
| The user wants |
Route to |
| A document or design artifact — context docs, a design brief for one feature, a direction, wireframes, mockups, prototypes, variants, an onboarding flow |
pe-design |
| Working production code — a component built, polished, animated, made accessible, or hardened; a UI bug fixed |
pe-build |
| A judgment on what exists — a review, critique, audit, or stress test of a screen, diff, or PR; fidelity to an approved design |
pe-review |
| Proof that something works — a verification run with recordings and screenshots, or the project's QA list re-checked before a release |
pe-verify |
| A behavior spec — documentation of what users see and do, verified against the product |
pe-product-description |
| A standalone asset — an illustration, social/OG image, or logo in the project's brand |
pe-brand-assets |
Disambiguation
- Verb beats noun. "Review the animation" →
pe-review. "Fix the animation" →
pe-build.
- A named diff, branch, or PR always means
pe-review, change mode.
- A bug in UI behavior is code to fix →
pe-build. If the user only wants to
know what's wrong, not a fix → pe-review.
- A spec or plan for something new — a feature not yet built →
pe-design, brief
mode. A spec of how the existing product behaves → pe-product-description.
- A mockup of something new →
pe-design. N takes on one existing piece →
pe-design, vary mode.
- "Did we match the design / mock?" →
pe-review, fidelity mode (checks against
the record in .product/approved/). "Make it match the mock" → pe-build.
- "Does it work?" vs "Is it good?" Proof of behavior with evidence →
pe-verify.
Judgment of quality — looks, motion, accessibility — → pe-review. "Run the QA
list" or "release check" is always pe-verify, list mode.
- Still ambiguous after that: ask one short question naming the two candidate
skills, then proceed.
After routing
State the choice in one line ("Routing to pe-build, motion mode"), load that skill,
and follow its contract — including its handoffs back to the other skills.
1---2name: product-engineering3description: The front door to the product-engineering kit. Use when the user says "product engineering" followed by any product, design, UI, review, or asset request; when they ask which pe-* skill fits a task; or when a product task doesn't clearly match one skill. Routes to pe-design, pe-build, pe-review, pe-verify, pe-product-description, or pe-brand-assets and then follows that skill. If a request already names or clearly matches a specific pe-* skill, that skill takes it directly — this router yields.4license: Apache-2.05---67# Product Engineering89Route, then defer. Decide which skill owns the request, read that skill's SKILL.md,10and follow it completely. Never do the work from this file's summaries.1112## Route by the deliverable1314Ask what should exist when the work is done:1516| The user wants | Route to |17| --- | --- |18| A document or design artifact — context docs, a design brief for one feature, a direction, wireframes, mockups, prototypes, variants, an onboarding flow | `pe-design` |19| Working production code — a component built, polished, animated, made accessible, or hardened; a UI bug fixed | `pe-build` |20| A judgment on what exists — a review, critique, audit, or stress test of a screen, diff, or PR; fidelity to an approved design | `pe-review` |21| Proof that something works — a verification run with recordings and screenshots, or the project's QA list re-checked before a release | `pe-verify` |22| A behavior spec — documentation of what users see and do, verified against the product | `pe-product-description` |23| A standalone asset — an illustration, social/OG image, or logo in the project's brand | `pe-brand-assets` |2425## Disambiguation2627- **Verb beats noun.** "Review the animation" → `pe-review`. "Fix the animation" →28 `pe-build`.29- **A named diff, branch, or PR** always means `pe-review`, change mode.30- **A bug in UI behavior** is code to fix → `pe-build`. If the user only wants to31 know what's wrong, not a fix → `pe-review`.32- **A spec or plan for something new** — a feature not yet built → `pe-design`, brief33 mode. **A spec of how the existing product behaves** → `pe-product-description`.34- **A mockup of something new** → `pe-design`. **N takes on one existing piece** →35 `pe-design`, vary mode.36- **"Did we match the design / mock?"** → `pe-review`, fidelity mode (checks against37 the record in `.product/approved/`). **"Make it match the mock"** → `pe-build`.38- **"Does it work?" vs "Is it good?"** Proof of behavior with evidence → `pe-verify`.39 Judgment of quality — looks, motion, accessibility — → `pe-review`. "Run the QA40 list" or "release check" is always `pe-verify`, list mode.41- Still ambiguous after that: ask one short question naming the two candidate42 skills, then proceed.4344## After routing4546State the choice in one line ("Routing to pe-build, motion mode"), load that skill,47and follow its contract — including its handoffs back to the other skills.
backnotprop