acceptance-spec

Generate detailed acceptance test specs for a Kazi feature area. Takes a feature ID from qa/acceptance/INDEX.md, reads phase requirements + architecture, and produces a structured acceptance criteria document with test cases ready for Playwright automation. Usage - /acceptance-spec <feature-id> [--update]

インストールへ移動

リポジトリ: rakheen-dama/b2b-strawman
ソースの最終更新活動: 2026年5月10日 18:49
検出された SKILL.md の言語: 英語
スター: 0
フォーク: 0

インストール方法

デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。

npx skills add https://github.com/rakheen-dama/b2b-strawman --skill acceptance-spec

コマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。

ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。

ソースファイルを確認

インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。

SKILL.md

ソースの指示 · 読み取り専用プレビュー

検索に戻るインストールに戻る

epic-v2

Implement a specific epic end-to-end — worktree, code, test, PR, review, merge. Supports auto-merge for automated phase execution. Pass the epic number as an argument (e.g. /epic_v2 7).

2026-06-23

epic

Implement a specific epic end-to-end — worktree, code, test, PR, review, merge. Pass the epic number as an argument (e.g. /epic 7).

2026-05-01

phase

Orchestrate an entire development phase — runs each epic slice sequentially via subagents, reviews, merges, then advances to the next. Pass the phase number (e.g. /phase 4).

2026-05-01

このリポジトリのすべてを見る

name	acceptance-spec
description	Generate detailed acceptance test specs for a Kazi feature area. Takes a feature ID from qa/acceptance/INDEX.md, reads phase requirements + architecture, and produces a structured acceptance criteria document with test cases ready for Playwright automation. Usage - /acceptance-spec <feature-id> [--update]

Acceptance Test Spec Generator

You are a QA architect with deep knowledge of the Kazi practice-management platform. Your job is to produce detailed, testable acceptance criteria for a specific feature area, structured for Playwright automation against the E2E mock-auth stack.

This is NOT a lifecycle narrative (that's /qa-cycle). This is feature-level acceptance testing — every behavior the feature promises, verified independently and repeatably.

Arguments

<feature-id> — the ID from qa/acceptance/INDEX.md (e.g., invoicing, customer-crud, trust-approvals)
[--update] — update an existing spec rather than creating from scratch

Step 0 — Resolve the Feature

Read qa/acceptance/INDEX.md to find the feature row matching <feature-id>.
Extract: feature name, phase number(s), dependencies, grouping.
If the feature ID doesn't exist in INDEX.md, tell the user and stop.

Step 1 — Gather Product Knowledge (Silent)

Read these sources to understand what the feature does. Read in parallel where possible:

Phase requirements: requirements/claude-code-prompt-phase{N}.md — the original spec. Read the sections relevant to this feature.
Phase architecture: architecture/phase{N}-*.md — data model, API endpoints, component design. Skim for the relevant entities and endpoints.

# {Feature Name} — Acceptance Test Spec > **Feature ID**: `{feature-id}` > **Phase(s)**: {phase numbers} > **Last Updated**: {YYYY-MM-DD} > **Status**: DRAFT | REVIEWED | AUTOMATED ## Overview {2-3 sentences: what this feature does, who uses it, why it matters.} ## Prerequisites {What must be set up before testing this feature: seed data, auth state, dependent features.} ## Test Environment - **Stack**: E2E mock-auth (localhost:3001 frontend, localhost:8081 backend) - **Auth**: Mock IDP (Alice=owner, Bob=admin, Carol=member) - **Org**: e2e-test-org ## Acceptance Criteria ### AC-{NNN}: {Criterion Title} **Given** {precondition} **When** {action} **Then** {expected outcome} **Test Cases:** | # | Scenario | Input | Expected | Priority | |---|----------|-------|----------|----------| | 1 | {Happy path} | {specific input} | {specific assertion} | P0 | | 2 | {Edge case} | {specific input} | {specific assertion} | P1 | | 3 | {Error case} | {specific input} | {specific assertion} | P1 | **Automation Notes:** - Selector hints: {CSS selectors, data-testid patterns, aria labels} - API verification: {backend endpoint to verify state after UI action} - Wait conditions: {what to wait for before asserting} {Repeat for each acceptance criterion} ## State Machine Tests (if applicable) {For features with lifecycle/status transitions:} | From | To | Trigger | Guards | Expected | |------|----|---------|--------|----------| | {state} | {state} | {action} | {conditions} | {result} | ## Permission Matrix (if applicable) | Action | Owner | Admin | Member | Portal Contact | |--------|-------|-------|--------|----------------| | {action} | {yes/no} | {yes/no} | {yes/no} | {yes/no} | ## Financial Accuracy (if applicable) {For billing/invoice/rate features: specific arithmetic test cases with exact numbers.} | Scenario | Inputs | Expected Calculation | Expected Total | |----------|--------|---------------------|----------------| | {case} | {values} | {formula} | {number} | ## Cross-Feature Integration Points {How this feature interacts with other features. Each is a potential regression surface.} | Integration | Related Feature | What to Verify | |-------------|----------------|----------------| | {description} | `{feature-id}` | {what breaks if this changes} | ## Known Bugs {Discovered during spec creation or testing. Each gets tracked and fixed.} | # | Description | Severity | Status | Fix PR | |---|-------------|----------|--------|--------| | | | | | | ## Playwright Test File Mapping {Where the automated tests should live:} | Spec File | Coverage | |-----------|----------| | `frontend/e2e/tests/{domain}/{feature}.spec.ts` | {what it tests} |

acceptance-spec

インストール方法

ソースファイルを確認

Acceptance Test Spec Generator

Arguments

Step 0 — Resolve the Feature

Step 1 — Gather Product Knowledge (Silent)

Acceptance Test Spec Generator

Arguments

Step 0 — Resolve the Feature

Step 1 — Gather Product Knowledge (Silent)

Step 2 — Identify Dependent Features

Step 3 — Generate the Spec

Quality Rules

Step 4 — Update INDEX.md

Step 5 — Report

--update Mode

Anti-Patterns

acceptance-spec

ソース情報

インストール方法

ソースファイルを確認

このリポジトリの他の Skills

このリポジトリの他の Skills

Acceptance Test Spec Generator

Arguments

Step 0 — Resolve the Feature

Step 1 — Gather Product Knowledge (Silent)

Acceptance Test Spec Generator

Arguments

Step 0 — Resolve the Feature

Step 1 — Gather Product Knowledge (Silent)

Step 2 — Identify Dependent Features

Step 3 — Generate the Spec

Quality Rules

Step 4 — Update INDEX.md

Step 5 — Report

--update Mode

Anti-Patterns