hermes-route

Name: hermes-route
Author: AlexAI-MCP

132stars24forks

How to install hermes-route?

alexai-mcp/hermes-ccc/hermes-route

$npx -y skills add AlexAI-MCP/hermes-CCC --skill hermes-route

Installs into the current project.

Summary

Route Claude Code work by complexity, risk, and tool needs. Use when deciding how much reasoning depth a task needs, whether to read project memory first, whether the task should be decomposed, and whether the work is lightweight, standard, or investigation-heavy.

Files · 1

View on GitHub

SKILL.md

1	# Hermes Route
2
3	## Purpose
4
5	- Route a task before execution instead of discovering complexity halfway through.
6	- Decide whether the task is lightweight, standard, or deep-investigation work.
7	- Decide whether memory, docs, code search, or external research should be loaded first.
8	- Decide whether the work should stay serial or be decomposed into independent streams.
9	- Decide whether the task needs a short answer, a coded implementation, or a formal review.
10
11	## Activation Signals
12
13	- Use this skill when the request is ambiguous and execution strategy matters.
14	- Use this skill when a task mixes coding, research, design, and review concerns.
15	- Use this skill when the user asks for the "best approach" before doing work.
16	- Use this skill when a repository is large and the wrong first step would waste time.
17	- Use this skill when a request includes pasted code, logs, stack traces, or multiple objectives.
18	- Use this skill when deciding whether model depth should be lightweight, balanced, or deep.
19	- Use this skill before spawning subagents if subagent use is permitted in the environment.
20
21	## Inputs To Assess
22
23	- User goal
24	- Expected deliverable
25	- Repository size or scope
26	- Availability of tests
27	- Presence of failing output
28	- Presence of URLs or external references
29	- Need for exact citations or source grounding
30	- Need for code edits versus explanation only
31	- Need for a review mindset versus implementation mindset
32
33	## Complexity Buckets
34
35	### Lightweight
36
37	- Single factual question
38	- Small formatting or wording change
39	- One-file trivial edit
40	- Quick command lookup
41	- Simple transformation with no hidden state
42
43	### Standard
44
45	- One feature or bug across a small number of files
46	- Straightforward repo navigation
47	- Routine API or CLI integration
48	- Clear user goal with moderate context gathering
49	- Normal answer length and low ambiguity
50
51	### Deep
52
53	- Bug with unclear root cause
54	- Refactor with behavioral risk
55	- Architecture question with tradeoffs
56	- Code review over a large diff
57	- Request that needs external verification
58	- Request that mixes implementation, validation, and migration
59
60	## Routing Procedure
61
62	1. Identify the user's actual deliverable.
63	2. Decide whether the request is asking for implementation, review, research, or planning.
64	3. Scan for hard signals:
65	- code blocks
66	- logs
67	- diffs
68	- URLs
69	- multiple numbered asks
70	- references to bugs, regressions, or production issues
71	4. Estimate the cost of taking the wrong first step.
72	5. Check whether project instructions such as `AGENTS.md` or `CLAUDE.md` are likely to constrain the work.
73	6. Decide whether memory should be loaded before action.
74	7. Decide whether a plan is necessary.
75	8. Decide whether the task can remain local or needs external verification.
76	9. Decide whether the work is serial or parallelizable.
77	10. Produce an execution recommendation before touching files.
78
79	## Decision Rules
80
81	- Favor `lightweight` when the request is self-contained and reversible.
82	- Favor `standard` when the work is bounded but still requires code or documentation reading.
83	- Favor `deep` when root cause, architecture, or evidence gathering dominates.
84	- Favor reading memory first when the task touches existing conventions, prior decisions, or long-lived projects.
85	- Favor reading project docs first when repository instructions likely govern the work.
86	- Favor a review mindset when the user asks for "review", "audit", "risk", "regression", or "findings".
87	- Favor implementation immediately when the task is concrete and the user did not ask to brainstorm.
88
89	## Model-Depth Mapping
90
91	- If model choice is exposed, map `lightweight` to a fast cheap model.
92	- If model choice is exposed, map `standard` to the default balanced model.
93	- If model choice is exposed, map `deep` to the strongest reasoning model.
94	- If model choice is not exposed, emulate the distinction with planning depth and evidence gathering.
95	- Never use a lightweight mode for debugging ambiguous failures or reviewing risky diffs.
96
97	## Pre-Execution Recommendations
98
99	- `Read memory first` when project memory or previous decisions likely matter.
100	- `Read instructions first` when a repo includes `AGENTS.md`, `CLAUDE.md`, or package docs.
101	- `Plan first` when more than one workstream or nontrivial sequencing exists.
102	- `Implement directly` when the request is bounded and the likely path is obvious.
103	- `Verify externally` when the user asks

People who liked this also viewed

6 picks

Type

hermes-route

132stars24forks

View on GitHub

How to install hermes-route?

alexai-mcp/hermes-ccc/hermes-route

$npx -y skills add AlexAI-MCP/hermes-CCC --skill hermes-route

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Hermes Route
2
3	## Purpose
4
5	- Route a task before execution instead of discovering complexity halfway through.
6	- Decide whether the task is lightweight, standard, or deep-investigation work.
7	- Decide whether memory, docs, code search, or external research should be loaded first.
8	- Decide whether the work should stay serial or be decomposed into independent streams.
9	- Decide whether the task needs a short answer, a coded implementation, or a formal review.
10
11	## Activation Signals
12
13	- Use this skill when the request is ambiguous and execution strategy matters.
14	- Use this skill when a task mixes coding, research, design, and review concerns.
15	- Use this skill when the user asks for the "best approach" before doing work.
16	- Use this skill when a repository is large and the wrong first step would waste time.
17	- Use this skill when a request includes pasted code, logs, stack traces, or multiple objectives.
18	- Use this skill when deciding whether model depth should be lightweight, balanced, or deep.
19	- Use this skill before spawning subagents if subagent use is permitted in the environment.
20
21	## Inputs To Assess
22
23	- User goal
24	- Expected deliverable
25	- Repository size or scope
26	- Availability of tests
27	- Presence of failing output
28	- Presence of URLs or external references
29	- Need for exact citations or source grounding
30	- Need for code edits versus explanation only
31	- Need for a review mindset versus implementation mindset
32
33	## Complexity Buckets
34
35	### Lightweight
36
37	- Single factual question
38	- Small formatting or wording change
39	- One-file trivial edit
40	- Quick command lookup
41	- Simple transformation with no hidden state
42
43	### Standard
44
45	- One feature or bug across a small number of files
46	- Straightforward repo navigation
47	- Routine API or CLI integration
48	- Clear user goal with moderate context gathering
49	- Normal answer length and low ambiguity
50
51	### Deep
52
53	- Bug with unclear root cause
54	- Refactor with behavioral risk
55	- Architecture question with tradeoffs
56	- Code review over a large diff
57	- Request that needs external verification
58	- Request that mixes implementation, validation, and migration
59
60	## Routing Procedure
61
62	1. Identify the user's actual deliverable.
63	2. Decide whether the request is asking for implementation, review, research, or planning.
64	3. Scan for hard signals:
65	- code blocks
66	- logs
67	- diffs
68	- URLs
69	- multiple numbered asks
70	- references to bugs, regressions, or production issues
71	4. Estimate the cost of taking the wrong first step.
72	5. Check whether project instructions such as `AGENTS.md` or `CLAUDE.md` are likely to constrain the work.
73	6. Decide whether memory should be loaded before action.
74	7. Decide whether a plan is necessary.
75	8. Decide whether the task can remain local or needs external verification.
76	9. Decide whether the work is serial or parallelizable.
77	10. Produce an execution recommendation before touching files.
78
79	## Decision Rules
80
81	- Favor `lightweight` when the request is self-contained and reversible.
82	- Favor `standard` when the work is bounded but still requires code or documentation reading.
83	- Favor `deep` when root cause, architecture, or evidence gathering dominates.
84	- Favor reading memory first when the task touches existing conventions, prior decisions, or long-lived projects.
85	- Favor reading project docs first when repository instructions likely govern the work.
86	- Favor a review mindset when the user asks for "review", "audit", "risk", "regression", or "findings".
87	- Favor implementation immediately when the task is concrete and the user did not ask to brainstorm.
88
89	## Model-Depth Mapping
90
91	- If model choice is exposed, map `lightweight` to a fast cheap model.
92	- If model choice is exposed, map `standard` to the default balanced model.
93	- If model choice is exposed, map `deep` to the strongest reasoning model.
94	- If model choice is not exposed, emulate the distinction with planning depth and evidence gathering.
95	- Never use a lightweight mode for debugging ambiguous failures or reviewing risky diffs.
96
97	## Pre-Execution Recommendations
98
99	- `Read memory first` when project memory or previous decisions likely matter.
100	- `Read instructions first` when a repo includes `AGENTS.md`, `CLAUDE.md`, or package docs.
101	- `Plan first` when more than one workstream or nontrivial sequencing exists.
102	- `Implement directly` when the request is bounded and the likely path is obvious.
103	- `Verify externally` when the user asks

People who liked this also viewed

6 picks

Type