executing-plans — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited executing-plans (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Load plan, review critically, execute tasks incrementally with verification at each step, report when complete.
Announce at start: "I'm using the executing-plans skill to implement this plan."
Note: Tell your human partner that Superpowers works much better with access to subagents. The quality of its work will be significantly higher if run on a platform with subagent support (such as Claude Code or Codex). If subagents are available, use superpowers:subagent-driven-development instead of this skill.
Each task in the plan follows this cycle:
┌──────────────────────────────────────┐
│ │
│ Implement ──→ Test ──→ Verify ──┐ │
│ ▲ │ │
│ └───── Commit ◄─────────────┘ │
│ │ │
│ ▼ │
│ Next task │
│ │
└──────────────────────────────────────┘For each task:
For each task:
After every 2-3 tasks (or at plan checkpoint markers):
After all tasks complete and verified:
Before writing any code, ask: "What is the simplest thing that could work?"
After writing code, review it against these checks:
Three similar lines of code is better than a premature abstraction. Implement the naive, obviously-correct version first. Optimize only after correctness is proven with tests.
Touch only what the task requires.
Do NOT:
If you notice something worth improving outside your task scope, note it — don't fix it:
NOTICED BUT NOT TOUCHING:
- src/utils/format.ts has an unused import (unrelated to this task)
- The auth middleware could use better error messages (separate task)
→ Want me to create tasks for these?Do not satisfy a requested functional surface with a different, easier, or more decorative one.
If the approved plan says a route or interaction is functional in the current slice, build that route or interaction. If you need to reduce scope, stop, say exactly which slice you can deliver, and get approval before continuing.
Each increment changes one logical thing. Don't mix concerns:
Bad: One commit that adds a new component, refactors an existing one, and updates the build config.
Good: Three separate commits — one for each change.
After each increment, the project must build and existing tests must pass. Don't leave the codebase in a broken state between tasks.
If a feature isn't ready for users but you need to merge increments:
// Feature flag for work-in-progress
const ENABLE_TASK_SHARING = process.env.FEATURE_TASK_SHARING === 'true';
if (ENABLE_TASK_SHARING) {
// New sharing UI
}This lets you merge small increments to the main branch without exposing incomplete work.
New code should default to safe, conservative behavior:
// Safe: disabled by default, opt-in
export function createTask(data: TaskInput, options?: { notify?: boolean }) {
const shouldNotify = options?.notify ?? false;
// ...
}Each task should be independently revertable:
The plan should already contain vertically-sliced tasks (from the writing-plans skill). If it doesn't, or if a task feels too large:
Vertical slicing means building one complete feature path at a time:
Bad (horizontal):
Good (vertical):
Each vertical slice delivers working, testable functionality.
Don't load the entire spec and all source files at once. Load what's needed for the current task:
When the work moves between design-heavy and implementation-heavy phases, reload the spec objective, success criteria, out-of-scope, and route/surface map before continuing. Context drift on these items causes the most expensive failures.
See context-engineering skill for detailed guidance on managing agent context.
When you encounter a non-trivial decision during execution (architectural choice, correct approach under uncertainty, irreversible change), consider using the doubt-driven-development skill to subject it to adversarial review before committing.
Non-trivial decisions include:
For routine decisions that are clearly specified in the plan, just follow the plan.
When implementing code that depends on a specific framework or library version, use the source-driven-development skill to verify patterns against official documentation instead of relying on training data.
STOP executing immediately when:
Ask for clarification rather than guessing.
Return to Review (Step 1) when:
Don't force through blockers — stop and ask.
Every code change flows through git. Treat commits as save points, branches as sandboxes, and history as documentation.
Format: <type>: <short description> followed by an optional body explaining why, not what.
Types: feat, fix, refactor, test, docs, chore.
# Good: Explains intent
feat: add email validation to registration endpoint
Prevents invalid email formats from reaching the database.
Uses Zod schema validation at the route handler level,
consistent with existing validation patterns in auth.ts.
# Bad: Describes what's obvious from the diff
update auth.tsBefore every commit:
git diff --staged — review what you're about to commitgit diff --staged | grep -i "password\|secret\|api_key\|token"main always deployable (trunk-based development)After any modification, provide a structured summary:
CHANGES MADE:
- src/routes/tasks.ts: Added validation middleware to POST endpoint
- src/lib/validation.ts: Added TaskCreateSchema using Zod
THINGS I DIDN'T TOUCH (intentionally):
- src/routes/auth.ts: Has similar validation gap but out of scope
- src/middleware/error.ts: Error format could be improved (separate task)
POTENTIAL CONCERNS:
- The Zod schema is strict — rejects extra fields. Confirm this is desired.package-lock.json, Prisma migrations)dist/, .next/), environment files (.env), or IDE config.gitignore that covers: node_modules/, dist/, .env, .env.local, *.pem# Find which commit introduced a bug
git bisect start
git bisect bad HEAD
git bisect good <known-good-commit>
# View what changed recently
git log --oneline -20
git diff HEAD~5..HEAD -- src/
# Find who last changed a specific line
git blame src/services/task.ts
# Search commit messages
git log --grep="validation" --oneline| Rationalization | Reality |
|---|---|
| "I'll test it all at the end" | Bugs compound. A bug in Task 1 makes Tasks 2-5 wrong. Test each task. |
| "It's faster to do it all at once" | It feels faster until something breaks and you can't find which of 500 changed lines caused it. |
| "These changes are too small to commit separately" | Small commits are free. Large commits hide bugs and make rollbacks painful. |
| "I'll squash it all later" | Squashing destroys the development narrative. Prefer clean incremental commits from the start. |
| "I'll add the feature flag later" | If the feature isn't complete, it shouldn't be user-visible. Add the flag now. |
| "This refactor is small enough to include" | Refactors mixed with features make both harder to review and debug. Separate them. |
| "I'll just quickly add this too" | Scope creep is the enemy of incremental delivery. Note it, don't do it. |
| "The plan is wrong, I'll just fix it" | If the plan has an issue, stop and discuss. Don't silently deviate. |
| "I'll commit when the feature is done" | One giant commit is impossible to review, debug, or revert. Commit each slice. |
Required workflow skills:
On-demand skills (triggered by context):
After completing all tasks:
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.