Glossary

Key terms used in the Opus system.

Core Concepts

• Opus — The overall AI assistant system built around Claude Code. Contains two parts:
  • Vault — Knowledge side (vault/). An Obsidian vault that stores memory, plans, features, docs, and ideas. What Opus knows.
  • Src — Code side (src/). Python codebase for tools, automations, and cron tasks. What Opus can do.
• Atlas — The user’s separate personal Obsidian vault (“My Life Lab”) for non-technical content. Not part of Opus. See FR-025.
• Frontmatter — YAML metadata block at the top of every vault document (between --- markers). Contains at minimum a type: field. See Document Types.
• Knowledge — A long-lived reference document on a specific topic. Lives in vault/20_knowledge/ under a subcategory (ai, tech, personal).

Feature Request Lifecycle

• Lifecycle — The flow an FR follows: new → planned → in-progress → review → done. Each stage corresponds to a folder in vault/10_features/.
• Idea — A vague, unstructured future thought. Lives in vault/10_features/01_ideas/. No FR number, no template required.
• Feature Request (FR) — A concrete, structured request with phases, acceptance criteria, and history. Uses FR-XXX numbering. Moves through lifecycle stages:
  • New — Unprocessed, awaiting review. Lives in vault/10_features/02_new/.
  • Planned — Approved and designed, ready to be picked up.
  • In Progress — Currently being built.
  • Review — Opus considers work complete. Awaiting user verification.
  • Done — Completed and verified.
• Phase — A numbered implementation stage within an FR (Phase 1, Phase 2, etc.). Each phase has its own scope and acceptance criteria.
• Group — A category used in the feature request dashboard to organize FRs by domain (e.g., “Core Infrastructure”, “Automation”).
• Pending Decision (PD) — An open question within an FR that needs resolution before work can proceed. Uses PD-XXX numbering. Tracked in the decision dashboard.

Self-Improvement

• Proposal — A suggested improvement to the system (new skill, new agent, CLAUDE.md update). Written to vault/90_inbox/proposals/<type>/ where type is one of: skills, agents, hooks, features, code. Requires user approval before implementation.

Infrastructure (Claude Code)

• CLAUDE.md — The master instruction file read by every Claude Code session. Defines all conventions, rules, and behavior.
• Memory — Claude Code’s persistent auto-memory (~/.claude/projects/.../memory/MEMORY.md). Carries context across sessions.
• Skill — A reusable slash command. Defined in .claude/skills/<name>/SKILL.md.
• Agent — A specialized sub-process launched via the Task tool for focused, parallel work. Defined in .claude/agents/.
• Hook — A shell command that runs automatically in response to Claude Code events (e.g., before a tool runs, after a session ends). Configured in .claude/settings.json.
• Rule — A context-specific instruction file loaded based on file path. Lives in .claude/rules/.
• MCP Server — An external tool integration configured in .mcp.json.

Workflow

• Dashboard — A vault file that tracks and summarizes system state. Lives in vault/00_system/dashboards/.
• Log — A historical record of events or decisions. Lives in vault/00_system/logs/.
• Inbox — Quick capture area. Lives in vault/90_inbox/. Contains: proposals/ (Claude-initiated, typed subfolders), drafts/ (Claude-processed user messages awaiting review), and quick-notes.md (direct user captures).
• Scratchpad — Informal personal document without structure or lifecycle (e.g., my-todos.md, inbox notes).
• Doc — System documentation (architecture, glossary, guides). Lives in vault/00_system/docs/.
• Extern — Reference document from outside the system. Lives in vault/00_system/external/.
• Template — A reusable document skeleton for FRs, proposals, etc. Lives in vault/_templates/.

Daily Operations

• Briefing — Daily summary covering open tasks, recent changes, and pending decisions. Lives in vault/30_daily/briefings/.
• Changelog — Daily record of changes made to the system. Lives in vault/30_daily/changes/.

Document Types

All vault documents have a type: in their YAML frontmatter. Complete list:

Type	Description	Defined in
briefing	Daily summary document	Daily Operations
changelog	Record of session/daily changes	Daily Operations
dashboard	Tracks and summarizes system state	Workflow
doc	System documentation (architecture, glossary, guides)	Workflow
extern	Reference document from outside the system	Workflow
feature-request	Structured FR with phases and criteria	Feature Request Lifecycle
idea	Vague future thought, no FR number	Feature Request Lifecycle
knowledge	Long-lived reference document	Core Concepts
log	Historical record of events/decisions	Workflow
proposal	Suggested system improvement	Self-Improvement
scratchpad	Informal personal document without lifecycle	Workflow
template	Reusable document skeleton	Workflow