hermes-traj

Name: hermes-traj
Author: AlexAI-MCP

132stars24forks

How to install hermes-traj?

alexai-mcp/hermes-ccc/hermes-traj

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

Installs into the current project.

Summary

Capture Claude Code interaction trajectories in training-friendly formats. Use when saving successful runs, failed runs, review samples, evaluation traces, or compact datasets for later QA and fine-tuning analysis.

Files · 1

View on GitHub

SKILL.md

1	# Hermes Traj
2
3	## Purpose
4
5	- Save useful conversations as structured training or QA artifacts.
6	- Separate successful traces from failed traces.
7	- Preserve the task, outcome, and signal-rich decisions without saving noise.
8	- Build a dataset that can be reviewed, filtered, and improved over time.
9	- Make post-task learning operational instead of aspirational.
10
11	## Default File Strategy
12
13	- Use a success JSONL file for completed helpful runs.
14	- Use a failure JSONL file for incomplete or incorrect runs.
15	- Keep one JSON object per line.
16	- Prefer append-only writes with later offline cleanup.
17	- Store files in a predictable project path.
18
19	## Recommended Fields
20
21	- `id`
22	- `timestamp`
23	- `task_type`
24	- `completed`
25	- `model`
26	- `tags`
27	- `source_context`
28	- `conversations`
29	- `artifacts`
30	- `verification`
31	- `failure_reason` for failed runs
32
33	## Conversation Shape
34
35	- Represent turns as ordered objects.
36	- Use explicit speaker labels such as `human` and `assistant`.
37	- Preserve the actual ask and the actual resolution.
38	- Remove filler and repeated status updates.
39	- Keep tool-heavy tasks summarized rather than dumping every command output.
40
41	## Supported Capture Modes
42
43	### Save
44
45	- Use for a successful interaction.
46	- Mark `completed` as `true`.
47	- Include what was changed or delivered.
48	- Include how success was verified.
49
50	### Save-Failed
51
52	- Use for incorrect, incomplete, or abandoned work.
53	- Mark `completed` as `false`.
54	- Include a short `failure_reason`.
55	- Include enough context to diagnose the failure later.
56
57	### Review
58
59	- Inspect recent entries for quality drift.
60	- Look for repeated failure reasons.
61	- Look for under-tagged entries.
62	- Look for overlong assistant messages.
63
64	### Stats
65
66	- Count entries by task type.
67	- Count success versus failure.
68	- Report model distribution if present.
69	- Report top tags and date range.
70
71	## Summarization Rules
72
73	- Keep the core problem statement.
74	- Keep the main actions and why they mattered.
75	- Keep the final result or failure.
76	- Keep verification evidence.
77	- Drop incidental chatter and repeated acknowledgements.
78	- Prefer one concise assistant summary over many micro-updates.
79
80	## Tagging Rules
81
82	- Use `2` to `5` tags.
83	- Choose tags that help slice the dataset later.
84	- Prefer subsystem, task type, and failure pattern tags.
85	- Avoid ultra-generic tags like `task` or `work`.
86	- Reuse existing tag vocabulary when possible.
87
88	## Task Type Suggestions
89
90	- `coding`
91	- `debugging`
92	- `review`
93	- `research`
94	- `writing`
95	- `ops`
96	- `other`
97
98	## Verification Field Guidance
99
100	- Note whether tests passed.
101	- Note whether lint passed.
102	- Note whether the result is unverified because execution was unavailable.
103	- Keep verification factual and short.
104	- Do not fabricate successful validation.
105
106	## Example Success Object
107
108	```json
109	{
110	"id": "traj-20260407-001",
111	"timestamp": "2026-04-07T04:00:00Z",
112	"task_type": "debugging",
113	"completed": true,
114	"model": "deep",
115	"tags": ["auth", "redirect-loop", "python"],
116	"source_context": "repo task",
117	"conversations": [
118	{"from": "human", "value": "Fix the login redirect loop."},
119	{"from": "assistant", "value": "Reproduced the loop, traced the auth guard, updated the condition, and added a regression test."}
120	],
121	"artifacts": ["tests/test_auth.py"],
122	"verification": "targeted test passed"
123	}
124	```
125
126	## Example Failed Object
127
128	```json
129	{
130	"id": "traj-20260407-002",
131	"timestamp": "2026-04-07T05:00:00Z",
132	"task_type": "coding",
133	"completed": false,
134	"model": "standard",
135	"tags": ["mcp", "config"],
136	"source_context": "repo task",
137	"conversations": [
138	{"from": "human", "value": "Register the MCP server."},
139	{"from": "assistant", "value": "Updated the config draft but could not verify transport startup."}
140	],
141	"artifacts": ["config/mcp.json"],
142	"verification": "not run",
143	"failure_reason": "environment lacked server executable for startup validation"
144	}
145	```
146
147	## Save Procedure
148
149	1. Determine whether the run was successful.
150	2. Choose success or failure file.
151	3. Summarize the turns into concise conversation objects.
152	4. Assign task type.
153	5. Assign tags.
154	6. Note artifacts touched.
155	7. Note verification honestly.
156	8. Append one JSON object as one line.
157
158	## Review Procedure
159
160	1. Read the recent tail of success and failure files.
161	2. Sample for quality rather than reading the full corpus.
162	3. Check for missing fields.
163	4. Check for repeated failure patterns.
164	5. Suggest dataset hygiene improvements.
165
166	## Stats Procedure
167
168	1. Count total lines in each file.
169	2. Parse entries that are valid JSON.
170	3.

People who liked this also viewed

6 picks

Type

hermes-traj

132stars24forks

View on GitHub

How to install hermes-traj?

alexai-mcp/hermes-ccc/hermes-traj

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Hermes Traj
2
3	## Purpose
4
5	- Save useful conversations as structured training or QA artifacts.
6	- Separate successful traces from failed traces.
7	- Preserve the task, outcome, and signal-rich decisions without saving noise.
8	- Build a dataset that can be reviewed, filtered, and improved over time.
9	- Make post-task learning operational instead of aspirational.
10
11	## Default File Strategy
12
13	- Use a success JSONL file for completed helpful runs.
14	- Use a failure JSONL file for incomplete or incorrect runs.
15	- Keep one JSON object per line.
16	- Prefer append-only writes with later offline cleanup.
17	- Store files in a predictable project path.
18
19	## Recommended Fields
20
21	- `id`
22	- `timestamp`
23	- `task_type`
24	- `completed`
25	- `model`
26	- `tags`
27	- `source_context`
28	- `conversations`
29	- `artifacts`
30	- `verification`
31	- `failure_reason` for failed runs
32
33	## Conversation Shape
34
35	- Represent turns as ordered objects.
36	- Use explicit speaker labels such as `human` and `assistant`.
37	- Preserve the actual ask and the actual resolution.
38	- Remove filler and repeated status updates.
39	- Keep tool-heavy tasks summarized rather than dumping every command output.
40
41	## Supported Capture Modes
42
43	### Save
44
45	- Use for a successful interaction.
46	- Mark `completed` as `true`.
47	- Include what was changed or delivered.
48	- Include how success was verified.
49
50	### Save-Failed
51
52	- Use for incorrect, incomplete, or abandoned work.
53	- Mark `completed` as `false`.
54	- Include a short `failure_reason`.
55	- Include enough context to diagnose the failure later.
56
57	### Review
58
59	- Inspect recent entries for quality drift.
60	- Look for repeated failure reasons.
61	- Look for under-tagged entries.
62	- Look for overlong assistant messages.
63
64	### Stats
65
66	- Count entries by task type.
67	- Count success versus failure.
68	- Report model distribution if present.
69	- Report top tags and date range.
70
71	## Summarization Rules
72
73	- Keep the core problem statement.
74	- Keep the main actions and why they mattered.
75	- Keep the final result or failure.
76	- Keep verification evidence.
77	- Drop incidental chatter and repeated acknowledgements.
78	- Prefer one concise assistant summary over many micro-updates.
79
80	## Tagging Rules
81
82	- Use `2` to `5` tags.
83	- Choose tags that help slice the dataset later.
84	- Prefer subsystem, task type, and failure pattern tags.
85	- Avoid ultra-generic tags like `task` or `work`.
86	- Reuse existing tag vocabulary when possible.
87
88	## Task Type Suggestions
89
90	- `coding`
91	- `debugging`
92	- `review`
93	- `research`
94	- `writing`
95	- `ops`
96	- `other`
97
98	## Verification Field Guidance
99
100	- Note whether tests passed.
101	- Note whether lint passed.
102	- Note whether the result is unverified because execution was unavailable.
103	- Keep verification factual and short.
104	- Do not fabricate successful validation.
105
106	## Example Success Object
107
108	```json
109	{
110	"id": "traj-20260407-001",
111	"timestamp": "2026-04-07T04:00:00Z",
112	"task_type": "debugging",
113	"completed": true,
114	"model": "deep",
115	"tags": ["auth", "redirect-loop", "python"],
116	"source_context": "repo task",
117	"conversations": [
118	{"from": "human", "value": "Fix the login redirect loop."},
119	{"from": "assistant", "value": "Reproduced the loop, traced the auth guard, updated the condition, and added a regression test."}
120	],
121	"artifacts": ["tests/test_auth.py"],
122	"verification": "targeted test passed"
123	}
124	```
125
126	## Example Failed Object
127
128	```json
129	{
130	"id": "traj-20260407-002",
131	"timestamp": "2026-04-07T05:00:00Z",
132	"task_type": "coding",
133	"completed": false,
134	"model": "standard",
135	"tags": ["mcp", "config"],
136	"source_context": "repo task",
137	"conversations": [
138	{"from": "human", "value": "Register the MCP server."},
139	{"from": "assistant", "value": "Updated the config draft but could not verify transport startup."}
140	],
141	"artifacts": ["config/mcp.json"],
142	"verification": "not run",
143	"failure_reason": "environment lacked server executable for startup validation"
144	}
145	```
146
147	## Save Procedure
148
149	1. Determine whether the run was successful.
150	2. Choose success or failure file.
151	3. Summarize the turns into concise conversation objects.
152	4. Assign task type.
153	5. Assign tags.
154	6. Note artifacts touched.
155	7. Note verification honestly.
156	8. Append one JSON object as one line.
157
158	## Review Procedure
159
160	1. Read the recent tail of success and failure files.
161	2. Sample for quality rather than reading the full corpus.
162	3. Check for missing fields.
163	4. Check for repeated failure patterns.
164	5. Suggest dataset hygiene improvements.
165
166	## Stats Procedure
167
168	1. Count total lines in each file.
169	2. Parse entries that are valid JSON.
170	3.

People who liked this also viewed

6 picks

Type