菜单
Sequence a large, multi-step refactor into small, independently-shippable, green-to-green steps behind a test safety net. Use when: planning a big refactor, restructuring a module safely, breaking a risky change into steps, migrating a pattern across a codebase.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Scaffold a web repo with pnpm, Astro, and astro-bulma — plus Drizzle when the site needs a database — including package.json scripts for build/lint/test/fmt (and db:migrate when db-backed). Use when: setting up a new Astro project, scaffolding a web repo, initializing the standard web stack. Building block for create-website.
Add a GitHub Actions CI workflow running build, lint, test, and fmt checks with pnpm. Use when: adding CI, setting up GitHub Actions checks, adding a build/lint/test workflow. Building block for create-website.
Create a new website end-to-end: Astro repo with pnpm/astro-bulma; GitHub Pages for static sites, or Turso + Fly.io when the site needs a database; GitHub Actions for CI and deploy. Use when: creating a new website, spinning up a new web project, new site, scaffolding a static or full-stack Astro project.
Create a new app on Fly.io for the current project without deploying it, generating fly.toml and a Dockerfile. Use when: creating a Fly.io app, setting up Fly hosting, fly launch. Building block for create-website.
Add a GitHub Actions workflow that builds a static site and deploys it to GitHub Pages, with an optional custom domain. Use when: deploying a static site, GitHub Pages hosting, static site with a custom domain. Building block for create-website.
Add a GitHub Actions workflow that deploys to Fly.io on merge to main, with db migrations run as a Fly release_command. Use when: adding a deploy workflow, deploying on merge, setting up continuous deployment to Fly.io. Building block for create-website.
| name | refactor-plan |
| description | Sequence a large, multi-step refactor into small, independently-shippable, green-to-green steps behind a test safety net. Use when: planning a big refactor, restructuring a module safely, breaking a risky change into steps, migrating a pattern across a codebase. |
| argument-hint | The target module/pattern and the desired end state |
Produce an ordered, low-risk plan for a large refactor — small steps that each keep the suite green and could ship on their own. This plans the refactor; it does not make the changes.
State precisely what's being refactored and the desired end shape. If the target or end state is ambiguous, ask before planning.
Explore the codebase to find everything the refactor touches:
Assess test coverage over the affected code:
write-tests) so behavior is pinned before it's movedProduce an ordered list of small steps, each green-to-green (suite passes before and after) and ideally independently shippable:
1. Add characterization tests for <seam> — pins current behavior.
2. Introduce <new abstraction> alongside the old, unused — no behavior change.
3. Migrate <call sites A, B> to the new path — suite stays green.
...
N. Delete the old path once no callers remain.
Prefer parallel-change (expand → migrate → contract) over big-bang cutovers.
Flag the riskiest steps, anything that can't be done incrementally, and the rollback/feature-flag strategy for each risky step. Output the plan only — no code changes.