CodyMaster Shared Helpers

DRY principle for skills. Reference sections here instead of embedding in every skill. Usage: Per helpers.md#Section-Name — reduces ~150-200 tokens per skill.

---

#Load-Working-Memory

Before executing any significant action, ALWAYS load context in this order (cheapest → richest):

Step 1 — Check context bus (free, ~50 tokens)

Read .cm/context-bus.json (or: cm continuity bus)
→ If active pipeline found:
    - Note current_step and pipeline name
    - Read shared_context to see what upstream skills already produced
    - SKIP re-doing any work already recorded in shared_context
→ If no bus: fresh session, proceed normally

Step 2 — Load L0 indexes first (~600 tokens total)

Read .cm/learnings-index.md   (~100 tokens) — IDs + 1-line summaries
Read .cm/skeleton-index.md    (~500 tokens) — modules, entry points, config files

→ If a specific learning ID looks relevant → resolve cm://memory/learnings/{id} for full detail
→ If a specific module looks relevant   → resolve cm://resources/skeleton at L2 for full detail
→ Otherwise: L0 is sufficient — DO NOT load full files

Step 3 — Scope-filter learnings (only if L0 flags relevant entries)

# SQLite backend (default):
Query: cm_query(scope="learnings", query="{current module or error type}", limit=5)
   OR read .cm/memory/learnings.json filtered to scope == "global" | "module:X"

Rules:
  NEVER  load status = "invalidated"   (proven wrong)
  CAUTION status = "corrected"         (verify before applying)
  TRUST  high reinforceCount + recent lastRelevant
  SKIP   learnings for other modules (noise + wasted tokens)

Step 4 — Check working memory

Read .cm/CONTINUITY.md → Active Goal, Next Actions, current phase
Run Memory Audit (decay + conflict detection) — see cm-continuity

Step 5 — Token budget check (before injecting large context)

cm continuity budget  (or: loadBudget + checkBudget in code)
→ If category is over soft limit → use L0/L1 depth instead of L2
→ Never inject full skeleton (20KB) when skeleton-index.md (~2KB) suffices

Token savings v5: Full cold load ~3,200 tokens → Smart Spine load ~700 tokens (78% reduction). L0 indexes + context bus + scope filter make this possible. Only escalate to L2 when L0/L1 explicitly flag the need.

Legacy note: Some older projects may still keep storage.backend: viking in config. CodyMaster now routes that back to SQLite, so do not design workflows around a separate Viking backend.

---

#Save-Decision

After making any significant architectural or product decision:

1. Write to .cm/memory/decisions.json:
   • id: Auto-increment (D001, D002, ...)
   • decision: What was decided
   • rationale: Why this option won over alternatives
   • scope: module:{name} or global
   • status: active
   • date: ISO date
2. Check for conflicts with existing decisions in same scope
   • If conflict → set older decision supersededBy = new ID, status = superseded

---

#Update-Continuity

At the end of every work session or task completion:

1. Update .cm/CONTINUITY.md:
   • Move completed work to "Just Completed"
   • Update "Next Actions" with remaining items
   • Update "Files Currently Being Modified"
   • Set currentPhase and timestamp
2. Record any new learnings in .cm/memory/learnings.json
   • If similar learning exists → reinforce (reinforceCount++) instead of creating duplicate
3. Record any new decisions via #Save-Decision

---

#Identity-Check

Before any git push, deploy, or database operation:

1. Read .project-identity.json for expected accounts
2. Verify current git config matches expected GitHub org
3. Verify Cloudflare account matches expected account ID
4. If mismatch → STOP and alert user

See cm-identity-guard for full verification protocol.

---

#Project-Level-Detection

Assess task complexity to determine the right workflow depth:

┌─────────┬───────────────────────┬────────────────────────────────────────┐
│ Level   │ Criteria              │ Workflow                                │
├─────────┼───────────────────────┼────────────────────────────────────────┤
│ L0      │ < 30 min, 1-2 files   │ Code + Test only (skip planning)       │
│ Micro   │ Bug fix, tiny tweak   │ Chain: tdd → quality-gate              │
├─────────┼───────────────────────┼────────────────────────────────────────┤
│ L1      │ 1-3 tasks, 1 area     │ Planning lite → Code → Deploy          │
│ Small   │ Small feature, config │ Chain: planning → tdd → quality-gate   │
├─────────┼───────────────────────┼────────────────────────────────────────┤
│ L2      │ 4-10 tasks, multiple  │ Full flow with analysis                │
│ Medium  │ areas, UI + backend   │ Chain: brainstorm → planning → tdd →   │
│         │                       │ execution → quality-gate → safe-deploy │
├─────────┼───────────────────────┼────────────────────────────────────────┤
│ L3      │ 10+ tasks, cross-     │ Full + PRD + Architecture + Sprint     │
│ Large   │ system, team impact   │ Chain: brainstorm → planning (with     │
│         │                       │ FR/NFR) → sprint → execution → gate →  │
│         │                       │ deploy                                 │
└─────────┴───────────────────────┴────────────────────────────────────────┘

Detection heuristics:

• Count estimated tasks from objective description
• Check number of files/modules likely affected
• Check if UI + API + DB changes needed (cross-layer = L2+)
• Check if multiple team members involved (L3)

Output: State the detected level and recommended chain to the user:

📊 Project Level: L1 (Small)
🔗 Recommended chain: planning → tdd → quality-gate
⏱️ Estimated time: 1-2 hours

---

#Outputs-Convention

All skill outputs should be saved in .cm/outputs/ with this structure:

.cm/outputs/
├── brainstorms/    ← cm-brainstorm-idea output
├── plans/          ← cm-planning implementation plans
├── reviews/        ← cm-code-review output
└── deploys/        ← cm-safe-deploy logs and reports

Naming: {date}-{slug}.md (e.g., 2026-03-23-user-auth-plan.md)