develop-full

Full Development Workflow

Develop a feature or fix end-to-end with TDD, testing, self-review, and clean commit history.

# Benchmark logging (entry)
bash .claude/benchmark/log.sh "develop_start" "" "" 2>/dev/null || true

Instructions

Phase 0: Understand the Task

1. Get the task from $ARGUMENTS -- either a GitHub Issue number or a task description.
2. If it's an issue number, fetch details:

   gh issue view <ISSUE_NUMBER> --json number,title,body,labels,milestone
   

3. Claim the issue (GitHub Issues only):

   # Assign to self
   gh issue edit <ISSUE_NUMBER> --add-assignee @me
   

   If the project uses a GitHub Projects board, move the issue to "In Progress".
4. Read the project's CLAUDE.md and AGENTS.md for conventions and patterns.
5. Read agent memory files if they exist:
   • .claude/agent-memory/MEMORY.md
   • .claude/agent-memory/cookbook.md
6. Check for spec (issue numbers only): look for .claude/specs/{issue-number}-*.md.
   • If found with Status: approved: read it. Report: "Using approved spec: {filename}". The /develop step will follow this spec as its primary guide.
   • If found with Status: draft: warn the user: "Draft spec exists at {filename} but is not approved. Run /spec {issue} to review and approve it, or proceed without spec guidance." Wait for user confirmation before continuing.
   • If not found: continue silently. Specs are optional -- not every task needs one.
7. Identify which module(s) this work touches and read relevant source code.
8. Check current branch -- if on main/master, create a feature branch before developing:

   BRANCH=$(git branch --show-current)
   if [ "$BRANCH" = "main" ] || [ "$BRANCH" = "master" ]; then
     echo "On main branch. Create a feature branch before developing."
   fi
   

Phase 1: Develop (TDD)

Follow the /develop command workflow:

1. Write tests first -- define expected behavior before implementation.
2. Implement the solution -- follow existing codebase conventions.
3. Scout check -- for every file touched, fix pre-existing issues you notice (failing tests, lint warnings, dead code, obvious bugs). Keep fixes small and low-risk.
4. Run the full CI-equivalent checks: {{ check_cmd }}. This covers linting, tests, formatting, invariants, and any other CI checks.
5. If any check fails, fix and re-run (up to 3 attempts).