Documentation-first skills for AI-powered software development. Agents and humans work from the same knowledge, memory, and context — structured docs are the shared state.
claude plugin add CommandOSSLabs/ai-devkitTell OpenCode:
Fetch and follow the instructions at https://raw.githubusercontent.com/CommandOSSLabs/ai-devkit/refs/heads/main/.opencode/INSTALL.md.
AI agents lose context between sessions. Teams repeat requirements, re-explain decisions, and re-establish scope every time a new conversation starts. There is no shared memory between agents and humans.
This devkit solves that by using structured documentation as the shared state. The repository becomes the single source of truth — agents read it to get up to speed, humans and agents write to it to preserve decisions, and both act on the same base of knowledge.
This is a guideline, not a rulebook. The goal is better structure, not more files. Teams can draft in Notion, Google Docs, or conversation — but finalized, development-critical context should live in the repository.
| Skill | Purpose |
|---|---|
cmk:docs |
Bootstrap or update the /docs directory structure |
cmk:prd |
Create or iterate product requirements |
cmk:system-design |
Create or iterate system architecture |
cmk:feature-spec |
Create or iterate feature specifications |
cmk:adr |
Create or update architecture decisions |
cmk:codebase-docs |
Generate or update hierarchical, AI-navigable docs under docs/ai/ |
cmk:learn |
Extract and record non-obvious learnings and gotchas |
cmk:rule |
Codify engineering standards into docs/rules/ |
cmk:worktree-dev-env |
Set up worktree-isolated local development environments |
Skills trigger automatically from natural language — just describe what you need. You can also invoke directly with slash commands (e.g. /cmk:prd).
Docs build on each other. Follow this order when starting a new project:
Set up the /docs directory structure. Do this once, then use it to verify or update as the project grows.
Set up the docs structure for this project
Check if our docs structure is up to date with the latest devkit
Define what to build and why. This is the upstream source of truth — everything downstream references it.
We just discussed the billing system requirements — save that as a PRD
Use this Notion doc to draft a PRD for the new onboarding flow: [link]
Update the PRD — we're cutting the SSO requirement from v1
Design how to build it. Informed by the PRD — the skill checks for conflicts with upstream scope and success criteria.
Draft a system design for our payments service
Update the system design — we switched from PostgreSQL to DynamoDB
We're adding a message queue between the API and worker — update the architecture
Break the system design into implementable features. Informed by both the PRD and system design — the skill checks for upstream conflicts.
Create a feature spec for checkout retry logic
Use this Notion doc to draft a feature spec for tenant-level rate limiting: [link]
Update the retry spec — we changed the backoff strategy to exponential with jitter
Record system-level decisions as they come up during any step. The skill checks for conflicts with the current system design.
We decided to use event sourcing over CRUD for the audit trail — record that as an ADR
Record an ADR: chose Redis over Memcached for session caching because of pub/sub support
Update ADR-0003 — we revisited the decision and switched from REST to gRPC
Extract non-obvious knowledge from any source — conversations, debugging, research, files. Saves to docs/knowledge/ for downstream use.
That was a long research session — extract the key learnings
Save that Redis connection pooling gotcha we just discovered
Review our accumulated learnings on infrastructure
Codify standards into docs/rules/. Create rules directly, or promote knowledge entries into enforceable standards.
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
Build a hierarchical tree of short docs under docs/ai/ so AI (or a human skimming) can quickly find the right source file for a topic. Update as the codebase evolves.
Set up AI docs for this repo
Update the AI docs — I added a new TUI input handler
Refresh docs/ai/ for the rcp module
When an upstream doc changes (e.g., PRD scope shifts), review downstream docs for consistency. Skills will warn when they detect conflicts with upstream — you decide how to resolve them.
Install as a plugin. Skills are auto-discovered and available as slash commands. See Install for setup.
Install as a plugin via opencode.json. Skills are auto-registered via the config hook. See .opencode/INSTALL.md for setup and troubleshooting.
The /docs directory is the shared protocol. Any agent — research, architecture, planning, QA — can participate by reading from and writing to the same structure:
┌──────────┐ ┌──────────┐ ┌──────────────┐
│ Research │────▶│ PRD │────▶│ System │
│ Agent │ │ (cmk:prd)│ │ Design │
└──────────┘ └──────────┘ │ (cmk:system- │
│ design) │
┌───────────────────────────┘──────────────┘
│ │
▼ ▼
┌──────────┐ ┌──────────────┐
│ Feature │ │ Knowledge │
│ Specs │ │ (cmk:learn) │
│ (cmk: │ │ │ │
│ feature- │ │ ▼ │
│ spec) │ │ Rules │
└──────────┘ │ (cmk:rule) │
└──────────────┘
- A research agent saves findings →
cmk:prdreads them to draft requirements - A planning agent reads the feature spec → breaks it into tasks
- A QA agent reads the spec → generates test cases from acceptance criteria
- A debugging session surfaces gotchas →
cmk:learncaptures them →cmk:rulepromotes to standards
The docs are the interface between agents. Each agent reads what it needs, writes what it produces, and the next agent picks up where the last one left off.
Refer to docs/README.md for the full directory structure and conventions.