paqad

██████╗  █████╗  ██████╗  █████╗ ██████╗
██╔══██╗██╔══██╗██╔═══██╗██╔══██╗██╔══██╗
██████╔╝███████║██║   ██║███████║██║  ██║
██╔═══╝ ██╔══██║██║▄▄ ██║██╔══██║██║  ██║
██║     ██║  ██║╚██████╔╝██║  ██║██████╔╝
╚═╝     ╚═╝  ╚═╝ ╚══▀▀═╝ ╚═╝  ╚═╝╚═════╝

Don't trust the prompt. Trust the workflow.

The open-source, spec-driven framework for AI coding agents that have to be right, not just fast.

Works with Claude Code, Cursor, GitHub Copilot, Gemini, Codex, Windsurf, Junie, Continue, Antigravity, Aider, and JetBrains AI Assistant.

Built by Eliyce

A prompt is the most error-prone part of AI development. paqad-ai replaces "hope the prompt works" with something a team can stand behind. Your specs, rules, and workflows become version-controlled context that every AI agent has to follow, and every change is proven by automatic checks instead of by another AI guessing. One command sets up all your agents at once, and the whole thing runs on your machine, so your code never has to leave the building.

Install in 30 seconds

npm install -g paqad-ai
cd your-project
paqad-ai onboard

paqad-ai reads your lockfiles, detects your stack, asks you to confirm, then sets everything up:

✓ Detected:  laravel + react (inertia, tailwind, pest, docker)
✓ Generated: CLAUDE.md, AGENTS.md, GEMINI.md, .cursor/rules, copilot-instructions, .windsurfrules
✓ Generated: docs/instructions/rules/* and stack-specific tool guides
✓ Wrote:     .paqad/project-profile.yaml, onboarding-manifest.json, detection-report.json
✓ Configured: entry files and MCP settings for every tool you picked

Ready. Your AI agents now understand your project, and your rules.

No account, no API key, no subscription. Prefer not to install anything? Run npx paqad-ai onboard.

Install in Claude Code (plugin)

Inside Claude Code you can install paqad as a plugin, with no npm package and no separate setup:

/plugin marketplace add Eliyce/paqad-claude-plugin
/plugin install paqad@eliyce

Then use it:

• /paqad:onboard if you are setting the project up for your team (the lead).
• /paqad:join if the project is already onboarded and you are setting up your own machine.

A few things worth knowing:

• This is Claude Code only. If you also use Codex, Gemini, Cursor, or another tool on the same project, keep the npm package (npm install -g paqad-ai) so those tools stay wired. Removing npm is fine when Claude Code is the only tool you use here. When both are installed, only one of them runs its hooks in a session, so nothing runs twice.
• The plugin keeps itself current. Claude Code updates it through /plugin, so you do not run an update command by hand.
• Onboarding from the plugin writes no paqad hooks into the project's .claude/settings.json, because the plugin brings its own. The plugin keeps a copy of itself in its data folder (~/.claude/plugins/data/paqad-eliyce/runtime) and points ~/.paqad-ai/current there, so the framework link keeps working when Claude Code cleans up an old plugin version.
• The optional RAG engine installs on first use, in the background, only if you turn RAG on. If you turn RAG on during /paqad:onboard, RAG stays on, onboarding says "search index is installing in the background; text search until it is ready", and the index is built once the engine is in. Until then search falls back to plain text, and paqad-ai doctor shows not ready: installing. If the index cannot be built for another reason, onboarding turns RAG off and tells you why. To remove the engine later, delete ~/.paqad/ (the shared model and engine cache).
• To open the dashboard, run paqad-ai dashboard from a terminal in the project. The plugin puts paqad-ai on your shell path inside a Claude Code session.
• The plugin shows where the change stands in a band above the prompt. To hide it, set hud_view=false in .paqad/.config (just you) or in .paqad/configs/.config.app (the team), or set PAQAD_HUD_VIEW=false. Its pane has tabs for the High Table, Cost, Trust, Ships and Record, and /paqad receipt draws the receipt as a card. For a short chime when the verdict lands, set hud_chime=true (or PAQAD_HUD_CHIME=true); it is off by default and never speaks.
• Already on the npm setup? paqad can move you to the plugin automatically in the background, with nothing to do on your side. The npm package stays installed as a fallback, so paqad is never off at any point. It is off by default today; plugin_migration=on or claude_install_mode=plugin turns it on, paqad-ai plugin rollback moves a machine back to the npm setup and removes the plugin, and claude_install_mode=settings in your team config keeps a project on npm.
  • paqad checks your organization's managed policy first. If it blocks the plugin or paqad's hooks, paqad stays on npm and writes nothing.
  • If the Desktop app already synced the plugin from claude.ai, the move is simply marked done. If the plugin is already installed some other way, paqad turns it on in your own Claude settings and then waits for it to run, like any other install.
  • When claude is on your path, paqad runs claude plugin marketplace add Eliyce/paqad-claude-plugin and claude plugin install paqad@eliyce --scope user, then checks that Claude Code recorded the plugin. With no claude on your path, it runs the same two commands with the claude that ships inside the Claude Desktop app (~/Library/Application Support/Claude/claude-code/<version>/ on macOS, %APPDATA%\Claude\claude-code\<version>\ on Windows). If neither is there, or the install fails, paqad stays on npm, records why, and tries again a day later. It never edits a project file.
  • paqad then watches your next Claude Code sessions. Once the plugin runs, the move is done. A session only counts once Claude Code has installed the plugin, because the Desktop app can take a few starts to do that. Until then paqad waits, and if the plugin is still not installed 7 days later it undoes the move and tries again later. After the install, three sessions with no sign of the plugin also undo the move, and paqad tries again a day later, up to five attempts.
  • If you turn the plugin off in your Claude settings, paqad records that you declined it and never turns it back on.
  • paqad-ai plugin rollback removes the plugin with claude on your path, or with the Desktop app's claude. If neither can run, it turns the plugin off and tells you the one command to remove it.
  • paqad-ai doctor shows where the move stands, including when it is still waiting for Claude Code to install the plugin, and ~/.paqad-ai/logs/plugin-migration.log has the details. If a settings file still wires the npm hooks, doctor names it: your own ~/.claude/settings.json (or the one in CLAUDE_CONFIG_DIR when that is set), the project's .claude/settings.json, or both. That project keeps running the npm hooks while the plugin stays quiet.
• Organizations (Team or Enterprise): add the paqad plugin in Organization settings > Plugins & skills and set it to Installed by default or Required. Members then do nothing and nothing on their machine is edited by paqad.
  • The Claude Desktop app picks up a plugin added on claude.ai, but a claude session in a terminal does not load plugins uploaded to claude.ai. Terminal users install it themselves with the two /plugin commands above, or IT deploys it as a managed plugin.
  • The plugin and its eliyce marketplace live together in the public repo Eliyce/paqad-claude-plugin. You never edit that repo: every npm release builds the plugin here, writes its marketplace file, and pushes it there with a v<version> tag, but only after npm publish succeeds. When nothing in the plugin changed, it pushes no new commit. The release job needs the repository secret PAQAD_PLUGIN_PUSH_TOKEN, a token that can push to Eliyce/paqad-claude-plugin. Without it, or when the push fails, the release job fails, so a missing plugin release never goes unnoticed. To see what would be pushed, run pnpm build && node scripts/assemble-plugin.mjs <folder>.

What paqad runs, writes and sends

paqad runs on your machine. There's no paqad account, no paqad server, and no telemetry.

What it runs. Node scripts inside the plugin, as Claude Code hooks: at session start, when you send a prompt, before Edit, Write and NotebookEdit, when Claude stops, and when a subagent stops. Some of them block an edit on purpose:

• before paqad has loaded in the session
• before planning on a feature change, and before the spec when the change needs one
• while a decision is waiting for you
• inside a closed evidence folder

When a gate hits an unexpected error, it blocks the edit instead of letting it through. Turn paqad off for a project with paqad_enable=false in .paqad/.config, or everywhere with the PAQAD_DISABLED=1 environment variable.

What it writes. Files under .paqad/ in your project (settings, rules, the evidence record and logs), plus docs/instructions/ when you onboard. It also uses the plugin's own data folder under ~/.claude/plugins/data/ for the optional search engine.

What it sends. Nothing from your project leaves your machine unless you turn on one of the services in the last three rows of this table:

API keys. The OpenAI and Cohere keys in the last two rows are optional. In Claude Code, set them as the plugin's options; they go to your system's secure credential store and reach paqad's hooks as environment variables. paqad uses the first key it finds, in this order: the key saved in the plugin options, then the environment variable (OPENAI_API_KEY or COHERE_API_KEY), then the project file (.paqad/secrets.env for OpenAI, created with mode 600 and ignored by git, and your paqad config for Cohere). A plugin option left empty counts as not set. With the npm package there are no plugin options, so paqad reads the environment and the project file exactly as before. Plugin options reach paqad's hooks, not the commands Claude runs in its shell, so a command such as paqad-ai spec pipeline start run there reads the environment or the project file. paqad sends a key only to the service it belongs to.

The dashboard and graph views run on 127.0.0.1 only.

What the HUD does (Claude Code)

The HUD is a Claude Code mod that ships inside the plugin. It only draws and asks; paqad's hooks do the enforcing, and they keep working when the HUD is off.

• Reads: this project's .paqad/ files (the session status, the evidence snapshot, pending decisions and the last rule stop), the environment variables PAQAD_DISABLED, PAQAD_ENABLE, PAQAD_HUD_VIEW, PAQAD_HUD_CHIME and CLAUDE_CODE_REMOTE, the session's tool calls, so it can show which stage is running, and the session's agent list ($.agent.list()) with the rows and tool calls of its subagents, so it can show which subagent runs, a one-line summary of what it is doing and how many finished. None of that is stored or sent anywhere.
• Writes: two files in .paqad/session/hud/: <session>.live, a heartbeat (written when you send a prompt and once a minute) that tells paqad the HUD is open, and a mark in <session>.last-block.json when you answer a rule stop. No other files, nothing outside .paqad/, and never a build, settings, start-up or instructions file. In Claude Code's own mod store it keeps three view preferences: whether the band is minimised, whether you hid it for a project, and which changes already opened the ledger pane.
• Runs: two programs, both paqad's own command from this plugin, and each run times out after 15 seconds.
  • When a rule stops an edit, only after you choose Allow once, recorded: paqad-ai rules override --rule <id> --file <path> --token <one-time token> --tool-use-id <id> --session <id> --project-root <path>, plus --reason=<your words> if you typed a reason. It adds one line to the change's rule-overrides.jsonl evidence file and contacts no network host. After the edit runs again, it runs the same command once more with --outcome landed or --outcome still-blocked and the same rule, file, tool call, session and project, which adds a second line saying whether the edit went through.
  • paqad-ai delivery-link refresh --session <id> --project-root <path> --min-age-seconds <n>, only while an open pull request's CI is pending, so the delivery rail can mark Push and CI after the turn ends. It checks every 30 seconds, for at most 60 minutes, one run at a time, and again after a git push from this session or when the pull request gets a newer head. It stops when CI passes or fails, the pull request is closed or merged, gh fails twice in a row (signed out or offline), the HUD closes, or paqad is off. It runs git and your own gh login, which contacts GitHub to read the pull request and its checks; it never pushes, comments or re-runs CI, and writes only the push, pull request and CI reading in the change's delivery.json. It is always on, with no setting.
• Sends: nothing of its own. The only network contact is the gh read above, made by your gh with your login. The chime (off unless you set hud_chime=true) is a short sound built into the plugin as bytes, not fetched from anywhere.
• Commands: /paqad, or /paqad-hud when another plugin already owns /paqad. It answers from this session's record (/paqad help lists the subcommands) and only changes the HUD's own view: show and hide bring the band back or hide it. It edits nothing in your project.
• Its hooks on your edits:
  • When one of paqad's rules stops an Edit, Write or NotebookEdit, the HUD asks you what should happen. If you allow it once, paqad records the override and runs the same edit again. paqad's own gate then asks Claude Code to show you its permission dialog for that one edit, and you approve it there. The HUD never approves an edit and never changes a permission answer. A deny from your settings rules, from another tool's hook or from a stop your organization enforces still blocks the edit. If anything fails, the edit stays blocked.

Try it in 2 minutes

1. Install the plugin, then open Claude Code in any project with a git repository (a new folder after git init works too).
2. Run /paqad:onboard and accept the suggested setup. paqad does nothing in a project until it's onboarded.
3. Ask Claude one of these:
   • "Add a CSV export button to the orders list" (paqad plans it, writes the spec, then builds, checks and records evidence)
   • "Review the changes on this branch against our rules"
   • "Run a codebase health check and show me the top risks"

Deploy for your organization

If you run Claude Code for a team, you can put paqad's edit-time rule block on every machine with one file that nobody on the machine can loosen. It uses Claude Code's managed settings, which IT pushes with the MDM tool you already use.

1. Turn on the team features (enterprise=true in .paqad/.config, or PAQAD_ENTERPRISE=true) and write the file:

   paqad-ai managed-settings --write ./managed
   

   This writes ./managed/paqad.json. Run it without --write to print the file instead, and add --no-plugin if you install the paqad plugin some other way.

2. Install paqad-ai globally on every machine through MDM (npm install -g paqad-ai). Do this before the file goes out: the file calls paqad-ai on every edit.

3. Push paqad.json into the managed settings folder for each OS:

   OS	Folder
   macOS	/Library/Application Support/ClaudeCode/managed-settings.d/
   Linux and WSL	/etc/claude-code/managed-settings.d/
   Windows	C:\Program Files\ClaudeCode\managed-settings.d\

4. Check it on one machine. Start claude --debug and look for the two paqad-ai hook --managed commands among the loaded hooks, then run /status inside Claude Code to see the managed settings it picked up.

Rolling back. Delete paqad.json from the managed settings folder through MDM. Claude Code goes back to normal on its next start, and there is no paqad state to clean up.

What you get, at a glance

The rest of this page walks through each of these. The full docs go deeper on every command and concept.

The problem it solves

AI writes the code now. The hard part moved: it is no longer typing the code, it is trusting it.

Here is the difference paqad-ai makes on the same request.

This is not a model problem you can wait out. The research is consistent:

• 84% of developers use AI tools, but more now distrust their accuracy (46%) than trust it (33%), and the single biggest frustration, named by 66%, is "AI solutions that are almost right, but not quite." ^[1]
• 81% of developers say they spend more time reviewing code since adopting AI. The work did not vanish, it moved to review. ^[2]
• About 1 in 5 packages an AI recommends do not exist, a hallucination so reliable it created a new supply-chain attack. ^[3]
• 45% of AI-generated code ships with a known security flaw, and bigger models are not measurably safer. ^[4]
• Every frontier model gets worse as you cram more into its context window, so dumping your whole repo into the prompt makes answers worse, not better. ^[5]

An agent driven by an ad-hoc prompt has no spec to meet, no rules it must follow, and no check that can tell "done" from "looks done." paqad-ai adds all three.

Spec Kit and Kiro tell the agent what to build. paqad-ai makes it prove it actually did, with automatic checks, on your machine, across every agent you use.

How it works

Three steps turn AI coding from a prompt you hope works into a pipeline you can trust.

   You ask for something
   "Add product search that filters by name and category"
            │
            ▼
   ┌─────────────────────────────────────────────┐
   │ 1. CODIFY                                     │   Your stack, rules, and spec become
   │    stack  ·  rules  ·  spec                   │   context every agent reads. Written once,
   └─────────────────────────────────────────────┘   reused everywhere.
            │
            ▼
   ┌─────────────────────────────────────────────┐
   │ 2. FOLLOW                                     │   The agent runs your workflow, not an
   │    route  →  plan  →  test  →  build          │   improvised prompt. Same process,
   └─────────────────────────────────────────────┘   every time.
            │
            ▼
   ┌─────────────────────────────────────────────┐
   │ 3. PROVE                                      │   Automatic checks confirm the work.
   │    ✓ tests   ✓ spec met   ✓ docs in sync     │   Code, not another AI. Nothing ships
   │    ✓ security  ✓ quality  ✓ no regressions   │   until they pass.
   └─────────────────────────────────────────────┘
            │
            ▼
        Done, and proven

When you turn the flags on, the spec itself can be produced by a pipeline: it grounds the request in your own docs, brings in the domain experts the request needs, asks one small batch of plain-language questions, and writes the spec with every line traced to where it came from.

Set up every agent once

Run paqad-ai onboard one time. It writes a thin, native config file for each tool you use, and they all point at the same shared instruction bundle. Change a rule in one place, and every agent sees it. Switch tools next month without losing anything.

paqad never writes another tool's MCP config file, so the servers you set up stay yours. The MCP servers it suggests for your stack go in .paqad/mcp-recommendations.json.

Pick one or pick all. Onboarding is multi-select.

Run your workflows, not prompts

This is the core idea: the prompt is the unreliable part, so paqad-ai does not rely on it. Your team writes its process down as plain workflows and rules, and the framework runs them the same way every time.

# docs/instructions/workflows/feature-with-review.yaml
name: feature-with-review
triggers:
  workflow: [feature]
  complexity: [medium, high]
steps:
  - skill: scope-check
  - skill: spec-diff
    condition: { complexity: [medium, high] }
  - parallel:
      - skill: implementation
      - skill: test-writer
  - skill: adversarial-review
    condition: { risk: [medium, high] }
  - skill: diff-doc-sync

Steps can run in order or in parallel, branch on complexity and risk, handle failure (abort, skip, or retry), and resume where they left off after a restart.

Prove the work is done

Any agent will happily tell you it finished. paqad-ai checks reality instead, using code rather than another AI that can be talked into a "yes."

• Spec coverage you can see. A structured spec becomes a checklist of everything it promised. A plain scan then reads your test files for the matching evidence and reports exactly which acceptance criteria are actually proven, and which are not. An agent cannot claim a feature is tested when no test exists for it.
• Gates that block bad changes. Lint, types, tests, build, and rule checks run in order. Any failure stops the change and records what broke, where, and why.
• Traceability both ways. Every promise in the spec maps to the code and test that satisfy it, flagging untested promises and leftover code that nothing asked for.
• Reproduce before you fix. A bug has to be reproduced, fixed, proven fixed, and proven to break nothing else.
• Mutation testing on changed code, if you turn it on, because a test that cannot catch a mistake is not really a test. It is off by default. Set mutation_mode to warn or strict and call paqad's backstop from your own CI or pre-push hook: your test command runs first, then the mutation tool you install for your stack, and under strict a surviving mutant fails that step. No agent host runs it at the end of a turn: on Claude Code and Codex the end-of-turn check reads it as not required, Gemini records the turn without a mutation verdict in chat, and on the advisory hosts paqad claims no mutation enforcement.
• Flaky tests get quarantined, never deleted. A suspected-flaky failure is re-run and held aside until it is fixed, so a green check actually means green.
• A quality floor that only goes up. Four measures (tangle, dead code, risky patterns, strictness) are pinned at today's level and can improve but never quietly slip.

Security and design, as full workflows

Most tools treat security as a separate scanner you remember to run. paqad-ai treats it as part of the work.

Security workflow. A resumable, OWASP WSTG-structured security self-review that hardens code before a certified pentest, timed to the moment the industry is formalizing security for AI agents.

It writes a local curl playbook to prove each finding (it never runs attacks for you), gives each finding a stable ID so it survives retests, scans only changed files after the first run, and replays findings later as fixed, still-open, or needs another look.

Design workflow. The same rigor, pointed at the front end. The design-test pass audits your UI against your own design system, covering tokens, components, accessibility, responsive behavior, and motion, and design-retest replays the findings after you fix them. The security self-review hardens the code. Design-test checks that the interface is consistent.

Documentation that stays current

Documentation is a real output here, not an afterthought you maintain by hand. Ask any connected agent to create documentation and the workflow re-reads your live stack, syncs anything that drifted, and writes stack, architecture, design-system, and per-feature docs. A differential refresh updates only what changed. When the code and the docs disagree, the framework treats that as a defect to fix. The result is documentation a new teammate, or a new agent, can actually rely on.

The right context, with fewer tokens

Your agent does not need your whole repo. It needs the right files. And since every model gets worse on a bloated context, loading less is not just cheaper, it makes the answers better.

paqad-ai keeps the session-start load lean: a rule manifest plus the files a task actually touches, instead of the whole rule tree. Measured across two projects, that resident load is 49-61% smaller than loading everything (paqad-ai's own repo: 61%; a fresh React onboard: 49%). Both used the char/4 heuristic tokenizer, so treat them as an honest floor, not a marketing ceiling. The method, the per-project numbers, and the caveats are in docs/instructions/benchmarks/measured.md, and you can reproduce them in your own repo:

node scripts/measure-footprint.mjs --project .

• It splits files at natural boundaries (functions and classes), not at arbitrary line counts.
• It ranks each piece by five signals: meaning, keywords, the symbols involved, how close the file is to the task, and how deeply nested it is.
• It fills a token budget in tiers, evicts the least useful context first, and collapses duplicate material to a single reference.
• It compresses old conversation turns into a short, structured summary using plain pattern-matching, with no extra AI call to pay for.
• It tidies noisy test output into a compact result, so a huge test log does not flood the agent's context, and the checks read the clean version.

Built for teams and enterprises

Everything above adds up to what a serious team needs before it lets AI near its pipeline.

• It runs on your machine. Analysis happens locally, embeddings default to a local model, and any remote keys you opt into live in a locked-down file and are scrubbed from logs. Your source never has to leave the building.
• No vendor lock-in. Ten agent platforms from one source of truth. Move between them whenever you want.
• A real audit trail. An append-only log, structured logging that redacts secrets, and decision records: architectural choices pause for a human and are saved with the reason and a timestamp, never decided silently.
• Reproducible by design. Onboarding is idempotent, detection reads lockfiles first, artifacts are schema-versioned, and drift tracking tells you when reality has moved away from what you onboarded.
• A quality bar enforced by code, not by good intentions, including the quality ratchet and a strict test-coverage standard.

See what your AI sees

paqad-ai dashboard    # the management surface: health, approvals, trust, the Graph area, and web editors for everything you own
paqad-ai status       # the same report as JSON or Markdown, for an agent to read

The Graph area inside the dashboard is an interactive map of modules, files, symbols, imports, and similarity. It lives behind the same left rail as every other area.

One command, nothing extra to install. The server, the interface, and the layout engine all ship inside paqad-ai, run on loopback only, and send no telemetry.

How it compares

paqad-ai sits in a space the others only touch the edges of: proof you can run locally, across every agent, driven by your own spec.

The short version: most tools tell the agent what to build, or review it after the fact. paqad-ai makes the agent follow your process and prove the result, before anything ships.

Works with your stack

paqad-ai does not ask what you use. It reads your repo across nine ecosystems and figures it out, trusting your lockfiles first.

Frameworks: laravel react vue flutter django fastapi rails spring-boot express angular svelte astro go-web rust-web dotnet nextjs flask nestjs kotlin-android

Plain Node projects: node-cli node-library node-service

Commands

onboard is the one you start with. The rest keep the project honest over time. Full reference at paqad.ai/docs.html.

# a few common runs
paqad-ai onboard --stack laravel --capability react tailwind --providers claude-code cursor copilot
paqad-ai onboard --providers github-copilot     # just one tool
paqad-ai compliance check                        # which promises are actually tested?
paqad-ai rag init --provider local               # free, on-device search
paqad-ai doctor                                  # exits 1 on failure, 0 on pass

What paqad-ai creates

your-project/
├── CLAUDE.md, AGENTS.md, GEMINI.md, .cursor/rules, copilot-instructions, ...
│       thin config files, one per tool you picked, all pointing at the same knowledge
│
├── docs/
│   ├── instructions/
│   │   ├── rules/        your conventions and writing rules (the source for rules-as-scripts)
│   │   ├── stack/        generated stack docs: overview, frameworks, dependencies, drift, ...
│   │   ├── tools/        stack-specific tool guides
│   │   └── workflows/    your own resumable workflow templates
│   ├── modules/          per-feature docs kept in sync with the code
│   └── pentest/          security workflow output
│
└── .paqad/               framework metadata, machine-managed
    ├── project-profile.yaml   project facts: stack, commands, capabilities
    ├── .config.example        every framework knob, commented; copy lines into .config (git-ignored) to override
    ├── stack-snapshot.json, stack-drift.json, onboarding-manifest.json
    ├── compliance/        spec obligations
    ├── decisions/         human decision records
    ├── audit.log          append-only event log
    ├── vectors/           optional search index, with opt-in keys kept in a locked file
    └── session/, context/, cache/, workflows/

The config files stay short. The real knowledge lives in shared bundles that every tool and every built-in role reads the same way.

Requirements

Development

pnpm install
pnpm run format     # run before you finish
pnpm run ci         # typecheck, lint, format check, test at 100% coverage, build

Every change keeps 100% line, statement, function, and branch coverage, adds tests for the flows it touches, and updates the matching docs and website surfaces when a contract changes.

Contributing

Issues and pull requests are welcome. The release workflow explains how changes ship: branch, open a PR, add a changeset, squash-merge, and the release is published automatically.

Sources

The statistics in "The problem it solves" come from outside research, linked here so you can check them.

1. Stack Overflow 2025 Developer Survey, AI section, about 49,000 respondents: https://survey.stackoverflow.co/2025/ai
2. Harness 2026 State of Engineering Excellence, via ITPro, May 2026: https://www.itpro.com/software/development/ai-might-help-speed-up-software-development-but-81-percent-of-devs-now-spend-more-time-reviewing-code-and-its-creating-an-invisible-work-trend-thats-pushing-teams-to-the-limit
3. Package-hallucination study, USENIX Security 2025: https://www.usenix.org/system/files/conference/usenixsecurity25/sec25cycle1-prepub-742-spracklen.pdf
4. Veracode 2025 GenAI Code Security Report: https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/
5. Chroma Research, "Context Rot," across 18 frontier models: https://www.trychroma.com/research/context-rot

MIT License · npm · Website · Docs · Built by Eliyce