Agent skill

implementation-planning

Create technical implementation plans and architecture designs. Use when someone needs a detailed technical approach before coding begins — "create a plan", "plan this ticket", "how should we implement this", "technical design", "architect this", "design the approach", "plan the migration", "refactor plan", "how should we structure this", or when shaped work or a groomed ticket needs a concrete implementation strategy with phases, file changes, and verification steps.

Stars 3
Forks 1

Install this agent skill to your Project

npx add-skill https://github.com/teambrilliant/dev-skills/tree/main/skills/implementation-planning

SKILL.md

Implementation Planning

Take a ticket, shaped work, or technical challenge and create a detailed implementation plan that any developer or agent can follow.

Plan Mode

Multi-phase plans → use plan mode:

  1. If not already in plan mode, call EnterPlanMode
  2. Research using sub-agents (see below)
  3. Write plan to BOTH locations:
    • The internal plan file (path in system message)
    • thoughts/plans/YYYY-MM-DD-descriptive-name.md (persistent)
  4. Call ExitPlanMode when done

Simple designs (single-phase, quick approach discussion) → skip plan mode, just discuss.

Plan File Storage

Save plans to thoughts/plans/ — this is the persistent, shareable location. The internal Claude Code plan file is temporary.

thoughts/plans/YYYY-MM-DD-descriptive-name.md

Use TODAY'S DATE from system context as prefix (e.g., "Today's date" in env info).

Design Philosophy

Before writing plans, read references/software-design-philosophy.md. Apply these principles when designing module boundaries, interfaces, and decomposition. Key checks: modules should be deep, information hiding, define errors out of existence, design it twice.

Principles

  • Research first — understand the codebase before proposing solutions
  • Be specific — include file paths, function names, code snippets
  • Be skeptical — question assumptions, identify risks early
  • Decide, don't ask — every open question gets a recommended resolution with reasoning. Never present a question without proposing what you'd do
  • Be practical — focus on incremental, testable changes
  • Agent-agnostic — plan should work for any implementer
  • Follow patterns — match existing codebase conventions

Process

1. Gather Context

Launch parallel Explore sub-agents before planning. Each serves a different purpose:

# 1. LOCATE — find where relevant files live (don't read contents, just map locations)
Agent(subagent_type="Explore", prompt="Find all files related to [feature/domain].
  Group by: routes, use-cases/business logic, components, DB schema, tests.
  Report file paths and directory structure only, don't read contents.")

# 2. PATTERNS — find similar implementations to model after (read code, extract complete examples)
Agent(subagent_type="Explore", prompt="Find similar implementations to [what we're building].
  Read the code thoroughly. Extract complete working examples with imports.
  Note file organization, naming conventions, error handling approach.")

# 3. ANALYZE — trace how an existing related feature works end-to-end
Agent(subagent_type="Explore", prompt="Analyze how [related feature] is implemented.
  Trace the data flow from entry point to DB/API.
  Map key functions, their inputs/outputs, and error handling paths.")

Use all three when the feature is complex. For simpler tasks, locate + patterns may suffice.

Also gather:

  • Related research docs in thoughts/research/
  • The tech stack:
markdown
**Package manager:** pnpm/npm/yarn
**Build tool:** turbo/nx/none
**Language:** TypeScript (strict mode?)
**Runtime:** Node.js/Bun/Deno
**Framework:** Fastify/Express/Hono
**Database:** Postgres + Drizzle/Prisma
**Testing:** Vitest/Jest
**Patterns to follow:** [reference existing implementations]

For monorepo projects:

  • Package structure from pnpm-workspace.yaml
  • Build configuration from turbo.json
  • Existing packages for patterns to follow

Ask clarifying questions if requirements are ambiguous.

2. Present Options (If Multiple Approaches Exist)

Present trade-offs clearly:

  • Option A: [approach] — Pros/Cons
  • Option B: [approach] — Pros/Cons
  • Recommendation: [which and why]

Get alignment before detailed planning.

3. Write the Plan

Create a structured plan following the output format below.

Output Format

markdown
# [Title] - Implementation Plan

## Overview
[1-2 sentences: what we're building and why]

## Current State
[What exists now, what's missing, relevant code locations]

## Desired End State
[What should work when done, how to verify — include example commands/usage]

## Out of Scope
[Explicitly list what we're NOT doing — prevents scope creep]

## Implementation Approach
[High-level strategy and reasoning]

---

## Phase 1: [Descriptive Name]

### What This Accomplishes
[Summary of this phase's goal]

### Changes

**File**: `path/to/file.ext`

```[language]
// Complete code to add or modify
// Not snippets — full implementation

File: path/to/another.ext

[language]
// Complete code

Verification

  • [Specific command to run]
  • [Expected output or behavior]

Phase 2: [Descriptive Name]

[Same structure as Phase 1]


Testing Strategy

Manual Verification

bash
# Step-by-step commands to verify everything works
command1
command2

Automated (if applicable)

  • Unit tests: [what to test]
  • Integration tests: [what scenarios]

File Summary

directory/
├── file1.ext           # Purpose
├── file2.ext           # Purpose
└── subdirectory/
    └── file3.ext       # Purpose

Total new files: N files

Related Research

  • thoughts/research/YYYY-MM-DD-name.md — [what it covers]

Open Questions

Every question includes a recommended resolution. Proceeding with these unless you steer otherwise.

  • [Question] Recommend: [option] — [why] Discarded: [option] ([why not])

## Phase Guidelines

**Good phases:**
- Each phase is independently verifiable
- Earlier phases don't break existing functionality
- Later phases build on earlier ones
- Can pause between phases if needed

**Phase sizing:**
- Small enough to verify quickly
- Large enough to be meaningful
- Typically 1-3 files per phase
- Each phase should have clear verification steps

**Code in phases:**
- Include COMPLETE code, not snippets
- Show the full file content or the full function
- Never use "..." or "// rest of code"
- Someone should be able to copy-paste and have it work

## What Makes a Good Plan

**Good** (specific, actionable):
- File paths exist or clearly describe where to create
- Code snippets show COMPLETE implementation
- Verification steps are concrete commands
- Expected outputs documented

**Bad** (vague, hand-wavy):
- "Update the relevant components"
- "Add appropriate error handling"
- "Test thoroughly"
- Code snippets with "..." placeholders

## Example

**Input ticket**: "Add database package with Drizzle ORM"

**Output plan** (abbreviated):

```markdown
# Database Package - Implementation Plan

## Overview
Create `packages/db` with Drizzle ORM for PostgreSQL, following monorepo patterns from jp-partner-platform.

## Current State
- Monorepo exists with Fastify API + Temporal worker
- Postgres in docker-compose (port 5462)
- No database package yet

## Desired End State
```bash
# Package builds successfully
pnpm --filter=@repo/db build

# Migrations work
pnpm --filter=@repo/db generate
pnpm --filter=@repo/db migrate

# Types available in other packages
import { users } from "@repo/db/schema"

Out of Scope

  • API endpoints using the database
  • Seed data
  • Production deployment config

Phase 1: Package Setup

What This Accomplishes

Create the package skeleton with Drizzle configuration.

Changes

File: packages/db/package.json

json
{
  "name": "@repo/db",
  "type": "module",
  "exports": {
    ".": { "default": "./dist/index.js" },
    "./schema": { "default": "./dist/schema/index.js" }
  },
  "scripts": {
    "build": "tsc",
    "generate": "drizzle-kit generate",
    "migrate": "drizzle-kit migrate"
  },
  "dependencies": {
    "drizzle-orm": "^0.44.0",
    "postgres": "^3.4.7"
  },
  "devDependencies": {
    "drizzle-kit": "^0.31.0"
  }
}

File: packages/db/drizzle.config.ts

typescript
import { defineConfig } from "drizzle-kit"

export default defineConfig({
  schema: "./src/schema/index.ts",
  out: "./drizzle",
  dialect: "postgresql",
  dbCredentials: {
    url: process.env.DATABASE_URL ?? "postgresql://postgres:postgres@localhost:5462/mydb",
  },
})

Verification

  • pnpm install succeeds
  • pnpm --filter=@repo/db build succeeds

Phase 2: Schema Definition

[...]


## Handoffs

- After plan approval, use `/dev-skills:implement-change` to execute phase by phase
- The plan in `thoughts/plans/` serves as the source of truth during implementation

Expand your agent's capabilities with these related and highly-rated skills.

teambrilliant/dev-skills

product-discovery

Validate whether a product idea is worth building before committing engineering investment. Use when someone says "should we build this", "validate this idea", "discovery", "run an experiment", "test this hypothesis", "what are the risks", "is this worth building", "feasibility check", "prototype plan", or when a team has a shaped feature or product idea and needs to assess risks and design experiments before building. Sits between product-thinker (should we?) and shaping-work (what exactly?) — this skill answers "will this actually work?" by identifying what you don't know, designing the cheapest way to find out, and defining evidence gates that justify (or kill) the investment. Also trigger when someone has a feature request and you sense high uncertainty — if the team is about to spend weeks building something nobody tested, this skill should intervene.

3 1
Explore
teambrilliant/dev-skills

qa-test

Browser-based QA verification after any implementation. Use when someone says "QA this", "test this in browser", "verify the feature", "qa test", "browser test", or after completing an /implement-change to verify acceptance criteria in a real browser. Opens Chrome via MCP, exercises each acceptance criterion, verifies via DOM snapshots, and reports pass/fail. The "closer" for every implementation — proof it works, not just that tests pass.

3 1
Explore
teambrilliant/dev-skills

shaping-work

Shape rough ideas into clear, actionable work definitions. Use this skill whenever someone has an unstructured idea that needs to become a concrete work definition — feature requests, bug reports, PRDs, customer feedback, Slack threads, stakeholder asks, or vague "we should do X" statements. Trigger phrases include "shape this", "scope this", "write a PRD", "define this work", "turn this into a ticket", "flesh this out", "spec this out", "what should we build for X", "I have an idea for...", or any rough input that needs structure before implementation can begin.

3 1
Explore
teambrilliant/dev-skills

implement-change

Execute code changes from an implementation plan. Use when someone says "implement this", "build this", "code this", "start building", "let's implement", "execute the plan", "make the changes", "do the work", or has an approved implementation plan ready for coding. Takes implementation plans and produces working code, phase by phase with verification.

3 1
Explore
teambrilliant/dev-skills

product-primitives

Break down complex products, features, or systems into fundamental primitives and building blocks from a software creator's perspective. Use when starting a new application, designing a large feature, or needing to understand a complex system's moving parts before building. Trigger phrases: "break down X", "decompose this", "what are the primitives", "building blocks of Z", "map the architecture", "what are the moving parts", "analyze this system", or any situation where you need to identify the atomic, reusable capabilities that compose a system. Complements product-thinker (user perspective) with the builder's perspective (system-level connections).

3 1
Explore
teambrilliant/dev-skills

loop-check

Assess what's needed to make feedback loops autonomous in a repo. Use when someone says "loop check", "what do I need to work autonomously", "check my feedback loops", "what's manual here", "what should I automate", "can an agent iterate here", or before starting work in an unfamiliar repo to understand what's missing for autonomous iteration. Also use when the user asks "what do you need to make this autonomous?" or describes a workflow they want to close the loop on. NOT for: full repo audits (use tap-audit), coding, test writing, or implementation.

3 1
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results