From godmode
Conducts design session: clarifies problem, scans codebase with git/package.json/grep, generates 2-3 approaches, recommends one, outputs .godmode/spec.md.
How this skill is triggered — by the user, by Claude, or both
Slash command
/godmode:thinkThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
- `/godmode:think`, "design", "brainstorm"
/godmode:think, "design", "brainstorm"PROBLEM STATEMENT:
- Goal: <one sentence>
- Constraints: <time, tech, backwards compat>
- Success criteria: <shell command that exits 0>
- Out of scope: <what this does NOT include>
IF ambiguous: offer 2 interpretations with examples
"A) You want X -- e.g. user clicks, modal appears"
"B) You want Y -- e.g. data syncs on page load"
User picks one. Proceed immediately.
IF success criteria is subjective ("works well"):
reject and propose concrete alternative
e.g., "response time < 200ms" or "tests pass"
IF greenfield (no repo): skip to Step 3.
# Project structure
git ls-files | head -150
# Entry points and configs
cat package.json 2>/dev/null \
|| cat pyproject.toml 2>/dev/null
# Existing types related to feature
grep -rn "interface\|type\|class\|def " \
--include="*.ts" --include="*.py" | head -40
# Recent changes in related areas
git log --oneline -15 -- <affected-paths>
# Test patterns
ls -la tests/ test/ __tests__/ spec/ 2>/dev/null
CODEBASE SCAN:
- Framework: <name + version>
- Patterns to reuse: <routing, error handling>
- Patterns to avoid: <deprecated patterns>
- Related code: <files in same domain>
APPROACH {A|B|C}: {name}
What: {1-2 sentences}
Why it wins: {main advantage}
Why it loses: {main disadvantage}
Files: {N} to create/modify
Disqualify any approach that:
RECOMMENDATION: Approach {A|B|C}
- Chosen because: <1-2 sentences>
- Approach B rejected: <key weakness>
- Top risk: <biggest risk>
- Mitigation: <concrete action>
IF two approaches are equal: prefer fewer files.
Write .godmode/spec.md with sections:
Problem (1-3 sentences), Approach (2-5),
Success Criteria (shell command exits 0),
Out of Scope, Files to Modify (path + what),
Files to Create (path + purpose),
Risks (risk + mitigation pairs).
Keep under 100 lines total.
# Verify referenced files exist
for f in <files_to_modify>; do
git ls-files --error-unmatch "$f"
done
# Verify new file parent dirs exist
for f in <files_to_create>; do
test -d "$(dirname "$f")" \
|| echo "MISSING: $(dirname "$f")"
done
# Verify success criteria syntax
bash -n -c '<success_criteria_cmd>' 2>&1
# Verify spec length (target <100)
wc -l .godmode/spec.md
# Commit
git add .godmode/spec.md \
&& git commit -m "spec: {feature}"
IF any validation fails: fix before committing.
Think: problem -- <goal>.
Think: scanned codebase -- <framework>, {N} files.
Think: generated {N} approaches.
Think: recommending Approach {X} -- <reason>.
Think: wrote .godmode/spec.md ({N} lines).
Spec: {path}. Approach: {chosen}. Files: {N}+{N}.
Append to .godmode/think-log.tsv:
timestamp\tfeature\tapproaches\tchosen\tfiles_modify\tfiles_create\tspec_lines\trisks
SKILL.md §14. Principles prelude (Think/Simplicity/Surgical/Goal-driven), 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..godmode/research.md if it exists — research auto-dispatched before think per SKILL.md §14.KEEP if: approach passes disqualification criteria
AND has testable success criteria
DISCARD if: violates constraints OR >30 files
OR no testable criteria
STOP when FIRST of:
- spec.md written, validated, and committed
- 3 approaches evaluated (max)
- >5 validation failures on spec
npx claudepluginhub arbazkhan971/godmodeGuides structured design brainstorming before implementation — explores codebase, asks clarifying questions, proposes approaches with trade-offs, and writes an approved spec. Use to avoid premature coding.
Use when starting any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements, and design before implementation.
Guides a disciplined Socratic brainstorming loop before any creative or implementation work: clarifying questions, pushback, trade-off analysis, design doc, user approval, then handoff to implementation.