Structured Commits as Lesson Inputs
Commit messages with What/Why/Learned sections capture reusable insights at the moment of discovery, feeding downstream lesson extraction pipelines
process (20 lessons)
Lesson 053: Audit-First Design
Before writing any code for a new feature, produce a written audit of the existing codebase: what exists, what can be reused, where new code slots in. The audit document prevents reimplementing existing functionality and identifies the exact extension points — saving more time than it costs to write...
Lesson 054: Phased Autonomous Execution Plans
Breaking large projects into numbered, independently shippable phases — each with explicit entry criteria, exit criteria, and a commit checkpoint — transforms ambitious multi-session work from a coordination problem into a queue of self-contained tasks. The plan file is both the work instruction and...
Code Review Driven Remediation
A whole-codebase code review is only as valuable as the remediation that follows it. The review itself produces a findings document. The remediation requires a separate phased plan that prioritizes findings by severity, groups them into shippable phases, and tracks each fix to completion with test v...
Design-First Development
Writing a design document and a Physical Design Requirements (PDR) document before coding catches architectural mistakes when they're cheapest to fix. The design doc explores the problem space; the PDR specifies the physical implementation. Skipping either leads to rework: skipping design means buil...
Lessons Learned as a Practice
Systematically extracting lessons from project work — and writing them as standalone documents — turns ephemeral experience into a durable knowledge base. The practice is most valuable when it is automated enough to be low-friction (discovery from git history) but requires human judgment for what ac...
Phased Release Planning
Breaking large features into ordered phases — each independently shippable, each ending with a commit — transforms ambitious work into manageable steps with explicit progress tracking. The phase plan is both a work queue and an audit trail.
Phased Plan Execution with One Commit Per Phase
When building a multi-phase system, track progress at the row level within each phase (Open → Started → Completed with timestamps), commit only when an entire phase is green, and never batch multiple phases into one commit. This granularity makes it possible to resume mid-phase, measure velocity, an...
Structured Code Review as a Phase Gate
Running a systematic, category-driven code review after implementation is complete catches a class of issues that per-phase testing and acceptance criteria miss. Per-phase verification asks "does this phase work?" — a structured review asks "what's wrong across the whole codebase?" The two are compl...
Phased Plans with Interstitial Phases
When mid-project discoveries require new work that doesn't fit the original phase structure, insert interstitial phases (3.5, 6.5) rather than renumbering downstream phases. This preserves commit history references, plan file anchors, and team communication while accommodating scope changes.
Dev Port Registry for Multi-Project Work
A centralized port assignment table in shared developer config prevents localhost collisions when running multiple projects simultaneously.
Tidy Skill for Repo Housekeeping
A structured, behavior-preserving housekeeping pass prevents repo entropy without the risk of accidental refactors.
Acceptance Testing with Playwright
Use BFS link crawling and smoke tests against live URLs to catch broken navigation and UI regressions before users do
Live Infrastructure for Integration Testing
When local services are already running, skip mocks and test the real pipeline end-to-end
Mock vs Live Testing Trade-offs
A decision framework for when to mock dependencies and when to test against real infrastructure
Preflight Gates as Local CI
Run the same checks CI will run before pushing to prevent the most common build failure patterns
Skill-Driven Workflow Automation
Composable slash-command skills turn multi-step developer workflows into repeatable single-command operations that enforce guardrails automatically
Code Review as Requirements Source
Systematic triage of code review findings produces a traceable requirements document — turning ad hoc observations into prioritized, implementable work.
Five-Stage Design-to-Execution Workflow
A repeatable workflow — Design, PDR, Plan, Execute, Commit — with table-driven task tracking and one-commit-per-phase discipline, applied across 18 project phases.
Validation Severity Model
Why the validator uses ERROR/WARNING/INFO levels and why warnings never fail the build.