メニュー
Load when accepted product intent must become a concise, implementation-ready local capability specification with explicit constraints, non-goals, test seams, and unresolved decisions.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Load when a task needs a throwaway prototype, state-model sanity check, UI variant, image-assisted visual mockup, mock interaction, or playable design; do not use for production feature work.
Load when a user describes a Web animation or motion effect without knowing its name and needs the precise term or close alternatives; use only for naming, not design, implementation, or review.
Load when a frontend task needs Apple-platform design guidance or physical, gesture-driven, velocity-aware, interruptible interaction; skip generic visual styling and use review-animations for report-only motion review.
Load when a task needs polished product UI, web pages, landing pages, dashboards, React components, HTML/CSS layouts, or styling; skip routine frontend logic and reports.
Load when a task needs React or Next.js frontend logic, component patterns, state, forms, routing, accessibility, or responsive behavior; use frontend-design for visual direction.
Load when an existing Web product, especially a dashboard, dense-data view, or multi-step app, needs a deep evidence-backed experience review; report findings only, and use design-taste-frontend for marketing-page direction, code-review for source diffs, web-design-guidelines for checklist compliance, or frontend-design for implementation.
| name | product-capability |
| description | Load when accepted product intent must become a concise, implementation-ready local capability specification with explicit constraints, non-goals, test seams, and unresolved decisions. |
| license | MIT |
| metadata | {"source":"Harness Hub; mattpocock/skills skills/engineering/to-spec","upstream_commit":"e9fcdf95b402d360f90f1db8d776d5dd450f9234"} |
Turn accepted product intent into a local engineering contract. This Skill specifies one capability; it does not own implementation, ticketing, or delivery.
Use grill-me first when consequential decisions remain. Use grill-with-docs when this work creates or changes a durable specification so the same decision graph is reconciled with repository evidence.
Read only relevant sources:
Do not invent product truth. Label an inference or unresolved decision instead of smoothing over missing evidence.
Write the smallest artifact that makes implementation unambiguous:
CAPABILITY
- actor, new behavior, and observable outcome
ACCEPTED SOURCE FACTS
- source anchor and fact
CONSTRAINTS
- invariants, ownership, trust, lifecycle, failure, migration, and rollout rules
INTERFACES
- inputs, outputs, states, errors, side effects, and compatibility boundaries
TEST SEAMS
- public behaviors and deterministic evidence that will prove acceptance
OUT OF SCOPE
- explicit non-goals and rejected expansion
OPEN DECISIONS
- unresolved choices that can still change implementation or acceptance
HANDOFF
- ready for implementation, needs alignment, or needs focused design review
Prefer updating the project's existing canonical spec or planning location. Do not create a new planning stack when the repository already owns one.
The result is ready only when:
Use to-tickets only when the accepted spec needs project-owned execution slices. Do not publish an issue, apply a label, or mutate a remote tracker from this Skill.