# AI 코딩을 위한 Markdown PRD 템플릿

Canonical: https://specscore.md/ko/articles/feature-spec-template/

마지막 업데이트: 2026년 11월 5일

제품 요구사항 문서(PRD, product requirements document)는 일을 작업으로 나누기 전에 문제와 범위를 적는 산문입니다. [기능 명세](https://specscore.md/feature-specification)는 제품의 한 능력에 대해 무엇을 하는지, 왜 있는지, 어떻게 행동하는지를 적은 SpecScore의 파일입니다. Markdown은 그 파일의 일반 텍스트 형식입니다. [명세 주도 개발](https://specscore.md/ko/spec-driven-development/)(SDD, spec-driven development)은 코드보다 먼저 명세를 쓰고, 명세를 진실의 원천으로 다루는 방식입니다. [SpecScore](https://specscore.md/)에서 요구사항(REQ, requirement)은 기능 안에 있는 이름이 있는 규칙입니다. [인수 기준](https://specscore.md/acceptance-criteria-specification)(AC, acceptance criterion)은 그 규칙 하나 이상을 가리키는 선택적 추상 조건입니다. 시나리오는 Given, When, Then 단계로 쓴 구체적 예입니다. [계획](https://specscore.md/plan-specification)은 기능을 작업으로 나누는 문서입니다. [작업](https://specscore.md/task-specification)은 사람이나 에이전트가 끝낼 수 있는 일의 한 단위입니다. [지속적 통합](https://specscore.md/ko/validators/)(CI, continuous integration)은 제안된 변경마다 도는 자동 검사입니다. 그 검사는 [명령줄 인터페이스](https://specscore.md/ko/cli/)(CLI, command-line interface) 명령 `specscore spec lint`이며, 그 CLI는 [specscore/specscore-cli](https://github.com/specscore/specscore-cli)에 있습니다. [Easy Approach to Requirements Syntax](https://specscore.md/ko/articles/ears-requirements/)(EARS)는 요구사항이 써도 되는 문장 패턴입니다. Claude Code는 이 사이트의 [CLI Skills](https://specscore.md/ko/ai/cli-skills/) 플러그인이 대상으로 작성된 AI 코딩 에이전트입니다. 이 기능 명세 템플릿은 그 기능 파일에, 그것을 다시 가리키는 계획과 작업을 더한 것입니다.

## 이 기능 명세 템플릿이란

PRD는 사람이 읽는 산문 파일 하나인 경우가 많습니다. SpecScore는 같은 개요를 린터가 검사할 수 있는 파일로 보관합니다. [기능 명세](https://specscore.md/feature-specification)는 기능을 제품 명세의 원자 단위라고 부릅니다. 기능은 `spec/features/` 아래의 디렉터리이고, 그 `README.md`가 기능이 무엇을 하는지에 대한 유일한 진실의 원천입니다. [계획 명세](https://specscore.md/plan-specification)는 계획을, 그 기능을 작업으로 분해하는 문서라고 부릅니다. 시나리오는 [시나리오 명세](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md)에서 기능의 `_tests/` 디렉터리에 있는 구체적인 Given/When/Then 파일입니다. [인수 기준 명세](https://specscore.md/acceptance-criteria-specification)는 기준을 추상으로 둡니다. 무엇이 참이어야 하는지는 기준이 말하고, 어떻게 증명하는지는 시나리오가 말합니다.

아래 checkout 파일은 채워 넣은 템플릿입니다. 기능 인덱스, 명세 README, `specscore.yaml`과 함께 `specscore spec lint`이 위반 0건으로 그것을 받아들였습니다. 그 검사는 2026년 11월 2일에 specscore 0.55.1과 0.39.1로 실행했습니다. 0.39.1은 [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml)이 설치하는 태그입니다. 기능 파일 안의 Studio 도구 모음 줄은 [specscore/specscore](https://github.com/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 관례](https://github.com/specscore/specscore/blob/main/spec/features/artifact-frontmatter-convention/README.md)는 모든 산출물이 YAML frontmatter에 `format:` 키를 싣고, 상태를 가진 산출물은 `status:`도 실어 본문의 `**Status:**`과 맞춘다고 말합니다. 같은 기능은 이를 강제하는 lint 규칙에 유예 기간이 있다고 말합니다. 검사한 파일은 두 키를 모두 포함합니다. 이 페이지는 v0.39.1 핀이 그 키를 뺀 파일을 거부한다고 주장하지 않습니다.

### specscore spec lint가 받아들인 기능 README (2026년 11월 2일)

```markdown
---
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*
```

### 같은 린트 실행의 기능 인덱스

```markdown
---
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

```markdown
# Checkout specification

## Open Questions

None at this time.
```

### 같은 린트 실행의 specscore.yaml

```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에서 명세를 린트하기](https://specscore.md/ko/articles/lint-specs-in-ci/)입니다. 그 트리의 명세 README에는 절이 하나, Open Questions가 있고, `None at this time.`라고 씁니다. 설정 파일은 CLI가 위쪽으로 찾아 올라가는 대상입니다. `specscore.yaml`이 없으면 명령은 종료 코드 3으로 끝나고 `specscore init`을 지목합니다.

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

[요구사항 명세](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md)는 각 규칙을 `## 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 요구사항 구문을 예와 함께 설명](https://specscore.md/ko/articles/ears-requirements/)에 있습니다.

### 인수 기준

[인수 기준 명세](https://specscore.md/acceptance-criteria-specification)는 각 기준이 `### AC: {slug}` 제목으로 `## Acceptance Criteria` 안에 있고, 이어서 `**Requirements:**` 줄이 `{feature-id}#req:{slug}` 값을 나열한 뒤, 무엇이 참이어야 하는지를 추상적으로 말한다고 합니다. 기준은 선택입니다. 명세는 관련된 요구사항을 둘 이상 묶으면 더 분명해질 때 기준을 하나 더하라고 말합니다. checkout 파일은 두 규칙을 `checkout#ac:invalid-submission`로 묶습니다. 그 문장에는 Given, When, Then이 없습니다. [인수 기준을 쓰는 법](https://specscore.md/ko/articles/acceptance-criteria/)이 작성 안내입니다. 규칙 `ac-heading-format`([ac_heading.go](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/ac_heading.go), CLI 태그 v0.55.1)은 제목이 `### AC: <id>`이고 id가 kebab-case인지 검사합니다. [린트 글](https://specscore.md/ko/articles/lint-specs-in-ci/)은 이 규칙이 `**Requirements:**` 줄을 요구하지 않고 단어를 채점하지 않는다고 기록합니다. 인수 기준 명세는 그 줄을 여전히 요구합니다.

### 시나리오

[시나리오 명세](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md)는 시나리오를 `_tests/`에 둡니다. 그곳은 하위 기능이 아니고 기능 인덱스에서 빠집니다. 파일은 `# Scenario: {Title}`로 시작하고, 요구사항이나 기준을 가리키는 `**Validates:**` 줄과, 키워드가 대문자 GIVEN, WHEN, THEN, AND인 `## Steps` 절이 있습니다. 모든 `_tests/` 디렉터리에는 시나리오 인덱스가 있는 README가 있어야 합니다. 아래 샘플은 그 파일 형태입니다. 2026년 11월 2일 린트 실행에는 들어 있지 않았습니다. `specscore spec lint`는 시나리오 단계 키워드를 검사하지 않습니다. `specscore rehearse`가 시나리오 파일을 실행합니다. [Rehearse](https://specscore.md/rehearse)가 그 실행기입니다. dogfood 워크플로는 린터를 실행하고 rehearse는 호출하지 않습니다.

### 시나리오 명세에 따른 시나리오 파일 형태

```markdown
# 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`에 있습니다. [계획 명세](https://specscore.md/plan-specification)는 제목 `# 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](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/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 절이 없는 이유는 그 트리에 계획이 없기 때문입니다.

[작업 명세](https://specscore.md/task-specification)는 작업을 계획 아래의 자체 디렉터리와 `README.md`로도 정의합니다. 제목은 `# Task: {Title}`입니다. 필수 필드는 `**Status:**`, `**Depends on:**`(의존이 없을 때의 리터럴은 `none`), `**Model:**`(`small`, `medium`, `large` 또는 `inherit`)입니다. 하위 작업 디렉터리를 담은 디렉터리는 계획이지 작업이 아닙니다. 아래 작업 파일은 checkout의 첫 작업에 그 필드를 씁니다. 2026년 11월 2일 린트 실행에는 들어 있지 않았습니다. 작업 문서의 바닥글 URL은 `https://specscore.md/task-specification`입니다.

### 계획 명세의 형태를 checkout에 맞춰 채운 것

```markdown
---
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*
```

### 작업 명세에 따른 작업 문서 형태

```markdown
---
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](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml)는 `SPECSCORE_VERSION`을 `v0.39.1`로 두고 CLI를 설치한 다음, pull request와 main으로의 push에서 `specscore spec lint`을 실행합니다. 워크플로 발췌, 실패 보고, 규칙 목록은 [CI에서 명세 린터로 명세를 린트하기](https://specscore.md/ko/articles/lint-specs-in-ci/)에 있습니다.

형식의 라이선스는 [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE)이며, [specscore/specscore](https://github.com/specscore/specscore)에 있습니다. CLI의 라이선스는 [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE)이며, [specscore/specscore-cli](https://github.com/specscore/specscore-cli)에 있습니다.

다른 명세 주도 도구는 서로 다른 검사를 공개합니다. 아래 문장은 그 프로젝트 자신의 페이지가 말하는 것만 사용합니다. [도구 정리](https://specscore.md/ko/spec-driven-development/tools/)는 같은 페이지를 2026년 10월 30일에 읽은 것으로 기록합니다. 다만 Spec Kit 문서 홈은 2026년 9월 28일을 인쇄합니다.

[OpenSpec](https://github.com/Fission-AI/OpenSpec)는 `openspec validate`를 자신의 [CLI 참고](https://openspec.dev/docs/cli)에 문서화합니다. 그 명령은 OpenSpec의 변경과 명세 구조를 검사하고, 검증이 실패하면 0이 아닌 값으로 끝납니다. SpecScore의 `### AC:` 제목이나 SpecScore 인덱스는 검사하지 않습니다.

[Task Master](https://github.com/eyaltoledano/claude-task-master) README는 `task-master parse-prd`로 PRD를 작업으로 파싱한다고 설명합니다. 그 PRD를 위한 린터는 설명하지 않습니다. PRD는 이 페이지의 기능 파일로 다시 쓰는 입력으로 남을 수 있습니다. 그 기능 파일을 검사하는 것이 `specscore spec lint`입니다.

[GitHub Spec Kit](https://github.github.io/spec-kit/)는 단계가 Markdown 산출물을 쓰는 에이전트 워크플로를 설명합니다. 그 문서 홈은 CI에서 SpecScore 기능 README를 린트하는 명령을 설명하지 않습니다. 그 도구들의 비교가 [도구 정리](https://specscore.md/ko/spec-driven-development/tools/)입니다.

## Claude Code가 읽을 수 있는 명세 템플릿

파일은 Markdown이므로, 저장소를 읽을 수 있는 에이전트는 템플릿을 읽을 수 있습니다. Claude Code는 [CLI Skills](https://specscore.md/ko/ai/cli-skills/) 페이지가 대상으로 하는 에이전트입니다. 그 페이지는 `ai-plugin-specscore`를 문서화합니다. CLI를 감싸는 얇은 Claude Code 플러그인입니다. 플러그인 저장소는 [specscore/ai-plugin-specscore](https://github.com/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](https://specscore.md/ko/ai/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 흐름입니다. [인수 기준 명세](https://specscore.md/acceptance-criteria-specification)는 기준이 단계를 규정하면 안 된다고 말합니다. 시나리오 파일은 단계를 적습니다.

### 린터는 PRD 산문을 채점합니까?

아닙니다. `specscore spec lint`가 검사하는 것은 구조입니다. 제목, 필수 절, 인덱스 행, `P-001`과 `P-002` 같은 참조입니다. 제품이 좋은 생각인지는 정하지 않습니다. [CI에서 명세 린터로 명세를 린트하기](https://specscore.md/ko/articles/lint-specs-in-ci/)가 그 명령을 더 길게 설명합니다.

### Claude Code가 이 명세 템플릿을 쓸 수 있습니까?

예. 템플릿은 저장소 안의 Markdown입니다. [CLI Skills](https://specscore.md/ko/ai/cli-skills/) 플러그인은 Claude Code 안에서 `specscore spec lint`와 기능 및 작업 명령을 내놓습니다. `specscore agent setup claude`는 그 에이전트를 위한 지시 파일을 씁니다. 플러그인은 다른 템플릿을 만들지 않습니다.

### 계획이 기능 명세를 대체합니까?

아닙니다. 기능 README가 요구사항과 인수 기준의 원천입니다. 계획은 그 기능을 작업으로 분해하고, 각 작업은 `**Verifies:**`로 다시 가리킵니다. [계획 명세](https://specscore.md/plan-specification)와 [작업 명세](https://specscore.md/task-specification)가 그 나눔을 위한 두 문서입니다.

## 출처

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

- [기능 명세](https://specscore.md/feature-specification)
- [specscore/specscore — 기능 명세](https://github.com/specscore/specscore/blob/main/spec/features/feature/README.md)
- [specscore/specscore — 요구사항 명세](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md)
- [인수 기준 명세](https://specscore.md/acceptance-criteria-specification)
- [specscore/specscore — 인수 기준 명세](https://github.com/specscore/specscore/blob/main/spec/features/acceptance-criteria/README.md)
- [specscore/specscore — 시나리오 명세](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md)
- [계획 명세](https://specscore.md/plan-specification)
- [specscore/specscore — 계획 명세](https://github.com/specscore/specscore/blob/main/spec/features/plan/README.md)
- [작업 명세](https://specscore.md/task-specification)
- [specscore/specscore — 작업 명세](https://github.com/specscore/specscore/blob/main/spec/features/task/README.md)
- [specscore/specscore — 산출물 frontmatter 관례](https://github.com/specscore/specscore/blob/main/spec/features/artifact-frontmatter-convention/README.md)
- [specscore/specscore](https://github.com/specscore/specscore)
- [specscore/specscore — CC BY 4.0 라이선스](https://github.com/specscore/specscore/blob/main/LICENSE)
- [specscore/specscore-cli](https://github.com/specscore/specscore-cli)
- [specscore-cli — Apache-2.0 라이선스](https://github.com/specscore/specscore-cli/blob/main/LICENSE)
- [specscore/specscore — dogfood.yml (CLI v0.39.1)](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml)
- [specscore-cli v0.55.1 — ac-heading-format](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/ac_heading.go)
- [specscore-cli v0.55.1 — 계획 규칙 P-001과 P-002](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/plan_rules.go)
- [CI에서 명세 린터로 명세를 린트하기](https://specscore.md/ko/articles/lint-specs-in-ci/)
- [AI 에이전트가 검증할 수 있는 인수 기준을 쓰는 법](https://specscore.md/ko/articles/acceptance-criteria/)
- [EARS 요구사항 구문을 예와 함께 설명](https://specscore.md/ko/articles/ears-requirements/)
- [CLI Skills — Claude Code 안의 SpecScore CLI](https://specscore.md/ko/ai/cli-skills/)
- [SpecStudio Skills](https://specscore.md/ko/ai/specstudio-skills/)
- [specscore/ai-plugin-specscore](https://github.com/specscore/ai-plugin-specscore)
- [SpecScore가 검증하는 것](https://specscore.md/ko/validators/)
- [Rehearse](https://specscore.md/rehearse)
- [OpenSpec CLI 참고 — openspec validate](https://openspec.dev/docs/cli)
- [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec)
- [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master)
- [GitHub Spec Kit 문서 (페이지 날짜 2026년 9월 28일)](https://github.github.io/spec-kit/)
- [명세 주도 개발 도구](https://specscore.md/ko/spec-driven-development/tools/)

## 관련

- [Claude Code와 Cursor로 하는 명세 주도 개발](https://specscore.md/ko/articles/claude-code-specs/)
- [기능 명세](https://specscore.md/feature-specification)
- [인수 기준 명세](https://specscore.md/acceptance-criteria-specification)
- [계획 명세](https://specscore.md/plan-specification)
- [작업 명세](https://specscore.md/task-specification)
- [AI 에이전트가 검증할 수 있는 인수 기준을 쓰는 법](https://specscore.md/ko/articles/acceptance-criteria/)
- [EARS 요구사항 구문을 예와 함께 설명](https://specscore.md/ko/articles/ears-requirements/)
- [CI에서 명세 린터로 명세를 린트하기](https://specscore.md/ko/articles/lint-specs-in-ci/)
- [명세 주도 개발](https://specscore.md/ko/spec-driven-development/)
- [명세 주도 개발 도구](https://specscore.md/ko/spec-driven-development/tools/)
- [Claude Code를 위한 CLI Skills](https://specscore.md/ko/ai/cli-skills/)
- [CLI](https://specscore.md/ko/cli/)