commands
// Prompting Mammouth
Read CLAUDE.md and requirements/backlog/US-002-homepage.md then build what is described.
// Build to Docker
docker compose up -d --build
// Push to Github from local repo
git push origin main && git push github main
Approach 1: Claude + Claude Code (Recommended)
The setup: Claude.ai (this chat) for requirements, architecture, and planning. Claude Code in your terminal, pointed at a GitHub repo, for building.
Strengths for your use case:
- Claude Code reads the entire repo — requirements docs, previous decisions, all code — in every session. Full context, no re-explaining
- Designed exactly for agentic development: multi-file edits, running tests, git operations, all from the terminal
- The
CLAUDE.mdfile acts as a persistent standing brief — it knows the operating model, the stack, the conventions every time - Tight loop: you update a requirement file, I build against it, you review the diff as a PR
Weaknesses:
- Separate subscription cost on top of what you already pay
- Terminal-based — no GUI, requires comfort with command line
Approach 2: Mammouth.AI + Mammouth Code
The setup: Mammouth AI gives you access to multiple leading models — GPT-4o, Claude, Grok, Mistral, Llama, Gemini — under a single €10/month subscription. Mammouth Code is their terminal-based coding agent, open source, installed via a single shell command and run by typing mammouth in your IDE’s integrated terminal.
Strengths for your use case:
- You already pay for it — no additional cost
- Mammouth Code has recently been updated with improved long context handling — more context capacity, better content extraction, improved management of long code context
- Model flexibility — if one model underperforms on a task, you can switch
- Works inside VS Code, Cursor, WebStorm — run it in the integrated terminal, navigate to your project directory, and it starts an interactive session right there
Weaknesses for your use case:
- Mammouth Code is a newer, less battle-tested tool than Claude Code for complex multi-file agentic work
- The model routing adds a layer of unpredictability — you don’t always know which model is doing what
- Less ecosystem depth around the
CLAUDE.md-style persistent briefing pattern - The operating model (BA → Architect → Dev) works best with a single consistent model that knows your codebase well; multi-model switching works against that
Side-by-Side
| Feature | Claude + Claude Code | Mammouth + Mammouth Code |
|---|---|---|
| Cost | Additional subscription | Already included |
| Repo awareness | Deep, by design | Good, improving |
| Agentic coding maturity | High | Moderate |
| Model consistency | Single model, predictable | Multi-model, flexible |
| Operating model fit | Purpose-built for this | Adaptable but not purpose-built |
| GitHub integration | Native | Works, not native |
| CLAUDE.md-style briefing | Built-in pattern | Achievable via custom mammouths |
Recommendation
Start with Mammouth Code since you already have the subscription — it’s capable enough to test the operating model at no extra cost. Use it in the integrated terminal of your IDE alongside your GitHub repo. If you hit limitations — context dropping, inconsistent behaviour across files, or architectural decisions not sticking between sessions — that’s the signal to switch to Claude Code.
The requirements + GitHub repo structure we designed works with either tool. The investment in setting that up isn’t wasted regardless of which you choose.