Communitygithub.com

caseycme/skills

Orchestre l'intégralité du cycle de vie d'une fonctionnalité : Affiner → Système de conception → Architecture → Construire → Vérifier la préparation à la production. À utiliser au démarrage d'une story, lors de l'implémentation complète d'une fonctionnalité ou pour finaliser le travail avant une PR. Le parent coordonne les compétences enfants — il ne duplique pas leurs règles.

Qu'est-ce que skills ?

Cette compétence agit comme un orchestrateur pour guider le développement d'une fonctionnalité de bout en bout, depuis le raffinement jusqu'à la vérification avant PR. Elle définit un flux en cinq phases, chacune déléguée à une compétence enfant spécialisée : refinement, design-system, architecture, build, et verify. Elle produit un plan unique et synthétique après les phases de planification, puis exécute la construction et la validation. Idéale pour les développeurs travaillant avec des assistants IA comme Claude Code ou Cursor sur des projets structurés, elle s'assure que chaque étape respecte les standards établis sans duplication d'effort.

Compatible avec✓Claude Code~Codex CLI~Cursor
Part ofDesign & UI
npx skills add https://github.com/caseycme/skills/tree/HEAD/skills/feature-development
Voir l'original→Voir toutes les compétences

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentation

Développement de fonctionnalités

Planifier selon les standards → construire selon les standards → vérifier selon les standards.

Cette compétence orchestre uniquement. Chaque phase délègue à une compétence enfant. Ne pas reformuler les workflows enfants ici.

PhaseCompétenceCheminMode (compétence enfant)
1refinerefine/SKILL.md—
2design-systemdesign-system/SKILL.mdPLAN
3architecturearchitecture/SKILL.mdPLAN
4buildbuild/SKILL.mdBUILD
5verifyverify/SKILL.mdgate de production

Utiliser feasibility avant la phase 1 lorsque l'équipe a besoin d'un verdict prêt/pas prêt pour décider de commencer.

Workflow

Avancement de la planification :
- [ ] 1. Affiner
- [ ] Décisions résolues (si applicable)
- [ ] 2. Système de conception (PLAN)
- [ ] 3. Architecture (PLAN)
- [ ] Plan de développement de fonctionnalité émis
- [ ] 4. Construire
- [ ] 5. Vérifier la préparation à la production
- [ ] Prêt pour PR

1. Affiner

Invoquer : refine/SKILL.md

Transmettre : clé du ticket ou contenu collé, liens Figma/conception, epic parent, contexte de discussion.

Sortie : quoi/comment suffisamment clair pour estimer ; décisions ouvertes nommées ou résolues ; brief de raffinement consolidé lorsque les décisions sont prises.

Barrière : s'arrêter pour les Questions nécessitant une décision avant la phase 2.

2. Système de conception

Invoquer : design-system/SKILL.md en mode PLAN.

Transmettre : brief de raffinement, Figma/captures d'écran, routes/surfaces concernées.

Sortie : recommandations de réutilisation, modifications PL potentielles, séquencement (PL PR si applicable). Ou « non applicable (pas d'interface utilisateur) » en une ligne.

3. Architecture

Invoquer : architecture/SKILL.md en mode PLAN.

Transmettre : brief de raffinement, plan du système de conception (si applicable), routes/API/champs de session concernés.

Sortie : liste de contrôle thème applicable avec précédents du dépôt.

Après 1–3 : émettre le plan combiné une seule fois.

4. Construire

Invoquer : build/SKILL.md.

Transmettre : brief de raffinement, sortie PLAN du système de conception, liste de contrôle PLAN de l'architecture.

Sortie : implémentation sur la branche conforme à ces standards.

5. Vérifier la préparation à la production

Invoquer : verify/SKILL.md — gate unique avant PR. Ne pas exécuter les REVIEW du système de conception ou de l'architecture séparément ; verify les possède.

Transmettre : brief de raffinement / critères d'acceptation, sortie PLAN du système de conception, liste de contrôle PLAN de l'architecture, diff de branche.

Sortie : RÉUSSI | PARTIEL | ÉCHEC, état de préparation pour PR, et ce qui a été vérifié/corrigé.

Règles d'orchestration

  • Les compétences enfants possèdent leur comportement. Lire et suivre la compétence liée pour chaque phase.
  • Transmettre le contexte — chaque phase consomme les sorties précédentes.
  • Un seul artefact de planification après les phases 1–3 ; ne pas déverser trois rapports complets.
  • Verify nécessite du code — ignorer les phases 4–5 lors des invocations de planification uniquement, sauf si l'implémentation existe déjà.
  • Avant PR est la phase 5 uniquement — pas de « relancer l'architecture avant PR » séparé.

Lors de l'invocation

IntentionExécution
Planifier une nouvelle storyPhases 1–3 → plan combiné
Implémenter une fonctionnalitéPhase 4 (après 1–3, ou avec brief existant)
Finaliser / avant PRPhase 5
Cycle de vie complet1 → 2 → 3 → plan → 4 → 5

Plan combiné (après les phases 1–3)

Synthétiser les sorties des enfants. Ne pas réimprimer les rapports complets des enfants.

# Plan de développement de fonctionnalité : [ticket ou titre]

## Résumé

[3–5 phrases issues du raffinement + blocages + état de préparation pour l'estimation]

## Raffinement

[Conclusions delta, brouillon des critères d'acceptation, suivis — issus de la sortie de la compétence refine]

## Système de conception (PLAN)

[Issu du mode PLAN du système de conception — ou « Non applicable »]

## Architecture (PLAN)

[Issu de la liste de contrôle du mode PLAN de l'architecture]

## Décisions ouvertes

[Vide si le raffinement est terminé]

## Suite

→ Phase 4 Construire, puis phase 5 Vérifier

Après la vérification (phase 5)

Ajouter ou retourner la sortie de la compétence verify (voir verify/SKILL.md). Le parent ne définit pas les sections de verify — l'enfant possède le rapport.

Compétences enfants

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

caseycme/skills

Guides systematic refactoring to align features with established patterns, remove duplication, and improve code reuse. Includes DataGrid/pattern-library, typing, fetch pagination, view-model vs override-prop guidance, and MUI sx-first layout (avoid deprecated Box style shorthand props). Use when refactoring features, consolidating duplicate code, extracting shared utilities, or aligning patterns across similar features.

caseycme/skills

>- Design-system guidance in three modes: PLAN (prospective reuse and abstractions before build), BUILD (apply those standards while implementing), REVIEW (audit branch diff against them). Use in feature-development phases 2, 4, and 5; or standalone for inline styles, sx, custom CSS, one-off cards, or pattern-library scope. Formerly pattern-library-refactor.

Skills associés

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community