dev-lifecycle

Dev Lifecycle

End-to-end feature development: plan, implement, test, validate, review, PR, verify CI, QA demo, merge, and clean up.

Feature request: "$ARGUMENTS"

If $ARGUMENTS is empty, ask the user what feature to implement before proceeding.

Phase 1: Understand the project

Before writing any code, understand the project conventions:

1. Read the project's CLAUDE.md (if present) for architecture, testing, linting, and commit conventions.
2. Check for a bin/ci script or equivalent CI pipeline to understand quality gates.
3. Note any coverage thresholds, linter configurations (.rubocop.yml, .reek.yml, eslint.config.*, etc.), and testing frameworks.
4. Identify the default branch:

   DEFAULT_BRANCH=$(git remote show origin | sed -n 's/.*HEAD branch: //p')
   

Phase 2: Plan

Think through the implementation before writing code:

1. Identify which files need to change and which new files are needed.
2. Consider edge cases, backward compatibility, and test coverage.
3. Draft a brief plan (3-7 bullet points) of what you'll implement.
4. Present the plan to the user and wait for approval before proceeding. Use AskUserQuestion with the plan summary.

If the user provides specific instructions (e.g., coverage thresholds, linting rules), note them as hard requirements for later validation.

Phase 3: Create a branch

# Ensure we're on the default branch and up to date
git checkout $DEFAULT_BRANCH
git pull

# Create a feature branch
# Use conventional branch naming: feat/, fix/, refactor/, etc.
git checkout -b <branch-name>

Parse --branch NAME from arguments if provided. Otherwise, derive a branch name from the feature description using conventional prefixes (e.g., feat/per-heartbeat-model, fix/session-timeout).

Phase 4: Implement

Write the code and tests:

1. Code changes — implement the feature, following project conventions from CLAUDE.md.
2. Tests — write tests for the new functionality. Match the project's testing framework and style.
3. Documentation — update inline docs, README sections, or CLAUDE.md if the feature changes architecture or public interfaces. Only add docs that are necessary — don't create new markdown files unless explicitly requested.