DOCC — Operations Command Console

A personal AI operating system built on Claude Code. DOCC turns Claude into a persistent, context-aware operations partner — not just a chat assistant. Instead of re-explaining your situation every session, DOCC maintains a living picture of your projects, tasks, contacts, and open loops, and uses it to help you work faster.

This repository is a template. Fork it, run ./setup.sh, fill in the [PLACEHOLDERS], and you have your own ops console. It was extracted from a system used daily in a real operations role, with all personal and company data stripped out.

Core design goals

• Double the operator's productivity by automating administrative overhead
• Create documentation as a byproduct of work (not a separate activity)
• Nothing falls through the cracks — loop tracking, source citation, project state
• Evolve from real usage, not upfront design

Core concepts

Three buckets of work

Bucket	What It Is	Example
Route	Work that flows through you because of your context and relationships	Answering questions, connecting people, coordinating across teams
Execute	Work that requires your hands on it	Data analysis, procurement, configuration, process work
Think	Strategy, planning, capability building — highest leverage	Architecture decisions, team structure, process design

The goal: make Route and Execute efficient enough to free more time for Think.

The capture layer

Documentation happens as a byproduct of working through DOCC. Conversations build the knowledge base. Project work builds context files. Decisions produce source-cited records automatically.

Engines, skills, agents

• Engines — persistent systems for each type of work (Router, Executor, Coordinator, Strategist)
• Skills — shared capabilities any engine uses (data analysis, technical writing, research, drafting)
• Agents — engine + skills combined for a specific job (ops--scheduler, str--critic, …)

DOCC is the interface layer — it routes to the right engine based on what you need. See ops/_architecture.md.

Quick start

git clone <your-fork-url> docc
cd docc
./setup.sh                          # fills in name/role/boss/reports/email across the template
pip install -r requirements.txt     # optional — full YAML for /kb-lint (a fallback works without it)

Then finish the manual placeholders setup.sh lists (Google user ID, MCP servers, Notion DB ids if used), and:

cp -n .mcp.json.example .mcp.json  # if not already created by setup.sh; then edit it with your servers + creds (gitignored)
claude .
/gm                                # your first morning briefing

Find anything you missed: grep -rn '\[' CLAUDE.md ops .claude

File structure

docc/
├── CLAUDE.md                       # System instructions, read by Claude every session
├── README.md / help.md             # This file + a command cheat-sheet
├── setup.sh                        # Placeholder-fill + init script
├── .mcp.json.example               # MCP server config template (copy to .mcp.json)
├── .claude/
│   ├── rules/ops.md                # Always-active operational rules (tracking, citation, archive)
│   ├── commands/                   # 13 slash commands
│   ├── agents/                     # 8 subagents (ops--*, str--*)
│   ├── hooks/session-save.sh       # SessionEnd safety-net logger
│   └── settings.json               # Plugin/permission config
├── memory/
│   ├── MEMORY.md                   # Always-loaded behavioral rules (how to act)
│   └── feedback_*.md               # Universal starter rules; grow your own
└── ops/
    ├── _index.md                   # Master project registry
    ├── _tasks.md                   # Unified task list (tiered)
    ├── _awaiting.md                # Open loops / waiting on others
    ├── _contacts.md                # People catalog
    ├── _goals.yaml(.example)       # Your OKRs
    ├── _architecture.md            # System architecture
    ├── _changelog.md / _future-agents.md / _google-chat-spaces.md
    ├── _kb/                        # Scoped knowledge base
    │   ├── _index.md               # Manifest (auto-generated by /kb-lint)
    │   ├── _inbox.md               # Auto-save landing zone
    │   ├── _kb-lint.py             # Manifest regenerator + drift detector
    │   └── {scope}/                # procurement, devices, finance, partners, …
    ├── _templates/                 # project.context.md, dated-note.md
    ├── router-engine/_routing.md   # Domain-to-owner routing table
    ├── _archive/                   # Cold storage (closed loops/tasks + histories)
    ├── _extractors/                # Deterministic signal extraction (optional)
    ├── _evals/                     # Eval/test harness placeholder (optional)
    └── {project-name}/             # One folder per project
        ├── {project-name}.context.md
        └── {date}-{description}.md

Slash commands

Command	Purpose
/gm	Morning briefing — scan all channels, surface priorities, plan the day
/sitrep	Generate an upstream or downstream status report
/followup	Multi-channel scan + loop reconciliation (1d / 7d / 14d)
/council	Strategy Council — major decisions get multi-perspective analysis
/meetings	Process meeting transcripts into decisions and action items
/route	Route a question/request to the right person
/work	Execute green-light tasks autonomously; handle ad-hoc drafts
/queue	What's on my plate right now?
/inventory	Monitor device/asset inventory against thresholds (optional)
/archive	Inbox archive sweep
/kb-lint	Regenerate the KB manifest + detect drift
/weekly	Weekly review: reconcile loops, trim tasks, triage KB inbox, archive
/close	Session flush — persist all context before ending

Session persistence

1. Auto-save (continuous) — after substantive work, DOCC persists to the relevant files immediately
2. /close (comprehensive) — full session review that catches anything auto-save missed
3. SessionEnd hook (safety net) — logs which ops files were modified when the session ends

Guardrails

• Never send communications without explicit approval — draft, present, wait for "send it"
• Recipients shown = recipients sent — no silent reply-all
• Never fabricate — unknown = say so and name the source you'd need
• Never skip source citations — every claim traces to an email, chat, meeting, or document

Integrations

Configure in .mcp.json (copy from .mcp.json.example). DOCC works with any subset — it notes what's unavailable and proceeds.

Integration	Used For
Gmail / Calendar / Chat / Drive / Sheets (Google MCP)	Email, scheduling, chat, documents, data
Notion MCP	Meeting signals/transcripts, people, projects
Slack MCP (one per workspace)	Channel monitoring (read-only)
Perplexity / web (optional)	Research synthesis

Optional subsystems

Not required to start — turn them on when friction demands:

• ops/_extractors/ — bottle a recurring email shape into a deterministic extractor
• ops/_archive/ — route closed loops/tasks to cold storage to keep session-start reads small
• Deep-retrieval store (e.g. gbrain) — sync the archive to a vector/graph store so closed history stays searchable without loading it every session
• ops/_evals/ — eval/test harness for command outputs

Design principles

1. Iterate, don't over-engineer — build when real friction demands it
2. Documentation is a byproduct — working through DOCC produces the paper trail
3. Engines chain together — work flows across buckets
4. Skills are shared — capabilities belong to the system, not one engine
5. Adapt both ways — you adapt where the system helps; the system adapts where your judgment is the value-add
6. Auto-save, don't prompt — when Claude knows enough to ask, it knows enough to just do it

Evolving the system

New agents get built when a pattern repeats 3+ times and the manual effort is clearly admin, not thinking. DOCC auto-proposes a project context file when a topic recurs across _tasks.md, _awaiting.md, and conversation. See ops/_future-agents.md.

Contributing

Designed to be forked and adapted. The core framework (engines, agents, commands, file structure) is generic; your content (contacts, projects, goals, KB) is yours. PRs that improve the generic framework are welcome.

License

MIT