--- name: setup-context-system description: "Guide a person through building a layered AI context system for their coding agent: global/project/initiative context files, index files, knowledge management with Rules and Hypotheses, decision logging, tone and behavior rules, optional discovery methodology, a maintenance command, and an optional offer to install obra's Superpowers. Use when someone wants to set up CLAUDE.md / AGENTS.md context from scratch, stop re-explaining context every session, or replicate a self-maintaining context setup." compatibility: "claude-code, opencode" --- # Set Up a Layered Context System You are guiding a person through building a **layered context system** for their AI coding agent. The goal is a self-maintaining setup where the agent always has the right context, tone, and methodology without the user re-explaining things every session. This system has proven components. You teach the **pattern** and the **reasoning** behind each layer, but the user fills in their **own** content. The output is *their* system, not a copy of anyone else's. ## Core Operating Rules (apply in every phase) 1. **One question at a time.** Prefer multiple-choice. Never batch questions. Wait for the answer before the next question. 2. **Phase gate.** Complete one phase, confirm it with the user, then STOP and ask before starting the next phase. Never run multiple phases in one pass. A user who stops after Phase 1 must have a working system. 3. **Diagnostic-first.** When a user can't answer a direct question (e.g., "what tone rules do you want?"), do NOT leave it blank. Ask indirect diagnostic questions and *derive* the answer, then propose it as concrete text for accept/modify/skip. 4. **Confirm before write.** Always show a preview of any file you are about to create or edit. Get explicit approval before writing. For bulk content (many files/sections), show 3-5 examples first and get approval before applying to all. 5. **Condense, don't dump.** When importing existing content (e.g., from Atlassian), summarize into small targeted files in the system's format. Never paste raw content verbatim. 6. **Lazy creation.** Create folders and files only when there is real content to put in them. No empty placeholders, no preemptive structure. 7. **Platform variables.** Use the variables set in Phase 0 (`CONTEXT_FILE`, `COMMANDS_DIR`, `HUB_PATH`) everywhere. Never hardcode `CLAUDE.md` or `AGENTS.md`. 8. **Verify, don't assume.** Never assume a platform's paths or behavior. Check the filesystem or ask the user. State the source of any path you rely on. --- ## Phase 0 — Detect & Orient No files are written in this phase. Establish the environment and resume point. ### Step 0.1 — Detect platform Inspect the filesystem to detect which agent platform is in use: - If `~/.claude/` exists → **Claude Code**. Set `CONTEXT_FILE = CLAUDE.md`, `COMMANDS_DIR = ~/.claude/skills/` (Claude Code merges custom commands into skills; a skill at `~/.claude/skills//SKILL.md` becomes `/`). - If `~/.config/opencode/` exists → **OpenCode**. Set `CONTEXT_FILE = AGENTS.md`, `COMMANDS_DIR = ~/.config/opencode/command/`. Skills live at `~/.config/opencode/skills//SKILL.md`. - If both or neither exist, ask the user: "Which agent are you setting this up for — Claude Code, OpenCode, or something else?" and set the variables accordingly. If "something else," ask the user for their global config path and the filename their agent reads for project instructions. Announce the detected platform and the file names you'll use, e.g.: > "Detected **Claude Code**. Global preferences go in `~/.claude/CLAUDE.md`, project context in `CLAUDE.md` files, commands/skills in `~/.claude/skills/`." ### Step 0.2 — Locate the context hub Ask: "Where do you want your **context hub** to live? This is the folder that holds your business/personal context, knowledge, and decisions." - Offer a sensible default (e.g., `~/Context` or `~/LLM Context`). - Set `HUB_PATH` to the chosen folder. ### Step 0.3 — Detect resume point Check which layers already exist on disk and report the user's current state: - Does the global preferences file exist and contain real rules? - Does `HUB_PATH/CONTEXT_FILE` exist? - Do index files exist (e.g., `profile.md`)? - Do `Knowledge/` or `Decisions/` folders exist anywhere under `HUB_PATH`? - Do maintenance commands exist in `COMMANDS_DIR`? Report: "You're at **Phase N**. Here's what exists, here's what's next." Then ask whether to start/continue there. ### Step 0.4 — Explain the model (briefly) Before building, give a 4-5 line explanation of the layered model so the user understands what they're building: > **The three layers:** > 1. **Global** (`CONTEXT_FILE` in your global config) — how the agent should behave on *every* project: tone, planning protocol, feedback style. > 2. **Project** (`CONTEXT_FILE` at a project root) — what *this* project is, where its context lives, how to navigate it. > 3. **Initiative** (`CONTEXT_FILE` inside a sub-folder) — context for one specific piece of work. > > **Plus:** index files (navigation to small context files), Knowledge files (learned rules), Decision logs, and a maintenance command that keeps it all current. Then proceed to Phase 1 only after the user confirms. --- ## Phase 1 — Essentials (the must-have working system) Goal: a functioning system after this phase alone. Produces the **global preferences file**, the **project hub context file**, and the **tone/behavior rules**. ### Step 1.0 — Propose universal default rules Start by offering a curated set of rules that work well for most people. Present them grouped, and ask the user to **accept / modify / skip each one** (don't force any). These are defaults, not mandates — the user's answers override them. Present this set (group as shown): **Communication** - No affirmative emphasis ("You're right", "Excellent idea", "Great point") — stay factual. - Keep responses concise; don't restate what the user already knows. - Use bullet points for feedback and summaries. - When showing diffs, include a summary of what changed and why. **Planning** - Discuss strategy and get approval before making changes. - A prior "go ahead" doesn't carry to a new design decision — each new decision needs its own approval. - Plan at the high level first, then drill into task detail. - When evaluating options, document the excluded ones with reasoning, not just the pick. **Feedback** - Give direct feedback and critiques — no hedging. - Challenge assumptions and claims rather than taking them at face value. **Grounding & verification** - Ground factual claims in sources or the user's explicit input; state when no source exists rather than filling the gap. - Never assume the capabilities or behavior of external platforms/tools — verify (docs, tooling, or ask) before relying on them. **Work style** - Clean up temp files and abandoned work when done. - Don't assign ownership, names, or responsibilities to items unless asked. After the user accepts/modifies/skips these, move to diagnostics for anything NOT already covered. ### Step 1.1 — Communication & tone gaps (diagnostic) For anything the default set didn't settle, ask diagnostics one at a time and derive rules. Skip questions already answered by Step 1.0. Examples: - "Paste a recent AI reply that annoyed you, or describe what bugs you about how AI assistants talk." → concision / anti-fluff specifics. - "Should the agent refer to you by name or use 'you'? Any pronoun conventions for context files?" → naming conventions (this is personal — derive, don't assume). - "Any formatting preferences beyond bullet points — tables, headers, code blocks?" → formatting default. Fold the answers into the **Communication Style** section. Accept/modify/skip each addition. ### Step 1.2 — Planning & feedback gaps (diagnostic) For anything not covered by Step 1.0, ask diagnostics, then derive: - "Should the agent ask clarifying questions one at a time, or batch them?" → question cadence. - "For bulk edits (many files/rows), should the agent show a few examples first and get approval before applying to all?" → bulk-edit rule. - "Should the agent ever state facts it isn't sure of, or always flag uncertainty / ask?" → grounding specifics (if not settled in 1.0). Fold into the **Planning Protocol** and **Feedback Style** sections. Accept/modify/skip. ### Step 1.3 — Work style gaps (diagnostic, light) Step 1.0 already proposed cleanup and no-unsolicited-ownership defaults. Ask only what's left: - "Do you work iteratively (structure first, then refine) or all-at-once?" - Any other working-style preference the defaults missed? Fold into the **Work Style** section. ### Step 1.4 — Write the global preferences file Assemble the approved sections into `CONTEXT_FILE` at the global config location. Structure: ```markdown # [Name]'s Global Agent Preferences These preferences apply to all projects and sessions. ## Communication Style [accepted defaults + derived bullets] ## Planning Protocol [accepted defaults + derived bullets] ## Feedback Style [accepted defaults + derived bullets] ## Work Style [accepted defaults + derived bullets] ## Core Context Hub [Name] maintains context files at `HUB_PATH`. Consult index files for navigation; load only what the task needs. ## Last Updated [YYYY-MM-DD] - Initial creation via setup-context-system ``` Show the full file as a preview. Write only after approval. ### Step 1.5 — Write the project hub context file Create `HUB_PATH/CONTEXT_FILE` explaining the context system itself: ```markdown # Context Hub - Agent Instructions This folder holds [Name]'s context files. Global behavior preferences live in the global config; this file covers the context system and file organization. ## Context System Index files point to small, targeted context files. Treat indexes as navigation, not content to load wholesale. ## How to Load Context 1. Identify the task domain. 2. Consult the relevant index file. 3. Load only the specific files needed. ## Lazy Creation Folders and files are created only when there is content to store. No preemptive structure. ## Last Updated [YYYY-MM-DD] - Initial creation ``` Preview, approve, write. **Phase gate: confirm Phase 1 is done, then ask before Phase 2.** --- ## Phase 2 — Index Files + Granular Context Goal: the navigation layer plus the first real context files. Only proceed when the user has actual content worth splitting out. ### Step 2.1 — Identify domains (diagnostic) Ask: "What topics do you find yourself re-explaining to an AI again and again?" One at a time, build a short list (e.g., a product, a company, a person, a recurring writing task). These become granular context files. If the user struggles, ask diagnostics: "What did you have to explain in your last 3 AI sessions that you'd already explained before?" ### Step 2.2 — Create an index file Create an index (e.g., `HUB_PATH/profile.md`) with a When-to-Load table: ```markdown # [Profile/Index Name] Index pointing to context files. Navigation only — load specific files as needed. | File | Purpose | When to Load | |------|---------|--------------| | `[file].md` | [purpose] | [trigger] | ## Last Updated [YYYY-MM-DD] - Initial creation ``` ### Step 2.3 — Create 2-3 starter context files For each domain the user has real content for, draft a small focused file. Show as preview, approve, write. Add a row to the index for each. Do NOT create files for domains the user can't fill yet — note them for later. **Phase gate: confirm, then ask before Phase 2.5 or Phase 3.** --- ## Phase 2.5 — Atlassian Import (OPTIONAL) Offer this only after Phase 2 (imported content needs a home). Skippable. ### Step 2.5.1 — Detect, and offer to set up the MCP Check whether Atlassian MCP tools are available in this session. - **Available** → proceed to Step 2.5.2. - **Not available** → offer to set it up: "Connecting an Atlassian (Confluence/Jira) integration lets me pull your existing docs straight into context files. Want to set it up now?" If the user wants to set it up, give the install method for the **detected platform** (verify the current method against the platform's MCP docs — methods change; do not hardcode from memory). The Atlassian remote MCP endpoint is `https://mcp.atlassian.com/v1/mcp`. - **OpenCode** — add to the user's `opencode.json` under `mcp`, then authenticate: ```json { "mcp": { "atlassian": { "type": "remote", "url": "https://mcp.atlassian.com/v1/mcp" } } } ``` Then run `opencode mcp auth atlassian` to complete the OAuth flow. (Source: https://opencode.ai/docs/mcp-servers) - **Claude Code** — run: ```bash claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp ``` Then run `/mcp` and follow the browser login to complete OAuth. (Source: https://docs.claude.com/en/docs/claude-code/mcp) - **Other platforms** — point the user to that platform's MCP-server docs; the endpoint is the same. Present the config/command and let the user run it — do not edit their MCP config or run auth silently. OAuth requires a browser step the user must complete. After setup, the Atlassian tools load on the next session (or after re-auth); if they aren't available in the current session yet, mark this step as deferred and tell the user to re-run Phase 2.5 once connected. If the user declines setup, mark as deferred and continue. ### Step 2.5.2 — Scope the pull Ask one at a time: - "Is there a Confluence space, set of pages, or Jira project worth importing as context?" - For Confluence: which space or page tree? - For Jira: which project, and what context do you want from it (epics, project conventions)? ### Step 2.5.3 — Map to structure (preview before fetching) Propose where imported content lands BEFORE fetching: - A team handbook space → several granular context files under `HUB_PATH` + index entries. - A project's docs → an initiative-level context file. Show the mapping. Get approval. ### Step 2.5.4 — Import as condensed drafts Fetch, then condense into the system's small-file format (not verbatim). For large spaces, show 3-5 condensed examples first and get approval before doing the rest. Preview each target file, approve, write. Update indexes. ### Step 2.5.5 — Seed knowledge Note any recurring patterns spotted during import (e.g., a documented pricing or naming convention). Offer them as starter Rules for Phase 3. **Phase gate: confirm, then ask before Phase 3.** --- ## Phase 3 — Knowledge & Decisions Goal: the learning layer. Only build when the user has patterns or decisions worth recording. ### Step 3.1 — Explain the Knowledge format Knowledge files capture learned patterns at three scopes (initiative → company/project → global). Format: ```markdown # [Domain Name] ## Rules ## Hypotheses ## Knowledge ``` Explain the mechanics: hypotheses get promoted to Rules after 3+ confirmations; Rules get demoted to Hypotheses when contradicted. The maintenance command (Phase 4) is what actually moves entries between these sections over time. ### Step 3.2 — Seed a first Knowledge file Ask: "What's one rule you already know is true in a domain you work in?" Capture it as a Rule in `Knowledge/[domain].md` at the right scope. Use any patterns seeded in Phase 2.5. Preview, approve, write (lazy creation — only if there's real content). ### Step 3.3 — Set up the Decision log Explain: decisions that affect more than one task get logged so they aren't re-litigated. Provide the template at `HUB_PATH/Shared/Templates/decision-template.md` (adjust the location to wherever the user keeps shared templates under their hub): ```markdown # Decision: {what was decided} ## Context {Why this came up} ## Alternatives Considered {What else was on the table, with brief pros/cons} ## Reasoning {Why this option won} ## Trade-offs Accepted {What was given up} ## Supersedes {Link to prior decision if replacing one, or "None"} ``` Explain the 3-level scoping (initiative → company/project → global) and the file-naming convention `Decisions/YYYY-MM-DD-{topic}.md`. Create the template file; create actual Decisions/ folders lazily. **Phase gate: confirm, then ask before Phase 4.** --- ## Phase 4 — Methodology & Maintenance Commands Goal: the self-maintaining loop and optional discovery methodology. ### Step 4.1 — Optional discovery methodology Ask: "Do you do product discovery or research work where a methodology would help (e.g., Teresa Torres' Continuous Discovery — outcomes over outputs, opportunity solution trees, regular interviews)?" - If yes → append a **Product Discovery Methodology** block to the global preferences file, scaled to how they work. - If no → skip. ### Step 4.2 — The maintenance command (the key loop) This is what keeps the system alive. Create a `/learnings`-style command in `COMMANDS_DIR` that, at the end of a session: 1. Reviews the conversation for new preferences, decisions, domain knowledge, corrections. 2. Compares against existing context files (reads them first to avoid duplicates). 3. Categorizes each learning (Preference / Decision / Workflow / Correction / Domain Knowledge / Rule / Hypothesis). 4. Proposes the exact target file and the exact text to add. 5. Walks through each proposed change ONE AT A TIME for accept/reject/modify. 6. Applies only approved changes; adds a "Last Updated" entry. 7. Handles Knowledge promotion/demotion: - Before proposing, check whether any existing Hypothesis was confirmed again this session. If it reaches 3+ confirmations, propose promoting it to a Rule (move it to `## Rules` with a note: "Promoted — confirmed in [dates/sessions]"). - Check whether any existing Rule was contradicted this session. If so, propose demoting it to a Hypothesis (move it to `## Hypotheses` with the contradiction noted). This closes the loop with Phase 3: the Knowledge format defines Rules vs Hypotheses; this command is what actually moves entries between them over time. Draft the command file, preview, approve, write. ### Step 4.3 — Optional initiative command Ask: "Do you run multi-step initiatives or projects that would benefit from a scaffolding command?" If yes, draft a `/create-initiative`-style command that interviews the user and creates an initiative folder with its own `CONTEXT_FILE`, overview file, and index entry. ### Step 4.4 — Optional: install Superpowers [Superpowers](https://github.com/obra/superpowers) (by obra) is a composable skills library that adds a development methodology — brainstorming → writing-plans → TDD → subagent-driven development — that triggers automatically. It complements this context system: this skill gives the agent *context*, Superpowers gives it *process*. First, **detect** whether it's already installed before offering: - OpenCode → check for `~/.config/opencode/skills/` entries from superpowers (e.g., a `brainstorming` skill) or a superpowers plugin in `~/.config/opencode/`. - Claude Code → check for a superpowers plugin/skills under `~/.claude/`. - If already present, say so and skip. If not installed, ask: "Want to install Superpowers? It adds an automatic spec → plan → TDD workflow." If yes, give the install method for the **detected platform** (verify against the current Superpowers README — methods change; do not hardcode from memory): - **Claude Code:** `/plugin install superpowers@claude-plugins-official` (official marketplace), or via `obra/superpowers-marketplace`. - **OpenCode:** tell the agent: "Fetch and follow instructions from `https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.opencode/INSTALL.md`". - **Other platforms** (Codex, Cursor, Copilot CLI, Gemini CLI): point the user to the install section of the Superpowers README, since each differs. Do not run the install silently — present the command/instruction and let the user run it. This skill only *offers and points*; it does not modify the user's plugin setup without consent. **Phase gate: confirm. System complete.** --- ## After Completion Summarize what was built and how to use it: 1. **Global preferences** at the global config — applies everywhere. 2. **Project hub** at `HUB_PATH` — explains the system; agent loads it when working there. 3. **Index files** — navigation to granular context. 4. **Knowledge / Decisions** — the learning layer; grows lazily. 5. **Maintenance command** — run it at the end of sessions to keep everything current. 6. **Superpowers** (if installed) — provides the development process layer alongside this context layer. Remind them: the system is meant to grow incrementally. Run the maintenance command regularly; add Knowledge and Decisions only when there's real content. Re-run this skill anytime to add a phase they skipped.