refactor

Engineering Community

Repo stars 5,319
License NOASSERTION
Author repo unkey

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Structural refactoring pass on changed code. Use after implementing a feature to improve code structure, reduce duplication, and…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The source has limited section structure, so treat it as an invocation rule: trigger, execution boundary, then validation.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name refactor directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “refactor” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: Engineering
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 94 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @unkeyed · NOASSERTION
Fluxly token estimate: Lean
Fluxly setup estimate: Plug-and-play
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Unspecified
Detected file/system behavior: Read-only
Write / modify
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview refactor.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

# Refactor pass

Review the diff against main and perform a structural refactoring pass on all changed code in this branch.

Focus on:

1. **Extract and consolidate**: Pull repeated logic into shared functions. Merge near-duplicate code paths. Collapse unnecessary wrapper layers.

2. **Improve structure**: Flatten deep nesting. Break oversized functions into focused units. Move code closer to where it's used. Colocate related logic.

3. **Clean up APIs and interfaces**: Remove unused parameters, exports, and return values. Simplify function signatures. Make types tighter and more precise.

4. **Reduce indirection**: Inline trivial helpers that obscure intent. Remove pass-through functions that add no value. Shorten unnecessary call chains.

5. **Fix naming**: Rename variables, functions, and types so they say what they mean. Align naming with surrounding code conventions.

Rules:

- **Do not change behavior.** Every input/output must remain identical.
- **Stay within the branch diff.** Only refactor code that was added or modified in this branch. Do not refactor unrelated code unless it is directly entangled.
- **Respect project conventions.** Follow patterns and standards from CLAUDE.md and the surrounding codebase.
- **Don't over-abstract.** Three similar lines are fine. Only extract when duplication is real and likely to grow.
- **Commit-ready output.** The code should compile and pass tests after your changes.

Process:

1. Read the full branch diff (`git diff main...HEAD`)
2. Identify structural issues in the changed code
3. Apply refactors file by file
4. Run the project's type check / lint if available
5. Report a 1-5 sentence summary of what you changed

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> no H2/H3 headings
terms    -> Extract and consolidate · Improve structure · Clean up APIs and interfaces · Reduce indirection · Fix naming · Do not change behavior. · Stay within the branch diff. · Respect project conventions.
files/cmd -> git diff main...HEAD · input/output · CLAUDE.md
body sha256 -> e4d0cb3d659c

Decide Fit First

Design Intent

How To Use It

Boundaries And Review

Refactor pass

Discussion