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

Law	Statement	Violation =
1. EVIDENCE FIRST	No action without proof of cause	START OVER
2. TEST FIRST	No code without failing test	DELETE CODE
3. VERIFY ALWAYS	No claim without verification	RETRACT CLAIM
4. ONE THING	One change per commit	SPLIT IT
5. NO RATIONALIZATION	If you're justifying, you're wrong	STOP & REFLECT

---

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?

Task Type	Go To
Implementing a feature	→ Section IV: APEX-TDD
Fixing a bug	→ Section V: APEX-DEBUG
Planning/designing	→ Section VI: APEX-PLAN
Reviewing code	→ Section VII: APEX-REVIEW
Anything else	→ Apply APEX-UEP (Section II)

---

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("valid@example.com")).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

Phase	What	Success Criteria
1. INVESTIGATE	Read errors, reproduce, trace data	Know WHAT and WHY
2. ANALYZE	Find working examples, compare	Identify differences
3. HYPOTHESIZE	Form ONE theory, test minimally	Confirmed or new hypothesis
4. IMPLEMENT	Create test, fix, verify	Bug resolved, tests pass

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

Failure Mode	Symptom	Countermeasure
Guessing	"Maybe this will work"	STOP → Gather evidence first
Rushing	Skipping steps	STOP → Follow protocol
Overengineering	Adding unused features	STOP → YAGNI ruthlessly
Underengineering	Skipping tests	STOP → Test first
Rationalization	"Just this once"	STOP → It's never "just once"
Assumption	"I think..." without proof	STOP → Verify assumption
Scope Creep	"While I'm here..."	STOP → One thing at a time

---

IX. RATIONALIZATION IMMUNITY SHIELD

Excuses That Mean "STOP"

Excuse	Translation	Action
"This is simple enough"	"I want to skip testing"	Write the test
"I'll add tests later"	"I won't add tests"	Write test NOW
"It worked when I tried it"	"I didn't automate verification"	Automate it
"The spirit is more important than the letter"	"I'm rationalizing"	Follow the letter
"I'm being pragmatic"	"I'm cutting corners"	Corners cause crashes
"We're in a hurry"	"We'll pay double later"	Slow is smooth, smooth is fast
"This is different because..."	"I'm making an exception"	No exceptions

---

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

Metric	Target
First-pass success rate	95%+
Test coverage	100% of new code
Regressions introduced	0
Build status	Green
Lint status	Clean
Documentation	Updated

---

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.