How do I install the Pflow Refactor skill?

Run npx skillmds@latest add phpinfo/pflow-refactor in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Pflow Refactor safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Pflow Refactor?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Pflow Refactor free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under MIT.

Who published Pflow Refactor?

phpinfo (@phpinfo) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Pflow Refactor by phpinfo — Agent Skill

Name: Pflow Refactor
Author: phpinfo

Pflow Refactor

Performs evidence-based refactoring research for a user-specified code, component, or subsystem. Produces an As Is analysis and a minimal, justified To Be proposal with naming, dependency, migration, and trade-off recommendations. Applies SOLID, KISS, YAGNI, BDUF, APO, Occam's Razor, DRY, Law of Demeter, and composition over inheritance. Analysis only; does not implement changes. Invoked manually only.

phpinfo 453d653 3 files · 7.2 KB Updated Sep 17, 2026

File contents

Workflow

Scope. Infer the target and desired depth from the conversation. Ask only about a decision that cannot be resolved from available context.
Inspect. Read applicable project rules, architecture docs, implementation, tests, consumers, and relevant history. Consult current framework or language guidance when it materially affects the design. Ignore unrelated code.
Principles. Read .agents/skills/pflow-refactor/references/clean-code.md and .agents/skills/pflow-refactor/references/solid.md. Use their smells to spot problems and their fixes to justify the To Be — cite the specific principle, not a generic appeal to cleanliness.
Analyze As Is. Establish evidence: responsibilities, ownership, dependencies, mutation and event boundaries, invariants, public API, tests, duplication, naming, change frequency, and concrete size or coupling indicators. Distinguish facts from inferences.
Design To Be. Propose the smallest architecture that addresses observed problems. Prefer composition and existing extension points. Preserve behavior, reduce coupling, define ownership and atomic change boundaries, and explain naming.
Challenge. Reject speculative abstractions and premature optimization. Add managers, repositories, interfaces, base classes, event buses, or generic mechanisms only when current evidence requires them.
Report. Lead with the conclusion, then present As Is, To Be, rationale and trade-offs, a safe migration sequence, risks, and explicit non-goals. Use exact paths and symbols where available. Mark unresolved decisions instead of inventing requirements.

Boundaries

Do not edit files, implement, commit, or turn the research into a task plan unless explicitly requested separately.
Do not recommend a rewrite when incremental migration can preserve behavior.
Do not extract abstractions solely to reduce line count or superficial duplication.
Do not optimize without measurements.

---name: pflow-refactordescription: Performs evidence-based refactoring research for a user-specified code, component, or subsystem. Produces an As Is analysis and a minimal, justified To Be proposal with naming, dependency, migration, and trade-off recommendations. Applies SOLID, KISS, YAGNI, BDUF, APO, Occam's Razor, DRY, Law of Demeter, and composition over inheritance. Analysis only; does not implement changes. Invoked manually only.license: MIT---## Workflow1. **Scope.** Infer the target and desired depth from the conversation. Ask only about a decision that cannot be resolved from available context.2. **Inspect.** Read applicable project rules, architecture docs, implementation, tests, consumers, and relevant history. Consult current framework or language guidance when it materially affects the design. Ignore unrelated code.3. **Principles.** Read `.agents/skills/pflow-refactor/references/clean-code.md` and `.agents/skills/pflow-refactor/references/solid.md`. Use their smells to spot problems and their fixes to justify the To Be — cite the specific principle, not a generic appeal to cleanliness.4. **Analyze As Is.** Establish evidence: responsibilities, ownership, dependencies, mutation and event boundaries, invariants, public API, tests, duplication, naming, change frequency, and concrete size or coupling indicators. Distinguish facts from inferences.5. **Design To Be.** Propose the smallest architecture that addresses observed problems. Prefer composition and existing extension points. Preserve behavior, reduce coupling, define ownership and atomic change boundaries, and explain naming.6. **Challenge.** Reject speculative abstractions and premature optimization. Add managers, repositories, interfaces, base classes, event buses, or generic mechanisms only when current evidence requires them.7. **Report.** Lead with the conclusion, then present `As Is`, `To Be`, rationale and trade-offs, a safe migration sequence, risks, and explicit non-goals. Use exact paths and symbols where available. Mark unresolved decisions instead of inventing requirements.## Boundaries- Do not edit files, implement, commit, or turn the research into a task plan unless explicitly requested separately.- Do not recommend a rewrite when incremental migration can preserve behavior.- Do not extract abstractions solely to reduce line count or superficial duplication.- Do not optimize without measurements.

Frequently asked questions