菜单
Plan a refactor as a sequence of tiny safe commits via interview and codebase exploration. Use when restructuring working code, or when the user says 'plan a refactor'.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
基于 SOC 职业分类
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/hashintel/brunch --skill ln-refactor命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | ln-refactor |
| description | Plan a refactor as a sequence of tiny safe commits via interview and codebase exploration. Use when restructuring working code, or when the user says 'plan a refactor'. |
| argument-hint | [area or module to refactor] |
"Make the change easy, then make the easy change" (Beck). Plan a refactor as tiny commits that each leave the codebase working (Fowler). Preparatory refactoring first, behavioral changes last.
memory/REFACTOR.md is a temporary derivative execution aid. Do not create alternate refactor ledgers or archive completed refactor plans; delete the file when the refactor is finished or superseded.
Skip steps you consider unnecessary.
The area to refactor: $ARGUMENTS
ln-build for that before continuing.memory/SPEC.md if it exists), then extractions (deepen shallow modules — Ousterhout), then interface alignments, then behavioral changes last. Each commit is a complete, passing state.memory/REFACTOR.md. Delete the file when the refactor is complete or superseded.Use this structure:
## Problem Statement
What is wrong, from the developer's perspective.
## Solution
The target state, from the developer's perspective.
## Commits
Ordered list of tiny commits. Each described in plain English — no file paths or snippets. Each leaves the codebase working.
1. [Commit description]
2. [Commit description]
3. ...
## Decisions
- Modules built or modified
- Interface changes
- Architectural decisions
- Schema changes, API contracts
No file paths or code snippets — they go stale. Record in `memory/SPEC.md` §Decisions when finalized.
## Testing Decisions
- What makes a good test here (behavior, not implementation)
- Which modules get tested
- Prior art in the codebase
## Out of Scope
What this refactor deliberately excludes.
After filing the refactor plan, present these options to the user (use tool-ask-question):
| # | Label | Target | Why |
|---|---|---|---|
| 1 | Build first commit | ln-build | Refactor plan is clear; implement one commit-sized step from memory/REFACTOR.md |
| 2 | Scope a commit | ln-scope | A commit needs more precise behavior/acceptance definition |
| 3 | Back to triage | ln-consult | Plan needs reassessment |
Recommended: 1 when the first commit step is concrete enough to execute; otherwise 2
Adapted from mattpocock/skills/request-refactor-plan.
Author a completed-spec fixture — a seeded intent graph plus a believable four-phase interview transcript — for a brunch feature, so it can feed any downstream tooling that consumes a completed spec or dogfood the UI. Use when you need a real completed specification in .brunch/brunch.db for testing or demo: pick a feature from memory/SPEC.md (or a free description), choose a stress profile (coverage|clean), and produce a registered scenario seed + an interview-questions doc that match exactly.
Review someone else's PR through an architectural/strategic lens — does it shift design, raise complexity, or quietly change precedent? Drives a brief reflective discussion with the user, then posts a concise review comment via `gh`. Defers line-level and bug-hunting concerns to AI review bots and the PR author.
Crystallize shared understanding into a reviewable spec, or update an existing one. Use when the problem needs a written specification, when assumptions or decisions have changed, or when the user says 'write a spec'.