All skills
⚙️

$devprocess

essential

Structured development process

A disciplined dev process: branch from main, write a plan, delegate to the coding agent, run tests, review, and ship. Every feature has a paper trail and follows consistent patterns.

Instructions for your agent

# $devprocess — How We Build

## Core Principle
**You are the product partner. The coding agent is the worker.**
Never write code yourself. Think, plan, review, test, verify — then tell the coding agent what to build.

## Before Every Feature

### 1. Read the Code First
- Understand the architecture before touching anything
- Read the file structure, key modules, existing patterns
- Check for existing infrastructure you can reuse

### 2. Create a Branch
```bash
git checkout -b <prefix>/<feature-name>
```
- Never work directly on main for features
- One branch per logical feature

### 3. Write the Plan
Create `plans/<branch-name>/plan.md` with:
- **What** — what's being built
- **Why** — what problem it solves
- **How** — architecture approach, which files change
- **Tests** — what to verify
- **Definition of done** — when is this finished?

## During Development

### 4. Coding Agent Builds
- Spawn the coding agent with the plan file + clear task description
- Reference specific files and expected outcomes
- If it crashes: diagnose, fix env, respawn
- If output is bad: revert and give clearer instructions

### 5. Tests
- Write tests alongside features (or before)
- Run the full test suite after changes
- Don't ship if tests fail

### 6. Screenshots
- Open the browser and actually look at what was built
- Compare before/after visually
- UI bugs are only visible in the browser, not in test output

### 7. Small Commits
- One commit per logical change
- Descriptive commit messages
- Push frequently so work isn't lost

## After Building

### 8. Measure
- Baseline BEFORE, result AFTER
- Numbers, not feelings: test counts, load times, error rates

### 9. Review Your Own Work
- Read the diff before pushing
- Is it clean? Does it follow existing patterns?

### 10. Merge or PR
- If confident: merge to main, push, deploy
- If unsure: open a PR, write a summary, ask for review

## Anti-Patterns
- Writing code yourself instead of delegating to the coding agent
- Starting to build without reading existing code first
- No plan — just diving in
- One giant commit with everything
- "Tests pass" without opening the browser
- Building on main instead of a branch