2.4 KiB
name, description, version, author, license, platforms, metadata
| name | description | version | author | license | platforms | metadata | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| implementation-workflows | Class-level umbrella for planning, spiking, TDD, and pre-commit verification in software implementation workflows. | 1.0.0 | Hermes Curator | MIT |
|
|
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
- If the user explicitly wants no code changes and only an actionable plan artifact, use planning mode.
- If the unknown is feasibility and the output should be disposable, use spike mode.
- If the user wants disciplined incremental implementation, use TDD mode.
- If code already exists and needs a quality/security gate before landing, use pre-commit verification.
- 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.