agentsclimarketplace

Tdd planner

Skill smicolon/ai-kit/packs/dev-loop/skills/tdd-planner

This skill should be used when the user asks to "plan a feature", "prepare for dev loop", "structure TDD approach", "break down this task", "create development plan", or when generating structured prompts for iterative development. Creates dev-loop-ready plans with TDD phases, file tables, code snippets, and framework-specific guidance.From its SKILL.md

Install
npx -y skills add smicolon/ai-kit --skill tdd-planner

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

7.7 KB, ~1.9k tokens by cl100k_base, as published. Nobody here has run it

TDD Planner

Generate high-quality, structured development plans following Test-Driven Development principles for use with the dev-loop command.

Quality Standard

Every plan must meet this checklist before saving:

  • Context lists specific items to work on (not just "the feature")
  • Success criteria are measurable (numbers, specific behaviors)
  • Every task has a file path
  • Code snippets show implementation structure
  • Verification has expected output (PASS/FAIL + why)
  • Self-correction is phase-specific, not generic
  • Files to Modify table exists
  • New Files to Create table exists
  • Stuck handling is framework/task-specific

Reference: See references/good-example.md for expected quality.

Activation Triggers

This skill activates when:

  • Planning a feature for iterative development
  • Preparing prompts for dev-loop execution
  • Breaking down complex tasks into TDD phases
  • Creating structured development workflows

Core Principles

  1. Specificity Over Vagueness - File paths, code snippets, measurable outcomes
  2. Iteration Over Perfection - Expect multiple passes, not first-draft solutions
  3. Failures as Data - Red phase tests MUST fail first
  4. Framework Awareness - Use correct patterns for detected framework

Required Plan Sections

1. Context

## Context

- **Framework**: Flutter / Django / Next.js / etc.
- **Current State**: What exists now
- **Test Command**: `flutter test` / `pytest` / etc.
- **Lint Command**: `flutter analyze` / `ruff check .` / etc.
- **Items to Work On**:
  - `ComponentA` (description)
  - `ComponentB` (description)

2. Success Criteria (Measurable)

## Success Criteria

- [ ] Login returns JWT token (specific behavior)
- [ ] 81+ tests pass (quantitative)
- [ ] Invalid credentials return 401 (negative case)
- [ ] All tests pass (`flutter test`)
- [ ] Linter clean (`flutter analyze`)

3. File Tables (Required)

## Files to Modify

| File | Action |
|------|--------|
| `lib/main.dart` | Replace MultiProvider with ProviderScope |
| `pubspec.yaml` | Add flutter_riverpod dependency |

## New Files to Create

| File | Purpose |
|------|---------|
| `lib/providers/auth_provider.dart` | Riverpod auth state |
| `test/providers/auth_test.dart` | Auth provider tests |

4. Phases with Code Snippets

### Phase 2: Green - Implement Auth Provider

**Goal:** Create Riverpod provider that passes tests

**Tasks:**
- [ ] Create `lib/providers/auth_provider.dart`:
  - StateNotifierProvider with AuthNotifier
  - Methods: login(), logout(), checkAuth()
  - State: AuthState (authenticated, user, token)

**Implementation Structure:**
```dart
final authProvider = StateNotifierProvider<AuthNotifier, AuthState>((ref) {
  return AuthNotifier();
});

class AuthNotifier extends StateNotifier<AuthState> {
  AuthNotifier() : super(AuthState.initial());

  Future<void> login(String email, String password) async {
    // Implementation
  }
}

Verification:

flutter test test/providers/auth_test.dart

Expected: Tests should PASS

Self-correction:

  • If tests fail, check state class matches test expectations
  • Verify StateNotifier lifecycle is correct

### 5. Stuck Handling (Framework-Specific)

```markdown
## Stuck Handling

### If same test keeps failing:
1. Read the exact error message
2. Check if ProviderScope wraps the widget tree
3. Verify ref.watch vs ref.read usage
4. Check state class matches expected structure

### If app won't start:
1. Check ProviderScope is at app root
2. Verify no circular provider dependencies
3. Check async initialization is handled

### Alternative approaches if blocked:
1. Keep hybrid approach temporarily (both Provider and Riverpod)
2. Migrate one screen at a time
3. Use ChangeNotifierProvider adapter for gradual migration

Framework Detection

Package manager auto-detection (defaults to bun):

  • bun.lockb → bun
  • pnpm-lock.yaml → pnpm
  • yarn.lock → yarn
  • package-lock.json → npm
  • No lockfile → bun (default)

Auto-detected frameworks (17+):

CategoryFrameworkDetectionTestLint
MobileFlutterpubspec.yamlflutter testflutter analyze
React Nativereact-native in package.json${PM} test${PM} run lint
PythonDjangomanage.pypytestruff check .
FastAPIfastapi in pyproject.tomlpytestruff check .
Flaskflask in pyproject.tomlpytestruff check .
Node.jsNestJS@nestjs/core${PM} test${PM} run lint
Next.jsnext${PM} test${PM} run lint
Nuxt.jsnuxt${PM} test${PM} run lint
Honohonobun testbun run lint
Expressexpress${PM} test${PM} run lint
TanStack@tanstack/react-routerbun testbun run lint
SystemsGogo.modgo test ./...golangci-lint run
RustCargo.tomlcargo testcargo clippy
WebRailsrails in Gemfilebundle exec rspecbundle exec rubocop
Laravellaravel in composer.jsonphp artisan test./vendor/bin/pint

${PM} = detected package manager (bun/pnpm/yarn/npm)

Custom frameworks:

/dev-plan "Build API" --framework elixir --test-cmd "mix test" --lint-cmd "mix credo"
/dev-plan "Add feature" --test-cmd "make test" --lint-cmd "make lint"

Phase Generation Rules

For New Features

  1. Red: Write tests for the feature interface (expect FAIL)
  2. Green: Implement minimum code to pass (include code snippet)
  3. Refactor: Clean up, add types, documentation

For Bug Fixes

  1. Red: Write test that reproduces the bug (should fail)
  2. Green: Fix the bug (test passes)
  3. Refactor: Ensure no regression, clean up

For Refactoring/Migration

  1. Red: Ensure existing tests pass (baseline)
  2. Green: Apply changes incrementally
  3. Refactor: Verify tests still pass after each change

Task Detail Pattern

Bad Task:

- [ ] Create login view

Good Task:

- [ ] Create `lib/screens/login_screen.dart`:
  - ConsumerStatefulWidget
  - Form with email/password TextFormFields
  - Calls `ref.read(authProvider.notifier).login()`
  - Shows loading state during auth
  - Navigates to home on success
  - Shows error snackbar on failure

Anti-Patterns to Avoid

Don'tDo Instead
"Implement the feature""Create lib/auth/login.dart with ConsumerWidget"
"If it fails, try again""If tests pass in Red, they're too weak - add assertions"
Missing code snippetsShow actual structure with types and patterns
No file tablesAlways list files to modify/create
"App works well""Login returns JWT, logout invalidates token, 401 on bad creds"
Generic stuck handlingFramework-specific: "Check ProviderScope wraps app"

Usage

Generate Plan

/dev-plan "Migrate to Riverpod" --framework flutter
/dev-plan "Add user authentication" --interactive

Execute Plan

/dev-loop --from-plan

References

  • references/plan-template.md - Full template with all variables
  • references/good-example.md - High-quality Flutter migration example
  • references/framework-patterns.md - Framework-specific patterns

What ships with it: 3 files

33.6 KB alongside SKILL.md

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.