Use when a change is small and already understood - at most three files, such as a typo, a config value, a rename, or a one-line bugfix - and a plan file would cost more than the change
Scanned 9/9/2026
Install to Claude Code
npx -y skills add pwdev-solucoes/pwdev-claude-marketplace --skill power-quick --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Power Quick?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/pwdev-solucoes-power-quick)More formats (shields.io, HTML) on the badges page.
---
name: power-quick
description: Use when a change is small and already understood - at most three files, such as a typo, a config value, a rename, or a one-line bugfix - and a plan file would cost more than the change
---
# Deliver a Bounded Change
Read [collaboration](../../references/collaboration.md) and
[safety](../../references/safety.md) before acting.
## The scope gate
This skill is for changes that are small **and** understood. Both, not either.
Escalate to `pwdev-power:power-brainstorm` the moment any of these is true:
- more than three files would change
- you cannot name the failure mode of the change
- it adds a new interface, dependency, or migration
- it touches auth, payments, permissions, or data deletion
- you are about to write "while I'm here"
Escalating is not failure. Discovering mid-change that this was never quick, and continuing
anyway, is.
## Steps
1. **Read before proposing.** Read the actual files. A quick change proposed from memory of a
codebase is a guess. `.planning/power/context/project.md`, if it exists, gives you the
conventions without exploring — which is the whole point on a change this small.
2. **Present a mini-plan**: what changes, in which files, and how you will verify it. Three or
four lines.
3. **Gate.** Wait for a yes.
4. **Implement.** If this is a bugfix, `pwdev-power:power-tdd` still applies — a bug means a
test was missing, and "it is only one line" is the most common way that test never gets
written.
5. **Verify.** Run the real command, read the real output. `pwdev-power:power-verify` states
the standard: evidence before the claim.
6. **Commit** with a message that says why, not what. The diff already says what.
## Record
Write `.planning/power/quick/<date>-<slug>/contract.md` with the mini-plan you agreed to, and
`report.md` with what you did and the verification output. Two short files.
They exist because "quick" changes are the ones nobody can explain three months later, and
because a pattern of quick changes to the same area is evidence that the area needs a real
plan.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!