to-prd

Par mkurman · zorai

Transforme le contexte actuel de la conversation en PRD et soumet-le en tant que GitHub issue. À utiliser quand l'utilisateur souhaite créer un PRD à partir du contexte actuel.

npx skills add https://github.com/mkurman/zorai --skill to-prd

Cette skill prend le contexte de conversation actuel et la compréhension de la base de code pour produire un PRD. N'interviewer PAS l'utilisateur — synthétisez simplement ce que vous savez déjà.

Process

  1. Explorez le repository pour comprendre l'état actuel de la base de code, si vous ne l'avez pas déjà fait.

  2. Esquissez les modules majeurs que vous devrez construire ou modifier pour compléter l'implémentation. Recherchez activement les opportunités d'extraire des modules profonds qui peuvent être testés en isolation.

Un module profond (par opposition à un module superficiel) est un module qui encapsule beaucoup de fonctionnalité dans une interface simple et testable qui change rarement.

Vérifiez auprès de l'utilisateur que ces modules correspondent à ses attentes. Vérifiez auprès de l'utilisateur pour quels modules il souhaite que des tests soient écrits.

  1. Écrivez le PRD en utilisant le template ci-dessous et soumettez-le comme issue GitHub.

<prd-template>

Problem Statement

Le problème auquel l'utilisateur est confronté, du point de vue de l'utilisateur.

Solution

La solution au problème, du point de vue de l'utilisateur.

User Stories

Une LONGUE liste numérotée d'user stories. Chaque user story doit être au format :

  1. En tant que <acteur>, je veux <feature>, afin que <bénéfice>

<user-story-example>

  1. En tant que client bancaire mobile, je veux voir le solde de mes comptes, afin que je puisse prendre des décisions mieux informées concernant mes dépenses </user-story-example>

Cette liste d'user stories doit être extrêmement complète et couvrir tous les aspects de la feature.

Implementation Decisions

Une liste des décisions d'implémentation qui ont été prises. Cela peut inclure :

  • Les modules qui seront construits/modifiés
  • Les interfaces de ces modules qui seront modifiées
  • Les clarifications techniques du développeur
  • Les décisions architecturales
  • Les changements de schéma
  • Les contrats API
  • Les interactions spécifiques

N'incluez PAS de chemins de fichiers spécifiques ou d'extraits de code. Ils pourraient devenir obsolètes très rapidement.

Testing Decisions

Une liste des décisions de test qui ont été prises. Incluez :

  • Une description de ce qui fait un bon test (ne tester que le comportement externe, pas les détails d'implémentation)
  • Quels modules seront testés
  • Les précédents dans la base de code pour les tests (par ex. types de tests similaires dans la base de code)

Out of Scope

Une description des choses qui ne sont pas dans le périmètre de ce PRD.

Further Notes

Des notes supplémentaires sur la feature.

</prd-template>

Skills similaires