linear-product-requirements

使用 Linear 的原生结构创建产品需求。适用于在 Linear 中创建或编辑倡议、项目、里程碑、项目文档（规格书），或问题（用户故事）时使用。触发短语包括“撰写 PRD”、“创建用户故事”、“设置项目”、“编写规格书”、“为 Linear 添加功能”等。

SKILL.md

--- frontmatter

name: linear-product-requirements
description: Create product requirements using Linear's native structure. Use when creating or editing Initiatives, Projects, Milestones, Project Documents (specs), or Issues (user stories) in Linear. Triggers include requests to write PRDs, create user stories, set up projects, write specs, or add features to Linear.

Linear Product Requirements

All product requirements live in Linear. No external docs needed.

Linear Hierarchy

Linear Level	Content	Who Writes	Who Reviews
Initiative	Strategic context (why, target outcome)	PM	Leadership
Project Overview	TL;DR, scope, decisions, constraints	PM	EL approves
Project Milestones	Delivery phases	PM	Team
Project Documents	Detailed specs per milestone	PM	Engineering
Issues	User stories	PM	Engineering

Visual Structure

code

INITIATIVE: Platform Compliance
│
│   Why: [business driver]
│   Target Outcome: [what we're trying to achieve]
│
└── PROJECT: Consent Management
    │
    ├── Project Overview (EL reviews this)
    │   └── TL;DR, Scope, Decisions, Technical Considerations
    │
    ├── Milestones
    │   ├── Admin Management
    │   ├── Customer Actions
    │   └── Customer Visibility
    │
    ├── Project Documents (Engineering reference)
    │   ├── Spec: Admin Management
    │   ├── Spec: Customer Actions
    │   └── Spec: Customer Visibility
    │
    └── Issues (created from specs)
        ├── As an admin, I can create a new consent so that...
        ├── As an admin, I can publish a consent version so that...
        └── ...

Workflow

code

1. PM creates Initiative (if new strategic area)
       ↓
2. PM creates Project under Initiative
       ↓
3. PM writes Project Overview → EL reviews & approves
       ↓
4. PM creates Milestones in Linear (manual)
       ↓
5. PM writes Project Document per Milestone
       ↓
6. PM creates Issues from specs, assigning to Milestones
       ↓
7. Engineering works Issues, posts Project Updates

Note: Milestones must be created manually in Linear before creating Issues.

Entry Points & Linear MCP

Level	Where in Linear	MCP Available
Initiative	Initiatives → New Initiative	❌ Manual
Project	Projects → New Project	✅ `create_project`
Milestone	Project → Milestones	❌ Manual
Document	Project → Documents → New	✅ `create_document`
Issue	Project → Issues	✅ `create_issue`

Before Writing Requirements

Always explore the codebase first. See references/codebase.md for patterns.

Find relevant:

•Models/schemas for data requirements
•Existing APIs for integration points
•Similar features for patterns to follow
•Validation logic for business rules

Naming Conventions

Element	Definition	Pattern	Example
Initiative	Groups projects with same business reason	Strategic theme	`Platform Compliance`
Project	The feature being built	Capability (2-3 words)	`Consent Management`
Milestone	How project is split for delivery	Focus area or phase	`Admin Management`, `Beta`
Document	Detailed requirements for a milestone	`Spec: [Milestone]`	`Spec: Admin Management`
Issue	A task an engineer completes	Full user story	`As a customer, I can...`

Project naming:

•❌ Customer Data Protection (problem-focused)
•✅ Consent Management (capability-focused)

User Story Rules

Title is the full user story:

code

As a [role], I can [action] so that [benefit]

Critical rules:

•User must always be human (customer, admin, staff), never a system
•Include "so that" clause with the benefit
•No short summaries as titles

Anti-pattern:

•❌ As a client app, I can check pending consents...
•✅ As a customer, when I have pending consents, I am prompted to review them...

Technical Ownership

Clear ownership keeps collaboration smooth:

PM Owns (WHAT)	Engineering Owns (HOW)
User goals and outcomes	Database schema design
Acceptance criteria	API endpoint specifications
Business rules and logic	Architecture decisions
Data requirements (what data)	Technology choices
Integration needs	Implementation approach

What PMs Should Include

Include	Example
Data requirements	"Must capture: timestamp, user ID, IP address"
Business rules	"Points expire 365 days after earning"
Integration needs	"Must integrate with existing auth"
Open questions	"How should we handle versioning?"

What PMs Should Avoid

❌ Avoid	✅ Instead
"Create table `consents` with columns..."	"System must store consent records"
"POST /api/v1/consents endpoint"	"Customer can grant consent"
"Use JSONB for content field"	"Content must support multiple languages"
"Use FIFO with FOR UPDATE locks"	"Deduct from oldest batches first"

When Technical Context Helps

Frame as considerations, not requirements:

Instead of...	Try...
"Use double-entry accounting"	"Similar systems use double-entry patterns. Engineering to evaluate."
"Add idempotency_key column"	"API must prevent duplicate transactions. Reference: Stripe idempotency."

Templates

See references/templates.md for complete templates.

Example

See references/examples.md for complete Consent Management example.

Quick Reference

EL Review Checklist

EL only reviews Project Overview:

• Problem is clear
• Solution makes sense
• Scope is reasonable (in/out)
• Decisions are answered or flagged
• No technical over-specification

PM Checklist Before Creating Issues

• Project Overview approved by EL
• Milestones created in Linear (manual)
• Project Document written for each milestone
• User stories identified in spec
• Business rules documented
• Edge cases covered
• Open questions flagged for engineering

Engineering Reference

For any Project, find requirements in:

•Project Overview → Scope, constraints
•Project Documents → Detailed specs per milestone
•Issues → Individual stories with acceptance criteria