mcpField
P
planify-write-plan

planify-write-plan

github.com/aymericderboisDevelopment62 installs
Repository

About planify-write-plan

A writing skill that turns a structured `planify` summary into `plan.md` and `tech.md`. It formats supplied decisions without adding tasks or constraints, for agents preparing implementation plans.

Key features

  1. 01Creates `plan.md` and `tech.md`
  2. 02Preserves existing plan content when updating
  3. 03Uses the supplied output path
  4. 04Keeps tasks ordered and verifiable

Use cases

  1. 01Turn a `planify` summary into readable planning files
  2. 02Update an existing plan with new summary details

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/aymericderbois/skills --skill planify-write-plan

After installing, type/planify-write-planin Claude Code to confirm it loaded.

Details

From the project README

Rédaction du plan

Tu mets en forme, tu ne décides rien. Tu reçois le récapitulatif structuré assemblé par planify (dans la conversation) et tu le coules dans deux fichiers. Tu ne reposes aucune question, ne prends aucune décision, et n'inventes aucune tâche ni contrainte absente du récapitulatif.

Règles

  • Tu dois faire des phrases courtes et concretes.
  • Tu dois utiliser des termes simples et précis.
  • Tu dois éviter les mots-valise et les expressions trop générales.
  • Tu dois faire des retours à la ligne pour que le fichier soit facile à lire.

Dossier de sortie

  1. Utiliser le chemin .task/<KEY>/<prefix>/ transmis par planify dans le récapitulatif.
  2. Créer ce dossier s'il n'existe pas. Si le chemin manque, le signaler à planify sans le choisir.

Reprise : si plan.md existe déjà dans ce dossier, le mettre à jour avec Edit (fusionner les changements du récapitulatif, préserver le reste) plutôt que de l'écraser aveuglément.

plan.md — lisible, facile à relire

# Plan — [titre]

## Contexte

[le pourquoi, couvrant la ou les fonctionnalités]

> Hors périmètre : [ce qu'on exclut explicitement — retirer la ligne s'il n'y a rien]

## T1 — [titre court]

[description de ce qu'il faut faire — technique et court extrait de code si cela aide à visualiser]

Contraintes d'acceptation :
- [ ] [condition à satisfaire]
- [ ] [condition à satisfaire]

## T2 — …

Règles : les tâches sont ordonnées par leur position (pas de champ de dépendance). Une tâche correspond à un changement de la taille d'un commit, facile à relire. Les contraintes forment une liste à cocher de conditions vérifiables (observables ou non : performance, sécurité, invariant) — pas de format « lorsque/alors » imposé.

tech.md — index technique dense pour l'agent

N'est pas relu par un humain. La densité et la précision priment.

# Technique — [titre]

## Fichiers concernés
### À créer
- `apps/<app>/...`
### À modifier
- `apps/<app>/models.py` — [quoi]

## Motifs réutilisés
- [nom] — `apps/.../foo.py` — comment il s'applique ici.

## Décisions techniques (mini-ADR)
### D1 — [titre]
**Contexte** · **Décision** · **Alternatives écartées** (et pourquoi) · **Conséquences**

## Éléments transverses
- migrations · permissions et sécurité · drapeaux de fonctionnalité · données de test utiles

Retirer une section si le récapitulatif n'a rien à y mettre.

Fin

Signaler les deux chemins écrits et rappeler que l'implémentation se fait en mode plan natif sur .task/<KEY>/<prefix>/plan.md.

Comments

Markdown supported