Plan Document Validation

VerifiedCaution

Validates plan document structure and frontmatter, ensuring compliance and proper formatting before commits.

Sby Skills Guide Bot
DocumentationIntermediate
8/6/2026
Claude Code
#plan-validation#yaml-frontmatter#schema-validation#documentation-quality#design-docs

Recommended for

Automated summary

This skill checks plan documents for compliance — YAML frontmatter, required fields, status/progress alignment and date ordering — using the validate-plan.sh script and the design.config.json configuration.

Strengths

  • Enforces concrete business rules: status-progress alignment (ready = 0%, completed = 100%) and correct date ordering
  • Produces an error/warning report with actionable recommendations, plus a --strict mode for stale plans
  • --all and --fix modes validate an entire directory or auto-correct common issues
  • Also checks optional relationships (modules, implements, phases) against the project configuration

Limitations

  • Assumes a project wired for the design-docs plugin with .claude/design/design.config.json and the co-located validate-plan.sh script
  • Validates structure and metadata only, not the writing quality or substance of the plan
  • The strict-mode description is cut off, so some checks (staleness, bidirectional links) are only partially documented
When to use it

Use it before committing or reviewing to confirm that one plan or the whole plan set matches the project's frontmatter contract.

When not to use it

Skip it if your project doesn't use the design-docs plugin, or if you want an editorial review of the plan's content rather than a structural check.

Security analysis

Caution
Quality score80/100

Nothing here is destructive or exfiltrating: no rm -rf, no curl|sh, no base64 payloads, no secrets sent outward, no safety-disabling instructions. However, the broad `Bash(bash *)` grant, execution of an unaudited co-located shell script, runtime fetching of a schema from a mutable remote branch, and a `--fix` mode that mutates repository files mean the skill should be listed with caution and the bundled script reviewed before use.

Findings
  • •allowed-tools `Bash(bash *)` permits arbitrary bash execution, far broader than a read-only validator needs (would only need to run one fixed script).
  • •The skill delegates core work to `scripts/validate-plan.sh`, which is not included in the SKILL.md; its behavior cannot be audited from the manifest alone.
  • •Fetches a JSON schema from a mutable `main` branch on raw.githubusercontent.com at runtime with no integrity pinning/checksum — remote-content supply-chain drift.
  • •`--fix` mode writes/modifies plan files (dates, field formats), so the skill is not purely read-only despite its framing.
  • •Invokes namespaced commands (`/design-docs:plan-validate`) whose implementation is external to this file.
How this analysis is made

Examples

Validate one plan
Validate the plan document plan-design-linking-phase-1 and tell me if its frontmatter is compliant before I commit it.
Validate everything
Run /design-docs:plan-validate --all and summarize which plans fail validation and why.
Strict check with fixes
/design-docs:plan-validate my-feature-plan --strict --fix — fix the dates and formatting where possible and report what still needs manual attention.

name: plan-validate description: Validate plan document structure and frontmatter. Use when checking plans for compliance, ensuring proper formatting, or verifying metadata before commits. allowed-tools: Read, Bash(bash *) context: fork agent: design-doc-agent

Plan Validation

Validates plan documentation files for structure, frontmatter, and quality compliance.

Overview

This skill validates plan documents by:

  1. Reading the plan configuration from design.config.json
  2. Finding plan files for validation
  3. Validating YAML frontmatter structure and values
  4. Checking required fields and data types
  5. Validating status-progress alignment
  6. Validating dates and field relationships
  7. Reporting issues with actionable recommendations

Quick Start

Validate specific plan:

/design-docs:plan-validate plan-design-linking-phase-1

Validate all plans:

/design-docs:plan-validate --all

Validate with strict mode:

/design-docs:plan-validate plan-design-linking-phase-1 --strict

How It Works

1. Parse Parameters

  • plan-name: Plan name/ID to validate (or --all for all plans) [REQUIRED]
  • --strict: Enable strict mode with additional quality checks
  • --fix: Auto-fix issues when possible

2. Load Configuration

Read .claude/design/design.config.json to get:

  • Plan paths and directories
  • Quality standards for plans
  • Required frontmatter fields
  • Valid status values
  • Progress range limits

The canonical JSON schema for plan frontmatter is published at https://raw.githubusercontent.com/spencerbeggs/design-docs-plugin/main/plan-frontmatter.schema.json — fetch it when a machine-checkable definition of the frontmatter contract is needed.

3. Locate Plan File

Use the plan name to find the file:

  • Check .claude/plans/{plan-name}.md
  • If not found, check .claude/plans/_archive/{plan-name}.md
  • Report error if file doesn't exist

4. Validate Plan Document

Execute scripts/validate-plan.sh (co-located with this skill) which checks:

Required Fields:

  • name (kebab-case format)
  • title (non-empty string)
  • created (YYYY-MM-DD format)
  • status (valid enum value)
  • progress (0-100 integer)

Status Values:

  • ready
  • in-progress
  • blocked
  • completed
  • abandoned

Status-Progress Alignment:

  • ready: progress must be 0%
  • in-progress/blocked: progress 1-99%
  • completed: progress must be 100%

Date Validation:

  • All dates in YYYY-MM-DD format
  • created ≤ updated
  • started ≤ completed (if both present)

Completion Requirements:

  • Status completed: requires completed date and outcome
  • Status abandoned: requires completed date and archival-reason

Optional Field Validation:

  • modules: must exist in design.config.json
  • implements: paths must point to existing design docs
  • phases: each phase has required fields (name, status, progress)

5. Generate Report

Output validation results:

Success:

✓ Plan validation passed: plan-design-linking-phase-1
  ✓ All required fields present
  ✓ Status-progress aligned (ready, 0%)
  ✓ Dates valid and in order
  ✓ No issues found

Failure:

✗ Plan validation failed: plan-design-linking-phase-1

Errors (3):
  ✗ Missing required field: status
  ✗ progress: 150 (must be integer 0-100)
  ✗ Status 'completed' requires 'outcome' field

Warnings (1):
  ⚠ Status 'ready' should have progress 0%, found 25%

Usage Patterns

Validate Before Commit

# Check plan before committing
/design-docs:plan-validate my-feature-plan

Validate All Plans

# Check entire plan directory
/design-docs:plan-validate --all

Fix Common Issues

# Auto-fix when possible (updates dates, formats fields)
/design-docs:plan-validate my-feature-plan --fix

Strict Validation

# Additional quality checks
/design-docs:plan-validate my-feature-plan --strict

Strict mode adds:

  • Check for stale plans (no updates >30 days)
  • Verify bidirectional links to design docs
  • Check for orphaned plans (no implements field)
  • Validate estimated vs actual effort alignment

Implementation Steps

  1. Parse arguments from user input (plan name, flags)
  2. Read config from .claude/design/design.config.json
  3. Locate plan file in .claude/plans/ or _archive/
  4. Execute validation script scripts/validate-plan.sh
  5. Parse script output to extract errors/warnings
  6. Check additional rules if strict mode enabled
  7. Generate report with colored output and recommendations
  8. Return exit code (0 = pass, 1 = fail)

Error Messages

Missing Required Fields

✗ Missing required field: {field}

Fix: Add '{field}: value' to the plan frontmatter

Invalid Status Value

✗ status: '{value}' (must be one of: ready, in-progress, blocked,
  completed, abandoned)

Fix: Change status to a valid value

Status-Progress Mismatch

⚠ Status 'ready' should have progress 0%, found {value}%

Fix: Either set progress to 0 or change status to 'in-progress'

Invalid Date Format

✗ {field}: {value} (must be YYYY-MM-DD)

Fix: Use format YYYY-MM-DD (e.g., 2026-01-18)

Missing Completion Fields

✗ Status 'completed' requires 'outcome' field

Fix: Add 'outcome: success|partial|failed' to frontmatter

Examples

See examples.md for detailed usage examples.

Related Skills

  • design-docs:plan-create - Create new plans
  • design-docs:plan-complete - Complete a plan and persist knowledge to design docs
  • design-docs:plan-list - List all plans
  • design-docs:design-validate - Validate design docs

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/plan-document-validation-msh3ut0b/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/plan-document-validation-msh3ut0b' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/plan-document-validation-msh3ut0b/download' --output '.skill-downloads/plan-document-validation-msh3ut0b/SKILL.md.part' && mv '.skill-downloads/plan-document-validation-msh3ut0b/SKILL.md.part' '.skill-downloads/plan-document-validation-msh3ut0b/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

Tools declared by the author (check availability in your agent): Read, Bash(bash *)

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.

Claude Code
test -f '.skill-downloads/plan-document-validation-msh3ut0b/SKILL.md' && test -s '.skill-downloads/plan-document-validation-msh3ut0b/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/plan-validate' && cp -R '.skill-downloads/plan-document-validation-msh3ut0b' '.claude/skills/plan-validate'

OpenSkills

OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.

Official OpenSkills installation
openskills install './.skill-downloads/plan-document-validation-msh3ut0b'

openskills read 'plan-document-validation-msh3ut0b'

Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.

For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.

openskills sync

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/plan-document-validation-msh3ut0b/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills