Start

You are starting a new session on this project. Your memory has reset; the memory bank is your only continuity. Use this workflow to orient the session around the Serel Memory bank.

Arguments the user gave with the call (Claude Code substitutes them here: [$ARGUMENTS]; in Codex they are in the user's message after the skill name).

Mode: Check those arguments for a mode keyword.

• If empty, quick, or brief → use Quick mode (compact output; both modes read the same inputs).
• If full, onboard, or dashboard → use Full mode (rich onboarding dashboard).
• If setup → use Setup mode (guided setup routing, docs/serel-setup.md).

Also check the arguments for --scope <path> (scoped banks only — see "Resolving scope" in docs/workflow-contract.md). --scope . is the root; a path equal to a project root selects that project's bank; anything else: stop and list the valid selectors (hooks/lib/resolve-scope.sh --list). Without it, resolve by the current directory, then the root. Never read more than one bank in a pass.

Local install at a project scope. After resolving the scope, and only when it is not the root, check from the repository root whether Serel Memory is installed locally (the test in "Setup routing" in docs/workflow-contract.md):

top="$(git rev-parse --show-toplevel)"
if [ -n "$(git -C "$top" ls-files --others --ignored --exclude-standard -- bin/serel-memory docs/workflow-contract.md hooks/lib/resolve-scope.sh)" ] ||
  git -C "$top" check-ignore -q .serel-memory.json; then echo "LOCAL INSTALL"; fi

A local install holds the root bank only: it excludes the root memory-bank/ and .rules, and scopes listed later do not extend that, so a bank seeded at this scope would be visible to Git. If it prints LOCAL INSTALL and this run would use Setup mode or offer to fill blank files (Step 1), do neither: stop before any plan or write. Say why in one or two sentences, write nothing, leave any existing files at this scope, the exclusions, .gitignore and instruction files as they are, and offer the supported choices: the root bank (start --scope .) or a shared, committed install, where scoped banks work. Never un-ignore, untrack or force-add anything.

Step 1 — Read the memory bank (both modes)

Effective bank: if memory-bank.local/ exists (upstream Serel Memory development only), it is the working bank — read its files and its .rules instead of the tracked ones, skip files it doesn't contain (intent lives in README.md/docs/), and don't report the blank tracked templates as uninitialized. See "Resolving the effective bank" in docs/workflow-contract.md.

Scope: resolve which bank this targets per "Resolving scope" in docs/workflow-contract.md — an optional --scope <path> argument selects a project bank when the repo configures scopes; otherwise the root bank, as always.

Do these in order, before anything else:

1. Read every file in memory-bank/ in this order:
   • projectbrief.md
   • productContext.md
   • systemPatterns.md
   • techContext.md
   • decisionLog.md
   • activeContext.md
   • progress.md
2. Read .rules.
3. Look for optional docs under memory-bank/ that clearly match the user's task or active context, and read only the relevant ones. Never read memory-bank/archive/ at startup.
4. Run git log --oneline -10 to see recent activity.
5. Run git status to see uncommitted changes.

6. If bin/serel-memory exists, run the read-only drift check on the resolved scope and keep its summary line for the audit:

   "$(git rev-parse --show-toplevel)/bin/serel-memory" check --scope <resolved scope>

   Report its findings and summary line as they are — it never blocks the session. If the file is absent, say checker absent.

If any memory bank file is empty, missing, or still only template placeholders, surface it as BLANK or UNINITIALIZED. If the mode is setup, or the effective bank is missing or no core file has real content, use Setup mode instead of Step 2 (at a project scope of a local install, stop as described above instead). Otherwise, when some files are blank (a partial bank), continue with Step 2 and offer to fill them: on yes, choose the seed workflow as Setup mode does; it proposes only the blank files and keeps the others exactly as they are.

Step 2 — Produce the output

Quick mode (default)

Produce a context audit and session summary in this exact format:

CONTEXT AUDIT:
- Read: [memory-bank files and .rules]
- Optional docs read: [paths or "(none)"]
- Scope: [only when the repo configures `scopes`: `.` or the selected project root]
- Uninitialized: [missing, empty, or template-only files]
- Recent commits not reflected in memory: [yes/no/unknown]
- Working tree: [clean / dirty summary]
- Drift: [the drift checker's summary line, or "checker absent"]

PROJECT: [one sentence — what we're building]
PHASE: [from progress.md]
LAST SESSION: [from activeContext.md — what was being worked on]
CURRENT STATE: [what works / what's in progress / known issues — 2 lines max]
NEXT STEPS: [from activeContext.md — top 1–3]
OPEN QUESTIONS: [anything blocking or unresolved]

If the repo configures scopes and the scope resolved to the root, add an Active scopes list before the closing question — one line per project root from hooks/lib/resolve-scope.sh --list, as --scope <path> [initialized|uninitialized]. Read nothing from those banks. Then end with: "Which scope, or stay at the root?" Otherwise end with: "Where do you want to pick up?" Then wait.

Full mode (start full)

Produce the full context audit (same as quick mode), then continue with all of the sections below.

Recent Progress (last 2–3 sessions)

Extract from progress.md recent milestones and activeContext.md recent changes:

• Session achievements with dates
• Key technical discoveries or architectural changes
• Milestones reached

Current State Analysis

What Works

• Pull from progress.md "What works" section — list each capability

In Progress

• Pull from progress.md "In progress" section
• Cross-reference with activeContext.md current focus

Known Issues

• Pull from progress.md "Known issues" section

What's Left to Build

• Pull from progress.md "What's left to build" section
• Include estimates where you can reasonably infer them

Open Decisions & Blockers

• Pull from activeContext.md open questions
• Pull from decisionLog.md any pending/draft decisions
• Flag any memory bank staleness (commits not reflected, files out of date)

Git Status

• Uncommitted changes that should be addressed
• Commits ahead/behind of remote
• Current branch info

Suggested Next Steps

Provide 3–5 specific, actionable recommendations organized by urgency:

🔴 URGENT — blocking progress or stale/broken 🟡 HIGH-VALUE — best use of this session based on momentum and impact 🟢 STRATEGIC — important but can wait

For each, include: clear action item, rough time estimate, expected outcome.

Direction Options

Present 3–4 options clearly:

• Option A: Continue recent momentum — [describe based on activeContext]
• Option B: Address top priority — [from what's left to build]
• Option C: Start next feature/initiative — [from what's left or open questions]
• Option D: Something else

End with: "Which direction would you like to take for this session?" Then wait.

Setup mode (start setup, or a missing or blank bank)

Follow docs/serel-setup.md "The flow" for the resolved scope, and stay read-only until the user approves. Serel Memory is already installed here, so installation is skipped; choosing capabilities is not. An initialized bank is kept exactly as it is.

1. Orient in the resolved scope: product code (Serel Memory's own files and code in another scope do not count), a PRD or spec, instruction files, how Serel Memory is installed (a tracked .serel-memory.json is shared; the local-install test above printing LOCAL INSTALL means local), the bank's state, Serel Kit (.serel-kit.json), and the workflows each CLI discovers (including .claude/commands/, .claude/skills/ and .agents/skills/ when present) by purpose, whatever their names: those already installed, and those a chosen Kit pack would add (docs/serel-setup.md "Overlapping workflows").
2. Ask only what you could not detect and the user has not already said: one short question per message, waiting for each answer, at most four in total.
3. Produce:

SETUP PLAN:
- Scope: [`.` or the selected project root]
- Bank: [missing / blank / partial / initialized]
- Install: [shared, committed / local, Git-excluded]
- Stage: [idea / spec, no code / code / code + spec] (evidence: [paths])
- Capabilities: [Serel Memory / Serel Memory + Kit packs <names> / Kit packs only]
- Requires: [none / verify: an initialized bank, so seed first]
- Instructions: [AGENTS.md and any Claude instruction files found]
- Overlaps: [none found / existing path ↔ other or incoming path: rules to preserve; primary: <entry>; kept both, recorded in <doc> / migrate, diffs shown / paused]
NEXT: [discover | from-prd <path> | init-memory | init-memory naming the spec] [--scope <path> when not the root] / add Kit packs <names> / resume

End with "Continue with <next>?" Then wait, unless the user has already told you to go ahead with this plan. A seed workflow runs in this session by following its own file, carrying the answers you already have. In Claude Code that is .claude/skills/<workflow>/SKILL.md when it exists, otherwise the retained .claude/commands/<workflow>.md, keeping its customizations and approval gates; in Codex it is .agents/skills/<workflow>/SKILL.md. Its proposals and approval come before any bank write, and in a partial bank it fills only the blank files. For code plus a spec, the code describes what exists and the spec stays planned intent. Kit packs come from Serel Kit's own installer, previewed before anything is written (docs/serel-setup.md "Serel Kit"); packs keep Kit's own requirements even when chosen alone: writing leaves the bank as it is; verify needs an initialized bank, so beside a missing, blank or partial one Requires and NEXT name the seed workflow, which keeps its own approval. An initialized bank is never re-seeded: when no Kit packs are wanted and no overlap choice or migration remains, end with "Where do you want to pick up?" instead.

Overlaps covers workflows already installed here, such as a custom session opener beside start, even when nothing new would be added. A resembling name, the Claude/Codex pair of one workflow, or a specialized workflow with a different job is not a finding, and a coexistence recorded in the project's docs is respected while it still applies. Settle a finding within the questions above and this plan's approval, never per file; an unresolved one pauses its whole capability (a Kit pack is not installed in part). Retiring or merging a workflow is a separate migration shown as diffs and approved explicitly; setup alone deletes and disables nothing. If an overlap remains unresolved, NEXT names the choice or migration review needed; it must not name installation of that capability.

Do not start working on anything until the user answers.