Files

T

sampson 9ea53542df setup-context-system: prebake universal default rules in Phase 1

2026-06-23 21:27:07 +02:00

21 KiB

Raw Blame History

name, description, compatibility

name	description	compatibility
setup-context-system	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.	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)

One question at a time. Prefer multiple-choice. Never batch questions. Wait for the answer before the next question.
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.
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.
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.
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.
Lazy creation. Create folders and files only when there is real content to put in them. No empty placeholders, no preemptive structure.
Platform variables. Use the variables set in Phase 0 (CONTEXT_FILE, COMMANDS_DIR, HUB_PATH) everywhere. Never hardcode CLAUDE.md or AGENTS.md.
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/<name>/SKILL.md becomes /<name>).
If ~/.config/opencode/ exists → OpenCode. Set CONTEXT_FILE = AGENTS.md, COMMANDS_DIR = ~/.config/opencode/command/. Skills live at ~/.config/opencode/skills/<name>/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:

Global (CONTEXT_FILE in your global config) — how the agent should behave on every project: tone, planning protocol, feedback style.

Project (CONTEXT_FILE at a project root) — what this project is, where its context lives, how to navigate it.

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:

# [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:

# 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:

# [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:
```
{
  "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:
```
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:

# [Domain Name]

## Rules
<!-- Confirmed patterns — apply by default -->

## Hypotheses
<!-- Need more data — test when opportunity arises. Promote to Rules at 3+ confirmations. -->

## Knowledge
<!-- Facts and patterns observed -->

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):

# 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:

Reviews the conversation for new preferences, decisions, domain knowledge, corrections.
Compares against existing context files (reads them first to avoid duplicates).
Categorizes each learning (Preference / Decision / Workflow / Correction / Domain Knowledge / Rule / Hypothesis).
Proposes the exact target file and the exact text to add.
Walks through each proposed change ONE AT A TIME for accept/reject/modify.
Applies only approved changes; adds a "Last Updated" entry.
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 (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:

Global preferences at the global config — applies everywhere.
Project hub at HUB_PATH — explains the system; agent loads it when working there.
Index files — navigation to granular context.
Knowledge / Decisions — the learning layer; grows lazily.
Maintenance command — run it at the end of sessions to keep everything current.
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.

21 KiB Raw Blame History