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 frameworks, no SDK — and if you're on Claude Code, this repo doubles as a plugin marketplace for one-command installs.
This repo is also a Claude Code plugin marketplace, so you can install it directly — no cloning, no context-file edits. Skills then show up namespaced as codered:<skill-name> (e.g. codered:nasa-dod-code-review), exactly like superpowers:brainstorming.
/plugin marketplace add codered/ai
/plugin install codered@coderedThen just ask for what you need:
nasa-dod review
Claude Code resolves that to codered:nasa-dod-code-review and loads the skill automatically.
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.
📺 See it catch a real Power-of-Ten violation in the demo at the top of this README.
| 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) |
📚 Teach Me
Turns "I want to learn X" into a self-contained, multi-chapter course written straight to disk. Asks what you want to learn, how deep to go (beginner/intermediate/advanced), and your background — proposes a chapter outline you can adjust before anything is written, then generates markdown chapters with diagrams, worked examples, and quizzes, plus a separate answer key with reasoning, and a combined PDF when pandoc is available.
| Trigger | "teach me X" · "I want to learn Y" · "create a lesson on Z" · "build me a course on..." |
| Flow | Intake (topic/depth/background) → outline approval checkpoint → chapter-by-chapter generation |
| Output | lessons/<topic-slug>/ — numbered chapters, 00_index.md, ANSWERS.md, optional combined PDF |
| Depth | Beginner · Intermediate · Advanced — calibrates vocabulary, pacing, and chapter count |
🧠 Memory
Builds and maintains a persistent, file-based memory store for a project — split into short-term (active, frequently-needed) and long-term (full project detail) tiers, backed by JSON indexes so any agent can quickly tell whether it already knows something and exactly where to look if it doesn't.
Always delegates the actual reading, categorizing, and writing to a sub-agent, so the main conversation's context stays clean. Can be triggered anytime, and offers itself when the agent estimates its own context is filling up — checkpointing what's been learned before it risks being lost.
| Trigger | "build memory" · "update memory" · self-offered at ~25% context |
| Tiers | short/ — active & frequent · long/ — full project detail |
| Lookup | JSON indexes (top-level tag manifest + per-tier detail) for fast "do we know this?" checks |
| Always | Delegates to a sub-agent — never reads/writes memory files in the main context |
Treats any question as an optimization problem rather than a request for a balanced survey. Pins the actual objective, names the binding constraint, enumerates the real contenders, scores them with magnitudes, and makes a single call with the runner-up and why it lost. Works in any domain — code, hardware, cooking, purchases, trip planning.
Three verbosity modes change how much reasoning is shown, never how much is done: lite (the default) gives the verdict and little else, verbose walks the full method out loud. "It depends" is treated as a starting point to resolve, never a conclusion to settle for.
| Trigger | "what's the best X" · "should I do A or B" · recommendations · build-vs-buy · any cost/quality/time tradeoff |
| Method | Pin objective → name binding constraint → decompose levers → enumerate options → score with magnitudes → call it |
| Modes | lite (default) · medium · verbose — switch with a word, per-message or standing |
| Output | A decision, not a survey — with the runner-up named and the reason it lost |
Shapes output for clarity, directness, and low cognitive load, applying the mechanical writing rules of ASD-STE100 Simplified Technical English to ordinary text. Built for readers who pay a real cost for ambiguity — buried warnings, hedged instructions, metaphors standing in for facts.
Every rule is countable rather than descriptive, so small and local models can self-check against them: sentence length, sentences per paragraph, noun-cluster depth, one instruction per sentence. Ships a standalone system-prompt version in three sizes for chat boxes and local models with no skill-loading mechanism at all.
| Trigger | [NFC: strict] · "plain language" · "clarity filter" · "make this unambiguous" · "reduce cognitive load" |
| Modes | standard (default) → clear → strict — increasing strictness, each inheriting the last |
| Rules | ≤20 words/procedural sentence · ≤6 sentences/paragraph · active voice · imperative steps · warnings before the step |
| Portable | references/system-prompt.md — full, compact, and one-line blocks for any model or API |
Applies NASA/DoD engineering standards to the code and ASD-STE100 Simplified Technical English to the prose that ships with it — comments, docstrings, error messages, identifiers, commit messages — from a single trigger, with no need to name two skills on every request.
The two standards contradict each other in specific places, and one line resolves all of them: STE governs the artifact, NASA/DoD governs the conversation about the artifact. A review of the same file therefore carries a required
| Trigger | "refactor this" · "implement X" · "review this code" · "mission grade" · any production code work |
| Code | Power of Ten · DoD secure-coding baseline · TDD Iron Law — no production code without a failing test |
| Prose | Procedural comments and error strings strict · docstrings and commits clear · identifiers by word rules |
| Review | Six gates — the five NASA/DoD gates plus a prose gate, severity by harm rather than rule count |
#️⃣ hashline
Teaches an agent to edit files by content hash instead of line number or string match. Every line read back carries an xxh32 anchor (2:a3); every patch cites the anchor it targets. If the file drifted since the read, the hash no longer matches and the edit is rejected — instead of a string replace quietly landing on the wrong occurrence, or a line number that moved two commits ago.
Wraps the hashline MCP server, which any harness with native MCP support can register directly. For Prime Agent — whose MCP support reaches only remote HTTP servers, and whose single-tool design has no edit tool to hook — the skill also ships a Python package that speaks the same stdio server from the IPython kernel.
| Trigger | Any file read, create, edit, delete, or rename in a project where hashline is installed |
| Loop | read for anchors → patch citing line:hash → patch result is the re-read file, so it verifies itself |
| Ops | SWAP · DEL · INS.PRE/POST/HEAD/TAIL · SWAP.BLK / DEL.BLK for whole syntactic blocks · dry_run |
| Setup | MCP: {"command": "hashline", "args": ["mcp"]} · Prime Agent: cp -r skills/hashline ~/.prime/agent/skills/ |
Not every problem fits in a markdown skill loaded into someone else's context window. Some need their own process: a loop that reviews, fixes, re-reviews, and repeats — with state that survives a crash and a rubric that decides when to stop. The agents/ directory holds standalone tools like that.
A LangGraph CLI that runs the NASA/DOD review loop end-to-end instead of just reporting it: scans a codebase, generates patches for findings above your fix threshold, applies them with backups, re-reviews only the changed files, and repeats until the rubric passes or it hits max_iterations.
A live run: catches an unguarded divide-by-zero, patches it, and ends with a diff of the fix. (regenerate with VHS)
A real captured run hitting max_total_fix_attempts: the agent stops itself and says why instead of grinding on. (regenerate with VHS)
| Install | cd agents/nasa-dod-agent && uv pip install -e ".[dev]" |
| Run | nasa-dod-agent review path/to/code |
| Loop | review → evaluate rubric → generate fix → apply → re-review → repeat |
| State | Checkpoints + .bak backups under .nasa-dod-agent/ — resumable and restorable |
See the nasa-dod-agent README for full usage, config, and architecture.
Plugin install (recommended)
This repo ships its own .claude-plugin/marketplace.json, so Claude Code can install it directly as a plugin — no cloning, no CLAUDE.md edits. Skills are namespaced as codered:<skill-name> (e.g. codered:nasa-dod-code-review, codered:memory), the same way plugins like superpowers show up.
Run both commands inside Claude Code:
/plugin marketplace add codered/ai
/plugin install codered@coderedVerify it's loaded:
/plugin listTo update later:
/plugin marketplace update coderedManual install (global)
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.
Manual install (per-project)
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.
Tip
On Claude Code, installing this repo as a plugin (see Installation) namespaces every skill under codered: — codered:nasa-dod-code-review, codered:memory, and so on — so they're unambiguous alongside skills from other plugins like superpowers:brainstorming. You can still trigger them by their natural-language phrases (nasa-dod review, build memory); Claude Code resolves those to the namespaced skill automatically. The manual clone install doesn't apply a namespace — skills are simply loaded by their plain folder name.
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.