origin-evolve-skill

Name: origin-evolve-skill
Author: yunzeforbetter

109stars0forks

How to install origin-evolve-skill?

yunzeforbetter/castflow/origin-evolve-skill

$npx -y skills add yunzeforbetter/CastFlow --skill origin-evolve-skill

Installs into the current project.

Summary

trace.md 执行记录进化：处理 trace 模式归纳、proposal 生成、知识更新审批与 skill 规则沉淀。

Files · 1

View on GitHub

SKILL.md

1	# Origin Evolve
2
3	Mission: turn `.claude/traces/trace.md` into approved updates of `.skillmanager/.skills/` (never write skill source files under `.claude/skills/` mirrors).
4
5	Trigger: user input `origin evolve` (or equivalent intent).
6
7	## Quick Navigation
8
9	\| Need \| See \|
10	\|------\|-----\|
11	\| Full proposal examples \| EXAMPLES.md \|
12	\| Evidence requirements (Rule 1) \| SKILL_MEMORY.md#rule-1-evidence-based-proposals \|
13	\| Attribution decision tree (Rule 2) \| SKILL_MEMORY.md#rule-2-attribution-decision-tree \|
14	\| Append / Merge / Retire operations (Rule 3) \| SKILL_MEMORY.md#rule-3-append--merge--retire \|
15	\| User approval policy (Rule 4) \| SKILL_MEMORY.md#rule-4-user-approval-required-for-every-write \|
16	\| Format & capacity compliance (Rule 5) \| SKILL_MEMORY.md#rule-5-format--capacity-compliance \|
17	\| Common pitfalls \| SKILL_MEMORY.md#pitfalls \|
18	\| When to update this skill \| ITERATION_GUIDE.md \|
19
20	## Trace Fields (schema:4)
21
22	The scoring/buffer subsystem and the hand-written IDP path were retired. A trace entry is now written ONLY when the model wrote auto-memory during the session — a memory-snapshot ledger record. Pure code sessions produce no trace entry.
23
24	Hook-generated fields: `timestamp`, `type`, `validated`, `pipeline_run_id`, `memory_snapshots`.
25
26	Lifecycle: `status` (pending/processed/expired/invalid), `validated` (`_`/true/false/pending-pipeline/invalid).
27
28	Memory snapshots are the sole learning source. `memory_snapshots: <N>` counts embedded `<!-- MEMORY slug:… type:… -->…<!-- /MEMORY -->` subblocks — verbatim copies of Claude Code auto-memory files the model wrote (`type` is `feedback`/`project`/`reference`; personal `user` memories are filtered out before capture). `type:` on the TRACE line is the dominant snapshot type (feedback > project > reference). These are raw material, not conclusions: distilling them into rules is your job in Step 2/3. Treat `feedback` content as the strongest evidence (an explicit rule the user gave), and always verify a snapshot's claim against current code/skills before proposing (snapshots are point-in-time copies and may have drifted).
29
30	Retired fields (legacy entries only): `score`, `score_breakdown`, `modules`, `correction`, `mode`, `skills`, `error_cause`, `fix_approach`, `user_feedback`, `lesson`. schema:1-3 entries may still carry these; read them if present but do not expect or require them on schema:4.
31
32	## Execution Flow
33
34	```
35	Step 1 Read & Triage -> Step 2 Identify Patterns -> Step 3 Generate Proposals -> Step 4 User Approval -> Step 5 Write & Mark Processed -> Step 6 Calibrate (optional)
36	```
37
38	### Step 1: Read & Triage
39
40	Acquire `.trace_lock` (overwrite if stale). Apply lifecycle transitions: `pending` with stale validated -> `expired`; `pending-pipeline` past expiry -> `invalid`.
41
42	Schema version gate: the current trace schema is `4`. Entries without a schema tag are treated as schema 1 (legacy). schema:1-3 entries may carry now-retired fields (`score`/`modules`/`correction`/experience fields); read them if present but never require them. Accept `schema:1` through `schema:4`. If any entry has `schema:N` where N > 4, abort and report "Unsupported trace schema version N. Update origin-evolve."
43
44	Read trace.md, keep `pending` only, then exclude entries with `validated:pending-pipeline` from proposal candidates until they are finalized to `true` / `false` or expire to `invalid`. Since schema:4 entries only exist because the model captured memory, treat any entry with a `feedback` memory snapshot as sufficient evidence to act on — do not gate it behind a minimum count. If no pending entry carries a memory snapshot (and no legacy correction signal exists), suggest waiting.
45
46	Compute three diagnostic counts across `.skillmanager/.skills/*/SKILL_MEMORY.md` and include in the analysis summary:
47	- within-skill rule pairs with anchor Jaccard >= 0.5
48	- cross-skill identical anchor sets
49	- cross-skill rule pairs with anchor Jaccard >= 0.5
50
51	Non-zero counts indicate prior attribution or merge errors and should inform Step 2 proposal generation.
52
53	Sort priority:
54	- Exclude `validated:pending-pipeline` from the priority queue; they are runtime-in-flight, not proposal evidence.
55	- P0: `validated:false` (a rejected pipeline result — something went wrong, highest signal)
56	- P1: any entry carrying a `feedback`-type memory snapshot (an explicit user rule — high-confidence raw material)
57	- P2: `validated:true` + memory snapshot (validated context worth distilling)
58	- P3: `memory_snapshots >= 1` with `project`/`reference` snapshots only
59	- P4 (legacy): schema:1-3 entries with a `correction` signal, by recency
60
61	### Step 2: Identify Patterns
62
63	Memory-snapshot distillation is the primary (and now essentially only) learning path. For each entry with `memory_snapshots >= 1`, read the `<!-- MEMORY -->` subblock content and distill it into a candidate rule yourself — the snapshot IS the raw

People who liked this also viewed

6 picks

Type

hyperframes-cliUse the HyperFrames CLI development loop: init, add, catalog, capture, lint, check, snapshot, compare, grade-compare, preview, play, present, beats, keyframes, single or batch render, publish, cloud, SkillsJul 2026262k37k
request-refactor-planSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026165k181k
analyze-projectRigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrSkillsMay 2026161k507
explore-codeRigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated braSkillsMay 2026161k507
ubiquitous-languageSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026160k181k
scaffold-exercisesSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026149k181k

origin-evolve-skill

109stars0forks

View on GitHub

How to install origin-evolve-skill?

yunzeforbetter/castflow/origin-evolve-skill

$npx -y skills add yunzeforbetter/CastFlow --skill origin-evolve-skill

Installs into the current project.

Summary

trace.md 执行记录进化：处理 trace 模式归纳、proposal 生成、知识更新审批与 skill 规则沉淀。

Files · 1

View on GitHub

SKILL.md

1	# Origin Evolve
2
3	Mission: turn `.claude/traces/trace.md` into approved updates of `.skillmanager/.skills/` (never write skill source files under `.claude/skills/` mirrors).
4
5	Trigger: user input `origin evolve` (or equivalent intent).
6
7	## Quick Navigation
8
9	\| Need \| See \|
10	\|------\|-----\|
11	\| Full proposal examples \| EXAMPLES.md \|
12	\| Evidence requirements (Rule 1) \| SKILL_MEMORY.md#rule-1-evidence-based-proposals \|
13	\| Attribution decision tree (Rule 2) \| SKILL_MEMORY.md#rule-2-attribution-decision-tree \|
14	\| Append / Merge / Retire operations (Rule 3) \| SKILL_MEMORY.md#rule-3-append--merge--retire \|
15	\| User approval policy (Rule 4) \| SKILL_MEMORY.md#rule-4-user-approval-required-for-every-write \|
16	\| Format & capacity compliance (Rule 5) \| SKILL_MEMORY.md#rule-5-format--capacity-compliance \|
17	\| Common pitfalls \| SKILL_MEMORY.md#pitfalls \|
18	\| When to update this skill \| ITERATION_GUIDE.md \|
19
20	## Trace Fields (schema:4)
21
22	The scoring/buffer subsystem and the hand-written IDP path were retired. A trace entry is now written ONLY when the model wrote auto-memory during the session — a memory-snapshot ledger record. Pure code sessions produce no trace entry.
23
24	Hook-generated fields: `timestamp`, `type`, `validated`, `pipeline_run_id`, `memory_snapshots`.
25
26	Lifecycle: `status` (pending/processed/expired/invalid), `validated` (`_`/true/false/pending-pipeline/invalid).
27
28	Memory snapshots are the sole learning source. `memory_snapshots: <N>` counts embedded `<!-- MEMORY slug:… type:… -->…<!-- /MEMORY -->` subblocks — verbatim copies of Claude Code auto-memory files the model wrote (`type` is `feedback`/`project`/`reference`; personal `user` memories are filtered out before capture). `type:` on the TRACE line is the dominant snapshot type (feedback > project > reference). These are raw material, not conclusions: distilling them into rules is your job in Step 2/3. Treat `feedback` content as the strongest evidence (an explicit rule the user gave), and always verify a snapshot's claim against current code/skills before proposing (snapshots are point-in-time copies and may have drifted).
29
30	Retired fields (legacy entries only): `score`, `score_breakdown`, `modules`, `correction`, `mode`, `skills`, `error_cause`, `fix_approach`, `user_feedback`, `lesson`. schema:1-3 entries may still carry these; read them if present but do not expect or require them on schema:4.
31
32	## Execution Flow
33
34	```
35	Step 1 Read & Triage -> Step 2 Identify Patterns -> Step 3 Generate Proposals -> Step 4 User Approval -> Step 5 Write & Mark Processed -> Step 6 Calibrate (optional)
36	```
37
38	### Step 1: Read & Triage
39
40	Acquire `.trace_lock` (overwrite if stale). Apply lifecycle transitions: `pending` with stale validated -> `expired`; `pending-pipeline` past expiry -> `invalid`.
41
42	Schema version gate: the current trace schema is `4`. Entries without a schema tag are treated as schema 1 (legacy). schema:1-3 entries may carry now-retired fields (`score`/`modules`/`correction`/experience fields); read them if present but never require them. Accept `schema:1` through `schema:4`. If any entry has `schema:N` where N > 4, abort and report "Unsupported trace schema version N. Update origin-evolve."
43
44	Read trace.md, keep `pending` only, then exclude entries with `validated:pending-pipeline` from proposal candidates until they are finalized to `true` / `false` or expire to `invalid`. Since schema:4 entries only exist because the model captured memory, treat any entry with a `feedback` memory snapshot as sufficient evidence to act on — do not gate it behind a minimum count. If no pending entry carries a memory snapshot (and no legacy correction signal exists), suggest waiting.
45
46	Compute three diagnostic counts across `.skillmanager/.skills/*/SKILL_MEMORY.md` and include in the analysis summary:
47	- within-skill rule pairs with anchor Jaccard >= 0.5
48	- cross-skill identical anchor sets
49	- cross-skill rule pairs with anchor Jaccard >= 0.5
50
51	Non-zero counts indicate prior attribution or merge errors and should inform Step 2 proposal generation.
52
53	Sort priority:
54	- Exclude `validated:pending-pipeline` from the priority queue; they are runtime-in-flight, not proposal evidence.
55	- P0: `validated:false` (a rejected pipeline result — something went wrong, highest signal)
56	- P1: any entry carrying a `feedback`-type memory snapshot (an explicit user rule — high-confidence raw material)
57	- P2: `validated:true` + memory snapshot (validated context worth distilling)
58	- P3: `memory_snapshots >= 1` with `project`/`reference` snapshots only
59	- P4 (legacy): schema:1-3 entries with a `correction` signal, by recency
60
61	### Step 2: Identify Patterns
62
63	Memory-snapshot distillation is the primary (and now essentially only) learning path. For each entry with `memory_snapshots >= 1`, read the `<!-- MEMORY -->` subblock content and distill it into a candidate rule yourself — the snapshot IS the raw

People who liked this also viewed

6 picks

Type