AI 코딩을 위한 Markdown PRD 템플릿

제품 요구사항 문서(PRD, product requirements document)는 일을 작업으로 나누기 전에 문제와 범위를 적는 산문입니다. 기능 명세는 제품의 한 능력에 대해 무엇을 하는지, 왜 있는지, 어떻게 행동하는지를 적은 SpecScore의 파일입니다. Markdown은 그 파일의 일반 텍스트 형식입니다. 명세 주도 개발(SDD, spec-driven development)은 코드보다 먼저 명세를 쓰고, 명세를 진실의 원천으로 다루는 방식입니다. SpecScore에서 요구사항(REQ, requirement)은 기능 안에 있는 이름이 있는 규칙입니다. 인수 기준(AC, acceptance criterion)은 그 규칙 하나 이상을 가리키는 선택적 추상 조건입니다. 시나리오는 Given, When, Then 단계로 쓴 구체적 예입니다. 계획은 기능을 작업으로 나누는 문서입니다. 작업은 사람이나 에이전트가 끝낼 수 있는 일의 한 단위입니다. 지속적 통합(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는 사람이 읽는 산문 파일 하나인 경우가 많습니다. 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는 빼지 않습니다. 아무것도 없으면 그 절은 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에는 절이 하나, Open Questions가 있고, None at this time.라고 씁니다. 설정 파일은 CLI가 위쪽으로 찾아 올라가는 대상입니다. specscore.yaml이 없으면 명령은 종료 코드 3으로 끝나고 specscore init을 지목합니다.

REQ 식별자, 인수 기준, 시나리오

요구사항 명세는 각 규칙을 ## Behavior 안의 주제 제목 아래에 둡니다. 제목은 #### REQ: {slug}이고, 콜론 뒤에는 공백이 하나 있습니다. slug는 소문자, 숫자, 하이픈을 씁니다. 정규 id는 {feature-path}#req:{slug}입니다. checkout 파일에서는 그것이 checkout#req:show-field-error와 checkout#req:reject-invalid-email입니다. 요구사항은 의무를 하나 말합니다. 명세는 요구사항이 RFC 2119 키워드 MUST, MUST NOT, SHOULD, SHOULD NOT, MAY를 쓸 것을 SHOULD로 둔다고 말합니다. REQ: 제목은 ## Behavior 밖에서는 유효하지 않습니다. EARS 문장이 그 산문이 될 수 있습니다. 린터는 영어를 채점하지 않습니다. 패턴은 EARS 요구사항 구문을 예와 함께 설명에 있습니다.

인수 기준

인수 기준 명세는 각 기준이 ### AC: {slug} 제목으로 ## Acceptance Criteria 안에 있고, 이어서 **Requirements:** 줄이 {feature-id}#req:{slug} 값을 나열한 뒤, 무엇이 참이어야 하는지를 추상적으로 말한다고 합니다. 기준은 선택입니다. 명세는 관련된 요구사항을 둘 이상 묶으면 더 분명해질 때 기준을 하나 더하라고 말합니다. 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

세 층을 순서대로 읽습니다. 요구사항이 규칙을 말합니다. 인수 기준은 그것이 지목하는 규칙에 대해 무엇이 참이어야 하는지를 말합니다. 시나리오는 구체적인 흐름을 하나 줍니다. PRD 산문만 보는 에이전트는 그 나눔을 스스로 만들어야 합니다. 템플릿에는 이미 그것이 있습니다.

계획과 작업

계획 README는 spec/plans/{plan-slug}/README.md에 있습니다. 계획 명세는 제목 # Plan: {Title}과 헤더 필드 Status, 출처 줄 정확히 하나, 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는 그 제목 중 하나로 해소되지 않는 **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입니다. 그 종료 코드가 CI 작업을 실패하게 합니다. 잘못된 인자는 종료 코드 2입니다. specscore.yaml이 없으면 종료 코드 3입니다. dogfood.yml는 SPECSCORE_VERSION을 v0.39.1로 두고 CLI를 설치한 다음, pull request와 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의 변경과 명세 구조를 검사하고, 검증이 실패하면 0이 아닌 값으로 끝납니다. 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가 받아들인 것 중 하나입니다.

기능 명세 템플릿에서 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:**로 다시 가리킵니다. 계획 명세와 작업 명세가 그 나눔을 위한 두 문서입니다.

출처

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일을 인쇄합니다.