Skip to content
cccskills
FreePublished on GitHub

aid-development

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

The English summary is being prepared. Showing the original description.

See how to install

Files included (3)

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

SKILL.md (original)

Review the instructions the agent will receive before you install.

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.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

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

The English summary is being prepared. Showing the original description.

ilandahan/AID10Updated Sep 23, 2026

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.

The English summary is being prepared. Showing the original description.

ilandahan/AID10Updated Sep 23, 2026

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

The English summary is being prepared. Showing the original description.

ilandahan/AID10Updated Sep 23, 2026

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

The English summary is being prepared. Showing the original description.

ilandahan/AID10Updated Sep 23, 2026

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

The English summary is being prepared. Showing the original description.

ilandahan/AID10Updated Sep 23, 2026

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.

The English summary is being prepared. Showing the original description.

ilandahan/AID10Updated Sep 23, 2026

See all skills by ilandahan

Report a problem with this skill