ash4180/skills/prd
skills/prd/SKILL.md
--- name: prd version: 2.1.0 description: Use when user says "write PRD", "create requirements", "define feature", "document requirements", "product spec", "create ticket", or wants to capture a feature spec as a single Linear ticket. Creates a Linear ticket carrying numbered AC-* acceptance criteria, ordered flow steps with F*-S* IDs + AC tags (Notion-doc format), component mapping intent (kind-of-component per block, NOT concrete DS names — that's /figma's job), state list (empty/loading/error
$ install --global
skillsauthnpx skillsauth add ash4180/vorbit skills/prdInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jun 5, 2026, 3:35 AM13.5s1 file scanned
SKILL.md
- name:
- prd
- version:
- 2.1.0
- description:
- Use when user says "write PRD", "create requirements", "define feature", "document requirements", "product spec", "create ticket", or wants to capture a feature spec as a single Linear ticket. Creates a Linear ticket carrying numbered AC-* acceptance criteria, ordered flow steps with F*-S* IDs + AC tags (Notion-doc format), component mapping intent (kind-of-component per block, NOT concrete DS names — that's /figma's job), state list (empty/loading/error/etc. as TEXT, not mockups), constraints, and success criteria. Treats PRD as agent contract first, engineering spec second.
- Create a Linear ticket that captures a product requirement. **PRD is the agent contract** — Figma is the visual contract, annotations are the bridge. Per the three-artifact convention (see `[[reference_three_artifact_convention]]`), PRD owns *intent + requirements*:
- numbered `AC-*`, ordered flow steps, state list, component mapping intent. Figma owns *the look*. Don't put visuals here; don't put rules in Figma.
- > **Linear MCP namespace**:
- All Linear calls in this skill use `mcp__plugin_linear_linear__*` (the namespace shipped with the vorbit plugin). Bare verb names below (`get_user`, `list_teams`, `save_issue`, etc.) refer to the corresponding `mcp__plugin_linear_linear__<verb>` tool.
- > **Locate `_shared/`**:
- This skill ships as a plugin, so `_shared/` files live in the plugin cache, not your project. Before reading any `_shared/...` path below, run `ls -d ~/.claude/plugins/cache/local/vorbit/*/skills/_shared 2>/dev/null | head -1` and use the output as the absolute base for every `_shared/...` reference.
- > **UX patterns reference**:
- Senior UX product designer knowledge lives in `_shared/ux-knowledge/`. When building Step 2 clarifying questions, consult `question-matrix.md` (14 categories). When checking AC + state completeness in Step 3, consult `edge-case-catalog.md`. When phrasing ACs (verbatim user-words rule), consult `ux-philosophy.md`. Read directly — no need to invoke `/vorbit:design:ux` unless requirements are deeply vague.
- ## Step 1:
- Gather Context (Draft First)
- **IF a Linear ticket URL or ID is provided (existing draft, similar feature, etc.):
- **
- 2. Restructure:
- keep the source intent, normalize wording to the schema below, mark gaps as `TBD`
- **IF the user pastes content from elsewhere (Notion, a doc, an old spec):
- **
- **IF the source is an `/explore` exploration document** (visual moodboard with `blocks_mined[]`, `flow_steps[]`, `references[]`, `recommended_direction` from `/vorbit:
- design:explore`):
- **IF conversation already covers the feature:
- ** use that context as input.
- **IF starting fresh:
- ** proceed to Step 2.
- ## Step 2:
- Clarify Requirements
- **Rule:
- ask about every meaningful uncertainty. Do not silently guess.**
- - If the API supports a designed UI, capture the design-derived contract:
- fields, states, ordering, error cases, and copy the UI needs.
- ## Step 3:
- Generate Draft
- **Required content:
- **
- - Description:
- one short paragraph under the H1
- - Problem:
- 1-2 short paragraphs, no tech detail
- - **User Stories**:
- `US-001`, `US-002`, ... each with `AC-N` items (numbered globally across the PRD so /figma annotations can reference them as `implements: AC-X`)
- - **User Flows**:
- at least one flow with **`F*-S*` step IDs** and `[AC-X]` tags per step (Notion-doc format — see template). Entry/Exit anchors kept for human scanning.
- - **State List**:
- ordered list of every UI state the feature touches (default / loading / empty / error / permission-denied / etc.) tagged with the AC each state is governed by. **Text only — no mockups.** Figma stays happy-path.
- - **Component Mapping Intent**:
- per block from `/explore`, declare the *kind* of component needed (intent), NOT the concrete DS name. /figma's Phase 2 resolves intent → DS.
- - Design Source of Truth:
- lighter than before — for UI work, the *target surface* and *conflict rule*, but not "what to design" prose (the lo-fi flow / blocks_mined already describes it).
- After showing the draft, ask:
- **"Does this look good? Ready to create the Linear ticket?"**
- * **Primary Figma node:
- ** [URL with exact `node-id`, or `N/A` for non-UI work]
- * **Parent flow/frame:
- ** [Figma parent frame/page/user flow that explains where this node lives]
- * **Implementation target:
- ** [screen/pane/component/block the node applies to]
- * **States/variants required:
- ** [default, empty, loading, error, selected, responsive breakpoints]
- * **Interaction flow:
- ** [entry point, user action, visible result, exit state]
- * **Design conflicts:
- ** [which source wins if ticket text and Figma disagree]
- * **Out of scope:
- ** [nearby mockup parts that should not be implemented]
- ### US-001:
- [Title]
- **Acceptance Criteria:
- **
- ### US-002:
- [Title]
- Use the Notion-doc format:
- each step has an `F*-S*` ID and `[AC-X]` tags. Keep Entry/Exit anchors at the flow level for human scanning, but make the per-step format machine-parseable so `/vorbit:design:figma` (Flow Page generation) and `/vorbit:implement:epic` (Related Flow Steps) can consume it without inference.
- ### Flow F1:
- [Name] (Happy flow)
- **Entry:
- ** [Start]
- **Exit:
- ** [End]
- - **F1-S1**:
- [Surface] → [User action] → [Visible result] [AC-1, AC-2]
- - **F1-S2**:
- [Surface] → [User action] → [Visible result] [AC-3]
- - **F1-S3**:
- [Surface] → [User action] → [Visible result] [AC-4]
- ### Flow F2:
- [Name] (Second main path or alternate)
- - **F2-S1**:
- [Surface] → [User action] → [Visible result] [AC-5]
- - **F2-S2**:
- Server returns error → Error toast, values preserved [AC-6]
- | Permission denied | User lacks `read:
- foo` scope | AC-10 |
- For each block surfaced by `/explore`'s `blocks_mined[]`, declare the *kind of component* the block needs. **No concrete DS names** — `/vorbit:
- design:figma`'s Phase 2 resolves intent → DS using the linked library inventory.
- ## Step 4:
- Confirm Draft
- ## Step 5:
- Create the Linear Ticket
- 1. `get_user` with `query:
- me"` to verify Linear auth/session
- - `title`:
- the feature name (the H1 line, without the `#`)
- - `team`:
- selected team name (string, name-based — not `teamId`)
- - `project`:
- selected project name if any (string, name-based — not `projectId`)
- - `description`:
- the full PRD body in markdown, starting at `## Description` and including everything below
- **Reliability rules:
- **
- ## Step 6:
- Report
- - Quick summary:
- X user stories, Y flows, Z success criteria
- - `/vorbit:
- design:journey` to draw a flow diagram in Excalidraw
Coverage Review Mode
When asked to review whether sub-issues fulfill a parent PRD ticket:
- Read the parent ticket (
get_issue) and all sub-issues (list_issueswith the parent'sparentId) - Map each User Story and
AC-Nto the sub-issue(s) covering it - Flag work that cannot be bundled into an existing sub-issue as a gap; bundle-able housekeeping is not a gap
- Report: coverage matrix (story → sub-issues), gaps, verdict (covered / has gaps)
Schema & Validation
Read this section before drafting in Step 3. Without these required sections and validation rules, the PRD ticket doesn't carry the structure that /vorbit:implement:epic needs to break it into traceable sub-issues. A passing draft skips no required section and trips no validation rule below.
Required Sections
| Section | Required | Rules |
|---------|----------|-------|
| Title (H1) | Yes | 3-8 words, no jargon. Becomes Linear ticket title. |
| Description | Yes | 1-2 short sentences, no tech detail |
| Problem | Yes | 1-2 short paragraphs, user pain not tech gap |
| Design Source of Truth | If UI work | Target surface + conflict rule. Light. The visual contract lives in Figma; PRD doesn't replicate it. |
| User Stories | Yes | As a [user], I want ..., so ... plus AC-N items, numbered globally |
| User Flows | Yes | At least one flow in Notion-doc format — F*-S* step IDs + [AC-X] tags per step, Entry/Exit anchors at flow level |
| State List | Yes (UI work) | Every UI state (default/loading/empty/error/etc.) as text, tagged by governing AC. NOT mockups. |
| Component Mapping Intent | Yes (UI work) | Per block from /explore, intent only (kind of component). No concrete DS names. |
| Constraints | Yes | Limits the implementation must respect |
| Success Criteria | Yes | Measurable with numbers |
Validation Rules
- Title: 3-8 words, no jargon
- Description: short, plain English, no tech detail
- Problem: describes user pain, not the technical fix
- Design Source of Truth: required for UI work — target surface and conflict rule. Doesn't replicate the visual; that's Figma's job.
- User Stories:
As a [user], I want [goal], so [benefit]. Each story has at least oneAC-N. AC numbering is global across the PRD (AC-1throughAC-N), not per-story — so/figmaannotations and/epicsub-issues can reference any AC unambiguously. - User Flows: at least one. Notion-doc format:
F*-S*step IDs +[AC-X]tags per step. 3-8 steps per flow is the sweet spot. - AC coverage: every
AC-Nshould appear in at least one step's[AC-X]tag AND in the State List (if it governs a state) — orphan ACs are a coverage gap caught at /verify time. - State List: every UI state the feature touches, text only, tagged by AC. No state mockups in Figma.
- Component Mapping Intent: each block from /explore gets a row with the intent string; never a concrete DS component name.
- Success Criteria: contain real numbers (percentages, times, counts)
- TBD: allowed in Constraints, Success Criteria numbers, and flow details only — never in Problem, Users, or User Stories. Every
TBDmust have a matchingAskUserQuestionattempt
Common Mistakes
| Wrong | Right | Why |
|-------|-------|-----|
| "We need JWT auth" | "Users cannot access personalized features without accounts" | Problem describes user pain, not the technical fix |
| "Users should be happy with login" | "90% of users complete login in under 10 seconds" | Success criteria need real numbers |
| "OAuth2 JWT Token Auth Implementation" | "User Login and Signup" | Title avoids jargon |
| Flow as system trace (User → API → DB → API → User) | **F1-S1**: Login screen → Click Submit → Loading state → Token returned [AC-1, AC-2] | Flows describe what the user sees, with F*-S* IDs and [AC-X] tags per step |
| component_mappings: ShadcnInput + Badge | component_mapping_intent: "search input with inline filter chips, multi-select" | PRD declares intent; /figma's Phase 2 resolves to concrete DS names from the linked library |
| Empty state in Design Source of Truth as a Figma node | Empty state in State List as text + governing AC | States are PRD concerns (text); Figma stays happy-path; code renders each state per AC |
| "Match Figma" | "Example: Implement Figma node <primary-node-id> exactly for <target surface>; <reference-node-id> is reference only; <specific layout/state rule> must come from the primary node" | Agents need a concrete source of truth and conflict rule |
Related Skills
ash4180/pencil
development
VerifiedTrustedCommunity
Sync design tokens and components from a codebase to a Pencil canvas (`.pen` files), or set up a Pencil canvas from a style guide when no codebase exists. Use when the user says "sync pencil", "setup pencil", "configure pencil", "pencil sync", "sync tokens to pencil", "build pencil component library", or names Pencil/`.pen` files explicitly. Also triggers when mockups generated by Pencil don't match project conventions.
2SKILL.mdUpdated May 18, 2026
ash4180/skills/figma
development
VerifiedTrustedCommunity
--- name: figma version: 1.6.0 description: Use when user says "figma", "figma it", "sync figma", "figma mockup", "create figma file", "design to figma", "figma from PRD", "figma from journey", "build in figma", or "figma design system" — anything that creates, syncs, or updates Figma design systems, components, variables, mockups, or front-end-ready screens. Always enumerates the linked Figma library FIRST (library-driven discovery, not per-need search), produces a block→DS mapping table for us
2SKILL.mdUpdated May 18, 2026
ash4180/vorbit-webflow
development
VerifiedTrustedCommunity
Use when the user wants to build Webflow pages, templates, or components, with or without Figma designs as reference.
2SKILL.mdUpdated May 18, 2026
ash4180/vorbit-verify
testing
VerifiedTrustedCommunity
Use when the user wants to verify an implementation, validate acceptance criteria, or run a Vorbit-style post-change check using shared project rules.
2SKILL.mdUpdated May 18, 2026