product-engineering
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.
소스 정보
- 저장소
- backnotprop/product-engineering
- 최근 소스 활동
- 2026년 8월 26일 18:20
- 감지된 SKILL.md 언어
- 영어
- 스타
- 21
- 포크
- 1
설치 방법
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
소스 파일 검토
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
SKILL.md 표시 중
SKILL.md
소스 지침 · 읽기 전용 미리보기- name
- product-engineering
- description
- 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.
- license
- Apache-2.0
- metadata
- {"provenance":"foundry/derivations/product-engineering.md in the source repository"}
# 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.
GitHub에서 보기