Skip to content

docs(spec): SKILL brain structure — mode-based vs connector-based (direction proposal)#156

Open
jordanrburger wants to merge 1 commit into
mainfrom
upstream/skill-structure-proposal
Open

docs(spec): SKILL brain structure — mode-based vs connector-based (direction proposal)#156
jordanrburger wants to merge 1 commit into
mainfrom
upstream/skill-structure-proposal

Conversation

@jordanrburger

Copy link
Copy Markdown
Collaborator

Direction-setting proposal — for review, no decision baked in and no implementation here. This sets the long-term shape of how every Scout instance's brain is organized, so it's deliberately up for debate. Companion to #149/#150/#152.

The fork

Scout has two brains that diverged in structure: a running vault's SKILL.md is mode-based (organized by run mode), the engine is connector-based (per-connector sections + a Run Modes dispatch table). They don't match, so every /scout-update that touches the brain throws a merge conflict, and the regenerated runner references a "Run Modes table" the mode-based brain lacks. Worth settling deliberately.

What the proposal does

  1. Lays out all three structures concretely (mode-based / connector-based / hybrid).
  2. Genuinely evaluates them on six criteria, weighted toward vault↔engine convergence, self-improvement-loop fit, distributability (legibility explicitly de-prioritized — the main argument for mode-based).
  3. Recommends connector-based from that analysis — it ends the merge tax by construction and is the shape the modular self-improvement loop + the optional-connector catalog are built for. The honest cost is human legibility, flagged for you to challenge.
  4. Migration = upstream-first: finish porting the vault's ~24 Patterns + capabilities into the engine's connector phases (partly done), then the vault re-renders and adopts — convergence by construction, no risky local re-graft.
  5. Zero-loss gate: a completeness checklist (every Pattern/capability/mode-behavior present in the engine brain before adoption) + behavioral dry-run validation of all three modes.

Asking reviewers

  • Is connector-based actually right — or does de-prioritized legibility (human-graspability for trust/debugging) matter more long-term?
  • Acceptable that the migration is gated on finishing the upstream effort?
  • The validation harness (safely dry-running the three modes) needs design — thoughts?

Spec: docs/superpowers/specs/2026-06-22-skill-brain-structure-direction-design.md

🤖 Generated with Claude Code

…rection proposal)

A direction-setting proposal (for review by others, not yet decided) on whether
SKILL.md should canonically use the mode-based structure (a running vault today) or
the connector-based structure (the engine today), and the migration path either way.

Genuinely open evaluation across six criteria, weighted toward vault<->engine
convergence, self-improvement-loop fit, and distributability (legibility explicitly
de-prioritized). The analysis recommends connector-based — it ends the recurring
merge tax by construction and is the shape the modular self-improvement loop and the
optional-connector catalog are built for; the honest cost is human legibility, flagged
for reviewers to challenge. Migration strategy is upstream-first (finish porting the
vault's ~24 Patterns + capabilities into the engine's connector phases, then the vault
re-renders and adopts — no risky local re-graft), gated by a completeness checklist +
behavioral dry-run validation so nothing is lost.

Out of scope: implementation (the remaining upstream PRs + the Phase-2 adoption/validation
harness) follows once the direction is agreed. Companion to specs #149/#150/#152.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant