본문으로 건너뛰기
cccskills
무료GitHub에 공개

aid-prd

AID Phase 1 - PRD creation. Use for user stories, acceptance criteria, scoping features, transitioning from discovery to tech spec.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(5)

  • SKILL.md4.4 KB
  • references/acceptance-criteria-patterns.md15.7 KB
  • references/prd-template-extended.md10.7 KB
  • references/user-stories-guide.md15.4 KB
  • SKILL.extended.md17.6 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Phase 1: PRD

Applies when: Discovery complete, problem validated, stakeholders identified. Done when: PRD complete, user stories with acceptance criteria, scope defined. Purpose: Define what will be built with clarity for unambiguous development.

Deliverables

  1. PRD Document - Readable by technical and non-technical
  2. User Stories - "As a [role], I want [capability] so that [benefit]"
  3. Acceptance Criteria - Gherkin format (REQUIRED), executable specifications
  4. Feature Files - Saved to features/ directory as .feature files
  5. Scope Definition - In-scope and out-of-scope explicit
  6. Traceability - Every requirement links to research or flagged as assumption

Gherkin is REQUIRED because acceptance criteria become the tests; no PRD-to-QA translation step. Gherkin syntax reference: cucumber-bdd skill. Deeper guides: references/user-stories-guide.md, references/acceptance-criteria-patterns.md, references/prd-template-extended.md.

User Story Format

### US-001: [Title]
**Research Backing**: [PROJECT]-A-INT-XXX OR ASSUMPTION - [rationale]

**As a** [role]
**I want** [capability]
**So that** [benefit]

**Priority:** [Must Have | Should Have | Could Have | Won't Have]
**Complexity:** [XS | S | M | L | XL]

Acceptance Criteria (Gherkin - REQUIRED)

Save as: features/[feature-area]/[story-slug].feature

# Research: [PROJECT]-A-INT-XXX
# PRD: US-001
@[feature-tag] @[priority-tag]
Feature: [Story Title]
  """
  WHY: [Copy the "So that" benefit here]
  """

  As a [role]
  I want [capability]
  So that [benefit]

  Background:
    Given [shared preconditions for all scenarios]

  @smoke @happy-path
  Scenario: [Happy path - main success]
    Given [precondition/context]
    And [additional setup if needed]
    When [user action]
    Then [expected outcome]
    And [additional verification]

  @error-handling
  Scenario: [Error case - validation failure]
    Given [precondition]
    When [invalid action]
    Then [error handling]
    And [user guidance shown]

  @edge-case
  Scenario: [Edge case - boundary condition]
    Given [edge condition]
    When [action]
    Then [expected behavior at boundary]

Common Pitfalls

PitfallFix
Implementation in requirementsKeep focused on outcomes
Untestable criteria"Should load in <2s" not "be fast"
Missing error casesDefine what happens when things fail
Scope creepExplicit acknowledgment for additions
Orphan requirementsLink to research or flag assumption

Phase Gate Checklist

Document Quality

  • PRD document complete
  • User stories follow proper format
  • Scope explicitly defined (in AND out)
  • Dependencies identified
  • Every requirement has research ID OR assumption flag
  • Traceability matrix updated

Acceptance Criteria (Gherkin) ⭐ REQUIRED

  • Every user story has acceptance criteria in Gherkin format
  • Feature files saved to features/ directory
  • Each story has at least 2 scenarios: happy path + error case
  • All scenarios have appropriate @tags (@critical, @smoke, etc.)
  • Research backing noted as comment in feature files
  • npm run cucumber:dry passes (validates Gherkin syntax)

Validation Command

npm run cucumber:dry   # Must pass before advancing to Phase 2

PRD Template

# [Feature] PRD

## 1. Overview
### Problem Statement
[Problem] **Research**: [ID]

### Goals
[Goals] **Research**: [ID]

### Non-Goals
[Excluded items]

## 2. User Stories
[Stories with research backing]

## 3. Scope
### In Scope
| Item | Research Backing |
|------|------------------|

### Out of Scope
| Item | Rationale |
|------|-----------|

## 4. Dependencies
## 5. Success Metrics
## 6. Assumptions Log
| ID | Assumption | Risk | Validation Plan |
## 7. Open Questions

Role Guidance

RoleFocus
PMOwn PRD, user stories, acceptance criteria
DevReview feasibility, identify edge cases
QAReview testability, identify scenarios
Tech LeadValidate fit, flag non-functionals

Handoff to Tech Spec

  • Approved PRD
  • Prioritized user stories
  • Complete acceptance criteria
  • Dependencies identified
  • Traceability matrix

Save to: docs/prd/YYYY-MM-DD-[feature].md

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

AID Phase 4 - Development phase. Use for implementing features, TDD practices, code reviews, transitioning from planning to QA.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

ilandahan/AID102026년 9월 23일 업데이트

AID Phase 0 - Research & discovery. Use for validating problem spaces, identifying stakeholders, defining success metrics, deciding whether to proceed.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

ilandahan/AID102026년 9월 23일 업데이트

AID Phase 3 - Implementation Planning with consolidation-first approach. Resolves contradictions between PRD and Tech Spec, creates consolidated master document, then breaks down into actionable tasks and populates Jira. Includes sprint planning and risk assessment.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

ilandahan/AID102026년 9월 23일 업데이트

AID Phase 5 - QA and Release. Use for validating implementations, acceptance tests, preparing releases, deployment, operational readiness.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

ilandahan/AID102026년 9월 23일 업데이트

AID Phase 2 - Technical Specification. Use for system architecture, API contracts, data models, security architecture, transitioning from PRD to implementation.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

ilandahan/AID102026년 9월 23일 업데이트

Build an Atomic Design system from Figma style guides - extract tokens, create atoms/molecules/organisms/templates/pages as reusable component libraries. Use when building or extending a design system or component library.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

ilandahan/AID102026년 9월 23일 업데이트

ilandahan의 스킬 모두 보기

이 스킬의 문제 신고