ai-native-toolkit

AI Native Toolkit

A Claude Code plugin - and a set of standalone skills for any AI assistant: skills, agents, and commands for AI-native development. In Claude Code it runs locally against your own codebase using whichever model you already pay for. Several of the skills also ship as standalone Agent Skills ZIPs you can upload to claude.ai, Claude Desktop, Cowork, or any assistant that supports the skills format - no Claude Code required.

Want the skills without Claude Code? Download the ZIPs from the latest release - the release notes link straight to that version's standalone skill bundle - and upload them in your assistant's Skills UI. Full walkthrough: Standalone skill ZIPs. Currently standalone: /assess, /huddle, /deslop, /skill-forge, /semantic-compress.

New here? The Map of Content is the navigation index - one trail to every skill, command, agent, and design doc in this repo. The CLAUDE.md contract holds the rules for editing it.

Here from the GitHub Marketplace? You found the AI-Readiness Assess Gate - the CI-gate half of this toolkit. It runs the same deterministic engine the /assess skill uses (complexity treemap, promissory-marker scan, doc-graph signals - zero AI tokens) on every pull request and gates on what your .assess/config.toml opts into. Jump straight to Use as a GitHub Action; the rest of this README covers the full plugin the action is carved from.

Why this exists

When you hand work to an AI, does it behave like a brand-new hire, or like an engineer who has been in the org eighteen months? The difference isn't capability - both can write correct code. It's externalized context: knowing where things live, which contracts are load-bearing, where the minefields are, and why the weird thing is weird. An AI contributor is structurally always the new hire - every session starts with an empty head, seeing the codebase through one narrow context window. So the whole question becomes: how much of the tenured engineer's implicit map has the codebase made explicit and navigable? The more it has, the more a fresh agent behaves like it has been here eighteen months.

The aim is not an AI that comprehends complexity humans no longer can, trusted blindly - an agent fluent about code nobody can verify is the dangerous case, not the goal. The aim is a codebase legible enough that the relevant slice fits one context window, where the agent's answers stay anchored to code you can still check in ten seconds. Legibility you can trust, not omniscience you can't.

There's a second half, and it's the same ethic pointed the other way. When a contributor makes a mistake, the question is never "who do we blame" but "what made that mistake possible, and what would make it impossible next time?" A bank doesn't give a new engineer production access and hope - it builds role-based access, staged environments, and CI that catches the error before it ships. Those guardrails aren't distrust; they're how you protect people from costly mistakes by design, and an AI contributor needs the same protection a human does. /assess scores exactly these: linters, architecture tests, CI gates, coverage, review automation. Framed positively: have we set the codebase up so that doing the wrong thing is hard, and the right thing is the path of least resistance? Give the contributor the map and the guardrails - that is what /assess measures the distance to.

The headline pieces are five skills:

• /assess - score any codebase's readiness for AI agent contributors against an 8-layer contract model (navigability, runtime liveness, code design, linters, architecture tests, CI, coverage, review bots, AI project management), with a Codecov-style complexity hotspot SVG and a doc-navigability graph SVG (both colour-blind-safe). Generates a report + the two SVGs and opens a PR in the target repo.
• /huddle - structured multi-perspective deliberation using Six Thinking Hats with Fibonacci team sizing (solo -> debate -> huddle -> panel -> board). See it in action: a narrated visual explainer, and the repeatable pipeline used to build it.
• /deslop - detect and remove the telltale signs of AI writing (puffery, the rule of three, "not X but Y", filler diction, chatbot leakage, fabricated citations). Runs as a silent quality gate while writing, or as an explicit audit/edit pass. Derived from Wikipedia's "Signs of AI writing".
• /skill-forge - harden a skill (draft or existing) through judge-panel refinement rounds until it clears a strict 3-tier promotion gate. A prove-and-promote quality gate that runs after authoring, built on the same team-lead pattern as /huddle - and proven by forging itself.
• /semantic-compress - shrink an LLM-directed document (a prompt, instruction set, or skill) while preserving what it does: point at core knowledge the model already holds, keep project-specific detail verbatim, and - in Claude Code - gate whole-document distillation on an A/B behavioural-equivalence check so every cut is proven, not guessed. Includes a directive-clarity pass that rewrites latent-action instructions into ones that name the action.

What /assess produces

Two paired SVG views from a single run, on a real ~650k-LOC monorepo (file paths sanitized). The first asks can an agent find its way? The second asks what's risky to change?

Here is the same repo twice: an already-good AI-native codebase before, then the same repo after its maintainers worked through the Top 3 Actions from the /assess report. The story is that it gets measurably cleaner. Click any image for the full interactive SVG; hover any node or block for its underlying numbers.

The measurable win. In the doc-navigability graph, reachability from the entry point climbs from 30% to 89%, orphaned docs fall from 24% to 11%, disconnected islands drop from 43 to 20, and the 15 broken links are gone. The rim of orphans thins, the islands reconnect, and the lying-map reds cool - the map an agent consults before changing anything becomes honest. The heatmap stays the same repo's complexity profile throughout: it tells you which territory is dangerous, while the graph tells you whether the map is honest.

How to read them. Doc graph - structure encodes reachability (centre = entry, rings = link-distance from entry, rim = unreachable, dashed ring = orphan, solid edge = link, dotted edge = reference); colour encodes staleness (vivid red = a frozen doc beside churning code, a lying map); size encodes file length. Heatmap - size encodes estimated tokens (~chars/4 - the keyhole size unit; the familiar LOC is one hover away in the tooltip), hue encodes cyclomatic complexity (red = high), saturation encodes recent git churn (vivid = active); the vivid-red blocks are the migration risk an agent (or human) is most likely to break next week. Both SVGs are colour-blind-safe (OrRd ramp, no red-green).

The same lens, three real public repos

The pair above is this toolkit assessing a private monorepo. Below is /assess run unmodified against three public codebases in different languages, ordered by score. It is a calibration check: the layered model should discriminate between genuinely-engineered projects, not rubber-stamp the famous ones. Click any image for the full interactive SVG; hover any block for its numbers.