Workflow de projet pour PRD et suivi

VérifiéSûr

Définit un workflow pour les tâches non triviales : triage, PRD, suivi des tâches, synchronisation de la documentation et leçons apprises.

Spar Skills Guide Bot
DeveloppementIntermédiaire
27004/09/2026
Claude Code
#prd#task-tracking#changelog#docs-sync#project-workflow

Recommandé pour

Notre avis

Ce skill impose un déroulé de projet structuré : triage du problème, rédaction d'un PRD, suivi des tâches dans task.md, puis synchronisation de changelog.md, files.md et des leçons apprises.

Points forts

  • Cadre explicite pour les tâches non triviales : triage avant de toucher au code, puis PRD avec cause racine, fichiers à modifier, cas limites et étapes de vérification
  • Traçabilité durable via des horodatages UTC, des statuts Draft/In Progress/Done et un journal de complétion des tâches
  • Synchronisation documentaire systématique après chaque feature ou correction, avec un changelog au format Keep a Changelog alimenté par les dates réelles de git log
  • Boucle d'apprentissage : les corrections récurrentes de l'utilisateur sont consignées dans prds/lessons.md

Limites

  • Repose sur une convention de fichiers stricte (prds/, task.md, changelog.md, files.md) qui doit déjà exister ou être créée dans le projet
  • Le processus complet est volontairement lourd et n'est allégé que pour les corrections évidentes d'un seul fichier
  • Suppose l'accès à git log et aux sous-agents, ce qui le lie fortement à Claude Code
Quand l'utiliser

À utiliser dès qu'une demande implique plusieurs fichiers, un changement d'architecture ou un suivi de projet à mettre à jour.

Quand l'éviter

À éviter pour une faute de frappe, un ajustement de texte ou un correctif manifeste tenant en un seul fichier.

Analyse de sécurité

Sûr
Score qualité85/100

The skill only describes a project workflow: creating PRDs, updating task.md, changelog.md, files.md, using git log for dates, and optionally using subagents. It does not declare or invoke any dangerous tools, destructive commands, exfiltration, or obfuscated payloads. The only command mentioned is `git log --date=short -n 10`, which is benign and read-only.

Aucun point d'attention détecté

Exemples

Multi-file feature
Add cursor-based pagination to the /orders endpoint — it touches the controller, the repository layer and the API docs. Write a PRD first, then track the work in task.md.
Docs sync
@update — sync task.md, changelog.md and files.md now that the SSO redirect fix is merged.
Bug with unknown cause
Users get logged out randomly after about 10 minutes. Triage the likely causes, write a PRD with the root cause once found, and log the fix in the changelog.

name: workflow description: Project workflow for PRDs, task tracking, changelog sync, and documentation updates. Use for any non-trivial task that spans multiple steps, touches several files, changes architecture, or needs project tracking updates. Also activates with @update to sync task.md, changelog.md, and files.md after completing work.

Project Workflow Skill

Use this skill for any non trivial task that spans multiple steps, touches several files, changes architecture, or needs project tracking updates.

Activate with: @update (for docs sync only)

Triage first

Before changing code:

  1. Identify what is missing, broken, or incomplete.
  2. Theorize a few likely causes or approaches.
  3. Narrow to the most likely plan.
  4. Ask if anything important is still unclear.

Skip the long process only for obvious one file fixes like typos or tiny copy changes.

PRD rules

Create a PRD before non trivial work.

  • Path: prds/<feature-or-problem-slug>.md
  • Extension: .md
  • Include:
    • problem
    • root cause for bugs
    • proposed solution
    • files to change
    • edge cases
    • verification steps
    • task completion log

Add metadata at the top:

  • Created: YYYY-MM-DD HH:mm UTC
  • Last Updated: YYYY-MM-DD HH:mm UTC
  • Status: Draft | In Progress | Done

Task tracking

Update task.md as the work moves forward.

  • Put new work under ## to do
  • Move finished work to ## completed
  • Add timestamps in YYYY-MM-DD HH:mm UTC
  • Do not mark a task done until it has been verified
  • Keep task notes short but specific enough for the next session

When useful, include:

  • the PRD path
  • the files touched
  • the verification command or outcome

Docs sync after changes

After each feature or fix, sync the project docs:

  • task.md
  • changelog.md
  • files.md

For changelog.md:

  • use Keep a Changelog structure
  • get real dates from git log --date=short -n 10
  • add timestamps when helpful

For files.md:

  • add new files
  • update descriptions that changed
  • keep descriptions brief and concrete

Execution style

  • Use subagents for research or parallel analysis when the task is large enough to benefit.
  • Use one focused subagent per task.
  • Stop and re plan if the work stops making sense.
  • Keep the change set tight.
  • Ask whether a staff engineer would approve the result before calling it done.

Learning loop

If the user corrects a repeated pattern, record the lesson in prds/lessons.md so the mistake does not come back.

Skills similaires