development-workflows

name	development-workflows
description	Systematic software development methodologies for code quality — systematic debugging (4-phase root cause investigation), test-driven development (RED-GREEN-REFACTOR), and structured code review (subagent review workflow). These three form a natural lifecycle: diagnose problems, build solutions with tests, and validate before merging.
license	MIT
metadata	{"version":"1.0.0","hermes":{"tags":["debugging","TDD","testing","code-review","quality","methodology","workflow","development"],"related_skills":["subagent-driven-development"]}}

Development Workflows — Code Quality Methodologies

Three linked methodologies that form the core development lifecycle. Use them together: debug → build (TDD) → review.

---

Section A: Systematic Debugging (references/systematic-debugging.md)

When: Any bug, test failure, or unexpected behavior. Rule: NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST.

The Four Phases

1. Understand the problem — reproduce it, characterize inputs/outputs, isolate from noise
2. Form a hypothesis — propose a causal mechanism, NOT a fix
3. Locate root cause — binary search, experiment, trace the call chain
4. Fix and verify — only now write the fix, then prove it works

Load full detail: skill_view(name="development-workflows", file_path="references/systematic-debugging.md")

---

Section B: Test-Driven Development (references/test-driven-development.md)

When: Any new feature, bug fix, or refactoring. Rule: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.

The Red-Green-Refactor Cycle

1. RED — write a failing test that specifies the desired behavior
2. GREEN — write the minimal code to make it pass
3. REFACTOR — clean up without changing behavior (tests stay green)

Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.

Load full detail: skill_view(name="development-workflows", file_path="references/test-driven-development.md")

---

Section C: Structured Code Review (references/code-review.md)

When: After completing a task, before merging, after bug fixes. Rule: A fresh perspective finds issues you'll miss.

Review Process

1. Self-review first — re-read your diff with fresh eyes
2. Checklist-based review — correctness, security, edge cases, naming, tests, docs
3. Subagent review — dispatch a reviewer subagent for fresh perspective
4. Address findings — fix or document each issue
5. Re-review — verify fixes, look for second-order issues

Load full detail: skill_view(name="development-workflows", file_path="references/code-review.md")

---

Quick Decision Guide

Situation	Use
Something is broken or unexpected	Debugging (Phase 1 first!)
You know what to build	TDD (write failing test first)
You finished a task	Code Review (fresh subagent)
Under time pressure, tempted to skip	Use the methodology MORE, not less
Simple/obvious issue	Root cause still exists — debug first