メニュー
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コマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？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'.