cmk:learn
Learn
Intents
That was a long research session — extract the key learnings
Save that Redis connection pooling gotcha we just discovered
Remember that the Stripe webhook retry window is 72h, not 24h
Review our accumulated knowledge on infrastructure
Learn that batch inserts above 1000 rows cause OOM in our ORM
References
Read references/learn-conventions.md for placement rules and entry format. Read references/learn-template.md for the topic file structure.
Input
Accept whatever the user provides — there is no fixed set of sources. Conversation context, debugging sessions, research findings, files, links, direct statements, incident post-mortems, PR reviews. Understand the source from natural language context; don't ask the user to categorize.
Extraction Rule
Extract knowledge that is non-obvious, non-trivial, and worth preserving: gotchas, counter-intuitive behavior, validated assumptions, hard-won fixes, discovered constraints.
Skip: common knowledge, decisions (→ cmk:adr), requirements (→ cmk:prd / cmk:feature-spec), opinions without evidence.
Workflow: Extract
- Read and understand the input.
- Identify entries that meet the extraction rule.
- Structure each entry: title, date, context, learning, applies-to tags (see
references/learn-template.md). - Find or create the topic file in
docs/knowledge/{topic}.md. - Check for conflicts with existing entries — flag contradictions to the user (they decide: replace, keep both, or discard).
- Present entries for user review before writing.
- Write approved entries.
Workflow: Review
- Read all files in
docs/knowledge/. - Present summary: topics, entry count, date range.
- Support: search by keyword/tag, clean up outdated entries, or promote entries to downstream skills (
cmk:rule,cmk:prd, etc.).
Output
- Entries go in
docs/knowledge/{topic}.md, newest first - Never write without user confirmation
- Flag conflicts between new and existing entries
- Every entry has: scannable title, date, context, actionable learning, applies-to tags
- No duplicates within a topic file
More from commandosslabs/ai-devkit
cmk:feature-spec
Create or iterate feature specifications. Use whenever someone wants to draft, refine, or update a feature spec — from conversation notes, local docs, external links, or direct prompts. Also triggers for "spec out this feature", "write up the requirements for X", "break this into a spec", or discussions about feature scope, flows, and acceptance criteria.
13cmk:codebase-summary
Create or iterate codebase summary documents that map repository structure, key entry points, core modules, and local dev setup. Use whenever someone wants to document how the repo is organized, update the codebase map after restructuring, or help new contributors navigate the codebase. Also triggers for "map the repo", "document the project structure", or "where does everything live".
13cmk:prd
Create or iterate product requirements documents. Use whenever someone wants to draft, refine, or update a PRD — whether from conversation notes, research sessions, user feedback, Notion docs, or direct instructions. Also triggers when users discuss product scope, success criteria, user needs, or say things like "save this as requirements" or "let's define what we're building".
12cmk:docs
Bootstrap or update the /docs directory structure with navigation files, guides, and templates. Use when someone wants to set up docs for a new repo, check if their docs structure is current, or sync scaffolding after devkit updates. Also triggers when users mention "docs structure", "initialize docs", or "docs scaffold".
12cmk:adr
Create or update architecture decision records for system-level technical choices. Use whenever someone needs to record, revise, or document a technical decision with trade-offs — like choosing a database, communication protocol, or infrastructure pattern. Also triggers for "record this decision", "we decided to use X over Y", or "document why we chose this approach".
12cmk:system-design
Create or iterate system design documents covering architecture, tech stack, components, and cross-cutting concerns. Use whenever someone wants to draft, refine, or update a system design — whether discussing architecture decisions, tech stack changes, infrastructure layout, or scaling strategy. Also triggers for "how should we build this", "design the backend", or "update the architecture".
12