本文へ移動
cccskills
無料GitHub で公開

aid-development

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

インストール方法を見る

含まれるファイル(3)

  • SKILL.md4.5 KB
  • references/documentation-standards.md8.1 KB
  • SKILL.extended.md9.0 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Development Phase Skill

Phase 4. Purpose: implement solution with quality built-in through TDD. Entry: tech spec completed, architecture defined. Exit: all features implemented, tests passing, code reviewed.

Deliverables:

  1. Production Code - Clean, documented, follows standards
  2. Test Suite - Unit, integration, E2E, >80% coverage
  3. Documentation - Code docs, API docs, README updates

MANDATORY: QA Gate After EVERY Task

Iron Rule: Task complete → Spawn QA → Wait for result → PASS? Next task : Fix

Per-task flow:

  1. Read task + QA criteria (.aid/qa/{task-id}.yaml)
  2. Implement task (TDD)
  3. Signal complete (TodoWrite)
  4. SPAWN QA SUB-AGENT (mandatory):
Task(
  subagent_type="general-purpose",
  prompt="You are a QA Validator. Read .aid/qa/{TASK-ID}.yaml and review modified files. Return JSON with verdict: PASS or FAIL.",
  description="QA validation for {TASK-ID}"
)
  1. Process QA report → PASS: proceed to next task. FAIL: fix issues in action_required, spawn QA again.

QA criteria file .aid/qa/{task-id}.yaml:

criteria:
  must_achieve:    # What code MUST do
  must_not:        # What code must NEVER do
  not_included:    # Scope boundaries
  best_practices:  # Quality standards

QA sub-agent context (isolated):

  • Sees: Epic goal, Story value, Acceptance criteria, Changed files
  • Does NOT see: Tech Spec, Architecture, Developer notes

QA gate rules:

RuleEnforcement
Hard blockCannot proceed until PASS
Max 3 cyclesAfter 3 FAILs, escalate to human
Check all criteriaReports ALL failures
No skippingMandatory for all tasks

When QA fails:

  1. Read report at .aid/qa/{task-id}-review-{N}.json
  2. Fix each issue in action_required
  3. Re-spawn QA
  4. Repeat until PASS or max cycles

TDD Workflow

RED (failing test) → GREEN (make pass) → REFACTOR (clean up) → REPEAT

PhaseRule
REDTest MUST fail first
GREENMinimal code to pass
REFACTORTests still pass

Common Pitfalls

PitfallFix
Skipping TDDWrite tests first
Test-specific codeNo if is_test: in prod
Over-mocking<20% mocking
Happy path onlyTest errors & edge cases
Weak assertionsAssert exact values

Code Quality

Required:

  • Single responsibility functions
  • DRY - no copy-paste
  • Type hints on public functions
  • Meaningful names
  • Error handling

Forbidden:

  • No any types
  • No TODO/FIXME
  • No commented-out code
  • No test-specific branching

Documentation Standards

Full rules and per-language examples: references/documentation-standards.md

File-Level:

/**
 * @file UserService.ts
 * @description Purpose
 * @related ./UserRepository.ts
 */

Function:

/**
 * Creates user account.
 * @param data - User input
 * @returns Created user
 * @throws {ValidationError} If email invalid
 */

Phase Gate Checklist

  • All features per spec
  • All tests passing
  • Edge cases tested
  • Code reviewed
  • No test-specific logic in prod
  • Documentation updated
  • All tasks passed QA gate

Role Guidance

RoleFocus
PMClarifications, validate intent
DevTDD, implement to pass tests
QAReview coverage, test scenarios
Tech LeadCode review, standards

Handoff to QA

  • Complete, tested code
  • Test results + coverage
  • Known issues (if any)
  • Deployment instructions

Pipeline Integration

When the automated pipeline is active (.aid/pipeline/state.json exists with pipeline_status: "running"), Phase 4 step sequencing is driven by the pipeline-orchestrator skill. Run /pipeline to start it; when inactive, the manual flow above applies.

Without PipelineWith Pipeline
Developer decides when to reviewPipeline enforces CODE_REVIEW after DEVELOP
Developer decides when to write testsPipeline enforces TDD after CODE_REVIEW passes
Developer decides when to validatePipeline enforces TEST_REVIEW + PHASE_GATE
Manual flowAutomated state machine with retry loops

Unchanged under pipeline: TDD workflow (RED-GREEN-REFACTOR), code quality standards, QA gate enforcement (same qa-validator-agent), documentation standards.

See ../pipeline-orchestrator/SKILL.md for full pipeline documentation.

レビュー

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

同じリポジトリのスキル

概要と使いどころ

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-prd

無料

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

日本語の概要は準備中です。原文の説明を表示しています。

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

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