@dzhechkov/keysarium 1.0.1 → 1.1.1
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.
- package/README.md +21 -5
- package/package.json +1 -1
- package/src/utils.js +5 -4
- package/templates/.claude/commands/brain-export.md +121 -0
- package/templates/.claude/commands/brain-import.md +115 -0
- package/templates/.claude/rules/checkpoint-protocol.md +46 -0
- package/templates/.claude/rules/feedback-loops.md +113 -0
- package/templates/.claude/rules/model-routing.md +65 -0
- package/templates/.claude/rules/trust-tiers.md +36 -0
- package/templates/.claude/shards/phase-0-discovery.shard.md +45 -0
- package/templates/.claude/shards/phase-1-explore.shard.md +32 -0
- package/templates/.claude/shards/phase-2-research.shard.md +42 -0
- package/templates/.claude/shards/phase-25-cjm.shard.md +47 -0
- package/templates/.claude/shards/phase-3-solve.shard.md +47 -0
- package/templates/.claude/shards/phase-4-architecture.shard.md +41 -0
- package/templates/.claude/shards/phase-5-presentation.shard.md +56 -0
- package/templates/.claude/skills/explore/SKILL.md +7 -4
- package/templates/.claude/skills/frontend-design/SKILL.md +3 -0
- package/templates/.claude/skills/goap-research-ed25519/SKILL.md +3 -0
- package/templates/.claude/skills/presentation-storyteller/SKILL.md +5 -2
- package/templates/.claude/skills/problem-solver-enhanced/SKILL.md +3 -0
- package/templates/.claude/skills/reverse-engineering-unicorn/SKILL.md +3 -0
- package/templates/CLAUDE.md +55 -3
- package/templates/docs/improvement-directions.md +641 -0
- package/templates/docs/skills-bto/01-deployment-guide.md +33 -33
- package/templates/docs/skills-bto/02-admin-guide.md +13 -13
- package/templates/docs/skills-bto/03-user-guide.md +1 -1
- package/templates/docs/skills-bto/04-infrastructure-requirements.md +4 -4
- package/templates/docs/skills-bto/05-architecture.md +4 -4
- package/templates/docs/skills-bto/06-user-flows.md +1 -1
package/README.md
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
**AI Case Research Toolkit for Claude Code**
|
|
4
4
|
|
|
5
|
-
Full 7-phase pipeline for AI case studies, hackathons, and casariums. Provides skills, commands, rules, agent templates, and
|
|
5
|
+
Full 7-phase pipeline for AI case studies, hackathons, and casariums. Provides skills, commands, rules, shards, agent templates, and brain portability for [Claude Code](https://docs.anthropic.com/en/docs/claude-code).
|
|
6
6
|
|
|
7
7
|
---
|
|
8
8
|
|
|
@@ -29,12 +29,12 @@ After installation, open Claude Code in your project directory and start using s
|
|
|
29
29
|
| Component | Count | Description |
|
|
30
30
|
|-----------|-------|-------------|
|
|
31
31
|
| **Skills** | 6 | `explore`, `frontend-design`, `goap-research`, `presentation-storyteller`, `problem-solver`, `reverse-engineering` |
|
|
32
|
-
| **Commands** |
|
|
33
|
-
| **Rules** |
|
|
32
|
+
| **Commands** | 13 | `/casarium`, `/new-research`, `/parallel-research`, `/discovery`, `/explore-case`, `/research`, `/cjm-prototype`, `/solve`, `/architecture-phase`, `/presentation`, `/harvest`, `/brain-export`, `/brain-import` |
|
|
33
|
+
| **Rules** | 10 | `research-quality`, `checkpoint-protocol`, `agent-swarm`, `domain-specific`, `anti-patterns`, `file-conventions`, `modular-reuse`, `feedback-loops`, `model-routing`, `trust-tiers` |
|
|
34
|
+
| **Shards** | 8 | Context shards for each phase: `phase-0-discovery`, `phase-1-explore`, `phase-2-research`, `phase-25-cjm`, `phase-3-solve`, `phase-4-architecture`, `phase-5-presentation`, `bto-evaluation` |
|
|
34
35
|
| **Agent Templates** | 5 | `discovery-worker`, `research-worker`, `cjm-variant-worker`, `presentation-worker`, `parallel-research-orchestrator` |
|
|
35
|
-
| **Hooks** | 3 | PreToolUse validation, PostToolUse notifications, audit logging |
|
|
36
36
|
| **Library** | 4 | `phase-utils`, `agent-patterns`, `skill-loader`, `domain-templates` |
|
|
37
|
-
| **Documentation** |
|
|
37
|
+
| **Documentation** | 12 | Deployment, admin, user guide, infrastructure, architecture, flows (for Keysarium and BTO) |
|
|
38
38
|
|
|
39
39
|
Everything is installed into your project's `.claude/` directory and works natively with Claude Code.
|
|
40
40
|
|
|
@@ -266,6 +266,22 @@ After completing research, extract reusable patterns:
|
|
|
266
266
|
|
|
267
267
|
The harvester reviews completed projects, identifies universal patterns, decontextualizes them, and updates `TOOLKIT_HARVEST.md`.
|
|
268
268
|
|
|
269
|
+
### Brain Portability
|
|
270
|
+
|
|
271
|
+
Export and import accumulated knowledge between projects:
|
|
272
|
+
|
|
273
|
+
```bash
|
|
274
|
+
# Export knowledge as a portable JSON container
|
|
275
|
+
/brain-export
|
|
276
|
+
|
|
277
|
+
# Import a brain container into another project
|
|
278
|
+
/brain-import path/to/brain.json
|
|
279
|
+
```
|
|
280
|
+
|
|
281
|
+
### Context Shards
|
|
282
|
+
|
|
283
|
+
Shards (`.claude/shards/`) are lightweight context fragments that phases load on demand. They keep the main CLAUDE.md lean while providing phase-specific instructions, semantic completion promises, and quality checklists.
|
|
284
|
+
|
|
269
285
|
---
|
|
270
286
|
|
|
271
287
|
## Requirements
|
package/package.json
CHANGED
package/src/utils.js
CHANGED
|
@@ -218,13 +218,14 @@ function getTemplatesDir() {
|
|
|
218
218
|
// ===========================================================================
|
|
219
219
|
|
|
220
220
|
const COMPONENTS = {
|
|
221
|
-
skills: { src: '.claude/skills', label: 'Skills (6 skill packs)',
|
|
222
|
-
commands: { src: '.claude/commands', label: 'Commands (
|
|
223
|
-
rules: { src: '.claude/rules', label: 'Rules (
|
|
221
|
+
skills: { src: '.claude/skills', label: 'Skills (6 skill packs)', group: 'core' },
|
|
222
|
+
commands: { src: '.claude/commands', label: 'Commands (13 slash commands)', group: 'core' },
|
|
223
|
+
rules: { src: '.claude/rules', label: 'Rules (10 auto-loaded rules)', group: 'core' },
|
|
224
|
+
shards: { src: '.claude/shards', label: 'Shards (7 context shards)', group: 'core' },
|
|
224
225
|
agents: { src: '.claude/agents', label: 'Agent templates (5 swarm configs)', group: 'core' },
|
|
225
226
|
hooks: { src: '.claude/settings.json', label: 'Hooks configuration', group: 'core', isFile: true },
|
|
226
227
|
lib: { src: 'lib', label: 'Library modules (4 modules)', group: 'extended' },
|
|
227
|
-
docs: { src: 'docs', label: 'Documentation (
|
|
228
|
+
docs: { src: 'docs', label: 'Documentation (12 guides)', group: 'docs' },
|
|
228
229
|
claude_md: { src: 'CLAUDE.md', label: 'Master instructions', group: 'core', isFile: true },
|
|
229
230
|
harvest: { src: 'TOOLKIT_HARVEST.md', label: 'Knowledge harvest tracker', group: 'core', isFile: true },
|
|
230
231
|
};
|
|
@@ -0,0 +1,121 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "Export accumulated knowledge as a portable brain container (JSON)"
|
|
3
|
+
argument: "optional path to specific research directory, or 'all' for everything"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Brain Export — Portable Knowledge Container
|
|
7
|
+
|
|
8
|
+
Export accumulated knowledge, patterns, and evaluations into a portable JSON container
|
|
9
|
+
that can be imported into other projects.
|
|
10
|
+
|
|
11
|
+
## Protocol
|
|
12
|
+
|
|
13
|
+
### Step 1: Scan Knowledge Sources
|
|
14
|
+
|
|
15
|
+
Scan the following sources for exportable knowledge:
|
|
16
|
+
1. `TOOLKIT_HARVEST.md` — harvested patterns and learnings
|
|
17
|
+
2. `researches/*/` — all completed research directories
|
|
18
|
+
3. `.claude/skills/*/SKILL.md` — skill metadata and trust tiers
|
|
19
|
+
4. BTO evaluation reports (if any exist in researches)
|
|
20
|
+
|
|
21
|
+
If `$ARGUMENTS` specifies a path, export only from that directory.
|
|
22
|
+
If `$ARGUMENTS` is "all" or empty, export from all sources.
|
|
23
|
+
|
|
24
|
+
### Step 2: Build Brain Container
|
|
25
|
+
|
|
26
|
+
Construct a JSON structure:
|
|
27
|
+
|
|
28
|
+
```json
|
|
29
|
+
{
|
|
30
|
+
"version": "1.0",
|
|
31
|
+
"format": "keysarium-brain",
|
|
32
|
+
"exported_at": "[ISO 8601 timestamp]",
|
|
33
|
+
"source_project": "product-keysarium-2026",
|
|
34
|
+
"source_branch": "[current git branch]",
|
|
35
|
+
|
|
36
|
+
"skills": {
|
|
37
|
+
"[skill-name]": {
|
|
38
|
+
"trust_tier": 0-3,
|
|
39
|
+
"trust_tier_label": "Advisory|Structured|Validated|Verified",
|
|
40
|
+
"bto_score": null or float,
|
|
41
|
+
"last_evaluated": null or ISO date
|
|
42
|
+
}
|
|
43
|
+
},
|
|
44
|
+
|
|
45
|
+
"domain_patterns": {
|
|
46
|
+
"[domain]": {
|
|
47
|
+
"rules_applied": ["list of domain rules"],
|
|
48
|
+
"common_pitfalls": ["list"],
|
|
49
|
+
"successful_strategies": ["list"]
|
|
50
|
+
}
|
|
51
|
+
},
|
|
52
|
+
|
|
53
|
+
"research_summaries": [
|
|
54
|
+
{
|
|
55
|
+
"slug": "[case-slug]",
|
|
56
|
+
"domain": "[detected domain]",
|
|
57
|
+
"phases_completed": ["list of completed phases"],
|
|
58
|
+
"key_findings": ["top 3-5 findings"],
|
|
59
|
+
"chosen_cjm_variant": "A|B|C|D or null",
|
|
60
|
+
"presentation_score": null or float
|
|
61
|
+
}
|
|
62
|
+
],
|
|
63
|
+
|
|
64
|
+
"harvest_patterns": [
|
|
65
|
+
{
|
|
66
|
+
"category": "skills|commands|rules|templates|patterns|snippets",
|
|
67
|
+
"name": "[pattern name]",
|
|
68
|
+
"description": "[what it does]",
|
|
69
|
+
"maturity": "beta|stable",
|
|
70
|
+
"used_in": ["project list"],
|
|
71
|
+
"content_hash": "[SHA-256 of content]"
|
|
72
|
+
}
|
|
73
|
+
],
|
|
74
|
+
|
|
75
|
+
"pipeline_metrics": {
|
|
76
|
+
"total_cases_processed": 0,
|
|
77
|
+
"avg_phase_times": {},
|
|
78
|
+
"most_common_domain": null,
|
|
79
|
+
"bto_evaluations_run": 0
|
|
80
|
+
},
|
|
81
|
+
|
|
82
|
+
"metadata": {
|
|
83
|
+
"export_scope": "all|[specific path]",
|
|
84
|
+
"files_scanned": 0,
|
|
85
|
+
"patterns_extracted": 0
|
|
86
|
+
}
|
|
87
|
+
}
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
### Step 3: Write Export File
|
|
91
|
+
|
|
92
|
+
Write the JSON to: `keysarium-brain-[YYYY-MM-DD].json` in the project root.
|
|
93
|
+
|
|
94
|
+
### Step 4: Generate Summary
|
|
95
|
+
|
|
96
|
+
Display:
|
|
97
|
+
```
|
|
98
|
+
═══════════════════════════════════════════════════════
|
|
99
|
+
Brain Export Complete
|
|
100
|
+
|
|
101
|
+
File: keysarium-brain-[date].json
|
|
102
|
+
Size: [file size]
|
|
103
|
+
Skills exported: [N] (tiers: [breakdown])
|
|
104
|
+
Research summaries: [N]
|
|
105
|
+
Harvest patterns: [N]
|
|
106
|
+
Domain patterns: [N domains]
|
|
107
|
+
|
|
108
|
+
Import into another project:
|
|
109
|
+
/brain-import keysarium-brain-[date].json
|
|
110
|
+
|
|
111
|
+
• "ок" — done
|
|
112
|
+
• "покажи [section]" — preview section
|
|
113
|
+
═══════════════════════════════════════════════════════
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
## Modular Reuse
|
|
117
|
+
|
|
118
|
+
This export format is project-agnostic. Any multi-phase pipeline can:
|
|
119
|
+
1. Define its own brain schema extending the base format
|
|
120
|
+
2. Export domain-specific patterns
|
|
121
|
+
3. Import patterns from other pipelines
|
|
@@ -0,0 +1,115 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "Import a portable brain container into the current project"
|
|
3
|
+
argument: "path to brain JSON file"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Brain Import — Load External Knowledge
|
|
7
|
+
|
|
8
|
+
Import a previously exported brain container to bootstrap knowledge in a new project.
|
|
9
|
+
|
|
10
|
+
## Protocol
|
|
11
|
+
|
|
12
|
+
### Step 1: Validate Brain File
|
|
13
|
+
|
|
14
|
+
1. Read the JSON file from `$ARGUMENTS`
|
|
15
|
+
2. Validate format:
|
|
16
|
+
- `version` field exists and is "1.0"
|
|
17
|
+
- `format` field is "keysarium-brain"
|
|
18
|
+
- Required sections present: `skills`, `harvest_patterns`, `metadata`
|
|
19
|
+
3. If validation fails → show error and stop
|
|
20
|
+
|
|
21
|
+
### Step 2: Selective Import
|
|
22
|
+
|
|
23
|
+
Ask user what to import:
|
|
24
|
+
|
|
25
|
+
```
|
|
26
|
+
Brain file: [filename]
|
|
27
|
+
Source project: [source_project]
|
|
28
|
+
Exported: [exported_at]
|
|
29
|
+
|
|
30
|
+
Available sections:
|
|
31
|
+
[1] Skills metadata ([N] skills) — trust tiers and BTO scores
|
|
32
|
+
[2] Domain patterns ([N] domains) — rules, pitfalls, strategies
|
|
33
|
+
[3] Research summaries ([N] cases) — findings and CJM choices
|
|
34
|
+
[4] Harvest patterns ([N] patterns) — reusable patterns and snippets
|
|
35
|
+
[5] Pipeline metrics — timing and performance data
|
|
36
|
+
[A] All sections
|
|
37
|
+
|
|
38
|
+
Which sections to import? (comma-separated numbers or 'A' for all)
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
### Step 3: Merge Strategy
|
|
42
|
+
|
|
43
|
+
For each imported section:
|
|
44
|
+
|
|
45
|
+
**Skills metadata:**
|
|
46
|
+
- Update trust_tier in SKILL.md files if imported tier is HIGHER than current
|
|
47
|
+
- Never downgrade a tier
|
|
48
|
+
- Log: "Skill [name]: tier [old] → [new] (from [source_project])"
|
|
49
|
+
|
|
50
|
+
**Domain patterns:**
|
|
51
|
+
- Append to existing domain knowledge (no overwrite)
|
|
52
|
+
- Deduplicate by pattern name
|
|
53
|
+
- Mark imported patterns with source: `[imported from: source_project, date]`
|
|
54
|
+
|
|
55
|
+
**Research summaries:**
|
|
56
|
+
- Store in `TOOLKIT_HARVEST.md` under "## Imported Research Summaries"
|
|
57
|
+
- Read-only reference (don't create research directories)
|
|
58
|
+
|
|
59
|
+
**Harvest patterns:**
|
|
60
|
+
- Merge into `TOOLKIT_HARVEST.md`
|
|
61
|
+
- Deduplicate by content_hash
|
|
62
|
+
- Preserve maturity level from source
|
|
63
|
+
|
|
64
|
+
**Pipeline metrics:**
|
|
65
|
+
- Store as reference baseline
|
|
66
|
+
- Don't overwrite current project metrics
|
|
67
|
+
|
|
68
|
+
### Step 4: Write Import Log
|
|
69
|
+
|
|
70
|
+
Create `brain-import-log-[YYYY-MM-DD].md` in project root:
|
|
71
|
+
|
|
72
|
+
```markdown
|
|
73
|
+
# Brain Import Log
|
|
74
|
+
|
|
75
|
+
- Source: [filename]
|
|
76
|
+
- Source project: [source_project]
|
|
77
|
+
- Imported at: [timestamp]
|
|
78
|
+
- Sections imported: [list]
|
|
79
|
+
|
|
80
|
+
## Changes Made
|
|
81
|
+
- [list of all changes with before/after]
|
|
82
|
+
|
|
83
|
+
## Conflicts Resolved
|
|
84
|
+
- [any deduplication or merge decisions]
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
### Step 5: Summary
|
|
88
|
+
|
|
89
|
+
```
|
|
90
|
+
═══════════════════════════════════════════════════════
|
|
91
|
+
Brain Import Complete
|
|
92
|
+
|
|
93
|
+
Source: [filename]
|
|
94
|
+
Sections imported: [list]
|
|
95
|
+
Skills updated: [N]
|
|
96
|
+
Patterns merged: [N]
|
|
97
|
+
Conflicts resolved: [N]
|
|
98
|
+
|
|
99
|
+
Import log: brain-import-log-[date].md
|
|
100
|
+
|
|
101
|
+
• "ок" — done
|
|
102
|
+
• "покажи лог" — show full import log
|
|
103
|
+
═══════════════════════════════════════════════════════
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
## Modular Reuse
|
|
107
|
+
|
|
108
|
+
The import protocol handles:
|
|
109
|
+
- Version compatibility checking
|
|
110
|
+
- Selective import (user chooses sections)
|
|
111
|
+
- Merge-not-overwrite strategy
|
|
112
|
+
- Conflict resolution with logging
|
|
113
|
+
- Audit trail via import log
|
|
114
|
+
|
|
115
|
+
These patterns work for any knowledge transfer between projects.
|
|
@@ -7,14 +7,60 @@ Display a checkpoint banner and WAIT for user confirmation before proceeding.
|
|
|
7
7
|
```
|
|
8
8
|
═══════════════════════════════════════════════════════
|
|
9
9
|
⏸️ CHECKPOINT N: [Phase Name] Complete
|
|
10
|
+
<promise>[PROMISE_TAG]</promise>
|
|
11
|
+
|
|
12
|
+
[2-3 line summary of what was done]
|
|
13
|
+
Files created: [list] ✅
|
|
14
|
+
|
|
15
|
+
• "ок" — next phase
|
|
16
|
+
• "углуби [section]" — elaborate
|
|
17
|
+
• "[specific feedback]" — adjust
|
|
18
|
+
═══════════════════════════════════════════════════════
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
## Semantic Completion Promises
|
|
22
|
+
|
|
23
|
+
Each checkpoint MUST include the relevant promise tag to signal phase completion status.
|
|
24
|
+
Promises are machine-readable markers that formalize phase gates.
|
|
25
|
+
|
|
26
|
+
### Promise Tags by Phase
|
|
27
|
+
|
|
28
|
+
| Phase | Promise Tag | Meaning |
|
|
29
|
+
|-------|------------|---------|
|
|
30
|
+
| Phase 0 | `<promise>DISCOVERY_COMPLETE</promise>` | JTBD + competitors + ROI analyzed |
|
|
31
|
+
| Phase 1 | `<promise>CASE_EXPLORED</promise>` | Case fully understood, brief created |
|
|
32
|
+
| Phase 2 | `<promise>RESEARCH_PARANOID_PASSED</promise>` | All claims verified, zero unverified |
|
|
33
|
+
| Phase 2.5 | `<promise>CJM_VALIDATED</promise>` | CJM prototype created and variant chosen |
|
|
34
|
+
| Phase 3 | `<promise>SOLUTION_DESIGNED</promise>` | Solution strategy formulated |
|
|
35
|
+
| Phase 4 | `<promise>ARCHITECTURE_DEFINED</promise>` | C4 diagrams + sequence flows ready |
|
|
36
|
+
| Phase 5 | `<promise>PRESENTATION_READY</promise>` | All 4 artifacts (05-08) created |
|
|
37
|
+
| BTO L0 | `<promise>BTO_LAYER0_PASSED</promise>` | Deterministic checks passed |
|
|
38
|
+
| BTO L2 | `<promise>BTO_LAYER2_SCORED</promise>` | Panel of 3 judges scored artifact |
|
|
39
|
+
| BTO Opt | `<promise>BTO_OPTIMIZED</promise>` | Optimization converged |
|
|
40
|
+
|
|
41
|
+
### Enhanced Checkpoint Format
|
|
42
|
+
|
|
43
|
+
```
|
|
44
|
+
═══════════════════════════════════════════════════════
|
|
45
|
+
⏸️ CHECKPOINT N: [Phase Name] Complete
|
|
46
|
+
<promise>[PROMISE_TAG]</promise>
|
|
47
|
+
|
|
10
48
|
[2-3 line summary of what was done]
|
|
11
49
|
Files created: [list] ✅
|
|
50
|
+
|
|
12
51
|
• "ок" — next phase
|
|
13
52
|
• "углуби [section]" — elaborate
|
|
14
53
|
• "[specific feedback]" — adjust
|
|
15
54
|
═══════════════════════════════════════════════════════
|
|
16
55
|
```
|
|
17
56
|
|
|
57
|
+
### Promise Validation Rules
|
|
58
|
+
|
|
59
|
+
- A promise tag MUST only be emitted AFTER its conditions are verifiably met
|
|
60
|
+
- If conditions are NOT met, emit `<promise>[TAG]_INCOMPLETE</promise>` instead
|
|
61
|
+
- Downstream phases SHOULD check for upstream promises before starting
|
|
62
|
+
- Promise tags serve as formal phase gates — they replace informal "phase done" signals
|
|
63
|
+
|
|
18
64
|
## Rules
|
|
19
65
|
- NEVER skip checkpoints
|
|
20
66
|
- NEVER auto-advance to the next phase without user confirmation
|
|
@@ -0,0 +1,113 @@
|
|
|
1
|
+
# Cross-Phase Feedback Loops
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Formalize how data flows between phases in the Keysarium pipeline.
|
|
6
|
+
Each loop has a name, direction, data payload, and namespace for persistence.
|
|
7
|
+
|
|
8
|
+
## Named Feedback Loops
|
|
9
|
+
|
|
10
|
+
### Loop 1: CJM → Solve (Critical)
|
|
11
|
+
|
|
12
|
+
| Property | Value |
|
|
13
|
+
|----------|-------|
|
|
14
|
+
| Direction | Phase 2.5 → Phase 3 |
|
|
15
|
+
| Variable | `{CHOSEN_CJM}` |
|
|
16
|
+
| Payload | Selected CJM variant (A/B/C/D), pain points, conversion metrics |
|
|
17
|
+
| Consumers | Phase 3 (User Flow), Phase 5 (Slide 5) |
|
|
18
|
+
| Persistence | `researches/<slug>/.feedback/cjm-selection.json` |
|
|
19
|
+
|
|
20
|
+
**Contract:** Phase 3 MUST NOT start without `{CHOSEN_CJM}` being set.
|
|
21
|
+
|
|
22
|
+
### Loop 2: Research → Presentation
|
|
23
|
+
|
|
24
|
+
| Property | Value |
|
|
25
|
+
|----------|-------|
|
|
26
|
+
| Direction | Phase 2 → Phase 5 |
|
|
27
|
+
| Payload | Key findings, verified sources, statistics |
|
|
28
|
+
| Source file | `02_research_findings.md` |
|
|
29
|
+
| Consumers | Phase 5 (all slides referencing data) |
|
|
30
|
+
| Usage | Presentation claims must trace back to research findings |
|
|
31
|
+
|
|
32
|
+
**Contract:** Every data claim in presentation must have a source in `02_research_findings.md`.
|
|
33
|
+
|
|
34
|
+
### Loop 3: Discovery → All Phases (Context)
|
|
35
|
+
|
|
36
|
+
| Property | Value |
|
|
37
|
+
|----------|-------|
|
|
38
|
+
| Direction | Phase 0 → Phases 1-5 |
|
|
39
|
+
| Payload | Domain detection, JTBD segments, competitive landscape, business case |
|
|
40
|
+
| Source file | `00_product_discovery.md` |
|
|
41
|
+
| Key fields | `{DOMAIN}`, `{PRIMARY_USER}`, `{AHA_MOMENT}` |
|
|
42
|
+
|
|
43
|
+
**Contract:** Domain-specific rules activate based on Phase 0 detection.
|
|
44
|
+
|
|
45
|
+
### Loop 4: Solve → Architecture
|
|
46
|
+
|
|
47
|
+
| Property | Value |
|
|
48
|
+
|----------|-------|
|
|
49
|
+
| Direction | Phase 3 → Phase 4 |
|
|
50
|
+
| Payload | Chosen solution strategy, AI pipeline spec, HITL design, MVP scope |
|
|
51
|
+
| Source file | `03_solution_strategy.md` |
|
|
52
|
+
| Key fields | `{SOLUTION_CONCEPT}`, `{AI_PIPELINE}`, `{HITL_POLICY}` |
|
|
53
|
+
|
|
54
|
+
**Contract:** Architecture must implement the solution designed in Phase 3.
|
|
55
|
+
|
|
56
|
+
### Loop 5: BTO Judges → Optimizer
|
|
57
|
+
|
|
58
|
+
| Property | Value |
|
|
59
|
+
|----------|-------|
|
|
60
|
+
| Direction | BTO Layer 2 → BTO Optimize |
|
|
61
|
+
| Payload | Per-dimension scores, judge feedback, weak dimensions |
|
|
62
|
+
| Source | Layer 2 evaluation reports |
|
|
63
|
+
| Key fields | `{BASELINE_SCORE}`, `{WEAK_DIMENSIONS}`, `{JUDGE_FEEDBACK}` |
|
|
64
|
+
|
|
65
|
+
**Contract:** Optimizer mutations target weak dimensions identified by judges.
|
|
66
|
+
|
|
67
|
+
### Loop 6: History → Discovery (Cross-Case)
|
|
68
|
+
|
|
69
|
+
| Property | Value |
|
|
70
|
+
|----------|-------|
|
|
71
|
+
| Direction | Past cases → Phase 0 of new case |
|
|
72
|
+
| Payload | Domain patterns, common pitfalls, successful strategies |
|
|
73
|
+
| Source | `TOOLKIT_HARVEST.md`, brain export files |
|
|
74
|
+
| Persistence | `keysarium-brain.json` |
|
|
75
|
+
|
|
76
|
+
**Contract:** If brain file exists, Phase 0 loads historical patterns before starting.
|
|
77
|
+
|
|
78
|
+
## Feedback Loop Protocol
|
|
79
|
+
|
|
80
|
+
### At Phase Start
|
|
81
|
+
1. Check upstream promises are met
|
|
82
|
+
2. Load required source files
|
|
83
|
+
3. Extract key variables from upstream outputs
|
|
84
|
+
4. Apply domain-specific rules from Loop 3
|
|
85
|
+
|
|
86
|
+
### At Phase End
|
|
87
|
+
1. Emit phase promise tag
|
|
88
|
+
2. Write key outputs for downstream consumers
|
|
89
|
+
3. Validate contract fulfillment
|
|
90
|
+
|
|
91
|
+
## Variable Registry
|
|
92
|
+
|
|
93
|
+
All cross-phase variables in one place:
|
|
94
|
+
|
|
95
|
+
| Variable | Set In | Used In | Type |
|
|
96
|
+
|----------|--------|---------|------|
|
|
97
|
+
| `{DOMAIN}` | Phase 0 | All phases | string (banking/retail/enterprise/healthcare) |
|
|
98
|
+
| `{PRIMARY_USER}` | Phase 0 | Phase 2.5, 3, 5 | string |
|
|
99
|
+
| `{AHA_MOMENT}` | Phase 0 | Phase 2.5, 5 | string |
|
|
100
|
+
| `{CHOSEN_CJM}` | Phase 2.5 | Phase 3, 5 | string (A/B/C/D) |
|
|
101
|
+
| `{SOLUTION_CONCEPT}` | Phase 3 | Phase 4, 5 | string |
|
|
102
|
+
| `{AI_PIPELINE}` | Phase 3 | Phase 4 | structured |
|
|
103
|
+
| `{HITL_POLICY}` | Phase 3 | Phase 4, 5 | structured |
|
|
104
|
+
| `{BASELINE_SCORE}` | BTO L2 | BTO Optimize | float |
|
|
105
|
+
| `{WEAK_DIMENSIONS}` | BTO L2 | BTO Optimize | list[string] |
|
|
106
|
+
|
|
107
|
+
## Modular Reuse Note
|
|
108
|
+
|
|
109
|
+
This feedback loop system is domain-agnostic. The same pattern applies to any multi-phase pipeline:
|
|
110
|
+
1. Define named loops with direction and payload
|
|
111
|
+
2. Set contracts (what must exist before proceeding)
|
|
112
|
+
3. Register variables in a central registry
|
|
113
|
+
4. Validate contracts at phase boundaries
|
|
@@ -0,0 +1,65 @@
|
|
|
1
|
+
# Model Routing Enforcement
|
|
2
|
+
|
|
3
|
+
## 3-Tier Model Routing
|
|
4
|
+
|
|
5
|
+
All agent spawning MUST follow the model routing table below.
|
|
6
|
+
Using a higher-cost model than necessary wastes budget.
|
|
7
|
+
Using a lower-cost model than required degrades quality.
|
|
8
|
+
|
|
9
|
+
## Routing Table
|
|
10
|
+
|
|
11
|
+
| Tier | Model | Latency | When to Use |
|
|
12
|
+
|------|-------|---------|-------------|
|
|
13
|
+
| Tier 1 | haiku | ~500ms | File formatting, simple transforms, Layer 0 checks, Layer 1 quick eval, BTO variant fast-ranking |
|
|
14
|
+
| Tier 2 | sonnet | ~2s | Research synthesis, analysis, BTO Layer 2 judge panel, mutation workers, meta-judge escalation |
|
|
15
|
+
| Tier 3 | opus (default) | ~5s | Creative CJM design, presentation storytelling, BTO crossover synthesis, complex problem solving |
|
|
16
|
+
|
|
17
|
+
## Per-Task Assignment
|
|
18
|
+
|
|
19
|
+
### Keysarium Pipeline
|
|
20
|
+
|
|
21
|
+
| Task | Model | Rationale |
|
|
22
|
+
|------|-------|-----------|
|
|
23
|
+
| Phase 0 parallel agents (JTBD, Competitors) | sonnet | Research synthesis |
|
|
24
|
+
| Phase 1 exploration | opus | Creative clarification |
|
|
25
|
+
| Phase 2 parallel agents (Analogues, Tech, Regulations) | sonnet | Research analysis |
|
|
26
|
+
| Phase 2.5 CJM variant generation | opus | Creative design work |
|
|
27
|
+
| Phase 2.5 trend research agents | sonnet | Research synthesis |
|
|
28
|
+
| Phase 3 solution design | opus | Complex problem solving |
|
|
29
|
+
| Phase 4 architecture | opus | System design |
|
|
30
|
+
| Phase 5 presentation storytelling | opus | Creative storytelling |
|
|
31
|
+
| Phase 5 speaker script agents | sonnet | Structured generation |
|
|
32
|
+
| Phase 5 Q&A preparation | sonnet | Analytical work |
|
|
33
|
+
| File formatting, slug generation | haiku | Simple transforms |
|
|
34
|
+
|
|
35
|
+
### BTO Pipeline
|
|
36
|
+
|
|
37
|
+
| Task | Model | Rationale |
|
|
38
|
+
|------|-------|-----------|
|
|
39
|
+
| Layer 0 structural checks | haiku | Pattern matching only |
|
|
40
|
+
| Layer 1 semantic baseline | haiku | Fast coherence scan |
|
|
41
|
+
| Layer 2 Domain Expert judge | sonnet | Domain knowledge + nuanced scoring |
|
|
42
|
+
| Layer 2 Critic judge | sonnet | Adversarial analysis |
|
|
43
|
+
| Layer 2 Completeness Auditor judge | sonnet | Structured coverage check |
|
|
44
|
+
| Meta-judge (disagreement resolution) | sonnet | Arbitration |
|
|
45
|
+
| Optimization variant fast-eval (Round 1, 2) | haiku | Volume scoring |
|
|
46
|
+
| Optimization Round 3 full panel | sonnet | Final quality assessment |
|
|
47
|
+
| Optimization crossover / creative synthesis | opus | Novel combination of candidates |
|
|
48
|
+
|
|
49
|
+
## Enforcement Rules
|
|
50
|
+
|
|
51
|
+
1. **NEVER** use opus for Layer 0 or Layer 1 evaluation — this is wasteful
|
|
52
|
+
2. **NEVER** use haiku for Layer 2 judge panel — quality will be insufficient
|
|
53
|
+
3. **NEVER** use haiku for creative work (CJM design, storytelling) — output will be shallow
|
|
54
|
+
4. When spawning agents with the Agent tool, ALWAYS specify the `model` parameter
|
|
55
|
+
5. If model is not specified, the agent inherits the parent model (opus by default)
|
|
56
|
+
6. For cost optimization, prefer haiku for any task that is primarily pattern-matching or formatting
|
|
57
|
+
|
|
58
|
+
## Cost Impact
|
|
59
|
+
|
|
60
|
+
Approximate cost ratios (per 1K output tokens):
|
|
61
|
+
- haiku: 1x (baseline)
|
|
62
|
+
- sonnet: 15x
|
|
63
|
+
- opus: 75x
|
|
64
|
+
|
|
65
|
+
Using haiku instead of opus for Layer 0-1 saves ~98% on those evaluation steps.
|
|
@@ -0,0 +1,36 @@
|
|
|
1
|
+
# Trust Tier System
|
|
2
|
+
|
|
3
|
+
## Tier Definitions
|
|
4
|
+
|
|
5
|
+
| Tier | Label | Requirements | Promotion Path |
|
|
6
|
+
|------|-------|-------------|----------------|
|
|
7
|
+
| Tier 3 | Verified | Eval test suites with deterministic validation | — (highest) |
|
|
8
|
+
| Tier 2 | Validated | Passed /bto-test with Layer 2 score ≥ 7.0 | Run /bto-test, score ≥ 8.5 on Layer 2 |
|
|
9
|
+
| Tier 1 | Structured | SKILL.md + references/ or modules/ | Run /bto-test, score ≥ 7.0 on Layer 2 |
|
|
10
|
+
| Tier 0 | Advisory | Basic SKILL.md only | Add references/, examples/, structured output |
|
|
11
|
+
|
|
12
|
+
## Current Skill Tiers
|
|
13
|
+
|
|
14
|
+
| Skill | Tier | Label | Evidence |
|
|
15
|
+
|-------|------|-------|----------|
|
|
16
|
+
| explore | 1 | Structured | SKILL.md + references/ |
|
|
17
|
+
| frontend-design | 0 | Advisory | SKILL.md only, no references |
|
|
18
|
+
| goap-research-ed25519 | 1 | Structured | SKILL.md + references/ + scripts/ |
|
|
19
|
+
| problem-solver-enhanced | 1 | Structured | Comprehensive SKILL.md with TRIZ framework |
|
|
20
|
+
| presentation-storyteller | 1 | Structured | SKILL.md + references/ |
|
|
21
|
+
| reverse-engineering-unicorn | 1 | Structured | SKILL.md + modules/ + references/ + examples/ |
|
|
22
|
+
| bto | 1 | Structured | SKILL.md + modules/ + references/ + examples/ |
|
|
23
|
+
|
|
24
|
+
## Tier Enforcement
|
|
25
|
+
|
|
26
|
+
- Tier 0 skills: Flag with warning when loaded in production pipeline
|
|
27
|
+
- Tier 1 skills: Standard usage, recommend /bto-test for promotion
|
|
28
|
+
- Tier 2 skills: Full confidence, include BTO score in metadata
|
|
29
|
+
- Tier 3 skills: Highest confidence, deterministic validation available
|
|
30
|
+
|
|
31
|
+
## Promotion Protocol
|
|
32
|
+
|
|
33
|
+
1. Run `/bto-test .claude/skills/<name>/`
|
|
34
|
+
2. If Layer 2 score ≥ 7.0 → promote to Tier 2, record score in SKILL.md
|
|
35
|
+
3. If Layer 2 score ≥ 8.5 + deterministic eval tests exist → promote to Tier 3
|
|
36
|
+
4. Record promotion date and score in SKILL.md frontmatter
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# Phase 0: Discovery — Governance Shard
|
|
2
|
+
|
|
3
|
+
## Time Budget
|
|
4
|
+
15% of total timeline
|
|
5
|
+
|
|
6
|
+
## Skill
|
|
7
|
+
Load: `.claude/skills/reverse-engineering-unicorn/SKILL.md` (modules M2-M5)
|
|
8
|
+
|
|
9
|
+
## Mandatory Outputs
|
|
10
|
+
- `00_product_discovery.md`
|
|
11
|
+
|
|
12
|
+
## Content Requirements
|
|
13
|
+
- As-Is process mapping
|
|
14
|
+
- JTBD segments (minimum 3)
|
|
15
|
+
- Voice of Customer synthesis
|
|
16
|
+
- Aha Moment identification
|
|
17
|
+
- Why AI / Why Now justification
|
|
18
|
+
- Competitive landscape (minimum 3 competitors)
|
|
19
|
+
- Business Case with ROI projections
|
|
20
|
+
- Adoption Strategy
|
|
21
|
+
|
|
22
|
+
## Agent Swarm
|
|
23
|
+
- Agent 1 (sonnet): JTBD + Voice of Customer + Aha Moment
|
|
24
|
+
- Agent 2 (sonnet): Competitor Analysis + Business Case + Why AI Why Now
|
|
25
|
+
- Synthesize results into single document
|
|
26
|
+
|
|
27
|
+
## Domain Detection
|
|
28
|
+
Detect domain from case description and apply domain-specific rules:
|
|
29
|
+
- Banking: on-premise LLM, ФЗ-152, ЦБ, ФСТЭК
|
|
30
|
+
- Retail: latency < 200ms, A/B testing
|
|
31
|
+
- Enterprise: Change Management, Legacy integration
|
|
32
|
+
- Healthcare: HITL mandatory, ФЗ-323
|
|
33
|
+
|
|
34
|
+
## Quality Gates
|
|
35
|
+
- Zero unverified competitor names
|
|
36
|
+
- ROI must include concrete numbers (FTE/hours/currency)
|
|
37
|
+
- JTBD format: "When [situation], I want to [motivation], so I can [outcome]"
|
|
38
|
+
|
|
39
|
+
## Promise
|
|
40
|
+
On completion: `<promise>DISCOVERY_COMPLETE</promise>`
|
|
41
|
+
|
|
42
|
+
## Anti-Patterns to Check
|
|
43
|
+
- "Just add GPT" without specific model/pipeline → BLOCK
|
|
44
|
+
- No metrics/KPIs → BLOCK
|
|
45
|
+
- Vague claims without numbers → FLAG
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
# Phase 1: Explore — Governance Shard
|
|
2
|
+
|
|
3
|
+
## Time Budget
|
|
4
|
+
5% of total timeline
|
|
5
|
+
|
|
6
|
+
## Skill
|
|
7
|
+
Load: `.claude/skills/explore/SKILL.md`
|
|
8
|
+
|
|
9
|
+
## Prerequisites
|
|
10
|
+
- Phase 0 complete: `<promise>DISCOVERY_COMPLETE</promise>`
|
|
11
|
+
- File exists: `00_product_discovery.md`
|
|
12
|
+
|
|
13
|
+
## Mandatory Outputs
|
|
14
|
+
- `01_case_brief.md`
|
|
15
|
+
|
|
16
|
+
## Content Requirements
|
|
17
|
+
- 5 Whys root cause analysis
|
|
18
|
+
- Data landscape analysis
|
|
19
|
+
- Constraints Map: hard / soft / hidden
|
|
20
|
+
- Success Criteria (measurable)
|
|
21
|
+
- Key Question (single, focused)
|
|
22
|
+
|
|
23
|
+
## Model Routing
|
|
24
|
+
- Default model (opus) for creative clarification
|
|
25
|
+
|
|
26
|
+
## Quality Gates
|
|
27
|
+
- Constraints must be categorized (hard/soft/hidden)
|
|
28
|
+
- Success criteria must be quantifiable
|
|
29
|
+
- Key Question must be single and actionable
|
|
30
|
+
|
|
31
|
+
## Promise
|
|
32
|
+
On completion: `<promise>CASE_EXPLORED</promise>`
|