request-refactor-plan

par mattpocock

Créer un plan de refactorisation détaillé avec de petits commits via un entretien utilisateur, puis le déposer en tant que ticket GitHub. À utiliser lorsque l'utilisateur souhaite planifier une refactorisation, créer un RFC de refactorisation, ou décomposer une refactorisation en étapes incrémentales sûres.

npx skills add https://github.com/mattpocock/skills --skill request-refactor-plan
Télécharger ZIPGitHub
196.2k

This skill will be invoked when the user wants to create a refactor request. You should go through the steps below. You may skip steps if you don't consider them necessary.

  1. Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions.

  2. Explore the repo to verify their assertions and understand the current state of the codebase.

  3. Ask whether they have considered other options, and present other options to them.

  4. Interview the user about the implementation. Be extremely detailed and thorough.

  5. Hammer out the exact scope of the implementation. Work out what you plan to change and what you plan not to change.

  6. Look in the codebase to check for test coverage of this area of the codebase. If there is insufficient test coverage, ask the user what their plans for testing are.

  7. Break the implementation into a plan of tiny commits. Remember Martin Fowler's advice to "make each refactoring step as small as possible, so that you can always see the program working."

  8. Create a GitHub issue with the refactor plan. Use the following template for the issue description:

Problem Statement

The problem that the developer is facing, from the developer's perspective.

Solution

The solution to the problem, from the developer's perspective.

Commits

A LONG, detailed implementation plan. Write the plan in plain English, breaking down the implementation into the tiniest commits possible. Each commit should leave the codebase in a working state.

Decision Document

A list of implementation decisions that were made. This can include:

  • The modules that will be built/modified
  • The interfaces of those modules that will be modified
  • Technical clarifications from the developer
  • Architectural decisions
  • Schema changes
  • API contracts
  • Specific interactions

Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.

Testing Decisions

A list of testing decisions that were made. Include:

  • A description of what makes a good test (only test external behavior, not implementation details)
  • Which modules will be tested
  • Prior art for the tests (i.e. similar types of tests in the codebase)

Out of Scope

A description of the things that are out of scope for this refactor.

Further Notes (optional)

Any further notes about the refactor.

Plus de skills de mattpocock

improve-codebase-architecture
mattpocock
Trouver des opportunités d'approfondissement dans une base de code, en s'appuyant sur le langage du domaine dans CONTEXT.md et les décisions dans docs/adr/. Utiliser lorsque l'utilisateur souhaite améliorer l'architecture, trouver des opportunités de refactorisation, consolider des modules fortement couplés, ou rendre une base de code plus testable et navigable par l'IA.
developmentcode-reviewapi
tdd
mattpocock
Développement piloté par les tests avec boucle rouge-vert-refactorisation. À utiliser lorsque l'utilisateur souhaite développer des fonctionnalités ou corriger des bugs en utilisant le TDD, mentionne "rouge-vert-refactorisation", veut des tests d'intégration, ou demande un développement test-first.
developmenttesting
handoff
mattpocock
Compacter la conversation actuelle en un document de transfert pour qu’un autre agent puisse le reprendre.
communicationproject-managementdocument
prototype
mattpocock
Construisez un prototype jetable pour étoffer une conception avant de vous y engager. Achemine entre deux branches — une application terminal exécutable pour les questions d'état/logique métier, ou plusieurs variations d'interface utilisateur radicalement différentes, basculables depuis une seule route. À utiliser lorsque l'utilisateur souhaite prototyper, vérifier la cohérence d'un modèle de données ou d'une machine d'état, maquetter une interface utilisateur, explorer des options de conception, ou dit « prototype ceci », « laisse-moi jouer avec », « essaie quelques designs ».
developmentdesigncreative
triage
mattpocock
Trier les problèmes via une machine à états pilotée par des rôles de triage. Utiliser lorsque l'utilisateur souhaite créer un problème, trier des problèmes, examiner les bogues entrants ou les demandes de fonctionnalités, préparer des problèmes pour un agent AFK, ou gérer le flux de travail des problèmes.
developmentproject-managementcommunication
obsidian-vault
mattpocock
Rechercher, créer et gérer des notes dans le coffre Obsidian avec des wikiliens et des notes d’index. Utiliser lorsque l’utilisateur souhaite trouver, créer ou organiser des notes dans Obsidian.
productivitydocument
edit-article
mattpocock
Modifier et améliorer des articles en restructurant les sections, en améliorant la clarté et en resserrant la prose. À utiliser lorsque l'utilisateur souhaite éditer, réviser ou améliorer un brouillon d'article.
documentcreative
writing-great-skills
mattpocock
Référence pour bien rédiger et éditer des compétences — le vocabulaire et les principes qui rendent une compétence prévisible.
documentdevelopment