Validation de plans

VérifiéPrudence

Valide la structure et le frontmatter des documents de plan, en vérifiant la conformité et le formatage avant les commits.

Spar Skills Guide Bot
DocumentationIntermédiaire
06/08/2026
Claude Code
#plan-validation#yaml-frontmatter#schema-validation#documentation-quality#design-docs

Recommandé pour

Synthèse automatique

Ce skill vérifie la conformité des documents de plan (frontmatter YAML, champs obligatoires, cohérence statut/progression et dates) via le script validate-plan.sh et la configuration design.config.json.

Points forts

  • Contrôle des règles métier précises : alignement statut-progression (ready = 0 %, completed = 100 %) et ordre des dates
  • Rapport d'erreurs et d'avertissements avec recommandations actionnables, plus un mode --strict pour les plans obsolètes
  • Modes --all et --fix pour valider tout un répertoire ou corriger automatiquement les problèmes courants
  • Vérifie aussi les relations optionnelles (modules, implements, phases) par rapport à la configuration du projet

Limites

  • Suppose un projet équipé du plugin design-docs avec .claude/design/design.config.json et le script validate-plan.sh co-localisé
  • Ne valide que la structure et les métadonnées, pas la qualité rédactionnelle ni la pertinence du contenu du plan
  • La description du mode strict est tronquée et certaines vérifications (fraîcheur, liens bidirectionnels) restent partiellement documentées
Quand l'utiliser

À utiliser avant un commit ou une revue pour s'assurer qu'un plan ou l'ensemble des plans respectent le contrat de frontmatter du projet.

Quand l'éviter

À éviter si votre projet n'utilise pas le plugin design-docs ou si vous cherchez une relecture de fond du contenu du plan plutôt qu'un contrôle de structure.

Analyse de sécurité

Prudence
Score qualité80/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.

Points d'attention
  • •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.
Comment cette analyse est faite

Exemples

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

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/plan-document-validation-msh3ut0b/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

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. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Outils déclarés par l’auteur (à vérifier dans votre agent) : Read, Bash(bash *)

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.

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 doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.

Installation officielle d’OpenSkills
openskills install './.skill-downloads/plan-document-validation-msh3ut0b'

openskills read 'plan-document-validation-msh3ut0b'

La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.

Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.

openskills sync

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/plan-document-validation-msh3ut0b/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires