dev

/dev - Development Workflow for KiCAD Schematic API

Purpose: Complete development workflow from problem description to pull request, using KiCAD reference-driven development with comprehensive testing and format preservation validation.

Use when: Building features, fixing bugs, or adding functionality that requires systematic development with PRD, reference schematics, tests, and iterative implementation.

---

Workflow Overview

/dev (end-to-end development)
  ├─ Phase 1: Generate PRD (research → ask questions → document)
  │   └─ STOP: User reviews PRD
  ├─ Phase 2: Create Reference Schematic (Interactive - agent creates, user refines)
  │   └─ STOP: User edits in KiCAD, says "done"
  ├─ Phase 3: Generate Tests (autonomous - no stop)
  ├─ Phase 4: Implementation (autonomous + communicative - shows progress)
  │   └─ STOP if stuck after 8 iterations
  ├─ Phase 4.5: Manual Validation (Interactive - agent guides, user inspects)
  │   └─ STOP: User validates in KiCAD
  └─ Phase 5: Cleanup & PR (autonomous - no stop)

Time estimate: 1-4 hours depending on complexity

---

Reviewing and Fixing Existing PRs

If you encounter an existing PR with failing CI, follow these steps to fix it:

Step 1: Checkout the PR branch

gh pr checkout {PR_NUMBER}

Step 2: Fix formatting issues

# Format code
uv run black kicad_sch_api/ tests/
uv run isort kicad_sch_api/ tests/

Step 3: Fix other CI failures

# Run tests to identify failures
uv run pytest tests/ -v

# Fix type errors
uv run mypy kicad_sch_api/

# Fix linting issues
uv run flake8 kicad_sch_api/ tests/

Step 4: Commit and push fixes

git add -A
git commit -m "chore: Fix CI formatting and test failures

Apply black and isort formatting to pass CI checks.
Fix any test failures and type errors.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>"

git push origin {BRANCH_NAME}