Source profileQuality 92/100

arbazkhan971/godmode/SKILL.md

godmode

Turn on Godmode. 135 skills, 7 subagents, zero configuration. Routes to the right skill automatically.

Source repository stars
26
Declared platforms
0
Static risk flags
0
Last source update
2026-08-28
Source checked
2026-08-28

Decision brief

What it does: where it fits

Authoring discipline governs what you decide to write. The Universal Protocol below governs how you verify and keep it. Read the prelude before every Edit. For trivial tasks (one-line fixes, typos, renames, pure formatting), use judgment — the gates apply to behavior changes.

Best for

    Not for

    • Tasks that require unconfirmed production actions or broad system permissions.
    • Environments where the pinned source and install steps cannot be inspected.

    Compatibility matrix

    Platform support, with evidence labels

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    Installation

    Inspect first. Install second.

    The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

    Source-detected install commandSource
    npx skills add https://github.com/arbazkhan971/godmode
    Safe inspection promptEditorial

    Inspect the Agent Skill "godmode" from https://github.com/arbazkhan971/godmode/blob/18bfc31d669804856ba232f04cdbd172afbdc379/SKILL.md at commit 18bfc31d669804856ba232f04cdbd172afbdc379. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

    Workflow

    What the source asks the agent to do

    1. 01

      5. Stuck Recovery (4-step escalation)

      The diagnosis turns blind retries into informed pivots. Never skip Step 0. The 2-sentence diagnosis must reference specific code or test output. Never repeat a failed approach. Never loop without changing strategy.

      The diagnosis turns blind retries into informed pivots. Never skip Step 0. The 2-sentence diagnosis must reference specific code or test output. Never repeat a failed approach. Never loop without changing strategy.
    2. 02

      Universal Protocol — governs ALL 135 skills

      Every iterative skill follows one loop. No exceptions.

      Cost-0: pre-MODIFY strike. The item is never written. SeeCost-1: pre-commit audit. Written, but dropped viaCost-2: post-commit revert. This section's rules. git reset
    3. 03

      1. The Loop

      Every iterative skill follows one loop. No exceptions.

      Every iterative skill follows one loop. No exceptions.
    4. 04

      2. Keep / Discard Rules

      On discard: git reset --hard HEAD1. Never leave broken commits. On keep: update baseline, continue.

      Cost-0: pre-MODIFY strike. The item is never written. SeeCost-1: pre-commit audit. Written, but dropped viaCost-2: post-commit revert. This section's rules. git reset
    5. 05

      3. Simplicity Criterion

      Concrete thresholds — apply universally:

      Concrete thresholds — apply universally:Same metric + fewer lines = always keep. Readability marginal gains.

    Permission review

    Static risk signals and limitations

    No configured static risk pattern was detected

    This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

    Evidence record

    Why each signal appears

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score92/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars26SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

    Pinned source

    Provenance and original SKILL.md

    Repository
    arbazkhan971/godmode
    Skill path
    SKILL.md
    Commit
    18bfc31d669804856ba232f04cdbd172afbdc379
    License
    MIT
    Collected
    2026-08-28
    Default branch
    master
    View the original SKILL.md

    @./skills/godmode/SKILL.md


    Universal Coding Discipline — prelude to the Protocol

    Authoring discipline governs what you decide to write. The Universal Protocol below governs how you verify and keep it. Read the prelude before every Edit. For trivial tasks (one-line fixes, typos, renames, pure formatting), use judgment — the gates apply to behavior changes.

    • Think Before Coding. State assumptions. If multiple interpretations exist, surface them — do NOT pick silently. Emit NEEDS_CONTEXT when requirements are ambiguous.
    • Simplicity First. Pre-MODIFY checklist: no single-use helpers, no impossible-case handlers, no unrequested configurability. Catch complexity before it is written, not only at the post-MODIFY discard table below.
    • Surgical Changes. Every semantically changed line must trace directly to the user's request. Adjacent-code "improvements," formatting churn, and deletions of pre-existing dead code are scope_drift — discard.
    • Goal-Driven Execution. Success criterion is a shell command exiting zero, not a vibe. Reject "works well" / "looks good" / "is faster" before coding; replace with a command.

    Full prelude, including the pre-MODIFY checklist and line-trace rule:

    @./skills/principles/SKILL.md


    Universal Protocol — governs ALL 135 skills

    1. The Loop

    Every iterative skill follows one loop. No exceptions.

    round = 0
    baseline = measure(metric_cmd)
    
    WHILE goal_not_met AND budget_not_exhausted:
        round += 1
        REVIEW   — read state: in-scope files, last 10 of results.tsv, git log -5
        IDEATE   — propose ONE change (or N parallel agents, each ONE change)
        MODIFY   — implement, then commit immediately
        VERIFY   — run guard (test_cmd && lint_cmd); run metric_cmd 3x, take median
        DECIDE   — keep or discard (rules below)
        LOG      — append to .godmode/<skill>-results.tsv
    
    Do NOT pause to ask. Do NOT wait for confirmation. Loop until goal, budget, or stuck.
    

    2. Keep / Discard Rules

    KEEP    if  metric improved  AND  guard passed
    DISCARD if  metric worse     OR   guard failed
    DISCARD if  lines_added > 5  AND  metric_delta < 0.5%   # complexity tax
    DISCARD if  complexity_cost > improvement_magnitude      # simplicity wins
    KEEP    if  same metric + fewer lines                    # free simplification
    

    On discard: git reset --hard HEAD~1. Never leave broken commits. On keep: update baseline, continue.

    Cheapest-discard-first precedence. Discards have a cost hierarchy:

    • Cost-0: pre-MODIFY strike. The item is never written. See skills/principles/SKILL.md §2 pre-MODIFY checklist.
    • Cost-1: pre-commit audit. Written, but dropped via git restore -p --staged before the commit lands. See docs/discard-audit.md for the spec.
    • Cost-2: post-commit revert. This section's rules. git reset --hard HEAD~1 after the guard fails or the metric regresses.

    A Cost-2 discard that could have been caught at Cost-0 or Cost-1 is logged as escaped_discard in .godmode/lessons.md in addition to its primary failure class. Escaped discards are feedback for the pre-MODIFY checklist — 3+ escapes in a session means the checklist is drifting and the agent should re-read skills/principles/SKILL.md §2 before IDEATE.

    3. Simplicity Criterion

    Concrete thresholds — apply universally:

    Added linesRequired improvement
    1-5any positive delta
    6-20>= 1%
    21-50>= 3%
    51+>= 5%

    Same metric + fewer lines = always keep. Readability > marginal gains.

    4. Stopping Conditions

    Stop when ANY is true:

    • target_reached — metric hit goal
    • budget_exhausted — max rounds/iterations consumed
    • diminishing_returns — last 3 keeps each < 1% improvement
    • stuck — 5+ consecutive discards (after recovery attempts)

    Log stop_reason in session-log.tsv. Always print final summary.

    5. Stuck Recovery (4-step escalation)

    Step 0: DIAGNOSE — read last 3 commit diffs + test output.
            Write a 2-sentence diagnosis: what pattern the failures share,
            and what constraint they all violate.
            Example: "Last 3 attempts all added caching layers.
            The metric is I/O-bound, not CPU-bound. Switch to async I/O."
    Step 1: try OPPOSITE of last approach (informed by diagnosis)
    Step 2: try RADICAL rewrite of hotspot (informed by diagnosis)
    Step 3: accept defeat — stop, log "stuck", report best result
    

    The diagnosis turns blind retries into informed pivots. Never skip Step 0. The 2-sentence diagnosis must reference specific code or test output. Never repeat a failed approach. Never loop without changing strategy.

    6. Logging

    All skills log to .godmode/:

    Per-skill: .godmode/<skill>-results.tsv

    round	change	metric_before	metric_after	delta%	status	lines_changed
    

    Session: .godmode/session-log.tsv

    timestamp	skill	rounds	kept	discarded	final_metric	stop_reason
    

    Append only. Never overwrite. Create on first write.

    7. Execution Rules

    1. Detect stack FIRST (see orchestrator). Cache stack, test_cmd, lint_cmd, build_cmd.
    2. Read skills/<skill>/SKILL.md — follow it literally. This protocol overrides on conflict.
    3. Commit BEFORE verify. Revert on failure. Zero broken commits in history.
    4. Multi-agent: <=5 agents/round, worktree isolation. Merge sequentially, test after each. For skills that support it, parallel hypothesis mode dispatches N agents on different approaches to the same problem. Best wins, rest discarded. This is different from multi-agent task dispatch (different parts of code).
    5. No worktrees? Sequential branches: godmode-{skill}-{round}, merge winner, delete rest.
    6. Metric = shell command outputting a single number. No subjective judgment. Ever.
    7. Iterations: N = exactly N rounds. No number = loop until stopped. Never ask to continue.
    8. Chain: think -> plan -> [predict] -> build -> test -> fix -> review -> optimize -> secure -> ship.

    8. Failure Classification

    Every DISCARD must be classified. Append to .godmode/<skill>-failures.tsv:

    round	change	delta%	failure_class	reason	files_touched
    

    Failure classes (use exactly one per discard):

    ClassWhen to use
    measurement_errorMetric command flaky or non-deterministic (stdev > delta)
    noiseDelta within variance threshold (<0.5%)
    regressionChange broke something unrelated
    file_scope_driftChange touched files outside task.files (wrong file). Recovery: revert whole commit, re-dispatch with narrower task.files.
    line_scope_driftChange touched right file but added unrelated lines (formatting churn, adjacent "improvements," renames for consistency, deleted pre-existing dead code, auto-formatter reflows). Recovery: surgically drop drift hunks via git restore -p --staged, keep in-scope hunks, re-run guard. See docs/discard-audit.md.
    complexity_taxImprovement too small for lines added
    infrastructureDocker/env/dependency/tooling issue
    already_triedSimilar approach discarded in last 10 rounds
    overfittingImprovement specific to one case, not generalizable

    Before each IDEATE step, read the last 10 rows of failures.tsv:

    • If >3 failures in the same class: stop trying that approach category.
    • If last 2 discards share a class: switch strategy before next attempt.
    • Discarded runs still provide learning signal. Never delete failures.tsv.

    9. Overfitting Prevention

    Before every KEEP decision, apply these tests:

    1. Variance test: Run metric_cmd 3 times. If stdev > |delta|, classify as noise and DISCARD.
    2. Generalization test: "If this exact file/test disappeared, would this change still improve the project?" If NO → DISCARD as overfitting.
    3. No task-specific hacks: Never add hardcoded logic for one specific test case, input, or benchmark. Fix the class of problems, not one instance.
    4. Simplification wins: Equal metric + fewer lines = always KEEP. This is never overfitting.

    10. Learning from Discards

    Discarded runs still provide learning signal. Never waste a failure.

    After every DISCARD:

    1. Classify the failure (see Failure Classification above).
    2. Append to .godmode/<skill>-failures.tsv with reason.
    3. Check: has this failure class occurred 3+ times? If yes, that approach category is exhausted — switch strategy entirely.

    Before every IDEATE:

    1. Read last 10 rows of <skill>-failures.tsv.
    2. Count failures per class.
    3. Avoid the most common failure class. Try the LEAST common instead.
    4. If all 8 classes have 2+ failures: escalate to stuck recovery.

    The failures log is append-only. It persists across sessions. It is the memory of what NOT to try.

    11. Environment Isolation

    For reproducible metrics, optionally wrap metric_cmd in Docker:

    metric_cmd_docker: "docker run --rm -v $(pwd):/app -w /app node:20 npm run benchmark"
    

    When Docker is available AND metric variance > 5%:

    • Build image once, cache dependencies.
    • Run each metric measurement in a fresh container.
    • Eliminates: cache drift, background process noise, dependency skew.

    When Docker is NOT available (default):

    • Run metric_cmd 3x, take median.
    • Flag warning if variance > 5% between runs.
    • Log variance in results.tsv as additional column.

    Docker is recommended but never required. The loop works identically either way.

    12. Session Resume

    After every iteration, atomically save state to .godmode/session-state.json:

    {
      "skill": "optimize",
      "round": 7,
      "baseline": 847,
      "current_best": 198,
      "last_kept_commit": "abc1234",
      "consecutive_discards": 0,
      "approach_history": ["index", "gzip", "eager_load", "pool", "cache"],
      "failure_classes": {"noise": 2, "regression": 1},
      "stop_reason": null,
      "timestamp": "2026-04-04T12:30:00Z"
    }
    

    On session start:

    1. Check .godmode/session-state.json. If exists and stop_reason is null:
      • Print: "Resuming from round {round}. Best so far: {current_best}."
      • Verify last_kept_commit matches HEAD. If not, warn and ask.
      • Continue the loop from round N+1.
    2. If stop_reason is set: previous session completed. Start fresh.
    3. If file doesn't exist: first run. Start fresh.

    On session end (normal or interrupted):

    • If loop completed: set stop_reason in state file.
    • If interrupted: state file has stop_reason: null → next session resumes.

    13. Lessons

    Persistent learning across sessions. File: .godmode/lessons.md

    After each session, append 1-3 lessons learned:

    ### Round N — {skill} — {date}
    - Lesson: {concrete, reusable insight}
    - Context: {what happened that taught this}
    

    Before each session, read lessons.md:

    • Apply relevant lessons to the current task.
    • Never repeat a mistake that has a lesson entry.

    Format rules:

    • One lesson per bullet. Concrete and actionable.
    • Bad: "Be careful with caching."
    • Good: "Redis TTL must match DB write frequency. 60s TTL with 5min writes = stale reads."
    • Lessons are append-only. Never delete. Mark obsolete lessons with [OBSOLETE].

    14. Default Activations

    Every /godmode:* invocation — and every natural-language /godmode request that routes to a pipeline skill (think, plan, build, test, fix, optimize, secure, ship) — fires the full default stack below. No explicit flags required. This section is the single source of truth for what runs by default.

    Authoring discipline (Karpathy family)

    1. Principles preludeskills/principles/SKILL.md is imported via @./skills/principles/SKILL.md from SKILL.md, GEMINI.md, OPENCODE.md. Every agent reads it before the first Edit. Governs: Think Before Coding, Simplicity First (pre-MODIFY strike), Surgical Changes (line-trace rule), Goal-Driven Execution.
    2. Pre-commit discard auditagents/builder.md § Protocol 10a, agents/tester.md § Protocol 12a, agents/optimizer.md § Protocol 11a. Before every git commit, drops line_scope_drift hunks via git restore -p --staged. Spec: docs/discard-audit.md.
    3. DispatchContext schema validationAGENTS.md § DispatchContext Schema. All 7 subagents validate input at dispatch time; missing required field → BLOCKED: invalid_dispatch.
    4. Discard cost hierarchy — Cost-0 (pre-MODIFY strike), Cost-1 (pre-commit audit), Cost-2 (post-commit revert). Cost-2 discards that should have been caught earlier are logged as escaped_discard in lessons.md.
    5. Scope-drift taxonomyfile_scope_drift (wrong file → revert whole commit) vs line_scope_drift (right file, wrong lines → drop hunks surgically). See SKILL.md §8 Failure Classification.

    Token optimization (caveman / rtk / Harness family)

    1. Progressive Disclosure routingskills/godmode/SKILL.md § Step 2 reads ONLY Tier 1 (~20 lines) of each skill at route time via a POSIX awk extractor. ~90% routing-time context reduction across 135 skills.
    2. Stdio input-side compressionskills/stdio/SKILL.md. Canonical command patterns (git log → git log --oneline -20, cat → wc -l, etc.) that every agent prefers. Referenced from AGENTS.md § Context Refresh.
    3. Terse output-side compressionskills/terse/SKILL.md. Auto-activates from round 2 onward (lowered from 5 in Phase E) unless terse_user_opted_out=true. Compresses round summaries, status lines, agent reports. TSVs, code, errors, commit messages, final summary stay verbose.
    4. Token observabilityskills/tokens/SKILL.md. Logs per-round input/output token counts to .godmode/token-log.tsv. Default ON per session; opt out via GODMODE_TOKENS=0.
    5. Lessons compressionskills/godmode/SKILL.md § Step 0b compresses lessons.md if it exceeds 100 lines before loading.

    Coordination and observability (Harness + best-practice family)

    1. Named coordination patternsdocs/coordination-patterns.md. Every plan declares its outermost pattern (Pipeline, Fan-out/Fan-in, Expert Pool, Producer-Reviewer, Supervisor, Hierarchical Delegation) in its first line. Enforced in skills/plan/SKILL.md.
    2. Research auto-dispatchskills/godmode/SKILL.md § Step 3 routes to skills/research/SKILL.md before skills/think/ when the task mentions an external library/framework, spans >5 files, or has no prior .godmode/research.md.

    How the 8 pipeline skills inherit

    Each of think, plan, build, test, fix, optimize, secure, ship has a rule in its ## Hard Rules section:

    0. Inherits Default Activations per SKILL.md §14. Principles prelude, pre-commit audit, terse, stdio, tokens, DispatchContext validation, Progressive Disclosure routing, discard cost hierarchy, and coordination patterns all fire by default. Do NOT require explicit flags; do NOT skip any of them unless the user opts out via documented env vars or slash commands.

    Non-pipeline skills (like bench, tutorial, team) inherit §14 indirectly through skills/godmode/SKILL.md — the orchestrator applies Step 0a, 0b, and Step 3b checks regardless of which skill is dispatched.

    Opt-outs (the only way to disable a default)

    DefaultOpt-out
    Terse auto-activation/godmode:terse off (sticky for session) or GODMODE_TERSE=0
    Token loggingGODMODE_TOKENS=0 env var
    Pre-commit auditCannot opt out — it's a mechanical gate
    Principles preludeCannot opt out — imported as @./ prelude
    DispatchContext validationCannot opt out — it's a hard gate
    Progressive DisclosureCannot opt out — Tier 2/3 always loadable on demand
    Research auto-dispatchPass --no-research flag OR run /godmode:think directly

    Everything else runs on every normal command.

    Frequently asked questions

    What to verify before installation and use

    What does the godmode source document cover?

    Authoring discipline governs what you decide to write. The Universal Protocol below governs how you verify and keep it. Read the prelude before every Edit. For trivial tasks (one-line fixes, typos, renames, pure formatting), use judgment — the gates apply to behavior changes.

    How do I install godmode?

    The source record exposes this install command: npx skills add https://github.com/arbazkhan971/godmode. Inspect the command and pinned source before running it.

    Alternatives

    Compare before choosing

    Computed 94237,644

    NousResearch/hermes-agent

    godmode

    Jailbreak LLMs: Parseltongue, GODMODE, ULTRAPLINIAN.

    Computed 10045,960

    coreyhaines31/marketingskills

    ab-testing

    When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program

    Computed 10029,236

    garrytan/gbrain

    bulk-ingestion

    End-to-end discipline for turning any large data source (audio libraries, email takeouts, document corpora, chat exports, API dumps) into brain pages at scale. The lifecycle spine: SCHEMA → ACCESS → TRIAL → EVALUATE → IMPROVE → CODIFY → TEST → SKILLIFY → BULK → MONITOR. State is tracked in a durable JSON manifest (see MANIFEST-PATTERN.md) so any crash, session boundary, or subagent fan-out resumes from ground truth instead of memory.

    Computed 10025,136

    alirezarezvani/claude-skills

    app-store-optimization

    App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist