| name | gormes-context-sourcing |
| description | Use when Gormes work needs external library, framework, upstream repo, provider API, or reference-project context before planning or implementation. |
Gormes Context Sourcing
Overview
Best context is the smallest verified source slice. For Gormes, prefer source-backed evidence over memory, summaries, or broad documentation dumps.
When to Use
Use for Gormes tasks involving:
- unfamiliar Go packages, CLIs, SDKs, providers, browser automation, or installer behavior;
- Hermes, Honcho, OpenClaw, GoClaw, or
references/go-agent-os comparison;
- prompts asking to “reference the codebase”, “check upstream”, “use docs”, or “avoid guessing”.
Do not use this to bypass gormes-hermes-parity; Hermes behavior remains the product contract.
Workflow
- Define the exact question the reference must answer.
- Locate the nearest source of truth:
- in-repo Gormes code first;
./hermes-agent for Hermes behavior;
references/go-agent-os/ for Go donor patterns;
- external docs only when source is unavailable or API semantics are ambiguous.
- Pull only narrow evidence: file path, function/type name, command output, or minimal snippet.
- State how the evidence affects the plan.
- Proceed with the smallest relevant Gormes skill chain.
Quick Reference
| Need | Action |
|---|
| Find behavior contract | Inspect Hermes source or fixture |
| Find Go implementation shape | Inspect local Go reference donor |
| Avoid context bloat | Quote path + symbol, not whole repo |
| Resolve stale memory | Prefer filesystem and command output |
| External package risk | Check package age, repo activity, and lockfile impact |
Common Mistakes
- Dumping entire docs into context instead of searching for one symbol.
- Treating OpenClaw or donor code as the contract when Hermes parity decides behavior.
- Installing new packages before checking whether existing dependencies or standard library suffice.
- Letting the agent infer APIs from memory when source is locally available.