القائمة
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'.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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'.
Lightweight triage for the ln-* skill set. Use when unsure which ln skill to use next, starting work on something new, or when the user asks for guidance on their development process.
Explore radically different module shapes before committing to one. Use when choosing an API surface, deciding what a module hides vs exposes, or when the user says 'design it twice'.
Collapse meaningful ambiguity with contrastive examples. Use when a plan/design has several plausible meanings, requirements feel vague, examples would clarify intent faster than grilling, or the user asks to disambiguate, find ambiguity, use behavioral kernels, or ask contrastive questions.
| 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.