Mortdecai
ea3cf45953
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>
2.5 KiB
2.5 KiB
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
- 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.
- Fine-grained history. Each commit is one logical change.
git bisectactually works. Reverts are surgical, not radioactive. - No merge conflicts from batching. Small, frequent pushes rarely conflict. Large, infrequent pushes always do.
- 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:
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:
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
.envand 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)