auditing-slow-powers-usage

Auditing Slow-powers usage

Why you're being asked this

A slow-powers developer is running a deliberate, manual diagnostic. The session you just spent working, likely in some other codebase, is the subject. They want to know how the slow-powers skill set actually performed in a long, realistic, multi-turn session, something that's otherwise difficult to measure.

This is a check on slow-powers, not on your work. You are not in trouble, the work is not being reopened, and there is no "right answer" you're being graded against. Report honestly and specifically. Your report supplies cases for pressure tests and live spot-checks of the plugin.

Scope — stay inside these lines

Do:

• Report only on how slow-powers influenced the session that has already happened.
• Draw entirely on what's already in this conversation — your own decisions, what you read, what you skipped.

Don't:

• Read, explore, or search the host codebase to "investigate" — the audit is about slow-powers, not the project.
• Touch the host project: no edits, no fixes, no commits, no files written into its working directory — not even the audit doc.
• Re-open, redo, second-guess, or "improve" the work you just delivered.
• Propose changes to the host project. That's out of scope even if you spot something.

The one permitted write — and only this one: persisting the audit doc (and, if opted in, a transcript copy) under the operator's global ~/.slow-powers-audits/ folder, as described in The report below. That folder lives outside any host repo, so writing there never pollutes the project under audit. Everything else above still holds: the global audit folder is allowed; the host repo is forbidden. If the folder doesn't exist, you write nothing at all — report inline and stop.

Reporting rules

These rules are the point of the audit. Follow them exactly.

• Report what you decided and why, at the time. The reasoning that was live when the work was happening — not a tidied-up version, not what you'd do differently.
• No after-the-fact remediation or apology language. Do not write "I should have…", "I'll remember next time", "going forward I'll…", "good catch, I'll fix my approach." You cannot remember anything next session; that text is pure noise and it pollutes the data. If you skipped a skill, state the rationalization you actually had — don't recant it.
• Be honest about slow-powers's downsides. Where a skill added friction, wasted tokens, was ignored, or wasn't worth its cost, say so plainly. A glowing report that hides cost is useless.
• Mark uncertainty instead of fabricating. If you can't reliably recall whether you read a skill in full or what triggered an invocation, say "uncertain" and why — never invent a clean specific.