本文へ移動
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

レビュー

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

同じリポジトリのスキル

概要と使いどころ

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 のスキルをすべて見る

このスキルの問題を報告する