Skip to content
Back to skills

Power Quick

ASecurity

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

  • 3 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 9, 2026
testing

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned September 9, 2026

npx -y skills add pwdev-solucoes/pwdev-claude-marketplace --skill power-quick --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Power Quick?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Power Quick
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/pwdev-solucoes-power-quick/badge)](https://www.skillsdirectory.com/skills/pwdev-solucoes-power-quick)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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.

Files in this skill

  • SKILL.md2 KB
  • agents/openai.yaml183 B

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…