paad

PAAD — Engineering-driven AI, not AI-driven engineering

paad 2.0.0 is out. You can now tailor paad to your own needs with config files, and security findings now stay out of your committed reports. See the 2.0.0 release notes and the changelog.

PAAD (rhymes with "pad") is a set of skills that let you write production-quality code with AI. The AI does the work; you stay the engineer. PAAD reviews each stage — the spec, the plan, the architecture, the code — while you can still change it. That's Pushback, Alignment, Architecture, plus the Discipline to actually run them.

A full explanation/tutorial is here.

Quick start

In Claude Code:

/plugin marketplace add Ovid/paad

And then:

/plugin install paad@paad

Pick a scope when the details panel opens, then /reload-plugins. Run /paad-help to see everything.

Not using Claude Code? One command installs PAAD into 70+ other agents — Cursor, Codex, GitHub Copilot, Gemini CLI, Cline, Zed, Warp, Amp, OpenCode:

npx skills@latest add Ovid/paad

See Installation for the details, including the experimental Pi package.

The skills

Skill	What it does
/pushback [document]	Argues with your spec before anyone builds it
/alignment [files...]	Checks that the plan and the spec say the same thing
/agentic-review [base-branch] [path]	Six specialists review your branch before merge
/agentic-architecture [path...]	Five specialists find structural debt while it's cheap
/fix-architecture [report]	Works through those findings one at a time, test-first
/agentic-a11y [path]	Accessibility audit against WCAG 2.2 AA, by disability category
/vibe [task]	Small fixes, TDD guardrails still on
/rethink [topic]	Checks whether the premises under a recommendation hold
/test-roadmap	Builds a test suite that catches real regressions
/handoff [save|resume]	Hands this session's work to a fresh one, in writing
/makefile	Creates or updates a project Makefile
/paad-help [skill-name]	Lists the skills, or explains one

Experimental skills

Skill	What it does
/agentic-dedup [scope]	Finds duplicated meaning, not duplicated text — experimental
/agentic-owasp [scope]	Reviews code against the OWASP Top 10:2025 — experimental
/backlog [clean|fix]	Clears fixed bugs out of the review backlog, or fixes the next one — experimental

Every skill can also be steered per project: drop instructions in paad/config/paad.md (all skills) or paad/config/<skill-name>.md (one skill) and the skill reads them on invocation. Experimental — see Configuring skills per project.

Full descriptions are further down. The rest of this page is why any of it is worth your tokens.

"AI slop" is technical debt with better marketing

We have been accumulating technical debt since long before AI showed up, and we already know how to handle it: review the requirements, review the plan, review the architecture, review the code. Every one of those is an old, boring, well-understood engineering skill.

What AI changed is not the nature of the debt. It's the speed it arrives at.

• Vibe coding piles up debt fast.
• Spec-driven development piles it up slowly.
• Neither piles up zero.

That's the problem and it isn't new. It's just faster than the review habits most teams have, so the debt lands before anyone looks at it.

The model reads every line of your repository in seconds. It has never once heard about the outage that put that validation check there.

PAAD is how you stay on top of it — the same review layers your team already believes in, applied at the speed the assistant is working.

The four letters

Four points where the AI is about to decide something for you:

Area	What it means
Pushback	Argues with your spec before anyone builds it
Alignment	Checks that the plan and the spec actually say the same thing
Architecture	Finds the structural debt while it's still cheap to fix
Discipline	Yours, not the tool's — running the first three when the deadline says don't

The first three are reviews you run. The fourth is the one thing in the list the assistant will never bring for you.

Your team already runs specs, tests, code review, CI, QA, and incident response — layers that exist because mistakes are cheap to fix early and expensive to fix late, and because humans are stochastic. AI is stochastic too. PAAD's argument isn't that AI needs special safeguards; it's that AI needs the same safeguards, running fast enough to keep up with it.

It doesn't replace your current AI-assisted development tools; it complements them. You like Superpowers? Use it with PAAD.

PAAD supports Claude Code natively, installs into 70+ other agents with one npx command, and ships as an experimental Pi package. Hand-copying the pre-converted Kiro/Antigravity/Cursor tree still works and is now deprecated.

Who's driving

Most organizations adopting AI right now have it backwards. A developer tells the AI what to do and hopes the AI can take over. The AI is happy to oblige — it always is — and the developer finds out what it decided when the code lands.

That's AI-driven engineering: the assistant sets the pace, and the engineers are downstream of decisions they never saw made.

PAAD replaces it with engineering-driven AI. Same speed, opposite direction: you see what the AI is about to do while you can still change it, and you make the calls.

	AI-driven engineering	Engineering-driven AI
The spec	Whatever you typed, unchallenged	pushback argues with it before anyone builds it
The plan	Assumed to match the spec	alignment checks both directions
The code	A green CI run	agentic-review puts six specialists on the PR
The structure	Discovered later, expensively	agentic-architecture finds it while it's cheap
The decisions	The model's	Yours, on the record

You stay in the driver's seat. That is the point, and it's also the cost: PAAD gives you visibility and control, not autopilot.

Workflow

There's a lot to take in with PAAD, so I've written an article to explain how to write production-quality code with it.

If you are new to PAAD, start with /paad-help to see the available skills and when to use them.

A typical workflow looks like this:

1. Write the spec, using your existing spec-driven development method.
2. Run pushback on the spec. Revise and repeat as needed.
3. Develop the task list (you or the agent).
4. Run pushback on the task list. Revise and repeat as needed.
5. Run alignment on the task list to check it against the spec, and rewrite it for TDD. Revise and repeat as needed.
6. Execute the tasks, in a fresh session for each task.
7. Run agentic-review on the result. Fix findings and repeat as needed.
8. Human PR approval and merge. Repeat for the next feature.

That is the per-feature loop (section 10 of the tutorial). It improves the quality of each feature before it gets merged into your primary branch:

AI is now good enough that, with pushback alone, fewer issues surface in the rest of the loop. But the loop only minimizes slop in the current task. It can't prevent slop across the project as a whole. That takes aggressive technical debt management: agentic-architecture to find the structural problems, fix-architecture to work through them, and agentic-review before the fixes merge.

Not sure if the AI is presenting you with the best options? Run rethink to check whether the premises behind a recommendation actually hold.

Depending on the type of work, I also use (see below for full descriptions):

1. agentic-a11y for UI changes and accessibility-sensitive work
2. vibe for small fixes that still benefit from guardrails

Rerun pushback and alignment whenever the spec or the task list changes.

Configuring skills per project

Experimental. This may change or be withdrawn in any release, including a patch release. If you build on it, pin your plugin version.

Tired of typing the same extra instructions after every slash command, or of writing a wrapper skill just to add them? Put them in a file and every paad skill reads it on its own:

File	Read by
paad/config/paad.md	every paad skill
paad/config/<skill-name>.md	that one skill, e.g. paad/config/agentic-review.md

Both are optional, relative to where you run the skill (normally the repo root). There is no schema — write plain instructions, as you would have typed them. For example, paad/config/agentic-architecture.md:

- All output must be in simplified technical English.
- Add one more subagent that looks for over-engineering.
- Keep a log in `paad/logs/agentic-architecture.md` of every finding an
  agent raised that the verifier discarded.

The skill follows it for the whole run and passes the relevant parts to the subagents it dispatches. You know it was read because the skill's final answer opens with a line naming each file it followed:

Config: paad/config/paad.md, paad/config/agentic-architecture.md

No such line means nothing in the run came from your config.

What to watch for:

• Add, don't subtract. Config can tell a skill to skip or reorder its own safety gates, and the skill may comply. Use it for additions — an extra agent, an output rule, an artifact, a language.
• One thing is refused: config cannot change a subagent's type or give it write tools. The skill says so and carries on.
• It's untrusted input. A paad/config/ in a repo you cloned was written by someone else, and a skill will follow it. Read it before you run anything.
• Results vary. If a config line matters, check the output for it.

The full details are in CONFIG.md.

What PAAD can't fix

An engineer has to drive this — including knowing when the tool is wrong.

• PAAD reports; you decide. A finding is an argument, not a verdict — see The AI sees all of your code and none of your context.
• It's non-deterministic, like the assistant it's checking. Run it twice on the same branch and you'll get overlapping, not identical, results. Run the important ones more than once.