|
|
@@ -1,6 +1,6 @@
|
|
|
|
---
|
|
|
|
---
|
|
|
|
name: setup-context-system
|
|
|
|
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, and a maintenance command. 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."
|
|
|
|
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"
|
|
|
|
compatibility: "claude-code, opencode"
|
|
|
|
---
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
@@ -73,35 +73,64 @@ Then proceed to Phase 1 only after the user confirms.
|
|
|
|
|
|
|
|
|
|
|
|
Goal: a functioning system after this phase alone. Produces the **global preferences file**, the **project hub context file**, and the **tone/behavior rules**.
|
|
|
|
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.1 — Communication & tone rules (diagnostic)
|
|
|
|
### Step 1.0 — Propose universal default rules
|
|
|
|
|
|
|
|
|
|
|
|
Don't ask "what tone rules do you want?" Ask diagnostic questions one at a time and derive rules. Examples (ask, then derive):
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
- "Paste a recent AI reply that annoyed you, or describe what bugs you about how AI assistants talk." → derive concision / anti-fluff rules.
|
|
|
|
Present this set (group as shown):
|
|
|
|
- "When an AI opens with 'Great question!' or 'You're absolutely right!', is that helpful or noise?" → derive a no-affirmative-emphasis rule if noise.
|
|
|
|
|
|
|
|
- "Do you want the agent to refer to you by name or use 'you'? Any pronoun conventions for context files?" → derive naming conventions.
|
|
|
|
|
|
|
|
- "Bullet points or prose for summaries and feedback?" → derive formatting default.
|
|
|
|
|
|
|
|
- "Should the agent show diffs with a summary of changes, or just apply them?" → derive a diff/transparency rule.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
After 3-5 diagnostics, propose a **Communication Style** section as concrete bullet text. Accept/modify/skip each bullet.
|
|
|
|
**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.
|
|
|
|
|
|
|
|
|
|
|
|
### Step 1.2 — Planning & feedback protocol (diagnostic)
|
|
|
|
**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.
|
|
|
|
|
|
|
|
|
|
|
|
Ask diagnostics, then derive:
|
|
|
|
**Feedback**
|
|
|
|
- "When the agent takes on a task, should it plan and get your approval first, or just start?" → planning protocol.
|
|
|
|
- Give direct feedback and critiques — no hedging.
|
|
|
|
- "If you said 'go ahead' yesterday, does that approval carry to a new decision today?" → approval-carryover rule.
|
|
|
|
- Challenge assumptions and claims rather than taking them at face value.
|
|
|
|
- "Do you want direct critique or gentle suggestions?" → feedback style.
|
|
|
|
|
|
|
|
- "Should the agent challenge your assumptions or take them at face value?" → challenge rule.
|
|
|
|
|
|
|
|
- "Should the agent ever state facts it isn't sure of, or always flag uncertainty / ask?" → grounding rule.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Propose **Planning Protocol** and **Feedback Style** sections. Accept/modify/skip.
|
|
|
|
**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.
|
|
|
|
|
|
|
|
|
|
|
|
### Step 1.3 — Work style (diagnostic, light)
|
|
|
|
**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?"
|
|
|
|
- "Do you work iteratively (structure first, then refine) or all-at-once?"
|
|
|
|
- "Should the agent clean up temp files and abandoned work automatically?"
|
|
|
|
- Any other working-style preference the defaults missed?
|
|
|
|
|
|
|
|
|
|
|
|
Propose a short **Work Style** section.
|
|
|
|
Fold into the **Work Style** section.
|
|
|
|
|
|
|
|
|
|
|
|
### Step 1.4 — Write the global preferences file
|
|
|
|
### Step 1.4 — Write the global preferences file
|
|
|
|
|
|
|
|
|
|
|
@@ -113,16 +142,16 @@ Assemble the approved sections into `CONTEXT_FILE` at the global config location
|
|
|
|
These preferences apply to all projects and sessions.
|
|
|
|
These preferences apply to all projects and sessions.
|
|
|
|
|
|
|
|
|
|
|
|
## Communication Style
|
|
|
|
## Communication Style
|
|
|
|
[derived bullets]
|
|
|
|
[accepted defaults + derived bullets]
|
|
|
|
|
|
|
|
|
|
|
|
## Planning Protocol
|
|
|
|
## Planning Protocol
|
|
|
|
[derived bullets]
|
|
|
|
[accepted defaults + derived bullets]
|
|
|
|
|
|
|
|
|
|
|
|
## Feedback Style
|
|
|
|
## Feedback Style
|
|
|
|
[derived bullets]
|
|
|
|
[accepted defaults + derived bullets]
|
|
|
|
|
|
|
|
|
|
|
|
## Work Style
|
|
|
|
## Work Style
|
|
|
|
[derived bullets]
|
|
|
|
[accepted defaults + derived bullets]
|
|
|
|
|
|
|
|
|
|
|
|
## Core Context Hub
|
|
|
|
## Core Context Hub
|
|
|
|
[Name] maintains context files at `HUB_PATH`. Consult index files for navigation; load only what the task needs.
|
|
|
|
[Name] maintains context files at `HUB_PATH`. Consult index files for navigation; load only what the task needs.
|
|
|
@@ -200,11 +229,33 @@ For each domain the user has real content for, draft a small focused file. Show
|
|
|
|
|
|
|
|
|
|
|
|
Offer this only after Phase 2 (imported content needs a home). Skippable.
|
|
|
|
Offer this only after Phase 2 (imported content needs a home). Skippable.
|
|
|
|
|
|
|
|
|
|
|
|
### Step 2.5.1 — Detect
|
|
|
|
### Step 2.5.1 — Detect, and offer to set up the MCP
|
|
|
|
|
|
|
|
|
|
|
|
Check whether Atlassian MCP tools are available in this session.
|
|
|
|
Check whether Atlassian MCP tools are available in this session.
|
|
|
|
- **Not available** → explain: "Connecting an Atlassian (Confluence/Jira) integration lets me pull your existing docs straight into context files. You can connect it and re-run this step later." Mark as deferred; continue.
|
|
|
|
- **Available** → proceed to Step 2.5.2.
|
|
|
|
- **Available** → proceed.
|
|
|
|
- **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
|
|
|
|
### Step 2.5.2 — Scope the pull
|
|
|
|
|
|
|
|
|
|
|
@@ -319,6 +370,22 @@ Draft the command file, preview, approve, write.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.**
|
|
|
|
**Phase gate: confirm. System complete.**
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
---
|
|
|
@@ -331,5 +398,6 @@ Summarize what was built and how to use it:
|
|
|
|
3. **Index files** — navigation to granular context.
|
|
|
|
3. **Index files** — navigation to granular context.
|
|
|
|
4. **Knowledge / Decisions** — the learning layer; grows lazily.
|
|
|
|
4. **Knowledge / Decisions** — the learning layer; grows lazily.
|
|
|
|
5. **Maintenance command** — run it at the end of sessions to keep everything current.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|