Give your AI coding agent institutional knowledge — in five minutes, with zero config.
The NASA/DOD Code Review skill catching a real Power-of-Ten violation — rule citation, fix options, and merge gate, all in one pass. (regenerate with VHS)
Every new chat with your AI coding agent starts from zero. It doesn't know your team's review standards, your branching conventions, or the five-step process you always run before merging. So you re-explain it — every session, every project, in slightly different words, until the agent's behavior drifts from what you actually wanted.
Skills fix that. A skill is a focused set of markdown instructions that encodes a specific way of working — a review process, a planning workflow, an analysis format — once, precisely, so any agent that can read a file can run it the same way every time.
Note
If your agent can read a file, it can use these skills. No plugins, no frameworks, no SDK.
1. Clone the repo
# Global install (available across all your projects)
git clone https://github.com/codered/ai ~/.codered
# Per-project install (lives alongside your code)
git clone https://github.com/codered/ai .codered2. Tell your agent where to find the skills
Add one line to your agent's context file. The exact file depends on your agent — see Installation for specifics.
Skills are available at <path>/skills/. Load the SKILL.md in the relevant skill folder when asked to use a skill.
3. Use a skill
nasa-dod review
That's it.
Reviews your code against the same engineering standards used for flight software, defense systems, and mission-critical infrastructure.
Works in two modes — full codebase scan during development, diff-first during PR review. Critical findings block the merge. Every issue comes with three fix options, trade-offs included, and working code in your language.
| Trigger | nasa-dod review · nasa-dod dev review · nasa-dod pr review |
| Languages | C/C++, Python, Go, Rust, Java, JavaScript/TypeScript |
| Standards | NASA Power of Ten · DOD JSF AV · SEI CERT · MISRA · OWASP |
| Gate | P0/Critical blocks merge · 2+ approvals to override on teams |
The companion to the review skill above — this one shapes code as you write it, rather than grading it after the fact. Applies the discipline behind flight software (NASA's "Power of Ten") and defense systems (DISA STIGs, CERT Secure Coding, NIST SSDF) to everyday production work, with TDD as the non-negotiable baseline: no production code without a failing test first.
| Trigger | Writing production code · reviewing a PR · refactoring safety-critical systems · setting standards for a new project |
| Discipline | TDD as the iron law — write the failing test, then the minimum code to pass, then refactor |
| Rules | Bounded loops · short functions · assertion density · minimal scope · input validation |
| Standards | NASA Power of Ten · DISA STIGs · CERT Secure Coding · NIST SSDF |
Assembles a five-role engineering team inside any repository — PM, Developer, QA, Security, and DevOps. Each agent has a distinct persona, scope, and responsibilities. They coordinate through a shared memory system and a rolling pipeline that keeps work moving without bottlenecks.
The PM creates a phased plan with explicit gate criteria. The Dev agent implements using TDD and self-reviews with the NASA/DOD Code Review skill before handoff. QA and Security review each completed task while Dev moves forward. DevOps handles CI/CD, infra, and produces the final readiness gate before anything ships.
| Trigger | init agent team · agent team · agent team status |
| Roles | PM · Dev · QA · Security · DevOps |
| Pipeline | Rolling — Dev never blocks waiting on review |
| Gate | P0/P1 findings block task close · phase gates before advancing |
Produces a structured Markdown analysis of any piece of code — function breakdowns, data flow, dependencies, and test case analysis — within a strict 2-minute time budget. Emits live status updates as it works so you always know where it is.
Covers purpose, parameters, return values, side effects, error conditions, and edge cases. Saves the result as <filename>_analysis.md when file tools are available. Designed for developers who need to quickly understand code they didn't write.
| Trigger | "analyze this code" · "explain what this does" · "document this function" · pasting code with no explanation |
| Output | Structured Markdown: overview, function breakdown, data flow, dependencies, test cases |
| Time budget | 120 seconds — pauses and asks to continue if the limit is reached |
| Tone | Plain language for developers who didn't write the code |
Reads an entire codebase and produces a multi-document specification suite thorough enough that an engineer — or an AI agent — can reimplement the whole thing in a different language with no access to the original source.
Works in five phases: orientation, ambiguity resolution, module-by-module analysis, cross-cutting concerns, and delivery. Outputs a spec/ directory with numbered documents covering architecture, requirements, assumptions, limitations, data models, API contracts, per-module deep-dives, and cross-cutting concerns (auth, error handling, logging, concurrency, security). Designed for large codebases (100+ files) but works at any scale.
| Trigger | "write a spec for this codebase" · "document this project" · "I want to migrate this" · "reverse engineer this" |
| Output | spec/ directory — 00_overview.md through NN_cross_cutting.md |
| Scale | Designed for 100+ file codebases; works at any size |
| Gate | Reimplementation completeness checklist before delivery |
Challenges a request, design, plan, or position by actively hunting for logical gaps, hidden assumptions, missed edge cases, and unconsidered counter-framings — in a tone that's friendly yet firm. Doubles as a general-purpose debate partner for any topic, technical or not.
Triages every exchange as low-stakes or high-stakes first, and that single call drives everything downstream: how many rounds of pushback it runs, how direct its tone gets, and whether it replies in structured findings or natural conversation. It's advisory only — it never blocks anything, and it never re-raises a concern you've already closed.
| Trigger | "play devil's advocate" · "poke holes in this" · "challenge my thinking" · "steelman the other side" · any general debate request |
| Categories | Logical/reasoning gaps · hidden assumptions · missed edge cases · counter-framings |
| Pushback | 1 mention (low-stakes) · up to 3 rounds (high-stakes), then defers either way |
| Output | Conversational prose (low-stakes/debate) · structured findings list (high-stakes/design review) |
Global install
git clone https://github.com/codered/ai ~/.coderedAdd to ~/.claude/CLAUDE.md:
Skills are available at ~/.codered/skills/. When asked to use a skill,
load and follow the SKILL.md in the relevant skill folder.
Per-project install
git clone https://github.com/codered/ai .coderedAdd to CLAUDE.md in your project root:
Skills are available at .codered/skills/. When asked to use a skill,
load and follow the SKILL.md in the relevant skill folder.
Global install
git clone https://github.com/codered/ai ~/.coderedAdd to ~/.cursor/rules/codered.mdc:
Skills are available at ~/.codered/skills/. When asked to use a skill,
load and follow the SKILL.md in the relevant skill folder.
Per-project install
git clone https://github.com/codered/ai .coderedAdd to .cursor/rules/codered.mdc in your project root:
Skills are available at .codered/skills/. When asked to use a skill,
load and follow the SKILL.md in the relevant skill folder.
git clone https://github.com/codered/ai .coderedAdd to .github/copilot-instructions.md:
Skills are available at .codered/skills/. When asked to use a skill,
load and follow the SKILL.md in the relevant skill folder.
git clone https://github.com/codered/ai ~/.coderedAdd to ~/.gemini/GEMINI.md:
Skills are available at ~/.codered/skills/. When asked to use a skill,
load and follow the SKILL.md in the relevant skill folder.
If your agent reads a context file — AGENTS.md, system-prompt.txt, .cursorrules, or anything else — add this:
Skills are available at <path>/skills/. When asked to use a skill,
load and follow the SKILL.md in the relevant skill folder.
Use the path that matches where you cloned the repo.
Tip
Not sure which file your agent reads? Check its documentation or look for AGENTS.md, CLAUDE.md, or .cursorrules in your project root.
Each skill is a folder inside skills/. When you invoke a skill by name, your agent loads the SKILL.md in that folder — a YAML frontmatter block (name, description) followed by the instructions — and follows it from that point forward. Companion files referenced inside are loaded as needed during execution.
skills/
└── nasa-dod-code-review/
├── SKILL.md ← agent entry point (frontmatter + instructions)
├── standards-sources.md ← fetched at runtime
├── reviewer-prompt.md ← analysis instructions
├── severity-guide.md ← P0–P3 classification
├── codeowners-template.md ← first-run setup
└── report-template.md ← output format
Skills are plain markdown. They work because agents are good at following clear written instructions — and plain text is easy to read, version, improve, and contribute to.
One skill, one job. Each skill does exactly one thing well. No skill depends on another, and none require a specific agent or platform.
Blocking is an act of care. A critical finding that stops a bad merge is worth more than a report that gets ignored. Skills that have gates, have them for a reason.
Actionable over advisory. Every finding comes with working code, not just a rule number.
Quality over quantity. Skills ship when they're ready — tested against real codebases, reviewed, and held to a high standard of clarity.
Contributions are welcome. A few things before you start:
- Open an issue first for new skills so we can align on scope
- New skills should follow the structure in
skills/nasa-dod-code-review/— aSKILL.mdwith frontmatter as the agent entry point, companion files for anything that would bloat it - Test with at least two agents before submitting a PR
- No vague instructions — if a step could be interpreted two ways, pick one and make it explicit
git checkout -b skill/your-skill-name
# build, test, then open a PRIf these skills save you time or catch a bug before it ships, consider leaving a star. It helps others find the project.
MIT — see LICENSE for details.