Mammoth Growth Agentic Harness Review — cc-wrapped

Why this is in the vault

The founder built this harness during his time at Mammoth Growth. It represents his prior art in agentic tooling — the work that preceded RDCO’s setup. Understanding what he built, what worked, and what to bring forward informs our own architecture decisions and validates the trajectory from consulting-mode agent to autonomous COO agent.

Architecture overview

Three-layer repository structure:

Wrapper (root): Claude Code skills, commands, agents, hooks — the harness itself
App (apps/*): Client deliverable code (dbt projects)
Project Docs (docs/*): Specs, bundles, ADRs, documentation

Key constraint: never cd into nested repos — always operate from wrapper root with full paths. This is enforced via a bash guardrail hook.

Key components

Bundle system (standout feature)

Entity-centric work tracking with phase subdirectories. Each bundle is a self-contained directory:

bundles/{NNN}-{slug}/
├── _bundle.md              # Manifest (status, links, session log)
├── discovery/              # Scout reports
├── architecture/           # ADRs
├── planning/               # Implementation plans
├── validation/             # Test reports
├── delivery/               # Documentation
└── session-log.md          # Agent activity history

The _bundle.md manifest tracks linked documents, key decisions, open questions, and session history. Context travels WITH the work.

Workflow orchestrator

Template-based SDLC phases: Discovery → Architecture → Planning → Building → Validation → Delivery. Five templates (full, quick-fix, investigation, refactor, doc-only) map to different task complexities. Mandatory human gate before code changes even in auto mode. Headless mode for CI/CD.

56 dbt best-practice rules

Individual atomic files covering architecture tiers, naming conventions, SQL formatting, join patterns, testing strategy, and performance. Composable, referenceable rule system.

Scout agent system

Complexity-based allocation: haiku for simple tasks, opus for deep analysis. Strategic mixing per subtask.

Hooks

Bash guardrail: DENY gh pr merge and cd into nested repos; ASK for destructive SQL, terraform destroy, kubectl delete
QMD session-start auto-indexing
QMD post-edit re-indexing
Browser cleanup on stop

Grade: B+

Dimension	Grade
Architecture	A-
Skill depth	A
Security	A
Ergonomics	B
Autonomy	C+
Self-improvement	C
TDD/Evals	C+
Portability	B+

What to bring into RDCO

Bundle concept for project-scoped context — complement to Notion, not replacement
Workflow templates — pre-defined phase sequences for different task types
Bash guardrail — add destructive SQL detection as ASK rule
Visual-explainer skill — HTML diagrams with branded templates for newsletter
Compound/learnings system — categorized atomic learning documents

Gaps relative to RDCO

No autonomous loops or watch modes (interactive-only)
No self-improvement feedback loop (captures learnings but doesn’t self-modify skills)
Validation after building, not test-first (TDD gap the founder identified)
Bundle system requires configuration — no zero-config fallback
Commands format rather than skills format for core workflow

2026-04-11-garry-tan-thin-harness-fat-skills — Tan’s framework validates the architecture: thin harness (CLAUDE.md + hooks), fat skills (56 dbt rules, visual-explainer)
synthesis-harness-thesis-dissent-2026-04-12 — the “data is the real moat” argument applies here: MG harness is reusable, but the dbt rules + client knowledge are the moat
../01-projects/data-quality-framework/testing-matrix-template — our testing framework addresses the TDD gap the founder identified