AIコーディング向けMarkdownのPRDテンプレート

製品要求文書（PRD、product requirements document）は、作業をタスクに分ける前に、問題と範囲を述べる散文です。機能仕様は、製品の1つの能力について、何をするか、なぜ存在するか、どう振る舞うかを書いた SpecScore のファイルです。Markdown は、そのファイルのプレーンテキスト形式です。仕様駆動開発（SDD、spec-driven development）は、コードより前に仕様を書き、仕様を真実の源として扱うやり方です。SpecScoreでは、要件（REQ、requirement）は機能の中にある名前付きの規則です。受け入れ基準（AC、acceptance criterion）は、それらの規則の1つ以上を指す任意の抽象的な条件です。シナリオは、Given、When、Then のステップで書いた具体例です。プランは、機能をタスクに分ける文書です。タスクは、人またはエージェントが終えられる作業の1単位です。継続的インテグレーション（CI、continuous integration）は、提案された変更のたびに走る自動検査です。その検査はコマンドラインインターフェース（CLI、command-line interface）のコマンド specscore spec lint で、その CLI は specscore/specscore-cli にあります。Easy Approach to Requirements Syntax（EARS）は、要件が使ってよい文型です。Claude Code は、このサイトの CLI Skills プラグインが対象として書かれている AI コーディングエージェントです。この機能仕様テンプレートは、その機能ファイルに、それを指して戻るプランとタスクを加えたものです。

最終更新: 2026年11月5日

この機能仕様テンプレートとは

PRD は、人が読む散文のファイル1つであることが多いです。SpecScore は、同じ要旨を、リンターが検査できるファイルとして保ちます。機能仕様は、機能を製品仕様の原子的単位と呼びます。機能は spec/features/ の下にあるディレクトリで、その README.md が、機能が何をするかの唯一の真実の源です。プラン仕様は、プランを、その機能をタスクへ分解する文書と呼びます。シナリオはシナリオ仕様において、機能の _tests/ ディレクトリにある具体的な Given/When/Then のファイルです。受け入れ基準の仕様は、基準を抽象のままにします。何が真でなければならないかを述べ、どう証明するかはシナリオが述べます。

下の checkout のファイルは、記入したテンプレートです。機能インデックス、仕様 README、specscore.yaml と合わせて、specscore spec lint は違反 0 件でそれを受け入れました。その検査は 2026年11月2日に、specscore 0.55.1 と 0.39.1 で実行しました。0.39.1 は dogfood.yml がインストールするタグです。機能ファイルの中の Studio ツールバーの行は、specscore/specscore の機能 README が載せている行です。機能仕様の必須セクション表には、その行は載っていません。

機能の README

機能仕様の必須セクション表は、すべての機能 README が次を持つと言います。タイトル # Feature: {Title}、タイトルの直後の **Status:** 行、Summary、Problem、Behavior の節、Acceptance Criteria の節、Open Questions の節、そして準拠のフッターです。状態の値は Draft、In Review、Approved、Implementing、Stable、Amending、Rejected、または Deprecated のいずれかです。Contents の節が必須なのは、機能に子ディレクトリがあるときだけです。**Source Ideas:** は任意です。検査したファイルはこれを — にしています。

Open Questions は省けません。1つもないときは、その節は None at this time. と書きます。Acceptance Criteria も省けません。基準が定義されていないとき、その節は Not defined yet. と書き、Open Questions には次を含めなければなりません。Acceptance criteria not yet defined for this feature. フッターは最後の行で、その URL は https://specscore.md/feature-specification です。

成果物の frontmatter 規約は、すべての成果物が YAML の frontmatter に format: キーを載せ、状態を持つ成果物はさらに status: を載せ、本文の **Status:** と揃える、と述べています。同じ機能は、それを強制する lint 規則には猶予期間がある、と述べています。検査したファイルは両方のキーを含みます。このページは、v0.39.1 のピンがそれらを省いたファイルを拒否する、とは主張しません。

specscore spec lint が受け入れた機能 README（2026年11月2日）

---
format: https://specscore.md/feature-specification
status: Draft
---

# Feature: Checkout validation

> [SpecScore.**Studio**](https://specscore.studio): | [Explore](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=explore) | [Edit](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=edit) | [Ask question](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=ask) | [Request change](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=request-change) |

**Status:** Draft
**Source Ideas:** —

## Summary

The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address.

## Problem

A vague sentence such as "the form should handle bad input" does not say which event causes which response. Checkout needs those obligations written so a reviewer and a linter can point at them.

## Behavior

### Field validation

The checkout system checks the form when the shopper submits it.

#### REQ: show-field-error

When a shopper submits the checkout form with invalid data, the checkout system MUST show a validation error next to the invalid field.

#### REQ: reject-invalid-email

If the submitted email is not a valid address, then the checkout system MUST reject the form.

## Acceptance Criteria

### AC: invalid-submission

**Requirements:** checkout#req:show-field-error, checkout#req:reject-invalid-email

Submitting the checkout form with invalid data shows a validation error next to the invalid field, and an email that is not a valid address is rejected.

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/feature-specification*

同じリント実行の機能インデックス

---
format: https://specscore.md/features-index-specification
---

# Features

| Feature | Status | Description |
|---|---|---|
| [Checkout validation](checkout/README.md) | Draft | The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address. |

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/features-index-specification*

同じリント実行の仕様 README

# Checkout specification

## Open Questions

None at this time.

同じリント実行の specscore.yaml

# SpecScore Repo Config Schema: https://specscore.md/repo-config

project:
  title: Checkout sample
  host: github.com
  org: example
  repo: checkout

機能の識別子は、spec/features/ からの相対ディレクトリパスです。インデックスのリンク checkout/README.md は、ファイルが spec/features/checkout/README.md にあることを意味するので、要件と基準が使う機能 id は checkout です。インデックスは最上位の機能をすべて列挙します。載っていない子ディレクトリは index-entries の違反であり、それを説明しているのが CIで仕様をリントするです。そのツリーの仕様 README には節が1つ、Open Questions があり、None at this time. と書きます。設定ファイルは、CLI が上へ向かって探す対象です。specscore.yaml がないと、コマンドは終了コード 3 で終わり、specscore init を挙げます。

REQ 識別子、受け入れ基準、シナリオ

要件仕様は、各規則を ## Behavior の中のトピック見出しの下に置きます。見出しは #### REQ: {slug} で、コロンの後は空白1つです。slug は小文字、数字、ハイフンを使います。正準の id は {feature-path}#req:{slug} です。checkout のファイルでは、それが checkout#req:show-field-error と checkout#req:reject-invalid-email です。要件は義務を1つ述べます。仕様は、要件が RFC 2119 のキーワード MUST、MUST NOT、SHOULD、SHOULD NOT、MAY を使うことを SHOULD とする、と述べています。REQ: の見出しは ## Behavior の外では妥当ではありません。EARS の文が、その散文になってよいです。リンターは英語を採点しません。パターンは EARS要件構文を例で説明するにあります。

受け入れ基準

受け入れ基準の仕様は、各基準が ### AC: {slug} という見出しで、## Acceptance Criteria の中にあり、続いて **Requirements:** 行が {feature-id}#req:{slug} の値を列挙し、その後に何が真でなければならないかを抽象的に述べる、と述べています。基準は任意です。仕様は、関連する要件を2つ以上まとめると明確になるときに、基準を1つ足すと言います。checkout のファイルは両方の規則を checkout#ac:invalid-submission にまとめています。その文には Given、When、Then は含まれません。受け入れ基準の書き方が執筆の案内です。規則 ac-heading-format（ac_heading.go、CLI タグ v0.55.1）は、見出しが ### AC: <id> で、id が kebab-case であることを検査します。リントの記事は、この規則が **Requirements:** 行を必須にせず、語を採点しない、と記録しています。受け入れ基準の仕様は、その行をなお必須としています。

シナリオ

シナリオ仕様は、シナリオを _tests/ に置きます。そこはサブ機能ではなく、機能インデックスから外れます。ファイルは # Scenario: {Title} で始まり、要件または基準を指す **Validates:** 行と、キーワードが大文字の GIVEN、WHEN、THEN、AND である ## Steps の節があります。すべての _tests/ ディレクトリには、シナリオのインデックスを持つ README が必要です。下の見本はそのファイルの形です。2026年11月2日のリント実行には含まれていません。specscore spec lint はシナリオのステップのキーワードを検査しません。specscore rehearse がシナリオのファイルを実行します。Rehearse がその実行器です。dogfood ワークフローはリンターを実行し、rehearse は呼びません。

シナリオ仕様によるシナリオファイルの形

# Scenario: Reject an invalid email

**Validates:** [checkout#ac:invalid-email-rejected](../README.md#ac-invalid-email-rejected)

## Steps

GIVEN the shopper is on the checkout form
WHEN the shopper submits the email "not-an-email"
THEN the page shows "Enter a valid email address" beside the email field
AND the order is not placed

3つの層を順に読みます。要件が規則を述べます。受け入れ基準は、それが名指す規則について何が真でなければならないかを述べます。シナリオは具体的な流れを1つ示します。PRD の散文しか見ないエージェントは、その分割を自分で作らなければなりません。テンプレートには、すでにそれがあります。

プランとタスク

プランの README は spec/plans/{plan-slug}/README.md にあります。プラン仕様は、タイトル # Plan: {Title} と、ヘッダのフィールド Status、出所の行ちょうど1つ、Date、Owner、Supersedes を必須とします。機能を出所とするプランは **Source Feature:** に機能の slug を足します。ここでは checkout です。ほかに許される出所の行は **Source:** idea:{slug} と **Source:** none です。必須の節は Summary、Approach、Tasks、Open Questions です。プランの中では、各タスクが ### Task N: の見出しで、**Verifies:** 行の形は feature-slug#ac:ac-slug です。規則 P-001（plan_rules.go）は、どのタスクも覆っておらず、## Deferred AC Coverage にも載っていない受け入れ基準の見出しを報告します。規則 P-002 は、それらの見出しの1つに解決しない **Verifies:** の値を報告します。idea を出所とするプランと、**Source:** none のプランは P-001 を免除されます。

下のプランは、checkout 機能について公開されたその形に従い、frontmatter の format: と status: を含みます。2026年11月2日のリント実行には含まれていません。プランが触れる機能は、列が Plan、Status、Author、Approved の ## Plans 表を含まなければなりません。検査した機能ファイルに Plans の節がないのは、そのツリーにプランがないからです。

タスク仕様は、タスクを、プランの下にある独自のディレクトリと README.md としても定義します。タイトルは # Task: {Title} です。必須のフィールドは **Status:**、**Depends on:**（依存がないときのリテラルは none）、**Model:**（small、medium、large、または inherit）です。子タスクのディレクトリを含むディレクトリはプランであり、タスクではありません。下のタスクファイルは、checkout の最初のタスクにそれらのフィールドを使います。2026年11月2日のリント実行には含まれていません。タスク文書のフッター URL は https://specscore.md/task-specification です。

プラン仕様の形を checkout 用に記入したもの

---
format: https://specscore.md/plan-specification
status: Draft
---

# Plan: Show checkout validation errors

**Status:** Draft
**Source Feature:** checkout
**Date:** 2026-11-05
**Owner:** @example
**Supersedes:** —

## Summary

This plan decomposes the checkout feature into the work that shows a field error and rejects an email that is not a valid address.

## Approach

Both tasks verify the same acceptance criterion, which bundles the two requirements. Nothing is deferred, so this plan has no Deferred AC Coverage section.

## Tasks

### Task 1: Show a validation error beside the invalid field

**Verifies:** checkout#ac:invalid-submission

When the shopper submits the checkout form with invalid data, show a validation error next to the invalid field.

### Task 2: Reject an email that is not a valid address

**Verifies:** checkout#ac:invalid-submission

If the submitted email is not a valid address, reject the form.

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/plan-specification*

タスク仕様によるタスク文書の形

---
format: https://specscore.md/task-specification
status: queued
---

# Task: Show a validation error beside the invalid field

**Status:** queued
**Depends on:** none
**Model:** medium

## Acceptance Criteria

- Submitting the checkout form with invalid data shows a validation error next to the invalid field.

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/task-specification*

機能ファイルは、checkout のフォームが何をしなければならないかに答えます。プランは、その作業をどう分けるかに答え、各インラインのタスクは検証する基準を名指します。タスク文書は、人またはエージェントが手に取る末端です。基準の id は動かさないでください。checkout#ac:invalid-submission は、機能とプランの両方が使う文字列です。

CI でテンプレートをリントする

specscore spec lint は、仕様ツリーを構造上の規約違反について検証します。違反のない実行は 0 violations found を印字して終了コード 0 です。違反を見つける実行は、発見ごとに1行を印字して終了コード 1 です。その終了コードが CI ジョブを失敗させます。無効な引数は終了コード 2 です。specscore.yaml がないと終了コード 3 です。dogfood.yml は SPECSCORE_VERSION を v0.39.1 に設定して CLI をインストールし、その後プルリクエストと main への push で specscore spec lint を実行します。ワークフローの抜粋、失敗の報告、規則カタログは CIで仕様リンターを使って仕様をリントするにあります。

フォーマットのライセンスは CC BY 4.0 で、specscore/specscore にあります。CLI のライセンスは Apache-2.0 で、specscore/specscore-cli にあります。

ほかの仕様駆動のツールは、別の検査を公開しています。下の文は、それらのプロジェクト自身のページが述べていることだけを使います。ツールまとめは、同じページを 2026年10月30日に読んだと記録しています。ただし Spec Kit の文書のホームは 2026年9月28日と印字しています。

OpenSpec は openspec validate を、その CLI リファレンスで文書化しています。そのコマンドは OpenSpec の変更と仕様の構造を検査し、検証が失敗するとゼロ以外で終わります。SpecScore の ### AC: 見出しや SpecScore のインデックスは検査しません。

Task Master の README は、task-master parse-prd で PRD をタスクへ解析することを述べています。その PRD のためのリンターは述べていません。PRD は、このページの機能ファイルへ書き直す入力であり続けてよいです。その機能ファイルを検査するのが specscore spec lint です。

GitHub Spec Kit は、段階が Markdown の成果物を書くエージェントのワークフローを述べています。その文書のホームは、CI で SpecScore の機能 README をリントするコマンドを述べていません。それらのツールの比較がツールまとめです。

Claude Code が読める仕様テンプレート

ファイルは Markdown なので、リポジトリを読めるエージェントはテンプレートを読めます。Claude Code は、CLI Skills のページが対象とするエージェントです。そのページは ai-plugin-specscore を文書化しています。CLI を包む、薄い Claude Code プラグインです。プラグインのリポジトリは specscore/ai-plugin-specscore です。ページは、プラグインが specscore spec lint、specscore feature、specscore task、specscore feature change-status をプラグインのコマンドとして出す、と述べています。そのページのインストール行は /plugin marketplace add specscore/ai-marketplace と /plugin install cli-skills@specscore です。

同じページは、SpecScore が管理するプロジェクトの中で実行する specscore agent setup <agent-name> を、claude、copilot、cursor、codex、antigravity.google、pi.dev、または opencode について文書化しています。SpecStudio Skills は案内付きのワークフロー（/ideate、/specify、/plan、/implement）で、これも Claude Code プラグインです。このページのテンプレートは、それらのコマンドがリントするファイルです。プラグインは機能 README を置き換えません。

よくある質問

MarkdownのPRDテンプレートとは何ですか？

決まった形を持つ Markdown ファイルとして書いた製品要求文書です。SpecScore では、その形は機能 README です。タイトル、状態、要約、問題、#### REQ: の規則を持つ振る舞い、受け入れ基準、未解決の質問です。このページの checkout のファイルは、specscore spec lint が受け入れたものの1つです。

機能仕様テンプレートで REQ の id はどこに置きますか？

## Behavior の中のトピック見出しの下に、#### REQ: {slug} として置きます。id は {feature-path}#req:{slug} です。受け入れ基準は、それらの id を **Requirements:** に列挙します。プランのタスクは、基準の id を **Verifies:** に列挙します。

受け入れ基準とシナリオはどう違いますか？

受け入れ基準は抽象的な条件です。シナリオは _tests/ にある具体的な Given/When/Then の流れです。受け入れ基準の仕様は、基準がステップを規定してはならない、と述べています。シナリオのファイルはステップを書きます。

リンターは PRD の散文を採点しますか？

いいえ。specscore spec lint が検査するのは構造です。見出し、必須の節、インデックスの行、P-001 や P-002 のような参照です。製品が良い考えかどうかは決めません。CIで仕様リンターを使って仕様をリントするがそのコマンドをより長く説明しています。

Claude Code はこの仕様テンプレートを使えますか？

はい。テンプレートはリポジトリの中の Markdown です。CLI Skills プラグインは、Claude Code の中で specscore spec lint と、機能およびタスクのコマンドを出します。specscore agent setup claude はそのエージェント向けの指示ファイルを書きます。プラグインは別のテンプレートを作りません。

プランは機能仕様を置き換えますか？

いいえ。機能 README が、要件と受け入れ基準の源です。プランはその機能をタスクへ分解し、各タスクは **Verifies:** で戻って指します。プラン仕様とタスク仕様が、その分割のための2つの文書です。

出典

checkout の機能、機能インデックス、仕様 README、specscore.yaml は、2026年11月2日に specscore spec lint が specscore 0.55.1 と 0.39.1 で受け入れました。プランとタスクの見本は公開された仕様に従い、その実行には含まれていません。他プロジェクトのページは下にリンクしたものです。ツールまとめは、それらを 2026年10月30日に読んだと記録しています。ただし Spec Kit の文書のホームは 2026年9月28日と印字しています。