linter-driven-development

---

name: linter-driven-development description: | WHEN: User requests Go code work (implement, fix, add, refactor) or mentions @ldd in a Go project. Orchestrates complete workflow (Phases 1-5): design → test → implement → lint → fix → documentation. Auto-triggers parallel quality analysis and iterative fix loop until code is commit-ready. allowed-tools:

• Skill(go-linter-driven-development:code-designing)
• Skill(go-linter-driven-development:testing)
• Skill(go-linter-driven-development:refactoring)
• Skill(go-linter-driven-development:documentation)
• Task

---

Reference: See reference.md for agent prompt templates, example reports, and output formats.

<essential_principles> Auto-Pilot Behavior: This skill triggers automatically when Go code work is detected. After permission is granted, announce: "Using go-ldd workflow for this Go code work" and proceed to pre-flight check.

Trigger Conditions:

• User requests Go code work (implement, fix, add, refactor, update, change, modify, etc.)
• User mentions "ldd" or "@ldd" (shorthand for linter-driven-development)
• Working directory contains Go project (go.mod or .go files) </essential_principles>

<quick_start> Immediate Action: Run Pre-Flight Check, then execute phases sequentially until commit-ready.

1. Pre-Flight: Verify Go project, find test/lint commands, identify plan context
2. Phase 1: Design types (if needed) → Write tests → Implement code
3. Phase 2: Run quality-analyzer agent → Route based on status
4. Phase 3: Fix loop until CLEAN_STATE
5. Phase 4: Documentation
6. Phase 5: Present commit summary with options </quick_start>

<pre_flight_check> ALWAYS RUN FIRST

Extract commands:

• Test command: go test, make test, task test
• Lint command: golangci-lint run --fix, make lint, task lintwithfix
• Fallbacks: go test ./... and golangci-lint run --fix

<decision_tree> </decision_tree> </pre_flight_check>

Write Tests First:

• Invoke @testing skill for guidance
• Write table-driven tests or testify suites
• Target: 100% coverage on new leaf types

Implement Code:

• Follow coding principles from coding_rules.md
• Keep functions <50 LOC, max 2 nesting levels
• Use self-validating types, prevent primitive obsession

The agent automatically:

• Executes tests, linter, and code review in parallel (40-50% faster)
• Identifies overlapping issues with root cause analysis
• Returns structured report with prioritized fixes

<test_focus_mode> Loop until tests pass:

1. Analyze failure root cause
2. Apply fix to implementation or tests
3. Re-run quality-analyzer (mode: "full")
4. Check status → continue or exit loop

Max 10 iterations. If stuck, ask user for guidance. </test_focus_mode>

1. Apply Fix:

   • Invoke @refactoring skill with file, function, issues, and root cause
   • @refactoring applies patterns: early returns, extract function, storifying, extract type, switch extraction, extract constant

2. Verify Fix (Incremental Mode):

   • Re-run quality-analyzer with mode: incremental
   • See reference.md → "Agent Prompt Templates" for prompt
   • Agent returns delta report: fixed, remaining, new issues

3. Route Based on Status:

   • TEST_FAILURE → Enter Test Focus Mode
   • CLEAN_STATE → Break loop, go to Phase 4
   • ISSUES_FOUND → Continue to next fix (or retry if no progress)

4. Safety Limits:

   • Max 10 iterations per fix loop
   • If stuck after 3 attempts → show status, ask user

Loop until agent returns CLEAN_STATE.

Verify: Run go doc -all ./... and ensure examples compile.

Present user with options:

1. Commit as-is
2. Fix design debt only, then commit
3. Fix design + readability debt, then commit
4. Fix all findings, then commit
5. Refactor entire file, then commit

<workflow_control> </workflow_control>

Agents invoked:

• go-linter-driven-development:quality-analyzer (Phase 2 and Phase 3 verification)
  • Internally delegates to go-linter-driven-development:go-code-reviewer for design analysis

After committing:

• Feature complete → Already documented in Phase 4
• More work needed → Run this workflow again for next commit

<success_criteria> Workflow is complete when ALL of the following are true:

• Pre-flight check passed (Go project verified, commands discovered)
• Phase 1 complete (tests written, code implemented)
• Quality-analyzer returns CLEAN_STATE:
  • Tests pass
  • Linter passes (0 errors)
  • Code review clean (0 findings)
• Phase 4 complete (documentation added/updated)
• Commit summary presented to user with options
• User has chosen commit action (or deferred) </success_criteria>