Braynee Restucture

[hamchowderr]

I want to think about rebuilding braynee and pulling somethings out and updating them

[samskara-factory]

Type	maintenance — an aspirational restructure/rebuild proposal from the repo owner, not a defect report
Route	Await approval
Severity	🟢 low — no bug or broken behavior; a planning/scoping placeholder
Confidence	high — the one-line body ("rebuilding braynee and pulling somethings out and updating them") is unambiguous in intent, undefined in scope
Effort	high — any real rebuild touches the whole plugin surface: 37 hooks across 15 events, 25 skills, 9 agents, 24 scripts, plus the mastracode/ TS subproject
Impact	low — no current user pain identified; benefit is speculative until the author defines what gets extracted and why
Next step	Author/maintainer should scope the restructure — enumerate which components to pull out, what "updating" means, and the target architecture — before any planning

Understanding

• What this is: hamchowderr (repo owner, 49 merged PRs — core contributor) filed a placeholder to "think about" rebuilding Braynee and extracting/updating parts of it. There is no bug, no reproduction, no acceptance criteria.
• Current shape of the repo (282 tracked files, ~39k LOC in js/py/md):
  • hooks/ — 37 hooks across 15 Claude Code events (largest and most coupled surface; several have colocated tests)
  • skills/ — 25 skills (board, beads/prd tooling, obsidian tooling, sessions, setup, etc.)
  • agents/ — 9 agent definitions
  • scripts/ — 24 support scripts; monitors/, formulas/, commands/
  • mastracode/ — an already-separate TypeScript subproject with its own package.json/tsconfig, the most natural first extraction candidate
• Recent history: active development (14 commits in the last 30 days), heavily concentrated on the beads/board subsystem (feat(beads), feat(board), fix(prd-seed) …). The beads tooling (hooks + skills + agents beads-auditor/beads-enricher) is a second coherent cluster that could plausibly be "pulled out."
• Prior work: no related issues or PRs mention restructuring; Braynee Restucture #52 is the only match. Not a duplicate, not a regression.
• Suggested direction if approved: treat this as a scoping exercise first — inventory the coupling between hooks/skills/scripts, then decide extraction boundaries (e.g. mastracode/ → own repo/package; beads subsystem → optional module). No code should change until the owner writes down the target state.

Assumptions

• Interpreted "pulling somethings out" as extracting subsystems (likely mastracode/ and/or the beads cluster) rather than deleting features — based on repo structure and recent commit focus.
• Classified as maintenance rather than feature request: the body describes restructuring/updating existing code, not new capability.
• Treated the issue as intentionally open-ended ("I want to think about…"), so no reproduction or code-level root cause applies.

Open questions

• Which components does the owner actually want extracted, and into what form (separate repo, separate plugin, npm package)?
• What does "updating them" mean — dependency bumps, API modernization (e.g. newer Claude Code hook features), or rewrites?
• Is there a driving pain point (install size, hook latency, maintenance burden) that should shape the restructure's priorities?

Reproduction

Not applicable — no defect to reproduce.