distill-patterns-from-prd

distill-patterns-from-prd — extract reusable patterns from a PRD

When to trigger

• The user copied the "Distill patterns from this PRD" prompt from the PRDs tab in the workspace.
• The user explicitly asks "从这份 PRD 里抽 pattern" / "see what patterns this PRD needs" / "distill patterns".
• Invoked upstream by new-design when patterns/ is empty and a PRD exists.

Do not trigger this skill for:

• Generating actual design pages — that's new-design's job. Stop after patterns land.
• Editing an existing pattern — use the workspace Patterns tab or add-pattern.
• Anything not anchored to a concrete PRD body (use add-pattern conversational mode instead).

Output contract

For each new pattern, write three files to <project>/patterns/<id>/:

patterns/<id>/
├── pattern.json         { "name": "<id>", "whitelist": ["OmFoo", "OmBar"], "description": "..." }
├── template.tmpl.tsx    first line `// @pattern: <id>`; minimal skeleton; TODO placeholders for copy
└── README.md            "When to use" / "Skeleton" / "When NOT to use"

Whitelist entries must come from GET /preset/components (the Om* names exported by @omit-design/preset-mobile). Unknown names break ESLint's require-pattern-components rule.

Execution flow

Step 1 — Parse the PRD

Read the body (frontmatter already trimmed by the workspace's clipboard handler). Identify:

• Page count — how many distinct screens does this PRD cover?
• Archetype per screen — list / detail / form / dialog / dashboard / sheet / welcome?
• Data shape per screen — single record / homogeneous list / tree / kanban / table?
• User actions — read / select / fill / submit / compare / dismiss?

Step 2 — Scan existing patterns

ls <project>/patterns/*/pattern.json
cat <project>/patterns/<id>/README.md  for each

For each PRD screen, judge: does an existing pattern cover this archetype well enough? Match on the README's "When to use" / "When NOT to use" sections, not just on the name.