菜单
Guides Linear project management — creates projects over tracking issues, structures PRDs, phases milestones, sizes issues, applies labels, and formats cross-references. Use when creating Linear projects, planning work, or organizing issues.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/outfitter-dev/outfitter --skill linear-project-management命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Patterns for @outfitter/daemon including lifecycle management, IPC communication, health checks, and PID files. Use when building background services, daemons, or when "daemon", "IPC", "health check", "background service", or "@outfitter/daemon" are mentioned.
Creates handlers, CLI commands, MCP tools, and daemon services following Outfitter Dev Kit conventions. Use when adding new components to a project, scaffolding code, or when "create handler", "new command", "add tool", or "daemon service" are mentioned.
Deep patterns for @outfitter/mcp including tool registration, Zod schemas, resources, and server configuration. Use when building MCP servers, registering tools, defining resources, or when "MCP server", "MCP tool", "registerTool", or "@outfitter/mcp" are mentioned.
正在显示 SKILL.md
基于 SOC 职业分类
| name | linear-project-management |
| description | Guides Linear project management — creates projects over tracking issues, structures PRDs, phases milestones, sizes issues, applies labels, and formats cross-references. Use when creating Linear projects, planning work, or organizing issues. |
| allowed-tools | ToolSearch, Read |
| metadata | {"version":"1.0.0","author":"outfitter","category":"project-management","tags":["linear","project-management","workflow"]} |
Conventions for managing work in Linear. Covers project structure, PRDs, milestones, issue sizing, labeling, and cross-referencing.
Always use Linear projects. Never use tracking issues (parent issues with checklists or sub-issues used to group work).
Why:
Use backtick formatting for package names and technical terms:
Batteries-included CLI conventions for `@outfitter/cli`
Linear renders backticks as inline code in titles, improving readability for technical projects.
Single issues don't need a project. But when in doubt, create the project — it's cheap and adds structure.
The project description field serves as the PRD. Use this structure:
## Problem
What's wrong or missing. Be specific about who is affected and why the current state is inadequate.
## Solution
How we'll address it. High-level approach, not implementation details. Focus on the user-visible outcome.
## Design Principle
The guiding constraint that shapes decisions throughout implementation. One sentence.
Example: "Convention over configuration — sensible defaults, explicit overrides."
## Scope
### In scope
- Concrete deliverables (bullet list)
### Out of scope
- Things we're explicitly not doing (prevents scope creep)
## Milestones
### Milestone 1: Foundation
Core infrastructure. Issues: ...
### Milestone 2: Feature surface
User-facing functionality. Issues: ...
### Milestone 3: Polish
Edge cases, docs, DX refinements. Issues: ...
## Success Criteria
- Measurable outcomes that define "done"
- Include both technical criteria (tests pass, types check) and user criteria (workflow is faster, errors are clearer)
Milestones group related issues into phases. They represent logical groupings, not strict sequential gates.
Use descriptive names that convey what the milestone achieves:
| Pattern | Example |
|---|---|
| Foundation | Core types and contracts |
| Feature surface | User-facing commands and options |
| Integration | Cross-package wiring |
| Polish | Edge cases, docs, DX |
| Hardening | Performance, error handling, tests |
Avoid generic names like "Phase 1" or "Sprint 3" — they carry no meaning.
Every issue in a project should belong to a milestone. Unassigned issues create ambiguity about when they'll be addressed. If an issue doesn't fit a milestone, either:
Issues map 1:1 to pull requests. This is the fundamental sizing constraint.
| Metric | Target | Hard limit |
|---|---|---|
| Effective LOC | 100-250 | ~300 (non-mechanical) |
| Files touched | 3-5 | 8 |
| Review time | 30-60 min | 60 min |
Effective LOC = lines that require human review. Excludes lockfiles, codegen, formatting-only changes.
When work naturally sequences (each piece builds on the last), create stacked issues that mirror the PR stack:
Issue: Add base types for config → PR 1 (foundation)
Issue: Implement config loader → PR 2 (stacked on PR 1)
Issue: Add CLI flags for config options → PR 3 (stacked on PR 2)
Use issue dependencies (blocks/blocked by) in Linear to express this ordering.
Formatting, renames, codegen, lockfile updates — isolate these in their own issue/PR or mark clearly as mechanical. They inflate LOC counts and obscure meaningful changes when mixed with feature work.
Every issue and project gets at least one label. Labels enable filtering, reporting, and quick orientation.
| Dimension | Examples | When to use |
|---|---|---|
| Package | @outfitter/cli, @outfitter/contracts | Scopes issue to a specific package |
| Type | feature, bug, chore, docs | Classifies the nature of work |
| Concern | DX, performance, security, testing | Cross-cutting quality attribute |
@outfitter/cli and DX.Consistent cross-referencing connects issues, PRs, and projects into a navigable web of context.
When referencing Linear issues or projects from within Linear (descriptions, comments, updates), use bare URLs:
https://linear.app/outfitter/issue/OS-176/outfittercli-first-class-queryability
https://linear.app/outfitter/project/batteries-included-cli-conventions-78e01e25016a
Linear auto-generates rich embeds with status badges, icons, and full titles. Using markdown link format ([text](url)) downgrades the rendering to plain text.
The URL slug after the issue ID is optional but improves readability.
When referencing GitHub PRs or issues from within Linear, use markdown link format:
Implemented in [#405](https://github.com/outfitter-dev/stack/pull/405).
See [outfitter-dev/stack#42](https://github.com/outfitter-dev/stack/issues/42) for details.
GitHub URLs don't get rich embeds in Linear, so descriptive link text provides necessary context.
OS-176 and #405 are not clickable in Linear. Always provide full URLs.
Linear's storage wraps URLs in angle brackets internally ([text](<url>)). This can break rendering in some contexts. This is another reason bare URLs are preferred for Linear-to-Linear references.
Post project updates for milestone completions, blockers, or significant progress. Include:
onTrack, atRisk, or offTrack| Operation | Tool |
|---|---|
| Create/update issues | mcp__claude_ai_Linear__create_issue, update_issue |
| Create/update projects | mcp__claude_ai_Linear__create_project, update_project |
| Milestones | mcp__claude_ai_Linear__create_milestone, update_milestone |
| List/search | mcp__claude_ai_Linear__list_issues, list_projects |
| Labels | mcp__claude_ai_Linear__list_issue_labels, create_issue_label |
| Documents | mcp__claude_ai_Linear__create_document, update_document |
| Project status updates | save_status_update or GraphQL for more control |
| Comments with formatting | GraphQL commentCreate (the comment action breaks newlines) |
Linear MCP tools are deferred. Load them first:
ToolSearch with query: "+linear <operation>"
For complete API recipes, GraphQL patterns, and gotchas, see references/api-patterns.md.