feat: export core Hermes skills

2026-07-15 02:45:56 +00:00
parent a028b63eda
commit 54711fee2a
308 changed files with 41310 additions and 1 deletions
@@ -0,0 +1,63 @@
+---
+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.