無料GitHub で公開

feature-spec

Write a concise feature spec for engineering handoff. Use when the user says "write a spec", "feature spec", "one-pager for eng", "spec this out", "write up this feature", "I need to hand this off to engineering", "shape this up", or wants a concise technical brief - even if they don't say "feature spec".

qa-aman/claude-skills

インストール方法を見る

含まれるファイル（1）

SKILL.md3.6 KB

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Overview

Based on Shape Up by Ryan Singer (Basecamp). A feature spec is not a PRD. A PRD justifies building something. A spec tells engineers exactly what to build - but at the right altitude. Shape Up's principle: give engineers a shaped problem with clear boundaries, not a detailed recipe. Ambiguity in the spec becomes a bug in production. Over-specification kills ownership.

Workflow

Step 1: Write the header

# Feature Spec: [Feature Name]
**PM:** [your name]
**Eng Lead:** [engineer name]
**Appetite:** [1-2 weeks / 4-6 weeks]
**Status:** Draft | In Review | Approved
**Related PRD / Ticket:** [link]

Step 2: Write the Problem (2-3 sentences)

What is broken or missing? Who is affected? Shape Up framing: "Jobs to be done" - what job is the user hiring this feature to do?

Step 3: Write the Solution at the right altitude

Shape Up's "fat marker sketch" - describe the solution broadly. Engineers need room to make technical decisions. Write at the level of user-visible behavior, not implementation.

Structure:

Key interactions - what users can do (not how)
Boundaries - explicit scope limits
Rabbit holes - specific traps to avoid

Step 4: Write Functional Requirements

Number each. Cover in order:

Happy path
Error states
Empty states
Edge cases

Step 5: Write Non-Functional Requirements

Only include what's genuinely constrained:

Performance targets
Accessibility level (WCAG AA minimum)
Browser/device support
Security or compliance requirements

Don't pad. If there's no real constraint, don't list one.

Step 6: Define No-Gos (Shape Up)

Explicit list of what this spec does NOT include. This is Shape Up's most important contribution to spec writing - stating what you're NOT building is as important as what you are.

Step 7: List Open Questions

Q: [question]
Owner: [name]
Due: [date]

No spec should be approved with unresolved questions. Assign owners.

Step 8: Link assets

Figma files, API specs, data models. A spec without visuals is incomplete for UI work.

Anti-Patterns

1. Over-specifying implementation Bad: "The button is blue, 48px, positioned top-right with 16px margin." Good: "Users can trigger X from the main action area. Exact placement per Figma [link]." Shape Up: over-speccing removes creative ownership from engineers and designers.

2. Missing error states Bad: "User submits the form and sees confirmation." Good: Cover success, validation error, server error, empty state, and loading state.

3. No rabbit holes section Bad: Spec that describes what to build but not what to avoid. Good: "Don't rebuild the notification system for this - use existing email infrastructure."

4. Spec approved with open questions Bad: "TBD" items in an approved spec. Good: All open questions resolved or explicitly deferred with a named owner and date.

Quality Checklist

Appetite defined (small or big batch)
Problem framed as "job to be done"
Solution at the right altitude - behavior not implementation
Requirements cover happy path, errors, empty states, edge cases
No-Gos explicitly listed
Rabbit holes called out
Open questions have owners and due dates
Figma / mockup links included for UI work
Spec fits on one page (split if it doesn't)

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

11-star-framework

無料

Rate any product, feature, or experience on the 11-star scale (Brian Chesky's Airbnb thought experiment). Use when user says "rate this experience", "11-star", "star rating", "experience audit", "how good is this", "experience rating", "product audit", "quality assessment", or wants to evaluate product quality and identify improvement paths. Also trigger when user wants to benchmark a feature, assess where a product stands, or map out what "great" looks like - even if they don't explicitly say "11-star".

日本語の概要は準備中です。原文の説明を表示しています。