Skip to content

README.md

Latest commit

 

History

History
132 lines (107 loc) · 4.05 KB

README.md

File metadata and controls

132 lines (107 loc) · 4.05 KB

Deployment

  1. use the ./deploy create-config to initialize the configuration file.
  2. Read the configuration file carefully and tweak it as you wish
  3. use the ./deploy --sync to deploy the contents of the repo to your ~/.claude folder. (will ask you before doing anything)
  4. by default it will also create a backup which you can rollback to

Skills Overview

Workflow

/feature → /tdd → /breakdown → /engineer (per sub) → /test-design → /coder → /code-review → /qa
    ↓         ↓         ↓            ↓
  .feature  .tdd    .breakdown    .tdd (sub)

For large features, /breakdown splits the TDD into sub-features:

001-user-auth.tdd.md
        ↓
   /breakdown
        ↓
001a-password-validation → /engineer → /test-design → /coder → ...
001b-session-management  → /engineer → /test-design → /coder → ...
001c-password-reset      → /engineer → /test-design → /coder → ...

File Naming

All feature documents saved to ./docs/features/ with 3-digit auto-increment:

./docs/features/
├── 001-user-authentication.feature.md    # Feature spec
├── 001-user-authentication.tdd.md        # Technical design
├── 001-user-authentication.breakdown.md  # Sub-feature breakdown
├── 001a-password-validation.tdd.md       # Sub-feature TDD
├── 001a-password-validation.test.md      # Sub-feature tests
├── 001b-session-management.tdd.md
├── 001b-session-management.test.md
├── 002-notifications.feature.md
└── ...

Workflow Skills

Command Purpose Output
/feature Discover & define feature via interview <NNN>-name.feature.md
/tdd Technical design via interview <NNN>-name.tdd.md
/breakdown Split TDD into sub-features <NNN>-name.breakdown.md
/engineer Lightweight TDD for sub-features <NNN><x>-name.tdd.md
/test-design Test cases (unit/integration/E2E) <NNN>-name.test.md
/coder Implement using TDD approach Code
/code-review Review changes via git diff Pass/Fail
/qa Validate against feature spec Pass/Fail

Context Clearing

Transition Clear Context? Why
/feature → /tdd ✅ Yes Feature spec saved to file
/tdd → /breakdown ❌ No Breakdown needs TDD context fresh
/breakdown → /engineer ✅ Yes Starting fresh, reads from files
/engineer → /test-design ✅ Yes Test design reads from files
/test-design → /coder ✅ Yes Coder reads from files
/coder → /code-review ❌ No Reviewer needs to see what was coded
/code-review → /qa ❌ No QA benefits from review context

Rule of thumb: Clear when transitioning to a skill that reads everything from files.

Tech-Specific Skills (Auto-Trigger)

Skill Purpose
nestjs-core NestJS patterns: TypeORM Data Mapper, CQRS, auth, module structure
nestjs-testing NestJS test pyramid with solitary unit testing
apollo-graphql Apollo Client: queries, mutations, caching, subscriptions
react-router React Router v7: routing, loaders, actions, forms
riverpod Riverpod 3.x + flutter_hooks patterns

Usage

Start a New Feature

/feature

Claude will interview you and create the feature spec.

Continue to Technical Design

/tdd

Claude reads the feature spec and designs the solution.

Break Down Large Features

/breakdown

Claude analyzes the TDD and proposes sub-features with dependencies.

Design Sub-Feature (Lightweight TDD)

/engineer

Claude creates focused technical design for a sub-feature, referencing parent TDD.

Plan Tests

/test-design

Claude creates test specifications from the TDD.

Implement

/coder

Claude implements using TDD (tests first, then code).

Review

/code-review

Claude reviews git diff against quality standards.

Validate

/qa

Claude validates implementation matches feature requirements.