@dzhechkov/skills-feature-adr 1.3.0 → 1.3.2

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.
@@ -0,0 +1,188 @@
1
+ # Extract Module — Parallel Knowledge Extraction
2
+
3
+ ## Purpose
4
+
5
+ Spawn 5 focused extractor agents to scan a project directory through different lenses, collecting reusable knowledge findings with confidence scores.
6
+
7
+ ## Input
8
+
9
+ - `{TARGET_PATH}` — directory to scan (e.g., `researches/bank-kc-automation/`)
10
+ - `{SCOPE_FILTER}` — optional list of lenses to activate (null = all 5)
11
+ - `{MEMORY_PATTERNS}` — historical patterns from memory_query() (may be empty)
12
+ - `{SESSION_ID}` — harvest session identifier
13
+
14
+ ## Protocol
15
+
16
+ ### Step 1: Inventory Target Directory
17
+
18
+ List all files in `{TARGET_PATH}`. Build a file manifest with paths and sizes.
19
+ Skip binary files, images, and files > 100KB.
20
+
21
+ ### Step 2: Determine Active Agents
22
+
23
+ If `{SCOPE_FILTER}` is set, map categories to lenses:
24
+
25
+ | Requested Category | Agent Lens to Spawn |
26
+ |-------------------|---------------------|
27
+ | patterns | extractor-patterns |
28
+ | commands | extractor-commands |
29
+ | hooks | extractor-commands (shared) |
30
+ | rules | extractor-rules |
31
+ | templates | extractor-templates |
32
+ | snippets | extractor-snippets |
33
+ | skills | ALL agents (cross-cutting) |
34
+
35
+ If `{SCOPE_FILTER}` is null, spawn all 5 agents.
36
+
37
+ ### Step 3: Spawn Extractor Agents
38
+
39
+ Spawn selected agents in parallel using the Agent tool:
40
+
41
+ ```
42
+ Agent(
43
+ subagent_type="general-purpose",
44
+ model="sonnet",
45
+ description="Harvest Extractor — {LENS_NAME}",
46
+ prompt="""
47
+ You are a knowledge extraction agent with a focused lens: {LENS_DESCRIPTION}.
48
+
49
+ ## Your Task
50
+ Scan the following project files and extract reusable knowledge through your lens.
51
+ For each finding, provide:
52
+ 1. A short descriptive title (3-8 words)
53
+ 2. Content: the reusable knowledge (decontextualized where possible)
54
+ 3. "When to use" guidance (1-2 sentences)
55
+ 4. "When NOT to use" guidance (1-2 sentences)
56
+ 5. A concrete example of usage
57
+ 6. Reusability confidence (0.0 to 1.0):
58
+ - 0.9-1.0: Universal, works in any project
59
+ - 0.7-0.89: Works in most similar projects
60
+ - 0.5-0.69: Works in some contexts
61
+ - < 0.5: Probably too project-specific
62
+ 7. Suggested maturity: alpha (first time seen) or beta (if evidence of reuse)
63
+
64
+ ## Project Files
65
+ Read the following directory: {TARGET_PATH}
66
+
67
+ ## Historical Patterns (from previous harvests)
68
+ {MEMORY_PATTERNS_OR_NONE}
69
+
70
+ Avoid extracting findings that overlap with these historical patterns.
71
+
72
+ ## Extraction Rules
73
+ - Extract ONLY genuinely reusable knowledge
74
+ - DO NOT extract project-specific implementation details
75
+ - DO NOT extract trivial or obvious patterns
76
+ - Each finding must be independently useful outside this project
77
+ - Prefer actionable knowledge over abstract observations
78
+ - If in doubt about reusability, include it with a lower confidence score
79
+
80
+ ## Output Format
81
+ Return a numbered list of findings in this exact format:
82
+
83
+ ### Finding 1
84
+ **Title:** [short title]
85
+ **Confidence:** [0.0-1.0]
86
+ **Maturity:** [alpha|beta]
87
+ **Content:** [the reusable knowledge]
88
+ **When to use:** [guidance]
89
+ **When NOT to use:** [anti-guidance]
90
+ **Example:** [concrete example]
91
+
92
+ ### Finding 2
93
+ ...
94
+ """
95
+ )
96
+ ```
97
+
98
+ ### Step 4: Handle Agent Failures
99
+
100
+ If any extractor agent fails, times out, or returns malformed output:
101
+
102
+ 1. **Partial success:** Proceed with results from successful agents. Do NOT block the entire pipeline.
103
+ 2. **Log failures:** Record which lenses failed and why:
104
+ ```
105
+ ⚠️ Extractor agent failed: extractor-snippets (timeout after 120s)
106
+ Proceeding with 4/5 lenses. Snippets will not be harvested.
107
+ ```
108
+ 3. **Surface in report:** Add failed lenses to the harvest report's "Coverage Gaps" section.
109
+ 4. **Retry option:** Offer the user: `"повтори snippets"` — retry the failed lens only.
110
+ 5. **Malformed output:** If an agent returns output that cannot be parsed into the Finding format, discard that agent's results and log: `"Extractor {lens} returned unparseable output — discarded."`
111
+ 6. **Zero findings:** If an agent returns no findings, this is normal (not all lenses find relevant content). Log: `"Extractor {lens}: 0 findings (no relevant content detected)."`
112
+
113
+ ### Step 5: Report Skipped Files
114
+
115
+ Before merging, surface any files that were skipped during inventory:
116
+
117
+ ```
118
+ 📋 File inventory: {total_files} files scanned, {skipped_count} skipped
119
+ Skipped: {file1} (112KB, exceeds 100KB limit), {file2} (binary)
120
+ ```
121
+
122
+ Include this in the harvest report under "Coverage Gaps" so the user knows what was NOT examined.
123
+
124
+ ### Step 6: Merge Results
125
+
126
+ After all agents complete (or after handling failures):
127
+
128
+ 1. Collect all findings from all agents
129
+ 2. Assign sequential numbers starting from 1 (global numbering across all agents)
130
+ 3. Tag each finding with its source lens
131
+ 4. Set initial status to `raw`
132
+ 5. Write to findings JSON file at `.keysarium/harvest/findings-{SESSION_ID}.json`
133
+
134
+ ### 5 Agent Lens Descriptions
135
+
136
+ | Agent | Lens Description |
137
+ |-------|-----------------|
138
+ | extractor-patterns | Architecture patterns, design patterns, agent topologies, data flow patterns, orchestration strategies, parallelism approaches. Look for structural solutions that could be applied to other systems. |
139
+ | extractor-commands | CLI commands, scripts, pipeline stages, automation workflows, slash commands, build processes. Look for reusable command patterns and workflow automations. |
140
+ | extractor-rules | Constraints, quality gates, anti-patterns, domain rules, naming conventions, regulatory requirements, lessons learned. Look for guardrails and restrictions that prevent mistakes. |
141
+ | extractor-templates | Document structures, config file formats, diagram templates, report formats, checklist templates. Look for reusable document and configuration scaffolding. |
142
+ | extractor-snippets | Reusable code fragments, utility functions, React components, bash one-liners, prompt templates, hook implementations. Look for copy-paste-ready code blocks. |
143
+
144
+ ## Output Format
145
+
146
+ The findings JSON file structure:
147
+
148
+ ```json
149
+ {
150
+ "session_id": "{SESSION_ID}",
151
+ "status": "extracting",
152
+ "target_paths": ["{TARGET_PATH}"],
153
+ "scope_filter": null,
154
+ "created_at": "ISO-8601",
155
+ "next_number": 16,
156
+ "extractors_spawned": ["patterns", "commands", "rules", "templates", "snippets"],
157
+ "findings": {
158
+ "1": {
159
+ "number": 1,
160
+ "title": "Agent Swarm Topology",
161
+ "content": "...",
162
+ "when_to_use": "...",
163
+ "when_not_to_use": "...",
164
+ "example": "...",
165
+ "confidence": 0.85,
166
+ "maturity": "alpha",
167
+ "source_lens": "patterns",
168
+ "category": null,
169
+ "status": "raw",
170
+ "gate_results": {},
171
+ "gate_overrides": [],
172
+ "merged_from": null
173
+ }
174
+ }
175
+ }
176
+ ```
177
+
178
+ ## Anti-Patterns
179
+
180
+ | Anti-Pattern | Detection | Fix |
181
+ |-------------|-----------|-----|
182
+ | Agent extracts trivial findings | Findings like "use git for version control" | Prompt emphasizes non-obvious, actionable knowledge |
183
+ | Agent reads files outside target | File paths outside {TARGET_PATH} | Prompt constrains to target directory only |
184
+ | Duplicate findings across agents | Two agents extract the same pattern | Handled by Module 02 (dedup), not here |
185
+ | Agent returns unstructured text | Missing required fields in output | Strict output format in prompt; orchestrator validates |
186
+ | All findings have confidence 0.9+ | Agent is not being self-critical | Prompt calibration: explain the confidence scale |
187
+ | Agent timeout with no fallback | Pipeline stalls waiting for failed agent | Use Step 4 failure protocol: proceed with partial results |
188
+ | Large files silently skipped | User unaware of coverage gaps | Step 5 surfaces skipped files; harvest report includes coverage gaps |
@@ -0,0 +1,99 @@
1
+ # Classify Module — 7-Category Classification and Deduplication
2
+
3
+ ## Purpose
4
+
5
+ Assign each raw finding to one of 7 categories, deduplicate across agents, and cross-reference against existing toolkit entries.
6
+
7
+ ## Input
8
+
9
+ - Findings JSON file (from Module 01, status: `extracting` → set to `classifying`)
10
+ - `TOOLKIT_HARVEST.md` — existing entries to check for duplicates
11
+ - `references/artifact-categories.md` — category definitions and destination mapping
12
+
13
+ ## Protocol
14
+
15
+ ### Step 1: Load and Validate
16
+
17
+ 1. Read findings JSON file
18
+ 2. Verify all findings have status `raw`
19
+ 3. Set session status to `classifying`
20
+ 4. Read `references/artifact-categories.md` for category definitions
21
+
22
+ ### Step 2: Classify Each Finding
23
+
24
+ For each finding, assign a category based on content analysis:
25
+
26
+ | Category | Classification Signals |
27
+ |----------|----------------------|
28
+ | skills | Multi-step methodology, complete workflow, orchestrator + modules pattern |
29
+ | commands | Starts with `/` or describes a CLI invocation, has arguments/parameters |
30
+ | hooks | Triggered by an event, pre/post pattern, automation on lifecycle events |
31
+ | rules | Contains "must", "never", "always", constraints, anti-pattern tables |
32
+ | templates | Document skeleton, config file format, placeholder structure `{VAR}` |
33
+ | patterns | Architectural approach, design strategy, topology, reusable structure |
34
+ | snippets | Code block, function, component, < 50 lines, copy-paste ready |
35
+
36
+ **Tie-breaking rules:**
37
+ - If a finding could be both `patterns` and `skills` → prefer `patterns` unless it has modules/sub-components
38
+ - If a finding could be both `rules` and `patterns` → prefer `rules` if it's primarily a constraint
39
+ - If a finding could be both `templates` and `snippets` → prefer `templates` if it has placeholders, `snippets` if it's code
40
+
41
+ ### Step 3: Deduplicate
42
+
43
+ **Cross-agent dedup:** Compare all findings pairwise within the session using this algorithm:
44
+
45
+ 1. **Title similarity:** Normalize titles (lowercase, strip punctuation, remove stop words). Compute token overlap ratio: `shared_tokens / max(tokens_A, tokens_B)`.
46
+ 2. **Content similarity:** Extract the first 3 non-empty lines of each finding's `content` field. Compute 3-gram set overlap (Jaccard index): `|A ∩ B| / |A ∪ B|`.
47
+ 3. **Combined score:** `similarity = title_weight * title_sim + content_weight * content_sim` where `title_weight = 0.4`, `content_weight = 0.6`.
48
+ 4. **Threshold:** If `similarity >= 0.80` → duplicate. Keep the finding with higher confidence. Set the other's status to `removed`.
49
+ 5. Log: `"Dedup: #N removed (duplicate of #M, similarity: {score})"`
50
+
51
+ Note: Since an LLM is performing this comparison (not a deterministic function), the algorithm above provides guidance for consistent judgment. The orchestrator should evaluate each pair and apply the threshold consistently.
52
+
53
+ **Cross-toolkit dedup:** Compare findings against existing `TOOLKIT_HARVEST.md` entries:
54
+ 1. For each finding, scan TOOLKIT_HARVEST.md section headings and first paragraphs.
55
+ 2. If a finding's title matches an existing entry name (exact or near-match after normalization):
56
+ - Set finding's `duplicate_of` field to the existing entry name
57
+ - Flag for gate G6 (will be evaluated in Module 03)
58
+ 3. Near-duplicate range (0.70-0.85 similarity): propose a MERGE instead of flagging as duplicate.
59
+
60
+ ### Step 4: Cross-Reference
61
+
62
+ For each classified finding, check if it references or depends on existing toolkit items:
63
+ - If finding mentions a skill name → add cross-reference link
64
+ - If finding extends an existing pattern → note the relationship
65
+ - Record cross-references in the finding's metadata
66
+
67
+ ### Step 5: Write Results
68
+
69
+ 1. Update each finding in the JSON file with: `category`, `status: "classified"`
70
+ 2. Update session status
71
+ 3. Return classification summary for display
72
+
73
+ ## Output Format
74
+
75
+ The orchestrator displays classified findings grouped by category:
76
+
77
+ ```
78
+ ## patterns ({N} items)
79
+ #1 [0.85] Agent Swarm Topology — parallel agents with merge pattern
80
+ #4 [0.72] Event-Driven Pipeline — phase-to-phase data flow via files
81
+
82
+ ## rules ({N} items)
83
+ #2 [0.91] Domain Detection Rule — auto-detect domain from keywords
84
+ #7 [0.65] Regulatory Constraint — ФЗ-152 data isolation requirement
85
+
86
+ ## commands ({N} items)
87
+ ...
88
+
89
+ ## Removed by dedup: #5 (duplicate of #1), #9 (duplicate of #3)
90
+ ```
91
+
92
+ ## Anti-Patterns
93
+
94
+ | Anti-Pattern | Detection | Fix |
95
+ |-------------|-----------|-----|
96
+ | Everything classified as "patterns" | > 50% of findings in one category | Re-evaluate with stricter classification signals |
97
+ | Aggressive dedup removes valid findings | High similarity but different use cases | Compare "When to use" sections, not just content |
98
+ | Missing cross-references | Finding extends existing tool but no link | Check TOOLKIT_HARVEST.md entry names explicitly |
99
+ | Category mismatch with source lens | extractor-rules finding classified as pattern | Lens is a hint, not a binding — classify on content |
@@ -0,0 +1,150 @@
1
+ # Gate Module — 8 Quality Gates with 2-Pass Evaluation
2
+
3
+ ## Purpose
4
+
5
+ Evaluate each active finding against 8 quality gates using a two-pass approach: deterministic checks first (zero LLM cost), then semantic checks via haiku agent. Set finding status to `approved` or `blocked`.
6
+
7
+ ## Input
8
+
9
+ - Findings JSON file (from user checkpoint, active findings only)
10
+ - `references/quality-gates.md` — gate definitions, pass criteria, failure messages
11
+
12
+ ## Protocol
13
+
14
+ ### Step 1: Load Gate Definitions
15
+
16
+ ```
17
+ Read: references/quality-gates.md
18
+ ```
19
+
20
+ Load all 8 gate definitions with their type (deterministic/semantic) and pass criteria.
21
+
22
+ ### Step 2: Filter Active Findings
23
+
24
+ From the findings JSON, select only findings with status `classified` (not `removed` or `merged`).
25
+ These are the findings that survived the user checkpoint.
26
+
27
+ ### Step 3: Pass 1 — Deterministic Gates
28
+
29
+ For each active finding, evaluate deterministic gates. These are simple checks that require no LLM:
30
+
31
+ | Gate | Check Logic |
32
+ |------|------------|
33
+ | G1 | `finding.when_to_use` exists AND length > 10 characters |
34
+ | G2 | `finding.when_not_to_use` exists AND length > 10 characters |
35
+ | G5 | `finding.confidence >= 0.5` |
36
+ | G6 | `finding.duplicate_of` is null OR empty (set by Module 02) |
37
+ | G7 | `finding.maturity` is one of: `alpha`, `beta`, `stable` |
38
+
39
+ For each gate, record the result:
40
+ ```json
41
+ {
42
+ "gate_id": "G1",
43
+ "passed": true,
44
+ "evaluation_pass": "deterministic",
45
+ "reason": null
46
+ }
47
+ ```
48
+
49
+ If any deterministic gate fails, record the failure reason from `quality-gates.md`.
50
+
51
+ ### Step 4: Pass 2 — Semantic Gates
52
+
53
+ For findings that passed all deterministic gates (or for all findings if you want complete gate data), evaluate semantic gates using a haiku agent:
54
+
55
+ ```
56
+ Agent(
57
+ subagent_type="general-purpose",
58
+ model="haiku",
59
+ description="Harvest Gate Evaluator — semantic gates",
60
+ prompt="""
61
+ You are a quality gate evaluator. For each finding below, evaluate 3 semantic gates.
62
+ Be strict but fair. Err on the side of blocking rather than passing questionable findings.
63
+
64
+ ## Gates to Evaluate
65
+
66
+ **G3 — Decontextualized:**
67
+ Check if the finding contains project-specific references: variable names, file paths,
68
+ company names, dates, slugs, or any hardcoded values tied to the source project.
69
+ PASS if the finding is generic and reusable as-is.
70
+ FAIL if any project-specific detail remains.
71
+
72
+ **G4 — Concrete Example:**
73
+ Check if the finding includes at least one concrete, actionable example.
74
+ The example must show actual usage, not just describe it abstractly.
75
+ PASS if there is a real example with specifics.
76
+ FAIL if the example is vague, abstract, or missing.
77
+
78
+ **G8 — Brutal Honesty Review:**
79
+ Ask yourself: "Would a senior engineer actually find this useful in a different project?"
80
+ PASS only if the answer is genuinely yes — the finding adds real value.
81
+ FAIL if the finding is obvious, trivial, or too niche to be broadly useful.
82
+
83
+ ## Findings to Evaluate
84
+
85
+ {FINDINGS_LIST}
86
+
87
+ ## Required Output Format
88
+
89
+ For each finding, return:
90
+
91
+ Finding #N:
92
+ - G3: PASS/FAIL — [reason]
93
+ - G4: PASS/FAIL — [reason]
94
+ - G8: PASS/FAIL — [reason]
95
+ """
96
+ )
97
+ ```
98
+
99
+ ### Step 5: Set Approval Status
100
+
101
+ For each finding:
102
+ - If ALL 8 gates passed → status = `approved`
103
+ - If ANY gate failed → status = `blocked`, record failing gate IDs
104
+
105
+ Write results to findings JSON.
106
+
107
+ ### Step 6: Report Blocked Findings
108
+
109
+ The orchestrator displays blocked findings to the user:
110
+
111
+ ```
112
+ ✅ APPROVED: {N} findings passed all gates
113
+
114
+ ⚠️ BLOCKED: {M} findings failed quality gates:
115
+ #7 — G3 (project-specific references remain: mentions "bank-kc-automation")
116
+ #12 — G5 (confidence 0.35 < 0.5 threshold)
117
+ #14 — G4, G8 (no concrete example; fails brutal-honesty review)
118
+
119
+ Commands:
120
+ • "пропусти GN для #X" — override specific gate for specific finding
121
+ • "ок" — accept blocks, proceed with approved only
122
+ ```
123
+
124
+ ### Step 7: Apply Overrides (if any)
125
+
126
+ If user overrides a gate:
127
+ 1. Add gate ID to finding's `gate_overrides` array
128
+ 2. Recalculate: if all non-overridden gates pass → status = `approved`
129
+ 3. Log override for audit trail
130
+
131
+ ## Override Protocol
132
+
133
+ User command: `"пропусти G3 для #7"` (override G3 for finding #7)
134
+
135
+ Validation:
136
+ - Finding #7 must exist and be `blocked`
137
+ - G3 must be one of the failing gates for finding #7
138
+ - **G6 (Not Duplicate) and G8 (Brutal Honesty) CANNOT be overridden** — reject override attempts for these gates
139
+ - Record the override with timestamp
140
+
141
+ Multiple overrides: `"пропусти G3,G4 для #14"` — override multiple gates at once.
142
+
143
+ ## Anti-Patterns
144
+
145
+ | Anti-Pattern | Detection | Fix |
146
+ |-------------|-----------|-----|
147
+ | All findings pass all gates | 100% pass rate | Haiku semantic evaluator may be too lenient — add calibration examples |
148
+ | Gate G8 blocks everything | > 80% fail on G8 | Review extraction quality — if findings are genuinely weak, that's correct |
149
+ | Overriding all blocked gates | User overrides every block | Advisory: suggest improving extraction rather than overriding all gates |
150
+ | Semantic evaluator contradicts itself | G3 passes but content has project refs | Log discrepancy, flag for human review |
@@ -0,0 +1,159 @@
1
+ # Integrate Module — Auto-Placement and Harvest Report
2
+
3
+ ## Purpose
4
+
5
+ Place approved findings into their target directories as artifact cards, update TOOLKIT_HARVEST.md, generate the harvest report, and trigger post-harvest integrations (memory_store, dream cycles).
6
+
7
+ ## Input
8
+
9
+ - Findings JSON file (from Module 03, approved findings)
10
+ - `templates/artifact-card.md` — per-finding output template
11
+ - `templates/harvest-report.md` — session report template
12
+ - `TOOLKIT_HARVEST.md` — existing toolkit tracker
13
+
14
+ ## Protocol
15
+
16
+ ### Step 1: Load Approved Findings
17
+
18
+ 1. Read findings JSON file
19
+ 2. Filter findings with status `approved`
20
+ 3. Set session status to `integrating`
21
+ 4. Load artifact card template and harvest report template
22
+
23
+ ### Step 2: Render Artifact Cards
24
+
25
+ For each approved finding, render the artifact card by filling template placeholders:
26
+
27
+ | Placeholder | Source |
28
+ |-------------|--------|
29
+ | `{NAME}` | finding.title |
30
+ | `{CATEGORY}` | finding.category |
31
+ | `{MATURITY_BADGE}` | Lookup from maturity-model.md: alpha=🔴, beta=🟡, stable=🟢 |
32
+ | `{MATURITY_LEVEL}` | finding.maturity (capitalized) |
33
+ | `{CONFIDENCE}` | finding.confidence |
34
+ | `{SOURCE_PROJECT}` | session.slug |
35
+ | `{DATE}` | current date (YYYY-MM-DD) |
36
+ | `{DESCRIPTION}` | finding.content |
37
+ | `{WHEN_TO_USE}` | finding.when_to_use |
38
+ | `{WHEN_NOT_TO_USE}` | finding.when_not_to_use |
39
+ | `{EXAMPLE}` | finding.example |
40
+
41
+ ### Step 3: Auto-Place by Category
42
+
43
+ Place each rendered artifact card according to its category:
44
+
45
+ | Category | Placement Action |
46
+ |----------|-----------------|
47
+ | **skills** | Create `.claude/skills/{name}/SKILL.md` with the artifact card as initial skeleton. Add frontmatter (trust_tier: 0, trust_tier_label: "Advisory"). |
48
+ | **commands** | Create `.claude/commands/{name}.md` with `$ARGUMENTS` parameter reference and the artifact card content as the command body. |
49
+ | **hooks** | Append artifact card to TOOLKIT_HARVEST.md under `## Хуки` section. Create the section if it doesn't exist. |
50
+ | **rules** | Create `.claude/rules/{name}.md` with the artifact card content formatted as a rule table (anti-pattern detection format). |
51
+ | **templates** | Append artifact card to TOOLKIT_HARVEST.md under `## Шаблоны` section. |
52
+ | **patterns** | Append artifact card to TOOLKIT_HARVEST.md under `## Паттерны` section. |
53
+ | **snippets** | Append artifact card to TOOLKIT_HARVEST.md under `## Сниппеты` section. |
54
+
55
+ **Naming convention:** Convert finding title to kebab-case for file/directory names. Max 40 characters.
56
+
57
+ **Collision handling:** If a file already exists at the target path:
58
+ - Do NOT overwrite
59
+ - Log: "Skipped placement for #{N} — target already exists: {path}"
60
+ - Set finding status to `approved` (not `integrated`) and flag for manual review
61
+
62
+ ### Step 4: Update TOOLKIT_HARVEST.md
63
+
64
+ After placing all artifacts:
65
+
66
+ 1. Update the "Обработанные проекты" table:
67
+ ```markdown
68
+ | Проект | Дата harvest | Извлечено артефактов |
69
+ |--------|-------------|---------------------|
70
+ | {slug} | {date} | {approved_count} approved / {total_count} total |
71
+ ```
72
+
73
+ 2. Mark checked items in the relevant sections (skills, patterns, commands, etc.)
74
+
75
+ ### Step 5: Generate Harvest Report
76
+
77
+ Fill the harvest report template with computed metrics:
78
+
79
+ | Metric | Computation |
80
+ |--------|-------------|
81
+ | TOTAL_EXTRACTED | Count of all findings at creation |
82
+ | AFTER_DEDUP | Count after Module 02 dedup |
83
+ | USER_REMOVALS | Count where status = `removed` AND not from dedup |
84
+ | USER_MERGES | Count where merged_from is not null |
85
+ | APPROVED_COUNT | Count where status = `approved` or `integrated` |
86
+ | BLOCKED_COUNT | Count where status = `blocked` |
87
+ | OVERRIDE_COUNT | Sum of all gate_overrides arrays |
88
+ | PLACED_COUNT | Count where status = `integrated` |
89
+
90
+ Display the report to the user.
91
+
92
+ ### Step 6: Post-Harvest Integration
93
+
94
+ 1. **memory_store()** — Store harvest results:
95
+ ```json
96
+ {
97
+ "case_slug": "{slug}",
98
+ "domain": "{domain}",
99
+ "phase": "harvest",
100
+ "skill_used": "knowledge-extractor",
101
+ "reward": "{user_reward}",
102
+ "reward_label": "{label}",
103
+ "context": {
104
+ "patterns_loaded": "{count}",
105
+ "extractors_spawned": "{lens_list}",
106
+ "scope_filter": "{filter_or_null}"
107
+ },
108
+ "outcome": {
109
+ "artifacts_created": "{placed_files_list}",
110
+ "total_extracted": "{N}",
111
+ "total_approved": "{N}",
112
+ "total_placed": "{N}",
113
+ "gate_pass_rate": "{rate}"
114
+ }
115
+ }
116
+ ```
117
+
118
+ 2. **Dream trigger** — Update `.keysarium/insights/trigger-state.json`:
119
+ ```json
120
+ {
121
+ "event_type": "case_completion",
122
+ "timestamp": "ISO-8601",
123
+ "details": "Harvest completed for {slug}: {placed_count} artifacts placed"
124
+ }
125
+ ```
126
+
127
+ 3. **Clean up** — Delete the findings JSON file ONLY after confirming all placements succeeded and the harvest report was written. If any placement failed or the report could not be generated, keep the findings JSON as a recovery artifact and log: `"Findings JSON retained at {path} — manual review needed."`
128
+
129
+ ### Step 7: Final Display
130
+
131
+ Show the user a completion summary:
132
+
133
+ ```
134
+ ═══════════════════════════════════════════════════════
135
+ ✅ HARVEST COMPLETE: {SESSION_ID}
136
+
137
+ Extracted: {N} → Approved: {M} → Placed: {P}
138
+
139
+ Placed artifacts:
140
+ 📁 .claude/skills/agent-swarm-topology/SKILL.md
141
+ 📁 .claude/rules/domain-detection.md
142
+ 📄 TOOLKIT_HARVEST.md (3 entries added)
143
+
144
+ Gate pass rate: {rate}%
145
+ Memory reward stored: {score} ({label})
146
+
147
+ Run /bto-test on placed skills for promotion to Tier 2.
148
+ ═══════════════════════════════════════════════════════
149
+ ```
150
+
151
+ ## Anti-Patterns
152
+
153
+ | Anti-Pattern | Detection | Fix |
154
+ |-------------|-----------|-----|
155
+ | Overwriting existing files | Target file already exists | NEVER overwrite; skip and flag for manual review |
156
+ | Placing blocked findings | Finding status is `blocked` | Only place findings with status `approved` |
157
+ | Missing TOOLKIT_HARVEST.md sections | Section header doesn't exist yet | Create the section before appending |
158
+ | Forgetting to update "Обработанные проекты" | Table not updated after placement | Always update as the last TOOLKIT_HARVEST.md operation |
159
+ | Leaving findings JSON behind | Temp file not cleaned up | Delete after successful report generation |