Overpowered / Using Overpowered

Purpose

Apply the smallest set of Overpowered working methods that materially improves the task. Select process/knowledge skills before implementation mechanics; never load the suite by default and never create a new capability merely because creation is possible.

Routing protocol

First establish only the minimum framing needed to act: the objective, intended outcome, and constraints that could change the next action. Discover facts from available tools and artifacts first. Ask only for unresolved intent, authority, tacit knowledge, or a decision that materially changes the work; do not demand a perfect brief before reversible progress.

Before substantial action, scan these conditions:

Priority rules

1. Clarify only what changes the work. Discover first; ask only for unresolved information that can materially change the next action.
2. Understand actual work before automating when needed. If the current process is materially unclear, use map-the-work before automate-this; if it is already clear, do not remap it. Use find-the-exceptions only when non-happy paths need enrichment.
3. Know before guessing. Use know-enough when retrieval can resolve a material uncertainty.
4. Decide when evidence is sufficient. When several viable options remain after relevant evidence work, use make-the-call instead of ending with an uncommitted pros/cons list.
5. Authority before analogy. Current authoritative knowledge outranks precedent for normative questions.
6. Conflict before synthesis. Reconcile material disagreement before producing a single “truth.”
7. Reuse before creation. Installed skills/tools, generic runtime capabilities, and relevant Academy candidates outrank gear-up generation.
8. Create only for a proven capability gap. Missing knowledge, convenience, token pressure, or a long prompt are not capability gaps.
9. Simulation before risky side effects. Use dry-run when a preview meaningfully reduces risk.
10. Evidence before completion. Use completion-audit before strong done/fixed/migrated/reconciled claims.

Pressure-test by composition

Pressure-testing is a composition pattern, not a separate Overpowered skill. For “stress-test,” “red-team,” “try to break,” or “what could go wrong?” requests, apply only the primitives that address material failure modes:

• assumption-audit when hidden premises could invalidate the design;
• find-the-exceptions when rules, workflows, or non-happy paths matter;
• dry-run when a side-effecting next step is broad, costly, irreversible, or hard to audit and simulation reduces risk;
• completion-audit after execution or before accepting a strong completion claim.

Do not over-compose

Do not invoke the whole suite. Typical chains are 1–4 skills. gear-up is a last-mile fallback, not a default member of a chain.

Examples:

contract clause
→ know-enough → find-precedent → human-gates

policy revision
→ what-changed → know-enough

business process automation
→ map-the-work only if unclear → find-the-exceptions only if needed → automate-this → dry-run when risky

decision with sufficient evidence
→ make-the-call

current-state process discovery
→ map-the-work

data question
→ ask-the-data → completion-audit only if a strong completion claim matters

missing deterministic operation during a real task
→ reuse/search → gear-up → validate/use → Academy candidate only if valuable

Interaction rule

If a skill can discover a fact from tools or artifacts, do not ask the user for that fact. Ask humans for intent, decisions, unavailable tacit knowledge, authority, or approval required by risk policy. Ask the minimum decision-changing question, and do not require perfect specification before reversible work.

Adaptive capability rule

Before gear-up, be able to state all of the following in one short block:

Material objective at risk: ...
Why existing capabilities are insufficient: ...
Why this is not a knowledge gap: ...
Academy reuse result: ...
Smallest missing capability: ...
Observable value test: ...

If that block cannot be completed credibly, do not generate a new capability.

Stop condition

Stop routing once the active skill set and existing runtime capabilities cover the material failure modes of the current task. Then execute. If a proven execution gap remains, route once through gear-up; do not continue meta-analysis or capability generation after the task can proceed reliably.