cmk:rule
Rule
Intents
Add a rule that all API endpoints must validate auth tokens before processing
Promote the Redis pooling learning to an infrastructure rule
Update the security rules — we now require CSP headers on all responses
Make it a standard that all services must have health check endpoints
Review the knowledge entries and let me pick what to promote to rules
References
Read references/rule-conventions.md for placement rules and directory structure.
Scope
Rules are enforceable engineering standards in docs/rules/ organized by domain:
common/— language-agnostic (coding style, git workflow, security, testing){language}/— language-specific (e.g.,typescript/,python/){framework}/— framework-specific (e.g.,react/,nextjs/)
Input
Accept whatever the user provides: direct statements, knowledge entries from docs/knowledge/, conversation context, code patterns from review, or incident learnings.
Workflow: Create
- Understand the rule: what practice to enforce and why.
- Determine target: subdirectory (
common/, language, or framework) and topic file. Create new file if no match:docs/rules/{domain}/{topic}.md. - Write: clear actionable statement, brief rationale, example if not self-evident.
- Link back to
docs/knowledge/source when applicable.
Workflow: Iterate
- Read the existing rule file in full.
- Identify what changed and why.
- Update in place: revise statement, update rationale, add/update examples.
- Link back to knowledge source when applicable.
Workflow: Promote
- Read specified knowledge entries from
docs/knowledge/. - For each entry the user selects: determine target, transform learning into actionable rule, write to
docs/rules/. - User decides what gets promoted — never auto-promote.
Output
- Rules go in
docs/rules/{domain}/{topic}.md - Each rule is concise, actionable, and followable by an agent without ambiguity
- Rationale explains why, not just what
- Never promote without user confirmation
- Link to source knowledge entry when applicable
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