---
name: implementation-workflows
description: "Class-level umbrella for planning, spiking, TDD, and pre-commit verification in software implementation workflows."
version: 1.0.0
author: Hermes Curator
license: MIT
platforms: [linux, macos, windows]
metadata:
  hermes:
    tags: [software-development, planning, spike, tdd, verification, code-review, workflow]
    related_skills: [plan, spike, test-driven-development, requesting-code-review]
---

# Implementation Workflows

Umbrella skill for the class of implementation-shaping workflows that sit around code changes:
- planning before execution
- spikes / feasibility experiments
- test-driven implementation discipline
- pre-commit verification and independent review

These are better discovered as one class-level skill with labeled subsections than as a pile of siblings with narrowly different triggers.

## Use this skill when

The user is asking how to shape implementation work rather than asking about a domain technology itself.

Typical cases:
- "make a plan"
- "spike this"
- "use TDD"
- "review before commit"
- multi-step implementation that needs disciplined execution gates

## Subsections

### 1. Planning mode
Use when the user wants a plan and not execution.
- Reference: `references/plan.md`

### 2. Spike / feasibility mode
Use when the user wants throwaway experiments to answer feasibility questions before committing to production implementation.
- Reference: `references/spike.md`

### 3. Test-driven development
Use when implementation should follow red-green-refactor discipline.
- Reference: `references/test-driven-development.md`

### 4. Pre-commit verification / code review gate
Use when changes need an independent quality gate before commit/push.
- Reference: `references/requesting-code-review.md`

## Decision rules

1. If the user explicitly wants no code changes and only an actionable plan artifact, use planning mode.
2. If the unknown is feasibility and the output should be disposable, use spike mode.
3. If the user wants disciplined incremental implementation, use TDD mode.
4. If code already exists and needs a quality/security gate before landing, use pre-commit verification.
5. These modes can stack: plan -> spike -> TDD -> verification.

## Maintenance rule

New workflow-specific implementation skills should usually be folded into this umbrella as subsections or support files unless they define a truly different class of work.