106.9K+Télécharger
Aller au guide d’utilisation
Brief to Taskspar julianoczkowski

Brief to Tasks Skill.

Transformez un brief de design en unités de réalisation évaluables séparément.

  • Planification des tâches
  • Dépendances
Télécharger OpenDesignVoir le guide d'utilisation
Analyse de la source · brief-to-tasksSKILL.md
Tâche Transformez un brief de design en unités de réalisation évaluables séparément. Livrables Une liste TASKS.md enregistrée à côté du brief de design de la fonctionnalité. Avant de commencer Générer la liste ne réalise ni ne vérifie la fonctionnalité à lui seul.
Synthèse éditoriale · source vérifiée le 2026-11-02 · pas un exemple généré

01 Fonctionnement

Transformez un brief de design en unités de réalisation évaluables séparément

Transformez un brief de design en liste TASKS.md ordonnée, avec réutilisation des composants, dépendances, priorités visuelles et unités d’interface vérifiables.

Flux de travail fondé sur la sourcePas un benchmark d'exécution

La méthode de travail

Brief to Tasks transforme un brief de design en liste de réalisation ordonnée. Chaque tâche comprend suffisamment de structure, de styles et d’interactions pour produire un résultat visible qui peut être évalué seul. Cela aide à décider quoi terminer en premier et quelles preuves montrent qu’une unité respecte le brief.

Avant de créer les tâches, le skill examine les pages, composants, tokens, dépendances et tests existants. Il distingue réutilisation, modification et création afin que le plan reflète le dépôt réel. Les dépendances, l’importance visuelle et l’incertitude déterminent l’ordre, plutôt qu’une séparation générique en phases HTML, CSS et JavaScript.

Livrables attendus

  • Une liste TASKS.md enregistrée à côté du brief de design de la fonctionnalité.
  • Le statut de chaque tâche : réutilisation, modification ou création de composants.
  • Des dépendances, états couverts et critères de fin explicites.
Voir l'exemple de brief

Du brief à la revue

  1. 01
    Lire le contexte de design

    Repérez le fichier actif .design/<feature-slug>/DESIGN_BRIEF.md et, s’ils existent, son INFORMATION_ARCHITECTURE.md ou fichier de tokens. Si plusieurs dossiers de fonctionnalités existent, identifiez d’abord celui concerné pour éviter une liste fondée sur des exigences sans rapport.

  2. 02
    Recenser les éléments réutilisables

    Examinez composants, vues, styles, dépendances et conventions de test. Classez les éléments pertinents comme réutilisables, à modifier ou manquants.

  3. 03
    Créer et ordonner des unités complètes

    Réunissez structure, styles et comportement dans des tâches évaluables. Placez les dépendances en premier tout en exposant tôt la direction visuelle et les travaux les plus risqués.

  4. 04
    Enregistrer une liste exploitable

    Écrivez TASKS.md dans le même dossier de fonctionnalité. Précisez les états et vérifications attendus pour chaque unité, ainsi qu’une dernière tâche de revue du design.

02 Cas d’usage

Quand l’utiliser

Générer la liste ne réalise ni ne vérifie la fonctionnalité à lui seul.

Un bon choix

  • Un brief est validéL’équipe a besoin d’un ordre de réalisation concret qui préserve l’intention de design.
  • Un produit existant évolueUne fonctionnalité doit réutiliser les composants établis plutôt que prévoir de tout recréer.

Limites à vérifier

  • Un livrable de planificationGénérer la liste ne réalise ni ne vérifie la fonctionnalité à lui seul.
  • Des unités de bout en boutUne simple tâche de configuration ou de création de dossiers ne correspond pas à la définition d’une unité de réalisation donnée par la source.

Éléments à fournir

  • Brief de designFournissez la fonctionnalité choisie et ses exigences.
  • Interface existanteRendez accessibles les répertoires de composants, les tokens et les vues actuelles.
  • Contraintes de réalisationIncluez les dépendances, conventions de test et états responsive ou interactifs requis.

03 Décisions importantes

Les choix importants

  1. Des progrès évaluables

    Chaque tâche produit une interface vérifiable par rapport au brief.

  2. Une réutilisation visible

    La liste indique où les composants existants sont réutilisés ou modifiés.

  3. Vérifier plus tôt les incertitudes

    Les travaux risqués et visuellement importants précèdent les détails périphériques.

04 Exemple de brief

Essayez un brief ciblé

L'exemple de brief ci-dessous n'a pas été testé. Vérifiez la configuration du skill avant de l'utiliser.

Examiner la source et la configuration

Fournissez la fonctionnalité choisie et ses exigences.

Fichier source amont
https://github.com/julianoczkowski/designer-skills/blob/c259656c76d9758d7ead46b0d2f125cbe84f8665/brief-to-tasks/SKILL.md

La référence ci-dessous ouvre les instructions d’origine. Vérifiez la configuration du dépôt avant de les utiliser ; ce n’est pas une commande d’installation.

Commencer par un seul livrable

Adaptez le périmètre, les sources et les contraintes de ce brief avant d’exécuter le skill.

Exemple de brief
Utilise brief-to-tasks pour le brief validé des paramètres du projet dans .design. Lis son architecture de l’information et nos fichiers de tokens, puis examine les composants réutilisables de formulaire, navigation et retour utilisateur. Crée une liste TASKS.md d’unités complètes comprenant chacune structure, styles et interactions. Indique si chaque unité réutilise, modifie ou crée des composants. Traite les dépendances en premier et place tôt l’interaction de paramètres la plus incertaine. Inclue les états vide, d’erreur et d’enregistrement en cours lorsque nécessaire, avec des vérifications de fin concrètes et une dernière revue du design. Ne commence pas l’implémentation pendant cette passe.

Vérifier le résultat

Comparez le résultat réel à ces critères observables.

  • Chaque tâche indique clairement réutilisation, modification ou création.
  • Les dépendances sont explicites et chaque unité a un résultat vérifiable.
  • La liste préserve la direction visuelle et les états requis par le brief.

OpenDesign fournit un espace de travail de design local pour les agents de code. Cette fiche ne signifie pas que le skill est fourni avec ses outils externes, ses identifiants et ses dépendances logicielles.

Télécharger OpenDesignLire le guide de démarrage rapide

05 Source et licence

Source et licence

Cette page décrit la révision source figée liée ci-dessous. Le comportement et les exigences en amont peuvent changer.

Propriétaire de la source
julianoczkowski
Dépôt
julianoczkowski/designer-skills
Fichier du skill
SKILL.md
Licence
Apache-2.0
Version examinée
2026-11-02 · c259656c76d9
Résumé éditorial de la source
Transformez un brief de design en unités de réalisation évaluables séparément.

Résumé original de OpenDesign, fondé sur la source liée. Les étoiles du dépôt sont un indicateur de popularité daté, pas une mesure d'utilisation du skill ni une note de qualité.

06 Questions avant de commencer

Questions avant de commencer

Où enregistrer la liste ?

La source enregistre TASKS.md dans le même dossier de fonctionnalité .design que le brief.

Les styles doivent-ils former une phase séparée ?

Chaque unité complète associe structure, styles et interactions pour permettre une évaluation indépendante.

Et si un composant adapté existe déjà ?

Réutilisez-le tel quel si possible. Seuls les éléments à modifier ou à créer font l’objet de tâches distinctes.

OpenDesign

Gardez votre brief et votre travail de design au même endroit.

Gardez votre brief, vos sources et votre travail de design ensemble dans un espace de travail local. Vérifiez la configuration propre au skill avant de l'ajouter à votre flux de travail.

Télécharger OpenDesignParcourir les skills de design
Fichier source amont
https://github.com/julianoczkowski/designer-skills/blob/c259656c76d9758d7ead46b0d2f125cbe84f8665/brief-to-tasks/SKILL.md