Immutable. This exact content is served forever at /api/v1/blob/080077ef2a2c31cb.
--- name: council description: Use at the start of any non-trivial task. Loads focused, task-relevant context by reading CLAUDE.md, scanning for related files, and producing a structured Session Context block. Invoked automatically by quest or standalone via /council. --- # Council — Context-Aware Task Onboarding ## Overview Loads focused, task-relevant context at the start of any non-trivial work session. Produces a structured Session Context block that serves as the foundation for all downstream work. This is the "onboarding the agent within every repo" pattern from context engineering. ## When to Use - Starting any task that involves more than a quick fix - Beginning a new session on existing in-progress work - Invoked automatically as Phase 0 of `/quest` ## Process ### Step 0: Check for Existing Checkpoint Before doing anything else, check if `.fellowship/checkpoint.md` exists (in repo root). (`.fellowship/` is the default data directory; users can override it via `dataDir` in `~/.claude/fellowship.json`.) If it does: 1. Read the checkpoint file 2. Present the checkpoint summary to the user 3. Ask: **"Found a checkpoint from [timestamp] on branch [branch]. Resume from where you left off, or start fresh?"** 4. If resuming: load the checkpoint as the Session Context. Skip Steps 1-4 and go directly to Step 5 (confirm with user). 5. If starting fresh: delete the checkpoint file and continue with Step 1. ### Step 1: Read Project Context Read the root CLAUDE.md. Extract: - Reference files relevant to the task area - Review conventions that apply - Architecture constraints If no CLAUDE.md exists, note: "Consider running `/chronicle` to set up project context." Also check for `~/.claude/fellowship.json` (the user's personal Claude directory). If it exists, read it and note any non-default settings. These will be included in the Session Context block under Architecture Notes so downstream skills (quest, lembas) are aware of the active configuration. ### Step 2: Understand the Task Ask one focused question: > "What are you working on? (One sentence describing the task and which area of the codebase it touches.)" If invoked by quest, the task description is passed in — skip the question. ### Step 3: Identify Package Scope Determine the scope of the task within the project: **Monorepo** (has `packages/`, `apps/`, or a workspace config like `pnpm-workspace.yaml`): 1. Match the task area to a package directory (e.g., `packages/<name>/`, `apps/<name>/`) 2. If ambiguous, check the monorepo structure (`ls` top-level directories) and ask the user 3. If the task spans multiple packages, list all affected packages 4. If a package-level CLAUDE.md exists (e.g., `packages/<name>/CLAUDE.md`), read it and merge its conventions with the root CLAUDE.md. Package-level conventions override root conventions where they conflict. **Single-package repo:** Skip this step — the scope is the whole project. Proceed to Step 4. This scope constrains all downstream scanning and verification. ### Step 4: Scan for Relevant Files Use the Explore agent (Agent tool with subagent_type=Explore, passing `model: "haiku"` — file scanning does not need the session model; use `models.explore` from fellowship config instead if set) to find files related to the task description. **In a monorepo, scope the search to the identified package(s)** — do not scan the entire repo. Focus on: - Files that will likely need modification - Files that define the patterns to follow (reference files) - Test files for the affected area - Config or type files that constrain the work Keep the scan targeted — 5-10 key files maximum, not an exhaustive listing. ### Step 5: Produce Session Context Block Output a structured block in this exact format: ``` ## Session Context **Task:** [one-line description] **Package(s):** [package name(s) and path(s)] **Key Files:** - [path/to/file:lines] — [why it's relevant] - [path/to/file:lines] — [why it's relevant] **Relevant Conventions:** - [convention from root CLAUDE.md that applies] - [convention from package CLAUDE.md that applies, if exists] **Architecture Notes:** - [constraints, patterns, or dependencies to be aware of] **Out of Scope:** - [things explicitly not to touch or change] - [other packages not affected by this task] ``` ### Step 6: Confirm with User Present the Session Context block and ask: > "Does this capture the right scope? Anything missing or out of bounds?" Revise based on feedback. ## Key Principles - **Targeted, not exhaustive.** 5-10 key files, not every file in the directory. - **Carry forward.** The Session Context block is referenced by lembas and quest throughout the session. - **Minimal questions, never stall.** One focused task question (Step 2) when the task wasn't already provided; Steps 0, 3, and 6 ask only when genuinely ambiguous. As a fellowship teammate there is no direct user — route blocking questions to the lead via SendMessage, and otherwise proceed with documented assumptions rather than waiting on confirmation.