Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

refactor-plan

Estrellas2

Forks0

Actualizado2 de julio de 2026 a las 11:20

Create a concrete plan before starting a multi-file refactor. Use when the user asks to plan, sequence, scope, or safely execute a refactor across multiple files; always investigate first, output the plan, and wait for confirmation before making code changes.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

FilippoDeSilva

FilippoDeSilva/skills

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

SKILL.md

readonly

name	refactor-plan
description	Create a concrete plan before starting a multi-file refactor. Use when the user asks to plan, sequence, scope, or safely execute a refactor across multiple files; always investigate first, output the plan, and wait for confirmation before making code changes.
version	1.0.0
license	MIT
author	[Filippo De Silva](https://github.com/FilippoDeSilva)
tags	["planning","refactoring","code-quality","best-practices","code-review"]

Refactor Plan

Create a detailed plan before making any code changes.

Instructions

Do not edit files while preparing the plan.
Search the codebase to understand the current state. Read enough implementation, tests, configuration, and docs to make the plan specific to the repository.
Identify affected files, ownership boundaries, dependencies, and likely hidden coupling.
Plan changes in a safe sequence. Prefer contracts and types first, then implementations, then callers, then tests, then cleanup.
Include verification steps between phases and a final validation command.
Include rollback or recovery steps for the riskiest phases.
Output the complete plan using the format below.
Stop after the plan and ask for confirmation before implementing. If the user already asked you to implement, still produce the plan first and wait for confirmation unless they explicitly said to continue without review after the plan.

If the request is too ambiguous to plan safely, ask concise clarifying questions instead of editing files.

Output Format

## Refactor Plan: [title]

### Current State
[Brief description of how things work now]

### Target State
[Brief description of how things will work after]

### Affected Files
| File | Change Type | Dependencies |
|------|-------------|--------------|
| path | modify/create/delete | blocks X, blocked by Y |

### Execution Plan

#### Phase 1: Types and Interfaces
- [ ] Step 1.1: [action] in `file.ts`
- [ ] Verify: [how to check it worked]

#### Phase 2: Implementation
- [ ] Step 2.1: [action] in `file.ts`
- [ ] Verify: [how to check]

#### Phase 3: Tests
- [ ] Step 3.1: Update tests in `file.test.ts`
- [ ] Verify: Run `npm test`

#### Phase 4: Cleanup
- [ ] Remove deprecated code
- [ ] Update documentation

### Rollback Plan
If something fails:
1. [Step to undo]
2. [Step to undo]

### Risks
- [Potential issue and mitigation]

After the plan, ask: "Shall I proceed with Phase 1?"

Más de este repositorio

mismo repositorio

context7

FilippoDeSilva/skills

Retrieves up-to-date documentation, API references, and code examples for any developer technology. Use this skill whenever the user asks about a specific library, framework, SDK, CLI tool, or cloud service -- even for well-known ones like React, Next.js, Prisma, Express, Tailwind, Django, or Spring Boot. Your training data may not reflect recent API changes or version updates. Always use for: API syntax questions, configuration options, version migration issues, "how do I" questions mentioning a library name, debugging that involves library-specific behavior, setup instructions, and CLI tool usage. Use even when you think you know the answer -- do not rely on training data for API details, signatures, or configuration options as they are frequently outdated. Always verify against current docs. Prefer this over web search for library documentation and API details.

2026-07-022

react-native-design

FilippoDeSilva/skills

Master React Native styling, navigation, and Reanimated animations for cross-platform mobile development. Use when building React Native apps, implementing navigation patterns, or creating performant animations.

2026-06-272

react-native-optimizations

FilippoDeSilva/skills

Provides React Native performance optimization guidelines for FPS, TTI, bundle size, memory leaks, re-renders, and animations. Applies to tasks involving Hermes optimization, JS thread blocking, bridge overhead, FlashList, native modules, or debugging jank and frame drops.

2026-06-272

flutter-app

FilippoDeSilva/skills

Design Flutter applications to scale by strictly adhering to architectural principles: enforce separation of concerns, maintain single source of truth, implement unidirectional data flow, and treat UI as a function of state. Use when structuring layers, implementing data layer with services and repositories, or following feature implementation workflow.

2026-06-272

shadcn-ui-flutter

FilippoDeSilva/skills

A comprehensive Flutter UI library inspired by shadcn/ui. Provides high-quality, customizable, and accessible components including Buttons, Cards, Forms, and more. Use this skill when building Flutter UIs, implementing design systems, or needing specific component usage examples.

2026-06-272

nestjs-queue-architect

FilippoDeSilva/skills

Queue job management patterns, processors, and async workflows for video/image processing

2026-06-272

Refactor Plan

Create a detailed plan before making any code changes.

Instructions

Do not edit files while preparing the plan.

Search the codebase to understand the current state. Read enough implementation, tests, configuration, and docs to make the plan specific to the repository.

Identify affected files, ownership boundaries, dependencies, and likely hidden coupling.

Plan changes in a safe sequence. Prefer contracts and types first, then implementations, then callers, then tests, then cleanup.

Include verification steps between phases and a final validation command.

Include rollback or recovery steps for the riskiest phases.

Output the complete plan using the format below.

Stop after the plan and ask for confirmation before implementing. If the user already asked you to implement, still produce the plan first and wait for confirmation unless they explicitly said to continue without review after the plan.

If the request is too ambiguous to plan safely, ask concise clarifying questions instead of editing files.

Output Format

## Refactor Plan: [title] ### Current State [Brief description of how things work now] ### Target State [Brief description of how things will work after] ### Affected Files | File | Change Type | Dependencies | |------|-------------|--------------| | path | modify/create/delete | blocks X, blocked by Y | ### Execution Plan #### Phase 1: Types and Interfaces - [ ] Step 1.1: [action] in `file.ts` - [ ] Verify: [how to check it worked] #### Phase 2: Implementation - [ ] Step 2.1: [action] in `file.ts` - [ ] Verify: [how to check] #### Phase 3: Tests - [ ] Step 3.1: Update tests in `file.test.ts` - [ ] Verify: Run `npm test` #### Phase 4: Cleanup - [ ] Remove deprecated code - [ ] Update documentation ### Rollback Plan If something fails: 1. [Step to undo] 2. [Step to undo] ### Risks - [Potential issue and mitigation]

After the plan, ask: "Shall I proceed with Phase 1?"