wankimmy/bossku-ai/bosskuai-continuous-learning

BosskuAI Continuous Learning

Configured memory location

Run bossku memory-path --project <project-root> to resolve <memory-dir> before reading or writing memory. Automatically save verified durable notes with bossku remember without waiting for the user to ask. When memory_storage is obsidian, all memory including handoffs lives directly in the vault; never create .bossku/memory in a code repo. The configured storage overrides legacy export wording below.

Use this skill when recent work produced a lesson worth keeping beyond the current chat.

How this differs from nearby skills

• `bosskuai-permanent-memory-orchestration`: the mechanics of <memory-dir>/, bossku remember, and the Obsidian export; this skill decides what deserves to go there.
• `bosskuai-rules-distill`: promotes principles seen in 3+ places into rules; this skill handles a single fresh lesson.
• `bosskuai-skill-creator`: builds or revises a skill once this skill decides a skill is the right artifact.

Meaningfulness gate

• Meaningful if any of these are true: files changed, a decision was made, a bug/risk was found, a pattern repeated, or a workflow improvement emerged.
• Trivial if all are false. In that case, stop after noting there was no durable delta.

Routing ladder (smallest artifact that changes future behavior)

bossku remember redacts secrets and exports the four kind files to the Obsidian vault when one is configured, so a memory write is also the Obsidian sync.

Workflow

1. Gather evidence from the finished task, diff, tests, review findings, and memory state.
2. Write each candidate learning in one sentence.
3. Choose the smallest artifact from the ladder that will reliably change future behavior.
4. Write it: bossku remember --project . --kind <kind> "<one to three lines>" for memory kinds; edit the file directly for references.
5. Fix stale or contradictory memory if discovered (append a dated correction).
6. Record whether the learning was applied, deferred, or rejected, and what evidence would justify promotion later.

Guardrails

• Do not promote vague advice.
• Do not store secrets, sensitive customer data, or transient debug chatter in memory.
• Do not create a new skill when a checklist, pitfall, or short memory note is enough.
• Do not turn one-off observations into universal rules.
• Do not write the same lesson into two artifacts; the weaker one should point at the stronger.

Output

Return:

• signals reviewed
• candidate learnings
• chosen artifact for each learning
• smallest safe update (and the bossku remember result, including export status)
• freshness issues found
• next promotion actions

References

• ../../references/memory-first-handoff-protocol.md
• ../../references/checklists/learning-promotion-checklist.md
• ../../references/checklists/continuous-learning-checklist.md
• ../../references/playbooks/continuous-learning-playbook.md
• ../../docs/memory.md

Writing the lesson well

• Record the pattern, not the event. Title names the pattern ("browser default change breaks cross-origin auth"), not "fixed login bug". Failures teach more than clean wins; skip typo-level changes with no debugging, rework, rollback, or non-obvious decision.
• Extract it in five steps: say what happened in one sentence; ask "why" until you hit the root cause (usually 3-5 times); generalize to a class of problem; write "Next time I see [signal], I will [action]"; name the observable signal. No "next time" sentence means no lesson yet.
• Search before writing. Same root cause with a new symptom: add the symptom as an example to the existing note (merge). New root cause: new note.
• Shape: 4-8 sentences, covering context, root cause (not symptom), the transferable action plus signal, and related notes. Under 30 seconds of writing is too shallow; over 2 minutes means you are narrating.
• Scope check: language/framework conventions, file layout, and code style stay project-specific; security habits, tool workflow habits, and git practices can be global. Promote a project lesson to global only when it showed up in 2+ projects with good evidence.
• Confidence: tentative lessons are suggestions; raise them when seen again without correction, and lower or retire them when the user corrects them, they stop appearing, or contrary evidence shows up. Never export raw transcripts, only the distilled lesson.

Adapted in part from ECC skills/growth-log and skills/continuous-learning-v2 (affaan-m/ECC, MIT).