From paad
Verifies alignment between requirements/specs/PRDs and plans/tasks/implementation steps; detects coverage gaps, scope creep, design mismatches; rewrites tasks in TDD red/green/refactor format.
npx claudepluginhub ovid/paad --plugin paadThis skill uses the workspace's default tool permissions.
Verifies that intent documents (requirements, specs, PRDs) and action documents (plans, tasks, implementation steps) are aligned. Finds gaps in both directions — unaddressed requirements and out-of-scope tasks — then rewrites all tasks in TDD red/green/refactor format.
Transforms design documents into TDD-based implementation plans with parallelizable tasks. Enforces the Iron Law: no production code without a failing test first.
Reviews code implementation against task file requirements, extracting and verifying every spec scenario (WHEN/THEN) and Done When criterion. Identifies and reports gaps before shipping.
Reviews task-mapping.md and tasks.md for gaps in vertical slice completeness, TDD structure, story coverage, dependencies, and traceability; generates classified issues.
Share bugs, ideas, or general feedback.
Verifies that intent documents (requirements, specs, PRDs) and action documents (plans, tasks, implementation steps) are aligned. Finds gaps in both directions — unaddressed requirements and out-of-scope tasks — then rewrites all tasks in TDD red/green/refactor format.
This skill does NOT recommend a fresh session. The conversation history may contain the documents.
digraph alignment {
"Has $ARGUMENTS?" [shape=diamond];
"Conversation has docs?" [shape=diamond];
"Found in common locations?" [shape=diamond];
"Both sides found?" [shape=diamond];
"Git repo?" [shape=diamond];
"Source control conflicts?" [shape=diamond];
"Classify files as intent/action" [shape=box];
"Confirm with user" [shape=box];
"Present candidates, ask user" [shape=box];
"STOP: tell user what's missing" [shape=box, style=bold];
"Skip Reality Check" [shape=box];
"Present conflicts, resolve first" [shape=box];
"Proceed to Alignment Analysis" [shape=box];
"Has $ARGUMENTS?" -> "Classify files as intent/action" [label="yes"];
"Has $ARGUMENTS?" -> "Conversation has docs?" [label="no"];
"Conversation has docs?" -> "Confirm with user" [label="yes"];
"Conversation has docs?" -> "Found in common locations?" [label="no"];
"Found in common locations?" -> "Present candidates, ask user" [label="yes"];
"Found in common locations?" -> "STOP: tell user what's missing" [label="no"];
"Classify files as intent/action" -> "Both sides found?";
"Confirm with user" -> "Both sides found?";
"Present candidates, ask user" -> "Both sides found?";
"Both sides found?" -> "Git repo?" [label="yes"];
"Both sides found?" -> "STOP: tell user what's missing" [label="no"];
"Git repo?" -> "Source control conflicts?" [label="yes"];
"Git repo?" -> "Proceed to Alignment Analysis" [label="no"];
"Source control conflicts?" -> "Present conflicts, resolve first" [label="yes"];
"Source control conflicts?" -> "Proceed to Alignment Analysis" [label="no"];
"Present conflicts, resolve first" -> "Proceed to Alignment Analysis";
}
/paad:alignment accepts optional $ARGUMENTS:
/paad:alignment — auto-detect documents from conversation history or common file locations/paad:alignment requirements.md plan.md — check alignment between specific files/paad:alignment docs/specs/ docs/plans/ — check alignment across directoriesWhen file paths are provided, the skill classifies each as intent or action and proceeds. When multiple files are provided, the skill determines their relationships automatically.
Resolve the documents to check in this order:
$ARGUMENTS contains file paths → use those files, classify each as intent (what we want) or action (what we'll do) based on content.kiro/ — Kiro requirements, design, and task filesspecs/ — spec-kit feature specs and plans (spec.md, plan.md per feature folder); also check SPECIFY_SPECS_DIR env var.specify/memory/constitution.md — spec-kit project constitutiondocs/plans/, docs/specs/ — common conventionsrequirements.md, design.md, tasks.md, spec.md, plan.md, PRD.md — repo rootSkip this phase if the project is not a git repository.
Before analyzing document alignment, check whether recent codebase changes conflict with what the documents assume:
git log --oneline -50 --since="2 weeks ago" (whichever limit is reached first)Perform three checks against the classified documents:
For every item in the intent documents, check whether at least one action item addresses it.
For every item in the action documents, check whether it traces back to a stated requirement.
Check both directions:
Present issues dependency-ordered so that fixing upstream problems first may resolve downstream ones:
The user can say "good enough" or "stop" at any point.
After all issues are addressed (or user says "good enough"):
Ask: "Would you like me to update the documents to reflect our alignment decisions, or write a separate alignment report?"
If updating documents:
If writing a report:
Write to paad/alignment-reviews/<YYYY-MM-DD>-<topic>-alignment.md.
Create the paad/alignment-reviews/ directory if it doesn't exist.
Report template:
# Alignment Review: <topic or project name>
**Date:** YYYY-MM-DD
**Commit:** <current HEAD sha, or "N/A">
## Documents Reviewed
- **Intent:** <file paths or "conversation history">
- **Action:** <file paths or "conversation history">
- **Design:** <file paths, or "none">
## Source Control Conflicts
<conflicts found, or "None — no conflicts with recent changes.">
## Issues Reviewed
### [1] <title>
- **Category:** <missing coverage / out of scope / design gap>
- **Severity:** <critical / important / minor>
- **Documents:** <which documents are misaligned>
- **Issue:** <what's wrong>
- **Resolution:** <what the user decided>
(Repeat for each issue discussed.)
## Unresolved Issues
(Issues not yet discussed. Omit section if all were addressed.)
## Alignment Summary
- **Requirements:** N total, M covered, K gaps
- **Tasks:** N total, M in scope, K orphaned
- **Design items:** N total, M aligned (if applicable)
- **Status:** <aligned / needs further work>
If documents came from conversation history: Ask: "The documents aren't saved to files yet. Where should I write them?" Suggest a reasonable path based on project structure.
Once alignment is confirmed, check whether tasks should be rewritten in red/green/refactor format. Skip this step if:
If neither condition applies, rewrite action items in red/green/refactor format — it produces better implementations.
Why this works:
RED — Write a failing test first. Defines expected behavior before writing code. Occasionally the test passes immediately, revealing that the feature already exists or that assumptions are wrong. More commonly, the test fails in unexpected ways that highlight unknown issues in the codebase. Both outcomes are valuable information you'd otherwise miss.
GREEN — Write minimal code to pass. Forces simpler solutions. The AI looks at the problem more directly instead of over-engineering. Less speculative code means less "slop."
REFACTOR — Clean up what you just wrote. This is the step AI almost never does unless explicitly told to. It catches duplicated code that should be extracted, hard-coded values that belong in config, inconsistent patterns that should be consolidated, and other small issues that compound over time.
Format for each task:
### Task: <task name>
**Requirement:** <which requirement this addresses>
#### RED
- Write a test that: <what the test asserts>
- Expected failure: <how and why it should fail>
- If it passes unexpectedly: <what that would mean>
#### GREEN
- Implement: <minimal implementation to pass the test>
- Constraints: keep it simple — no anticipatory abstractions
#### REFACTOR
- Look for: <specific refactoring opportunities>
- Duplicated logic to extract
- Hard-coded values to move to config
- Patterns to consolidate with existing code
- Naming improvements
Rewrite the tasks in the action document in-place, or write to a new file if the user prefers.