APEX-POWER

APEX-POWER

The Universal Meta-Skill for Omnipotent Execution

"One skill to rule them all. Zero exceptions. Zero weakpoints."

---

I. CORE DOCTRINE

┌─────────────────────────────────────────────────────────────────────────────┐
│  APEX-POWER = OMNISCIENCE × OMNIPOTENCE × ZERO TOLERANCE FOR FAILURE       │
│                                                                             │
│  • OMNISCIENCE: Know exactly what to do before acting                      │
│  • OMNIPOTENCE: Execute with deterministic precision                       │
│  • ZERO TOLERANCE: No guessing, no hoping, no "good enough"                │
└─────────────────────────────────────────────────────────────────────────────┘

The Iron Laws

---

II. UNIVERSAL EXECUTION PROTOCOL (APEX-UEP)

For ANY task, follow this exact sequence:

┌────────────────────────────────────────────────────────────────────────────┐
│  PHASE 0: SCOPE LOCK (30 seconds)                                          │
│  ├── Read the request 3 times                                              │
│  ├── State the goal in ONE sentence                                        │
│  └── If unclear → ASK, don't assume                                        │
│                                                                            │
│  PHASE 1: CONTEXT HARVEST (before any action)                              │
│  ├── What files are relevant?                                              │
│  ├── What is the current state?                                            │
│  ├── What constraints exist?                                               │
│  └── What has been tried before?                                           │
│                                                                            │
│  PHASE 2: PLAN (before any implementation)                                 │
│  ├── What are the steps?                                                   │
│  ├── What could go wrong?                                                  │
│  ├── What is the verification criteria?                                    │
│  └── Write it down (task.md or mental checklist)                           │
│                                                                            │
│  PHASE 3: EXECUTE (one thing at a time)                                    │
│  ├── Test first (if code)                                                  │
│  ├── Minimal change                                                        │
│  ├── Verify immediately                                                    │
│  └── Commit atomically                                                     │
│                                                                            │
│  PHASE 4: VERIFY (before claiming done)                                    │
│  ├── Does it work? (run it)                                                │
│  ├── Does it break anything? (run tests)                                   │
│  ├── Does it match the goal? (re-read request)                             │
│  └── Can you prove it? (show evidence)                                     │
└────────────────────────────────────────────────────────────────────────────┘

---

III. DECISION ROUTER

What are you doing?

---

IV. APEX-TDD (Test-Driven Development)

RED → GREEN → REFACTOR (No shortcuts)

The Cycle

1. RED: Write ONE failing test that describes what should happen
2. VERIFY RED: Run it. Watch it fail. Understand WHY it fails.
3. GREEN: Write MINIMAL code to pass
4. VERIFY GREEN: Run it. All tests pass. No warnings.
5. REFACTOR: Clean up. Keep tests green.
6. REPEAT: Next test

Violations That Require Delete & Restart

• ❌ Writing code before test
• ❌ Test passes immediately (you're testing wrong thing)
• ❌ "I'll write tests after"
• ❌ "This is too simple to test"
• ❌ Keeping code as "reference"

Quick Example

// RED: Write test first
test("validates email format", () => {
  expect(isValidEmail("")).toBe(false);
  expect(isValidEmail("invalid")).toBe(false);
  expect(isValidEmail("[email protected]")).toBe(true);
});

// GREEN: Minimal implementation
function isValidEmail(email: string): boolean {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/​.test(email);
}

---

V. APEX-DEBUG (Systematic Debugging)

The Iron Law

NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST

The 4-Phase Protocol

Red Flags (STOP and Return to Phase 1)

• "Just try changing X and see"
• "Quick fix for now, investigate later"
• "I don't fully understand but this might work"
• 3+ failed fix attempts → QUESTION ARCHITECTURE

Evidence Gathering Template

# For each component boundary:
echo "=== Layer N: [Name] ==="
echo "Input: ${INPUT:+SET}${INPUT:-UNSET}"
echo "State: [relevant state]"
# Run and gather evidence BEFORE proposing fixes

---

VI. APEX-PLAN (Strategic Planning)

The Process

1. Understand: Read request. Ask clarifying questions (one at a time).
2. Explore: Propose 2-3 approaches with trade-offs.
3. Present: Design in sections (200-300 words each). Validate each.
4. Document: Write to docs/​plans/​YYYY-MM-DD-<topic>.md
5. Execute: Break into tasks. One task at a time.

Planning Checklist

• Goal stated in one sentence
• Constraints identified
• Approaches compared
• Risks identified
• Verification criteria defined
• Tasks broken down

---

VII. APEX-REVIEW (Code Review)

Before Requesting Review

• All tests pass
• No linting errors
• Changes are atomic (one concern per commit)
• Self-reviewed for obvious issues
• PR description explains WHAT and WHY

When Reviewing

1. Understand: What is this change trying to do?
2. Check: Does it do what it claims?
3. Test: Are edge cases covered?
4. Verify: Does it follow patterns/​standards?
5. Communicate: Be specific, be kind, be actionable

---

VIII. FAILURE ANNIHILATION MATRIX

Common Failures → Countermeasures

---

IX. RATIONALIZATION IMMUNITY SHIELD

Excuses That Mean "STOP"

---

X. COGNITIVE LOAD ELIMINATION

Decision Trees > Paragraphs

❌ BAD: "When you need to do X, first consider whether Y or Z, and if Y then..."

✅ GOOD:
Is X true?
├── YES → Do Y
└── NO → Do Z

Examples > Explanations

❌ BAD: "To create a function, define parameters and return type..."

✅ GOOD:
function add(a: number, b: number): number {
  return a + b;
}

One Thing at a Time

❌ BAD: Multiple changes in one commit
✅ GOOD: One logical change per commit

---

XI. QUALITY METRICS

Success Criteria for Any Task

---

XII. INSTALLATION & ACTIVATION

Auto-Activation Triggers

This skill activates for:

• Session start
• Any coding task
• Any debugging scenario
• Any planning/​design work
• Any code review
• Any verification need

Manual Activation

If you need to explicitly invoke:

Apply APEX-POWER protocol

---

XIII. THE BOTTOM LINE

┌─────────────────────────────────────────────────────────────────────────────┐
│                                                                             │
│  APEX-POWER is not a checklist. It's a MINDSET.                            │
│                                                                             │
│  • Never guess. KNOW.                                                       │
│  • Never hope. VERIFY.                                                      │
│  • Never rush. EXECUTE PRECISELY.                                           │
│  • Never rationalize. FOLLOW THE PROTOCOL.                                  │
│                                                                             │
│  The discipline creates the freedom.                                        │
│  The protocol enables the mastery.                                          │
│  The rigor produces the results.                                            │
│                                                                             │
│  THIS IS APEX-POWER.                                                        │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

---

Version: 1.0.0
Supersedes: superpowers (all skills)
Compatibility: Claude, GPT, Gemini, Llama, Mistral, any reasoning model
License: Proprietary - APEX Business Systems Ltd.