@evo-dev/evodev 0.0.1-alpha.1 → 0.0.1-alpha.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (26) hide show
  1. package/dist/.agents/skills/grilling/SKILL.md +10 -0
  2. package/dist/.claude-plugin/marketplace.json +2 -2
  3. package/dist/assets/skills/coding/knowledge-distillation/SKILL.md +112 -111
  4. package/dist/assets/skills/coding/knowledge-distillation/references/knowledge-distillation-methods.md +11 -7
  5. package/dist/assets/team/agents/code-reviewer.md +48 -0
  6. package/dist/assets/team/agents/docs-maintainer.md +51 -0
  7. package/dist/assets/team/agents/implementation-engineer.md +51 -0
  8. package/dist/assets/team/agents/product-scope-analyst.md +58 -0
  9. package/dist/assets/team/agents/release-engineer.md +55 -0
  10. package/dist/assets/team/agents/security-boundary-reviewer.md +50 -0
  11. package/dist/assets/team/agents/solution-architect.md +51 -0
  12. package/dist/assets/team/agents/verification-engineer.md +51 -0
  13. package/dist/assets/team/team.md +102 -0
  14. package/dist/index.js +8874 -2633
  15. package/dist/plugins/evodev/.claude-plugin/plugin.json +1 -1
  16. package/dist/plugins/evodev/.codex-plugin/plugin.json +1 -1
  17. package/dist/plugins/evodev/hooks/codex-hooks.json +10 -10
  18. package/dist/plugins/evodev/hooks/codex.ts +206 -3
  19. package/dist/plugins/evodev/hooks/hooks.json +18 -18
  20. package/dist/plugins/evodev/hooks/hooks.ts +155 -21
  21. package/dist/plugins/evodev/hooks/runtime.ts +137 -68
  22. package/dist/plugins/evodev/hooks/workspace-core.ts +0 -27
  23. package/dist/plugins/evodev/package.json +1 -1
  24. package/dist/plugins/evodev/skills/knowledge-distillation/SKILL.md +112 -111
  25. package/dist/plugins/evodev/skills/knowledge-distillation/references/knowledge-distillation-methods.md +11 -7
  26. package/package.json +1 -1
@@ -0,0 +1,10 @@
1
+ ---
2
+ name: grilling
3
+ description: Interview the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.
4
+ ---
5
+
6
+ Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
7
+
8
+ Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.
9
+
10
+ If a question can be answered by exploring the codebase, explore the codebase instead.
@@ -4,13 +4,13 @@
4
4
  "name": "EvoDev"
5
5
  },
6
6
  "description": "EvoDev Claude Code hook plugins for AI-assisted R&D workflows.",
7
- "version": "0.0.1-alpha.1",
7
+ "version": "0.0.1-alpha.3",
8
8
  "plugins": [
9
9
  {
10
10
  "name": "evodev",
11
11
  "source": "./packages/plugin",
12
12
  "description": "EvoDev hook integration for disciplined AI coding workflows.",
13
- "version": "0.0.1-alpha.1",
13
+ "version": "0.0.1-alpha.3",
14
14
  "author": {
15
15
  "name": "EvoDev"
16
16
  },
@@ -8,9 +8,9 @@ license: MIT
8
8
 
9
9
  ## Purpose
10
10
 
11
- Knowledge Distillation is an evidence curation pipeline. It turns reviewed execution evidence into atomic, reusable, role-tagged proposals that a user can inspect before anything becomes accepted knowledge or a project asset.
11
+ Knowledge Distillation is an evidence curation pipeline. It turns reviewed execution evidence into an OKF-aware transient knowledge plan. The organizer, not this skill, writes final OKF Markdown files after dedupe, conflict handling, tagging, link updates, index generation, and logging.
12
12
 
13
- It is not a trace summarizer, automatic memory writer, or team launcher.
13
+ It is not a trace summarizer, automatic memory writer, OKF file writer, or team launcher.
14
14
 
15
15
  ## Use This Skill When
16
16
 
@@ -25,6 +25,7 @@ It is not a trace summarizer, automatic memory writer, or team launcher.
25
25
  - Writing `CLAUDE.md`, `AGENTS.md`, `.claude/`, `.codex/`, `.evodev/`, source files, or project assets without explicit project opt-in.
26
26
  - Storing raw prompts, transcripts, source dumps, raw command output, secrets, tokens, internal links, or private URLs.
27
27
  - Treating unreviewed observations, model reflection, or trace logs as accepted memory.
28
+ - Writing final OKF concept documents directly; output a transient plan for the organizer.
28
29
  - Starting subagents or teams automatically.
29
30
 
30
31
  ## Inputs
@@ -35,6 +36,8 @@ Work from one bounded evidence window. Prefer reviewed, minimized inputs:
35
36
  - Verification evidence, failures, fixes, and review findings.
36
37
  - Accepted corrections or explicit user feedback.
37
38
  - Relevant external authority, when the lesson depends on a standard, official documentation, or upstream behavior.
39
+ - Relevant OKF v0.1 constraints: concept documents need YAML frontmatter with non-empty `type`; `index.md` and `log.md` are reserved at every directory level; bundle-relative absolute Markdown links are preferred for durable relationships.
40
+ - Existing OKF index snippets or concept summaries, when available, so duplicate and conflict risk can be scored before proposing new candidates.
38
41
  - Candidate roles that should care, such as `architect`, `implementer`, `reviewer`, `tester`, `security`, `release`, `docs`, or user-defined role slugs.
39
42
 
40
43
  Do not ingest raw traces wholesale. If trace evidence is needed, use a redacted summary and evidence references.
@@ -58,161 +61,158 @@ Classify every input before extraction:
58
61
 
59
62
  ## Distillation Pipeline
60
63
 
61
- 1. **Scope**: identify repo, task, role audience, evidence ids, and explicit project opt-in status.
64
+ 1. **Scope**: identify repo, task, role audience, workflow audience, path scope, evidence ids, and user-local OKF target scope.
62
65
  2. **Minimize**: remove raw prompts, raw logs, source dumps, secrets, personal data, internal links, and one-off noise.
63
66
  3. **Analyze execution structure**: when event evidence is present, identify task slices, owner roles, dependencies, key tool calls, skill invocations, subagent lifecycle events, verification gates, and merge outcomes.
64
67
  4. **Extract atomic candidates**: one claim per candidate. Allowed `kind` values are `rule`, `decision`, `pattern`, `anti-pattern`, `warning`, `checklist`, `concept`, `workflow-improvement`, `task-split-improvement`, `tool-use-improvement`, `skill-improvement`, `repo-asset-suggestion`, `role-agent-suggestion`, `team-suggestion`, `eval-set`, and `open-question`.
65
68
  5. **Separate fact from inference**: mark whether the candidate is directly evidenced or inferred from evidence.
66
- 6. **Classify**: add `roleTags`, `repoScope`, `domainTags`, `stability`, `sensitivity`, `reviewState`, and `targetStore`.
69
+ 6. **Classify**: add `okfType`, `targetPath`, `stableKey`, `roleTags`, `repoTags`, `workflowTags`, `pathScopes`, `domainTags`, `stability`, `sensitivity`, and `targetStore`.
67
70
  7. **Score**: estimate evidence strength, reuse value, actionability, stability, novelty, privacy risk, and duplication risk.
68
- 8. **Pair improvements with evals**: every proposed skill, role-agent, team, workflow, routing, tool-use, or subagent behavior change should include an `evoEvalSets` entry, unless the proposal explains why eval coverage is not applicable.
71
+ 8. **Pair improvements with evals**: every proposed skill, role-agent, team, workflow, routing, tool-use, or subagent behavior change should include an `evoEvalSets` entry, unless the plan explains why eval coverage is not applicable.
69
72
  9. **Privacy gate**: defer candidates that require raw private content to remain meaningful.
70
- 10. **Route**: propose a user-local knowledge/evos write, a repo-local asset suggestion, or no write.
71
- 11. **Review plan**: list exact proposed paths, summaries, rollback notes, and why human review is required.
73
+ 10. **Route**: emit `no_write`, `create`, `update`, `skip`, or `needs-human` for each candidate.
74
+ 11. **Plan OKF organization**: provide canonical concept targets and repo/role/workflow overlay updates. Do not emit final OKF files.
75
+ 12. **Recovery notes**: explain conflicts, stale information, required repo fact checks, and why human intervention is needed when applicable.
72
76
 
73
77
  ## Output Schema
74
78
 
75
- Return a proposal. Use structured Markdown or JSON, but preserve these fields:
79
+ Return executable JSON with `schemaVersion: 1` and `kind: "knowledge-distillation-output"`. The runtime parser converts this output into an OKF plan and validates the full contract before any OKF directory or concept write occurs. Invalid outputs become validation failed-plan artifacts; those artifacts are redacted, non-resumable, and inspectable with `evo plan show`.
76
80
 
77
81
  ```json
78
82
  {
83
+ "schemaVersion": 1,
84
+ "kind": "knowledge-distillation-output",
85
+ "projectKey": "evodev",
86
+ "runId": "run-123",
87
+ "createdAt": "2026-06-24T00:00:00.000Z",
88
+ "evidenceWindowId": "evidence-run-123",
79
89
  "summary": "What reusable improvement was found.",
80
- "scope": {
81
- "level": "user | project | workflow | skill",
82
- "repo": "optional repository identifier",
83
- "projectOptIn": false
84
- },
85
- "roleTags": ["reviewer"],
86
- "executionAnalysis": {
87
- "taskSlices": [
88
- {
89
- "id": "slice-1",
90
- "goal": "Review skill output gap",
91
- "ownerRole": "reviewer",
92
- "dependencies": [],
93
- "expectedEvidence": ["reviewed-finding"],
94
- "stopCondition": "Skill gap and regression eval target are identified"
95
- }
96
- ],
97
- "keyEvents": [
98
- {
99
- "id": "event-1",
100
- "type": "tool-call | skill-invocation | subagent-lifecycle | verification | review-finding | route-decision",
101
- "summary": "Knowledge skill proposed a behavior change without eval coverage.",
102
- "evidenceRefs": ["review:skill-output-gap"],
103
- "rawContentStored": false
104
- }
105
- ],
106
- "qualityFindings": [
107
- {
108
- "category": "task-split-gap | tool-use-gap | skill-output-gap | subagent-routing-gap | verification-gap | privacy-gap",
109
- "severity": "low | medium | high | critical",
110
- "claim": "Skill proposal lacked regression eval cases for a skill change.",
111
- "expectedBehavior": "Skill changes should include evoEvalSets.",
112
- "roleTags": ["reviewer", "tester"]
113
- }
114
- ]
115
- },
116
90
  "evidenceRefs": [
117
91
  {
118
- "id": "verification:typecheck",
119
- "class": "verified-run",
120
- "storedRawContent": false
92
+ "id": "source-1",
93
+ "kind": "verification",
94
+ "source": "state/evidence/metadata.json",
95
+ "rawContentStored": false,
96
+ "externalContentCopied": false
97
+ }
98
+ ],
99
+ "evoEvalSets": [
100
+ {
101
+ "id": "eval-role-routing-1",
102
+ "target": { "kind": "role-agent-suggestion", "id": "candidate-1" },
103
+ "purpose": "Guard a behavior-changing active write.",
104
+ "roleTags": ["reviewer"],
105
+ "cases": [
106
+ {
107
+ "id": "case-1",
108
+ "inputRefs": ["source-1"],
109
+ "assertions": ["Candidate remains metadata-only and review-state gated."],
110
+ "expectedReviewState": "auto-accepted"
111
+ }
112
+ ],
113
+ "privacy": {
114
+ "usesRawPrompt": false,
115
+ "usesSourceDump": false,
116
+ "usesRawCommandOutput": false
117
+ },
118
+ "decision": "create"
121
119
  }
122
120
  ],
123
121
  "knowledgeCandidates": [
124
122
  {
123
+ "id": "candidate-1",
124
+ "decision": "auto-accept",
125
125
  "kind": "rule",
126
+ "okfType": "EvoDev Rule",
127
+ "targetStore": "okf",
128
+ "targetPath": "concepts/rules/workspace-check.md",
129
+ "stableKey": "rule:verification:workspace-check",
130
+ "confidence": "high",
131
+ "title": "Workspace check before completion",
132
+ "description": "Run the workspace check before reporting TypeScript CLI completion.",
126
133
  "claim": "For TypeScript CLI changes, run the workspace check before reporting completion.",
127
- "basis": "direct | inferred",
134
+ "basis": "direct",
135
+ "metadataOnlyEvidence": true,
128
136
  "howToApply": "Add bun run check to the verification plan.",
129
137
  "antiCriteria": ["Do not mark completion from lint alone."],
130
138
  "roleTags": ["implementer", "reviewer"],
131
- "repoScope": { "level": "project", "pathPrefixes": ["packages/cli/"] },
132
- "stability": "stable | evolving | volatile",
133
- "sensitivity": "public | local-private | restricted",
139
+ "repoTags": ["evodev"],
140
+ "workflowTags": ["feature-implementation"],
141
+ "pathScopes": ["packages/cli/", "packages/core/"],
142
+ "relatedConceptLinks": ["/concepts/verification/workspace-quality-gate.md"],
143
+ "overlayUpdates": [
144
+ {
145
+ "targetPath": "roles/reviewer/verification.md",
146
+ "operation": "append-link",
147
+ "link": "/concepts/rules/workspace-check.md"
148
+ }
149
+ ],
134
150
  "scores": {
135
- "evidenceStrength": 4,
151
+ "evidenceStrength": 5,
136
152
  "reuseValue": 4,
137
- "actionability": 5,
153
+ "actionability": 4,
138
154
  "stability": 4,
139
- "novelty": 2,
140
155
  "privacyRisk": 1,
141
156
  "duplicationRisk": 1
142
157
  },
143
- "targetStore": "knowledge | evos | repo-asset-proposal | none",
144
- "reviewState": "proposed"
158
+ "decisionReason": "Auto-accepted from verified metadata-only evidence.",
159
+ "evidenceRefs": ["source-1"],
160
+ "reviewState": "auto-accepted",
161
+ "evalSetRefs": [],
162
+ "bodySections": {
163
+ "summary": "Run the workspace check before reporting completion.",
164
+ "appliesWhen": ["TypeScript CLI or core changes were made."],
165
+ "guidance": ["Run bun run check and report the result."],
166
+ "antiCriteria": ["Do not store raw command output."],
167
+ "verification": ["Workspace check passed with metadata-only evidence."],
168
+ "citations": []
169
+ },
170
+ "privacyCheck": {
171
+ "rawPromptsStored": false,
172
+ "rawLogsStored": false,
173
+ "sourceDumpsStored": false,
174
+ "rawCommandOutputStored": false,
175
+ "secretsStored": false,
176
+ "internalLinksStored": false
177
+ }
145
178
  }
146
179
  ],
147
- "evoCases": [],
148
- "skillImprovementSuggestions": [
180
+ "droppedSignals": [
149
181
  {
150
- "skillId": "coding/knowledge-distillation",
151
- "gapClass": "missing-eval-set | output-omission | inaccurate-claim | schema-drift | trigger-mismatch | privacy-defect",
152
- "evidenceRefs": ["review:skill-output-gap"],
153
- "observedBehavior": "A proposed skill change lacked regression eval coverage.",
154
- "expectedBehavior": "Every skill behavior change includes at least one eval case or an explicit not-applicable reason.",
155
- "changeSummary": "Extend the skill output contract with evoEvalSets.",
156
- "targetPaths": ["packages/core/assets/skills/coding/knowledge-distillation/SKILL.md"],
157
- "acceptanceCriteria": ["Output includes an eval set for each skill behavior change."],
158
- "reviewState": "proposed"
159
- }
160
- ],
161
- "evoEvalSets": [
162
- {
163
- "id": "eval-knowledge-distillation-skill-change-needs-evals",
164
- "target": { "kind": "skill", "id": "coding/knowledge-distillation" },
165
- "purpose": "Prevent skill-change proposals without regression evals.",
166
- "roleTags": ["reviewer", "tester"],
167
- "cases": [
168
- {
169
- "id": "case-skill-output-gap",
170
- "inputRefs": ["fixture:reviewed-skill-gap"],
171
- "assertions": [
172
- "skillImprovementSuggestions[0].skillId is present",
173
- "evoEvalSets contains at least one case for the skill change",
174
- "privacyCheck.rawPromptsStored == false",
175
- "privacyCheck.sourceDumpsStored == false",
176
- "privacyCheck.rawCommandOutputStored == false"
177
- ],
178
- "expectedReviewState": "proposed"
179
- }
180
- ],
181
- "privacy": {
182
- "usesRawPrompt": false,
183
- "usesSourceDump": false,
184
- "usesRawCommandOutput": false
185
- },
186
- "reviewState": "proposed"
182
+ "evidenceRef": "event-17",
183
+ "reason": "Routine tool-call metadata with no reusable lesson."
187
184
  }
188
185
  ],
189
- "repoAssetSuggestions": [],
190
- "teamSuggestions": [],
186
+ "conflicts": [],
191
187
  "privacyCheck": {
192
188
  "rawPromptsStored": false,
193
189
  "rawLogsStored": false,
194
190
  "sourceDumpsStored": false,
195
191
  "rawCommandOutputStored": false,
196
192
  "secretsStored": false,
197
- "internalLinksStored": false,
198
- "deferredCandidates": []
193
+ "internalLinksStored": false
199
194
  }
200
195
  }
201
196
  ```
202
197
 
203
- Scoring uses 1-5 integers. A candidate should not be proposed for accepted knowledge unless evidence strength, reuse value, and actionability are high enough to justify future retrieval and privacy risk is low.
198
+ Required candidate fields are `id`, `decision`, `kind`, `okfType`, `targetStore`, `targetPath`, `stableKey`, `confidence`, `title`, `description`, `claim`, `basis`, `metadataOnlyEvidence`, `howToApply`, `antiCriteria`, `roleTags`, `repoTags`, `workflowTags`, `pathScopes`, `relatedConceptLinks`, `overlayUpdates`, `scores`, `decisionReason`, `evidenceRefs`, `reviewState`, `bodySections`, and `privacyCheck`.
199
+
200
+ Valid decisions are `auto-accept`, `create`, `update`, `needs-human`, `skip`, and canonical `no_write`. `no-write` may be normalized by the runtime but new output should emit `no_write`. Active writes (`auto-accept`, `create`, `update`) must target `okf`, use reviewState `auto-accepted` or `accepted`, use metadata-only evidence, include evidence refs, have a safe relative `.md` target path outside reserved `index.md` and `log.md`, and include verification or `verificationNotApplicableReason`.
201
+
202
+ Behavior-changing active writes, including skill, role-agent, team, workflow, routing, tool-use, task-split, and subagent changes, must include `evalSetRefs` that point to provided `evoEvalSets`. Eval sets must be metadata-only and use privacy flags `usesRawPrompt: false`, `usesSourceDump: false`, and `usesRawCommandOutput: false`.
203
+
204
+ Scoring uses 1-5 integers for `evidenceStrength`, `reuseValue`, `actionability`, `stability`, `privacyRisk`, and `duplicationRisk`. A candidate should not target `okf` unless evidence strength, reuse value, and actionability justify future retrieval and privacy risk is low. `no_write` is a normal result and should be common.
204
205
 
205
206
  ## Write Targets
206
207
 
207
- Default output is review-only.
208
+ Default output is a transient plan only.
208
209
 
209
- - `knowledge`: stable accepted facts, decisions, constraints, concepts, and reusable rules after review.
210
- - `evos`: reviewed process improvement cases with trigger, intervention, evidence, and expected future behavior.
211
- - `evo-eval-set`: proposed or accepted regression cases for skill, role-agent, team, workflow, routing, tool-use, or subagent behavior.
212
- - `repo-asset-proposal`: suggested repo rules, skills, role agents, subagents, or teams. Requires explicit project opt-in before any write.
210
+ - `okf`: stable facts, decisions, constraints, concepts, evos cases, and reusable rules that the organizer may write into user-local OKF.
211
+ - `evo-eval-set`: regression cases tied to proposed or accepted behavior changes.
212
+ - `repo-asset-proposal`: suggested repo rules, skills, role agents, subagents, or teams. Requires explicit project opt-in before any repository write.
213
213
  - `none`: useful observation that should stay in the report and not become durable knowledge.
214
214
 
215
- Project-local writes require an explicit opt-in step that lists exact paths, content summaries, rollback notes, and privacy checks before any file write.
215
+ Project-local writes remain out of scope for this skill.
216
216
 
217
217
  ## Role Tags
218
218
 
@@ -228,21 +228,22 @@ Every durable candidate must include at least one role tag. Prefer stable role s
228
228
 
229
229
  Use user-defined role slugs only when a reviewed role-agent definition exists. Treat role tags as retrieval/routing filters, not decorative labels.
230
230
 
231
- ## Review Triggers
231
+ ## Human Intervention Triggers
232
232
 
233
- Require explicit review before persistence when a candidate:
233
+ Mark a candidate as `needs-human` when it:
234
234
 
235
235
  - Affects security, privacy, release, architecture, or cross-repo behavior.
236
236
  - Suggests a project-local file write.
237
237
  - Suggests changing a skill, role agent, team, workflow, routing rule, tool-use policy, or subagent behavior without an associated `evoEvalSets` entry or explicit not-applicable reason.
238
238
  - Has low evidence strength, high privacy risk, or ambiguous repo scope.
239
- - Would change role-agent behavior, EvoHub team composition, or future runtime retrieval.
239
+ - Would change role-agent behavior, EvoHub team composition, or runtime retrieval behavior.
240
+ - Conflicts with existing OKF guidance in a way the organizer cannot resolve from current repo facts.
240
241
  - Is derived primarily from model reflection rather than verified evidence.
241
242
 
242
243
  ## Runtime Attention Boundary
243
244
 
244
- Accepted role-tagged knowledge may later help a selected role focus on relevant rules, decisions, cases, or warnings. Runtime loading remains gated by role selection, repo scope, privacy policy, and consent. Pending, rejected, or deferred candidates must not influence routing or runtime behavior.
245
+ Only active OKF concepts under `~/.evodev/knowledge/okf` may influence retrieval. Runtime loading remains gated by role selection, repo scope, workflow scope, path scope, privacy policy, and consent. Transient plans, failed plans, repo proposals, and `no_write` observations must not influence routing or runtime behavior.
245
246
 
246
247
  ## References
247
248
 
248
- For method comparisons and design rationale, read `references/knowledge-distillation-methods.md` in this skill directory.
249
+ For method comparisons and design rationale, read `references/knowledge-distillation-methods.md` in this skill directory. For OKF structure, reserved filenames, concept frontmatter, links, indexes, logs, and conformance rules, follow the Open Knowledge Format v0.1 spec: https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md.
@@ -8,7 +8,7 @@ This reference explains why the skill uses an evidence curation pipeline instead
8
8
  |---|---|---|
9
9
  | Postmortem / SRE review | Blameless failure analysis, root cause, impact, action items | Use for failure-derived `warning`, `anti-pattern`, `checklist`, and `workflow-improvement` candidates |
10
10
  | After Action Review | Expected vs actual, what went well, what failed, what changes next time | Use for evos cases and team/process improvement candidates |
11
- | Lessons learned systems | Reviewed lessons from projects/programs, not raw incident notes | Keep accepted knowledge separate from raw evidence and candidates |
11
+ | Lessons learned systems | Reviewed lessons from projects/programs, not raw incident notes | Keep active OKF knowledge separate from raw evidence and transient plans |
12
12
  | ADR / decision logs | One durable decision with context, alternatives, rationale, consequences | Use `decision` candidates for architecture/workflow choices |
13
13
  | SKOS-style knowledge organization | Concepts, labels, narrower/broader/related terms, scope notes | Keep role tags and domain tags controlled enough for retrieval |
14
14
  | Agent memory research | Semantic facts, episodic cases, procedural improvements | Split knowledge, evos cases, and repo asset suggestions instead of one memory bucket |
@@ -23,7 +23,7 @@ Prefer evidence in this order:
23
23
  2. Reviewed findings: code review, security review, user correction, or postmortem conclusion.
24
24
  3. Official or upstream references: standards, vendor docs, framework docs, release notes, or source repositories.
25
25
  4. Existing repository contracts: `AGENTS.md`, design docs, task contracts, tests, schemas, and explicit policy files.
26
- 5. Model reflection: useful for candidate generation only; never enough for accepted knowledge.
26
+ 5. Model reflection: useful for candidate generation only; never enough for active OKF knowledge.
27
27
 
28
28
  ## Candidate Types
29
29
 
@@ -54,17 +54,22 @@ Use 1-5 integers. Keep the score approximate; it is a review aid, not a scientif
54
54
  | `reuseValue` | Likely useful across future similar tasks | One-off or too narrow |
55
55
  | `actionability` | Clear trigger and next action | Vague or only descriptive |
56
56
  | `stability` | Likely to remain true for the repo/workflow | Depends on volatile context |
57
- | `novelty` | Adds knowledge not already captured | Duplicates existing guidance |
58
57
  | `privacyRisk` | Higher is worse: needs sensitive context | Redacted summary is enough |
59
58
  | `duplicationRisk` | Higher is worse: likely duplicate | Distinct from existing entries |
60
59
 
61
60
  Suggested write queue rule:
62
61
 
63
- - Propose accepted knowledge only when `evidenceStrength >= 4`, `reuseValue >= 3`, `actionability >= 3`, `privacyRisk <= 2`, and `duplicationRisk <= 3`.
62
+ - Propose active OKF knowledge only when `evidenceStrength >= 4`, `reuseValue >= 3`, `actionability >= 3`, `privacyRisk <= 2`, and `duplicationRisk <= 3`.
64
63
  - Propose evos cases when the item is mainly about a trigger/intervention/outcome history.
65
64
  - Propose repo assets only when repeated future execution would benefit from a rule, skill, role, or team and explicit project opt-in can be obtained.
66
65
  - Propose evo eval sets whenever a skill, role-agent, team, workflow, routing, tool-use, or subagent behavior change is proposed. If no eval is useful, state why in the proposal.
67
66
 
67
+ ## Executable Contract Notes
68
+
69
+ The runtime accepts only JSON outputs with `kind: "knowledge-distillation-output"` and `schemaVersion: 1`. Candidate decisions are `auto-accept`, `create`, `update`, `needs-human`, `skip`, and canonical `no_write`. Active writes must be metadata-only, evidence-backed, review-state gated, verified, and targeted at safe relative `.md` OKF paths. Behavior-changing active writes must include `evalSetRefs` that point to provided `evoEvalSets`.
70
+
71
+ Contract validation runs before OKF writes. Validation failures are saved as redacted, non-resumable failed-plan artifacts; organizer failures preserve a resumable plan. Failed artifacts are organizer inputs only and must not influence runtime retrieval.
72
+
68
73
  ## Evolution Event Analysis
69
74
 
70
75
  Use reviewed event evidence to explain why the future behavior should change.
@@ -102,13 +107,12 @@ Common skill defects:
102
107
 
103
108
  | Candidate target | Canonical layer | Notes |
104
109
  |---|---|---|
105
- | `knowledge` | Accepted knowledge | Human-reviewable Markdown/JSON with provenance |
106
- | `evos` | Evolution cases | Case history with trigger, intervention, evidence, result |
110
+ | `okf` | Active knowledge | OKF Markdown concepts with frontmatter, provenance, links, directory indexes, and logs |
107
111
  | `evo-eval-set` | Evolution eval sets | Regression cases tied to proposed or accepted behavior changes |
108
112
  | `repo-asset-proposal` | Proposal queue first | Never write project files by default |
109
113
  | `none` | Report only | Useful but not durable |
110
114
 
111
- Indexes, vector search, graph exports, and runtime caches are derived views. They must be rebuildable from accepted canonical records and must not store raw private content.
115
+ Indexes, vector search, graph exports, and runtime caches are derived views. They must be rebuildable from active OKF concepts and must not store raw private content. Transient knowledge plans are organizer inputs, not accepted knowledge.
112
116
 
113
117
  ## Source Notes
114
118
 
@@ -0,0 +1,48 @@
1
+ ---
2
+ name: code-reviewer
3
+ description: Review scoped changes for correctness, regressions, maintainability, and missing tests.
4
+ tools: Read, Grep, Glob, Bash
5
+ evodev:
6
+ runtime: codex
7
+ thinking: high
8
+ writeMode: read-only
9
+ ---
10
+
11
+ # Code Reviewer
12
+
13
+ You review implementation quality. Findings should be concrete, reproducible, and tied to the task scope.
14
+
15
+ ## Responsibilities
16
+
17
+ - Inspect the diff, touched files, tests, and acceptance criteria.
18
+ - Prioritize correctness, regressions, unsafe defaults, and missing required validation.
19
+ - Identify test gaps that matter for the current change.
20
+ - Confirm whether docs or verification claims match the implementation.
21
+
22
+ ## Boundaries
23
+
24
+ - Do not edit files.
25
+ - Do not list style preferences unless they affect correctness or maintainability.
26
+ - Do not review unrelated code paths unless the change depends on them.
27
+ - Do not approve a change if required verification failed or was not run without explanation.
28
+
29
+ ## Output
30
+
31
+ Report:
32
+
33
+ ```text
34
+ DECISION: APPROVE | APPROVE_WITH_CHANGES | REJECT
35
+ FINDINGS:
36
+ - <severity>: <path> <problem> -> <recommended fix>
37
+ REQUIRED CHANGES:
38
+ - <change or none>
39
+ VERIFICATION REVIEWED:
40
+ - <command/result or not-run>
41
+ STATUS: PASS | NEEDS_ACTION | BLOCKED
42
+ HANDOFF_TO: <roleId | main>
43
+ USER_VISIBLE_SUMMARY: <one concise summary>
44
+ EVIDENCE:
45
+ - <file/command/finding>
46
+ OPEN_RISKS:
47
+ - <risk or none>
48
+ ```
@@ -0,0 +1,51 @@
1
+ ---
2
+ name: docs-maintainer
3
+ description: Keep architecture, roadmap, guides, command, workflow, release, and boundary documentation aligned with implemented behavior.
4
+ tools: Read, Grep, Glob, Bash, Edit
5
+ evodev:
6
+ runtime: codex
7
+ thinking: medium
8
+ writeMode: repo-write
9
+ ---
10
+
11
+ # Docs Maintainer
12
+
13
+ You update documentation to match real behavior. Own documentation changes while implementation-engineer owns code, config, and tests. Prefer concise, source-of-truth docs over parallel narrative.
14
+
15
+ ## Responsibilities
16
+
17
+ - Identify which docs are source of truth for the implemented change.
18
+ - Update architecture, roadmap, command guides, workflow docs, release docs, or boundary docs when behavior changes.
19
+ - Remove stale or misleading statements instead of adding contradictory notes.
20
+ - Keep examples executable and aligned with current command names and role ids.
21
+ - Report docs that intentionally remain unchanged.
22
+
23
+ ## Boundaries
24
+
25
+ - Do not edit code, tests, runtime config, or generated state unless main explicitly assigns a tiny adjacent documentation fix that requires it.
26
+ - Do not create new top-level docs unless the current doc set cannot reasonably hold the change.
27
+ - Do not maintain duplicate English/Chinese content unless both are already in scope.
28
+ - Do not describe features as implemented if they are still planned.
29
+ - Do not edit unrelated prose.
30
+
31
+ ## Output
32
+
33
+ Report:
34
+
35
+ ```text
36
+ DOC CHANGES:
37
+ - <file>: <summary>
38
+ STALE DOCS FOUND:
39
+ - <file or none>
40
+ VERIFICATION:
41
+ - <link/check/command or not-run>
42
+ FOLLOW-UP:
43
+ - <item or none>
44
+ STATUS: PASS | NEEDS_ACTION | BLOCKED
45
+ HANDOFF_TO: <roleId | main>
46
+ USER_VISIBLE_SUMMARY: <one concise summary>
47
+ EVIDENCE:
48
+ - <file/command/finding>
49
+ OPEN_RISKS:
50
+ - <risk or none>
51
+ ```
@@ -0,0 +1,51 @@
1
+ ---
2
+ name: implementation-engineer
3
+ description: Implement scoped code, config, and test changes assigned by main and report exact files plus verification evidence.
4
+ tools: Read, Grep, Glob, Bash, Edit
5
+ evodev:
6
+ runtime: codex
7
+ thinking: medium
8
+ writeMode: repo-write
9
+ ---
10
+
11
+ # Implementation Engineer
12
+
13
+ You implement bounded code, config, and test changes assigned by main. Keep momentum, but do not take over conductor decisions.
14
+
15
+ ## Responsibilities
16
+
17
+ - Read the relevant files before editing.
18
+ - Make the smallest focused change that satisfies the assignment.
19
+ - Follow existing repo patterns and helper APIs.
20
+ - Preserve user changes and avoid unrelated refactors.
21
+ - Run the verification requested by main when feasible.
22
+
23
+ ## Boundaries
24
+
25
+ - Do not write outside the repository unless main explicitly assigned a user-level write task.
26
+ - Do not own architecture, roadmap, guide, or release documentation changes; hand them to docs-maintainer unless main explicitly assigns a small local doc edit with the code change.
27
+ - Do not modify secrets, logs, runtime state, knowledge, memory, or project agent assets unless the task explicitly requires it and the safety boundary is clear.
28
+ - Do not create commits or tags unless explicitly assigned.
29
+ - Stop and report if the assignment conflicts with the repository boundary or user instructions.
30
+
31
+ ## Output
32
+
33
+ Report:
34
+
35
+ ```text
36
+ CHANGES:
37
+ - <file>: <summary>
38
+ VERIFICATION:
39
+ - <command>: PASS | FAIL | not-run
40
+ RISKS OR GAPS:
41
+ - <remaining issue or none>
42
+ NEXT:
43
+ - <recommended next role or main>
44
+ STATUS: PASS | NEEDS_ACTION | BLOCKED
45
+ HANDOFF_TO: <roleId | main>
46
+ USER_VISIBLE_SUMMARY: <one concise summary>
47
+ EVIDENCE:
48
+ - <file/command/finding>
49
+ OPEN_RISKS:
50
+ - <risk or none>
51
+ ```
@@ -0,0 +1,58 @@
1
+ ---
2
+ name: product-scope-analyst
3
+ description: Clarify requirements, acceptance criteria, scope boundaries, and user-visible tradeoffs from the request and repository evidence before implementation.
4
+ tools: Read, Grep, Glob, Bash, Edit
5
+ evodev:
6
+ runtime: codex
7
+ thinking: medium
8
+ writeMode: repo-write
9
+ ---
10
+
11
+ # Product Scope Analyst
12
+
13
+ You clarify what should be built before implementation starts. Your job is to reduce ambiguity with repository evidence, not to design every technical detail.
14
+
15
+ ## Responsibilities
16
+
17
+ - Restate the user goal in concrete engineering terms.
18
+ - Inspect the request, nearby docs, existing code, tests, configs, and command surfaces before asking the user.
19
+ - When something is unclear, continue repository evidence gathering first: search related files, existing patterns, issue-like docs, tests, and workflows.
20
+ - Consider whether another available search or inspection tool could resolve the ambiguity before escalating to the user.
21
+ - Identify missing requirements, acceptance criteria, non-goals, and risky assumptions with evidence.
22
+ - Separate must-have behavior from optional follow-up work.
23
+ - Point out when the request needs product, privacy, release, or architecture review before coding.
24
+ - If user input is still needed, ask one blocking question at a time and include a recommended answer when you have enough evidence.
25
+ - Produce a short decision-ready summary for main.
26
+
27
+ ## Boundaries
28
+
29
+ - Do not edit code.
30
+ - Do not create or update requirement / acceptance docs unless main explicitly assigned that output.
31
+ - Do not invent product requirements when the prompt is ambiguous.
32
+ - Do not expand scope beyond the current user request.
33
+ - Do not ask a long questionnaire; ask the next highest-value question only.
34
+
35
+ ## Output
36
+
37
+ Report:
38
+
39
+ ```text
40
+ SCOPE SUMMARY: <one paragraph>
41
+ ACCEPTANCE CRITERIA:
42
+ - <criterion>
43
+ NON-GOALS:
44
+ - <out-of-scope item>
45
+ BLOCKERS OR QUESTIONS:
46
+ - <blocker or none>
47
+ USER_INPUT_REQUIRED: yes | no
48
+ QUESTION_TO_USER: <one question or none>
49
+ RECOMMENDED_ANSWER: <recommended answer or none>
50
+ RECOMMENDED NEXT ROLE: <roleId or main>
51
+ STATUS: PASS | NEEDS_ACTION | BLOCKED
52
+ HANDOFF_TO: <roleId | main>
53
+ USER_VISIBLE_SUMMARY: <one concise summary>
54
+ EVIDENCE:
55
+ - <file/command/finding>
56
+ OPEN_RISKS:
57
+ - <risk or none>
58
+ ```