feat: add core/ tier reflecting actual universal workflow
The original repo presented everything as equal rules. In reality, the workflow has two tiers: core practices (used in every project) and advanced rules (only in complex projects like Mortdecai). Core tier adds: - backup-before-edit (global CLAUDE.md rule) - superpowers-workflow (the actual workflow engine) - memory-system (persistent feedback and project memories) - document-hierarchy (CLAUDE.md/SESSION.md/CONTEXT.md/IDEA.md) - commit-and-push discipline - feedback-driven behaviors Updated README, docs, and dynamic-methodology to reflect the two-tier reality instead of presenting advanced rules as universal. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Mortdecai
@@ -0,0 +1,41 @@
|
||||
# Backup Before Edit
|
||||
|
||||
Before editing any file, back up the original to a `.backup/` directory in the same parent folder.
|
||||
|
||||
## Why
|
||||
|
||||
Disk space is cheap. Lost work is expensive. AI assistants sometimes make destructive edits — overwriting files, truncating content, or introducing bugs that are hard to reverse. A `.backup/` directory provides instant recovery without relying on git history (which may not exist yet, or may have uncommitted changes).
|
||||
|
||||
## How
|
||||
|
||||
Before modifying `src/config.py`:
|
||||
|
||||
```bash
|
||||
mkdir -p src/.backup
|
||||
cp src/config.py src/.backup/config.py
|
||||
```
|
||||
|
||||
For files that get edited multiple times, timestamp the backup:
|
||||
|
||||
```bash
|
||||
cp src/config.py src/.backup/config.py.$(date +%Y%m%d-%H%M%S)
|
||||
```
|
||||
|
||||
## Gitignore
|
||||
|
||||
Add `.backup/` to your `.gitignore` so backups are never committed:
|
||||
|
||||
```
|
||||
.backup/
|
||||
```
|
||||
|
||||
## When to Apply
|
||||
|
||||
- **Always** before editing existing files, especially configuration or infrastructure files
|
||||
- **Always** when an AI assistant is making changes to files you haven't read yet
|
||||
- **Skip** for files you just created in this session (nothing to back up)
|
||||
- **Skip** for test files during rapid iteration (git handles recovery)
|
||||
|
||||
## Where This Rule Lives
|
||||
|
||||
This belongs in your global `~/.claude/CLAUDE.md` so it applies to every project without per-project configuration. It's the one rule that should be universal and unconditional.
|
||||
@@ -0,0 +1,73 @@
|
||||
# Commit & Push Discipline
|
||||
|
||||
The actual commit workflow: commit every meaningful change immediately, push on the same command. No squashing, no batching unrelated changes.
|
||||
|
||||
## The Rule
|
||||
|
||||
**Commit and push after every meaningful change.** Not at the end of the day. Not in batches. Every completed function, bug fix, test addition, or documentation update gets its own commit and push.
|
||||
|
||||
## Why This Is Non-Negotiable
|
||||
|
||||
1. **You never lose more than 15-30 minutes of work.** If the machine dies, the power goes out, or the AI assistant corrupts a file, your latest work is already on the remote.
|
||||
2. **Fine-grained history.** Each commit is one logical change. `git bisect` actually works. Reverts are surgical, not radioactive.
|
||||
3. **No merge conflicts from batching.** Small, frequent pushes rarely conflict. Large, infrequent pushes always do.
|
||||
4. **Accountability.** The commit message explains *what* and *why* for each change individually.
|
||||
|
||||
## Commit Message Format
|
||||
|
||||
Conventional commits, always:
|
||||
|
||||
```
|
||||
<type>: <short description>
|
||||
```
|
||||
|
||||
| Type | When |
|
||||
|------|------|
|
||||
| `feat:` | New feature or functionality |
|
||||
| `fix:` | Bug fix |
|
||||
| `docs:` | Documentation changes |
|
||||
| `refactor:` | Code restructuring (no behavior change) |
|
||||
| `test:` | Adding or updating tests |
|
||||
| `chore:` | Maintenance, dependencies |
|
||||
|
||||
Examples:
|
||||
```bash
|
||||
git commit -m "feat: add user authentication endpoint"
|
||||
git commit -m "fix: resolve null pointer in data parser"
|
||||
git commit -m "test: add unit tests for payment module"
|
||||
```
|
||||
|
||||
## Push Immediately
|
||||
|
||||
After committing, push in the same command or immediately after:
|
||||
|
||||
```bash
|
||||
git add <files> && git commit -m "feat: ..." && git push
|
||||
```
|
||||
|
||||
If using a git hosting CLI wrapper (like `gitea push`), use that — it handles authentication automatically.
|
||||
|
||||
## What Counts as "Meaningful"
|
||||
|
||||
- A function completed and working
|
||||
- A bug fixed and tested
|
||||
- Tests added or modified
|
||||
- Documentation updated
|
||||
- Configuration changed
|
||||
- Before switching to a different task
|
||||
- Before risky experiments
|
||||
- Every 15-30 minutes of active coding (at natural breakpoints)
|
||||
|
||||
## What Does NOT Get Committed
|
||||
|
||||
- Code that doesn't compile or run
|
||||
- Half-finished features with no clean boundary
|
||||
- Files containing secrets (.env, credentials, tokens)
|
||||
- Temporary debugging artifacts (console.log spam, print statements)
|
||||
|
||||
## Security Before Committing
|
||||
|
||||
Before every push:
|
||||
- Ensure `.env` and credential files are in `.gitignore`
|
||||
- The pre-push hook (if installed) scans tracked files against known secret values
|
||||
- Never commit secrets — if one slips through, rotate immediately (git rm doesn't erase history)
|
||||
@@ -0,0 +1,100 @@
|
||||
# Document Hierarchy
|
||||
|
||||
The foundation of the entire workflow. Four file types, each with a distinct purpose, used consistently across every project.
|
||||
|
||||
## The Four Documents
|
||||
|
||||
| File | Purpose | When Updated | Loaded |
|
||||
|------|---------|-------------|--------|
|
||||
| **CLAUDE.md** | Project instructions for the AI | When components, tools, or architecture change | Every session (auto) |
|
||||
| **SESSION.md** | Accumulated AI memory — decisions, discoveries, patterns | During/after each session | On demand |
|
||||
| **CONTEXT.md** | Static infrastructure facts — hosts, ports, services | When infrastructure changes | On demand |
|
||||
| **IDEA.md** | Plain-language project brief | Rarely (initial creation) | On demand |
|
||||
|
||||
## CLAUDE.md — The Starting Point
|
||||
|
||||
The AI reads this first, every session. It should contain:
|
||||
|
||||
- **Project state** — current phase, branch, test status, deployment
|
||||
- **Architecture** — how components connect, key files and their roles
|
||||
- **Conventions** — commit style, naming, project-specific rules
|
||||
- **Credentials** — where they live (never the values themselves)
|
||||
- **Development commands** — setup, run, test
|
||||
|
||||
**Keep it lean.** Everything in CLAUDE.md loads every session. Don't dump session notes or temporary debugging context here. Stable, long-term facts only.
|
||||
|
||||
**Keep it current.** If you create a new tool and don't document it here, the next session won't know it exists. Update CLAUDE.md immediately when components change — don't leave it for later.
|
||||
|
||||
## SESSION.md — The Living Memory
|
||||
|
||||
Accumulates decisions, discoveries, and context across AI sessions. Grouped by topic, not by date.
|
||||
|
||||
```markdown
|
||||
## Session Notes
|
||||
|
||||
### Infrastructure decisions
|
||||
- Chose LXC over Docker-in-LXC because the service doesn't need container isolation
|
||||
- Enabled nesting=1 on the container to allow Docker inside
|
||||
|
||||
### Bug fixes & discoveries
|
||||
- Service wasn't starting: had autoStart=false in config
|
||||
(fixed: set autoStart=true, verified with restart)
|
||||
|
||||
### Open threads
|
||||
- [ ] Add Redis backend for session persistence
|
||||
- [ ] Web dashboard for monitoring
|
||||
```
|
||||
|
||||
**Key principle:** Update the relevant section rather than appending raw timestamped blocks. A reader should be able to scan by topic, not wade through chronological entries.
|
||||
|
||||
## CONTEXT.md — The Infrastructure Facts
|
||||
|
||||
Static facts about where and how the project runs. Ports, hosts, services, dependencies. Updated when infrastructure changes, not during routine development.
|
||||
|
||||
This is separate from CLAUDE.md because infrastructure facts are reference material — loaded on demand, not every session.
|
||||
|
||||
## IDEA.md — The Original Intent
|
||||
|
||||
Written once at project creation. Captures what the project is, what problem it solves, and any known constraints. Rarely modified after creation.
|
||||
|
||||
Useful for: new contributors understanding why the project exists, AI assistants that need to understand the original motivation, and the project creator looking back at initial intent vs current reality.
|
||||
|
||||
## How They Relate
|
||||
|
||||
```
|
||||
Session start:
|
||||
→ AI reads CLAUDE.md (auto-loaded, always)
|
||||
→ AI checks MEMORY.md (auto-loaded, always)
|
||||
→ AI checks .claude/sessions/ for recent handoffs
|
||||
|
||||
During work:
|
||||
→ AI reads CONTEXT.md when infrastructure details needed
|
||||
→ AI reads SESSION.md when historical decisions needed
|
||||
→ AI reads IDEA.md when original intent/scope is questioned
|
||||
|
||||
Session end:
|
||||
→ AI updates SESSION.md with new decisions/discoveries
|
||||
→ AI updates CLAUDE.md if components changed
|
||||
→ AI writes handoff if work is unfinished
|
||||
```
|
||||
|
||||
## The Global CLAUDE.md
|
||||
|
||||
In addition to per-project CLAUDE.md files, a global `~/.claude/CLAUDE.md` applies to all projects. Use it for:
|
||||
|
||||
- Universal rules (like "backup before edit")
|
||||
- Tool documentation (CLI wrappers, custom scripts)
|
||||
- Infrastructure overview (what machines exist, how to reach them)
|
||||
- Cross-project conventions
|
||||
|
||||
Per-project CLAUDE.md files inherit from and can override the global one.
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
**CLAUDE.md as a dumping ground.** If it grows beyond ~200 lines, it's too heavy. Move reference material to CONTEXT.md, move decisions to SESSION.md, move architecture to `docs/`.
|
||||
|
||||
**SESSION.md as a chat transcript.** It's not a log of what was said. It's a curated record of what was *decided* and *discovered*. Group by topic, not by date.
|
||||
|
||||
**CONTEXT.md for opinions.** It stores facts (this service runs on port 8080), not opinions (we should probably migrate to a different port). Opinions go in SESSION.md or design docs.
|
||||
|
||||
**Forgetting to update CLAUDE.md.** The single most common failure mode. You create a new tool, the session ends, the next session doesn't know it exists. Update immediately, not "later."
|
||||
@@ -0,0 +1,82 @@
|
||||
# Feedback-Driven Behaviors
|
||||
|
||||
Over time, corrections and confirmed approaches accumulate into persistent behavioral patterns. These are the real workflow rules — not written in a rules file, but learned from experience and stored in memory.
|
||||
|
||||
## How It Works
|
||||
|
||||
When the user corrects the AI ("don't do X") or confirms a non-obvious approach ("yes, exactly like that"), the correction or confirmation is saved as a feedback memory. Future sessions load these memories and adjust behavior accordingly.
|
||||
|
||||
This means the workflow evolves organically. The rules files define the framework, but feedback memories define the actual behavior within that framework.
|
||||
|
||||
## Common Feedback Patterns
|
||||
|
||||
These are examples of the kinds of behavioral rules that emerge from real usage:
|
||||
|
||||
### Execution Style
|
||||
- **Prefer immediate execution over confirmation dialogs.** When the task is obvious, communicate what you're doing and go. Don't ask "should I proceed?" for routine operations.
|
||||
- **Queue awareness.** Users often queue follow-up instructions while work runs in the background. Always check for and address ALL queued messages before moving on.
|
||||
|
||||
### Subagent Safety
|
||||
- **Use subagent-driven execution by default** for independent tasks — it's faster and keeps context clean.
|
||||
- **NEVER use subagents for destructive operations.** Git history changes, bare repo operations, database modifications, file deletions on remote servers — do these manually in the main conversation, one at a time. A subagent can't be stopped mid-operation if something goes wrong.
|
||||
|
||||
### Research Depth
|
||||
- **Read memory files before creating tasks or starting work.** Feedback memories contain corrections that prevent repeating past mistakes. Skipping them means re-learning the same lessons.
|
||||
- **Verify infrastructure before acting on documentation.** Ping IPs before SSH, check services before connecting. Docs go stale faster than code.
|
||||
|
||||
### Communication
|
||||
- **Voice opinions.** Push back when the user's direction seems wrong. "I think there's a better approach because..." is more valuable than silent compliance.
|
||||
- **Use the question tool for design choices.** Don't make assumptions about architecture or design — ask explicitly when multiple valid approaches exist.
|
||||
|
||||
## Recording New Feedback
|
||||
|
||||
When a correction happens:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: feedback_no_mock_database
|
||||
description: Integration tests must use real database, not mocks
|
||||
type: feedback
|
||||
---
|
||||
|
||||
Integration tests must hit a real database, not mocks.
|
||||
|
||||
**Why:** Prior incident where mocked tests passed but the production migration failed.
|
||||
Mock/prod divergence masked a broken migration.
|
||||
|
||||
**How to apply:** When writing tests that touch database operations, always use a
|
||||
test database instance. Never mock the database layer in integration tests.
|
||||
```
|
||||
|
||||
Key elements:
|
||||
- **The rule itself** (lead with this)
|
||||
- **Why** — the reason, often a past incident or strong preference
|
||||
- **How to apply** — when/where this guidance kicks in
|
||||
|
||||
## Recording Confirmed Approaches
|
||||
|
||||
Corrections are obvious. Confirmations are quieter — watch for them:
|
||||
|
||||
- "Yes, exactly" or "perfect, keep doing that"
|
||||
- Accepting an unusual choice without pushback
|
||||
- "The single bundled PR was the right call here"
|
||||
|
||||
Save these too. If you only save corrections, you drift away from approaches the user has already validated.
|
||||
|
||||
## Feedback vs Rules
|
||||
|
||||
| Aspect | Rules (`.claude/rules/`) | Feedback (memory) |
|
||||
|--------|--------------------------|-------------------|
|
||||
| Scope | Project-wide | Often personal/contextual |
|
||||
| Authority | Highest (cannot override) | Advisory (can override freely) |
|
||||
| Creation | Deliberate, authored | Organic, from corrections |
|
||||
| Maintenance | Manual | Decays if unused |
|
||||
| Loading | Auto-loaded every session | Auto-loaded via MEMORY.md |
|
||||
|
||||
In most projects, feedback memories ARE the rules — there are no `.claude/rules/` files. The governance comes entirely from accumulated corrections and confirmed approaches.
|
||||
|
||||
## When Feedback Contradicts Rules
|
||||
|
||||
If a feedback memory says "skip tests for quick fixes" but a rule says "always write tests," follow the rule. Feedback memories are subordinate to explicit rules (see the authority hierarchy).
|
||||
|
||||
But in projects without explicit rules, feedback memories are the highest available authority after user instructions.
|
||||
@@ -0,0 +1,121 @@
|
||||
# Memory System
|
||||
|
||||
AI assistants forget everything between sessions. The memory system provides persistent, file-based memory that carries context forward.
|
||||
|
||||
## How It Works
|
||||
|
||||
Claude Code maintains a memory directory at `~/.claude/projects/<project-path>/memory/`. Each memory is a markdown file with frontmatter metadata, indexed by a `MEMORY.md` file.
|
||||
|
||||
## Memory Types
|
||||
|
||||
### User Memories
|
||||
Information about who you are — role, expertise, preferences. Helps the AI tailor its approach.
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: user_role
|
||||
description: User is a senior infrastructure engineer with deep Linux/networking expertise
|
||||
type: user
|
||||
---
|
||||
|
||||
Senior infrastructure engineer. Deep expertise in Linux, ZFS, Proxmox, networking.
|
||||
New to React frontend work — frame frontend explanations in terms of backend analogues.
|
||||
```
|
||||
|
||||
### Feedback Memories
|
||||
Corrections and confirmed approaches — what to do and what NOT to do. **The most important type.** These prevent the AI from making the same mistake twice.
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: feedback_subagent_safety
|
||||
description: Never use subagents for destructive server operations
|
||||
type: feedback
|
||||
---
|
||||
|
||||
Never use subagents for destructive server operations (git history changes,
|
||||
bare repo operations, database modifications). Do these manually, one at a time.
|
||||
|
||||
**Why:** A subagent running destructive ops in parallel caused data loss.
|
||||
The main conversation can't intervene if a subagent goes wrong.
|
||||
|
||||
**How to apply:** Before dispatching any agent, check if the task involves
|
||||
destructive operations. If yes, do it in the main conversation sequentially.
|
||||
```
|
||||
|
||||
### Project Memories
|
||||
Ongoing work, decisions, and context that isn't derivable from code or git history.
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: project_auth_rewrite
|
||||
description: Auth middleware rewrite driven by legal compliance, not tech debt
|
||||
type: project
|
||||
---
|
||||
|
||||
Auth middleware rewrite is driven by legal/compliance requirements around
|
||||
session token storage, not tech-debt cleanup.
|
||||
|
||||
**Why:** Legal flagged the current implementation for non-compliant token storage.
|
||||
**How to apply:** Scope decisions should favor compliance over ergonomics.
|
||||
```
|
||||
|
||||
### Reference Memories
|
||||
Pointers to where information lives in external systems.
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: reference_bug_tracker
|
||||
description: Pipeline bugs tracked in Linear project INGEST
|
||||
type: reference
|
||||
---
|
||||
|
||||
Pipeline bugs are tracked in Linear project "INGEST".
|
||||
API monitoring alerts go to #oncall-api Slack channel.
|
||||
```
|
||||
|
||||
## MEMORY.md Index
|
||||
|
||||
`MEMORY.md` is a one-line-per-entry index of all memory files. It's loaded into every conversation.
|
||||
|
||||
```markdown
|
||||
# Memory Index
|
||||
|
||||
- [user_role.md](user_role.md) — Senior infra engineer, new to React
|
||||
- [feedback_subagent_safety.md](feedback_subagent_safety.md) — No subagents for destructive ops
|
||||
- [project_auth_rewrite.md](project_auth_rewrite.md) — Auth rewrite is compliance-driven
|
||||
- [reference_bug_tracker.md](reference_bug_tracker.md) — Bugs in Linear INGEST project
|
||||
```
|
||||
|
||||
Keep entries under 150 characters. MEMORY.md is truncated after 200 lines.
|
||||
|
||||
## What NOT to Save
|
||||
|
||||
- Code patterns or architecture (derivable from reading current code)
|
||||
- Git history (use `git log` / `git blame`)
|
||||
- Debugging solutions (the fix is in the code, context in the commit message)
|
||||
- Anything already in CLAUDE.md
|
||||
- Ephemeral task details (use task tools instead)
|
||||
|
||||
## When to Save
|
||||
|
||||
- **Immediately** when the user explicitly asks to remember something
|
||||
- **Proactively** when you learn about the user's role, preferences, or expertise
|
||||
- **After corrections** — if the user says "don't do X", save it as feedback
|
||||
- **After confirmed approaches** — if something non-obvious worked, save that too
|
||||
- **When project context emerges** that won't be in code (deadlines, stakeholder decisions, compliance requirements)
|
||||
|
||||
## When to Read
|
||||
|
||||
- At conversation start (MEMORY.md index is auto-loaded)
|
||||
- When the user references prior-conversation work
|
||||
- Before making decisions that prior feedback might inform
|
||||
- When the user says "check", "recall", or "remember"
|
||||
|
||||
## Stale Memory
|
||||
|
||||
Memories can become outdated. Before acting on a memory:
|
||||
- If it names a file path: check the file exists
|
||||
- If it names a function or flag: grep for it
|
||||
- If the user asks about *current* state: prefer `git log` or reading code over recalling a snapshot
|
||||
|
||||
"The memory says X exists" is not the same as "X exists now."
|
||||
@@ -0,0 +1,144 @@
|
||||
# Superpowers Plugin — The Actual Workflow Engine
|
||||
|
||||
The Superpowers plugin is not optional tooling — it's the primary workflow enforcement mechanism. It drives the day-to-day development cycle across all projects.
|
||||
|
||||
## What Superpowers Enforces
|
||||
|
||||
Superpowers provides a suite of skills that activate based on what you're doing. The AI assistant is required to invoke them — they're not suggestions.
|
||||
|
||||
### Brainstorming (before any creative work)
|
||||
|
||||
**Trigger:** Creating features, building components, adding functionality, or modifying behavior.
|
||||
|
||||
**What it does:**
|
||||
1. Explores the current project context (files, docs, commits)
|
||||
2. Asks clarifying questions one at a time
|
||||
3. Proposes 2-3 approaches with trade-offs and a recommendation
|
||||
4. Gets user approval before any code is written
|
||||
5. Writes a design spec
|
||||
6. Transitions to implementation planning
|
||||
|
||||
**Why it matters:** Without brainstorming, AI assistants jump to the first reasonable implementation. Brainstorming catches bad assumptions before code exists.
|
||||
|
||||
### Test-Driven Development (before writing implementation)
|
||||
|
||||
**Trigger:** Implementing any feature or bugfix.
|
||||
|
||||
**What it does:**
|
||||
1. Write a failing test first
|
||||
2. Implement the minimum code to pass the test
|
||||
3. Refactor if needed
|
||||
4. Repeat
|
||||
|
||||
**Enforcement:** If active, Superpowers will delete production code written without failing tests first. This is intentionally strict.
|
||||
|
||||
### Systematic Debugging (before proposing fixes)
|
||||
|
||||
**Trigger:** Any bug, test failure, or unexpected behavior.
|
||||
|
||||
**What it does:**
|
||||
1. Reproduce the issue
|
||||
2. Form hypotheses about root cause
|
||||
3. Test hypotheses systematically
|
||||
4. Fix the root cause, not the symptom
|
||||
5. Add regression test
|
||||
|
||||
**Why it matters:** Without this, AI assistants guess at fixes and retry until something works. Systematic debugging finds the actual problem.
|
||||
|
||||
### Verification Before Completion (before claiming done)
|
||||
|
||||
**Trigger:** About to claim work is complete, fixed, or passing.
|
||||
|
||||
**What it does:**
|
||||
1. Requires running verification commands (tests, build, lint)
|
||||
2. Requires confirming output — not just "tests passed" but showing the output
|
||||
3. Evidence before assertions, always
|
||||
|
||||
**Why it matters:** AI assistants will confidently claim "all tests pass" without running them. This forces actual verification.
|
||||
|
||||
### Code Review (after completing work)
|
||||
|
||||
**Trigger:** Major project step completed, implementation finished.
|
||||
|
||||
**What it does:**
|
||||
1. Reviews implementation against the original plan
|
||||
2. Checks coding standards
|
||||
3. Identifies issues, gaps, and improvements
|
||||
|
||||
### Writing Plans (before multi-step implementation)
|
||||
|
||||
**Trigger:** Multi-step task with a design spec ready.
|
||||
|
||||
**What it does:**
|
||||
1. Creates a step-by-step implementation plan
|
||||
2. Identifies critical files and dependencies
|
||||
3. Considers architectural trade-offs
|
||||
4. Provides review checkpoints
|
||||
|
||||
### Subagent-Driven Development (for parallel work)
|
||||
|
||||
**Trigger:** Implementation plan with independent tasks.
|
||||
|
||||
**What it does:**
|
||||
1. Dispatches independent tasks to parallel sub-agents
|
||||
2. Each agent works in isolation
|
||||
3. Results are reviewed and integrated
|
||||
|
||||
## The Actual Daily Cycle
|
||||
|
||||
For a typical feature, the real workflow is:
|
||||
|
||||
```
|
||||
1. User describes what they want
|
||||
2. Superpowers: brainstorming activates
|
||||
→ Clarify requirements
|
||||
→ Propose approaches
|
||||
→ Get approval
|
||||
→ Write spec
|
||||
3. Superpowers: writing-plans activates
|
||||
→ Create implementation plan
|
||||
4. Superpowers: test-driven-development activates
|
||||
→ Write failing test
|
||||
→ Implement
|
||||
→ Verify
|
||||
5. Superpowers: verification-before-completion activates
|
||||
→ Run tests, show output
|
||||
→ Confirm everything works
|
||||
6. Superpowers: code-review activates (if major step)
|
||||
→ Review against plan
|
||||
```
|
||||
|
||||
For a bugfix:
|
||||
```
|
||||
1. User reports bug
|
||||
2. Superpowers: systematic-debugging activates
|
||||
→ Reproduce → Hypothesize → Test → Fix
|
||||
3. Superpowers: verification-before-completion activates
|
||||
→ Run tests, confirm fix
|
||||
```
|
||||
|
||||
## Installation
|
||||
|
||||
```bash
|
||||
# In Claude Code
|
||||
claude plugin install superpowers
|
||||
```
|
||||
|
||||
Enable in `~/.claude/settings.json`:
|
||||
```json
|
||||
{
|
||||
"enabledPlugins": {
|
||||
"superpowers@claude-plugins-official": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Relationship to Rules
|
||||
|
||||
Superpowers is the **enforcement layer** — it actively intervenes during work. The `.claude/rules/` files are the **governance layer** — they define conventions and decision frameworks. Most projects rely on Superpowers alone for workflow enforcement, without explicit rules files.
|
||||
|
||||
When both exist (like in advanced projects), the authority hierarchy applies:
|
||||
1. Rules (`.claude/rules/`) — highest
|
||||
2. Superpowers enforcement — second
|
||||
3. Learned patterns — third
|
||||
4. Defaults — lowest
|
||||
Reference in New Issue
Block a user