Menu
Design Gormes package/API boundaries. Use for provider, gateway, tool, session, memory, Goncho, plugin, API, or TUI seams, unclear write_scope, or design comparison.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Implement one selected repo-scoped Gormes row with tests. Use when next-work says decision=build. Do not use for decision=plan, broad parity audits, or untracked feature ideas.
Shape source-backed Gormes progress rows. Use for decision=plan builder handoffs, row splitting, feature maps, or parity planning. Do not use when decision=build or for runtime code.
Route Gormes work to the smallest repo-local skill chain. Use before substantial planning/building/refactor work, when unsure which Gormes skill applies, or when creating/improving repo-local skills.
Build one selected Gormes behavior with red-green-refactor. Use when the row or reproduced bug defines a test target. Do not use after decision=plan or for broad planning.
Move one bounded cmd/gormes command domain out of root files toward root main.go only. Use when thinning cmd/gormes, burning down loose root files, preserving CLI behavior, or catching refactor regressions during cmd moves.
Use when an agent is unfamiliar with a Gormes code area, a change crosses package boundaries, or a refactor needs a source-backed module map before edits.
| name | gormes-interface-designer |
| description | Design Gormes package/API boundaries. Use for provider, gateway, tool, session, memory, Goncho, plugin, API, or TUI seams, unclear write_scope, or design comparison. |
For Gormes work, stay on the existing development branch. Do not create or
use feature branches, short-lived branches, or git worktrees. If the checkout
is not on development, stop before editing and switch safely or report the
blocker.
Choose Gormes interfaces that make Hermes-in-Go easier to finish: small caller-facing surfaces, strong compatibility, hermetic tests, and implementation complexity hidden behind useful modules.
Identify:
If the answer is in code, inspect code instead of asking.
Produce at least two materially different interface shapes:
Do not implement yet.
Compare in prose:
If one design is clearly best, recommend it and name the progress row it enables. If the design needs implementation, create/refine a builder-ready row rather than editing runtime code.
Report the considered interfaces, recommended design, rejected alternatives, tests that would prove it, and the row/write_scope to implement it.
