Add sandboxed claude to the devcontainer

.claude/commands/grill-me.md

@@ -0,0 +1,9 @@
+---
+description: Interview me relentlessly to stress-test a plan or design.
+---
+
+Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time.
+
+If a question can be answered by exploring the codebase, explore the codebase instead.

.claude/commands/memo.md

@@ -0,0 +1,43 @@
+---
+description: Save current task state to auto-memory, then promote reusable lessons to skills and trim memory.
+---
+
+# Memo
+
+Save a snapshot of current work to persistent memory, then clean up.
+
+## Step 1 — Save current state
+
+Write a concise summary of in-progress or recently completed work to the
+auto-memory `MEMORY.md` for this project. Include:
+
+- What was done (feature, bug, refactor, area of code)
+- Current status (completed, blocked, in-progress)
+- Key decisions or outcomes worth remembering across conversations
+
+Do not duplicate information already in skills, CLAUDE.md, or README-CLAUDE.md.
+
+## Step 2 — Promote to skills
+
+Review the memory file for items that represent **reusable patterns or
+lessons** — things that would help future sessions on this project. For
+each such item:
+
+1. Identify which skill file it belongs in (or create a new one under
+   `.claude/skills/<name>/SKILL.md`).
+2. Add it to the appropriate skill.
+3. Remove it from memory (it now lives in the skill).
+
+Examples of promotable items:
+- A non-obvious convention specific to this project
+- A "foot-gun" pattern worth warning future-you about
+- A reusable recipe (test invocation, deploy command, debugging trick)
+
+## Step 3 — Trim memory
+
+Remove from memory anything that is:
+- Already captured in skills, CLAUDE.md, or README-CLAUDE.md
+- Too specific to a single completed task to be useful again
+- Stale or superseded by later work
+
+Keep memory concise — ideally under 30 lines.

.claude/commands/to-issues.md

@@ -0,0 +1,96 @@
+---
+description: Break a plan/PRD into independently-grabbable issues using tracer-bullet vertical slices.
+argument-hint: "[issue ref or path, optional]"
+---
+
+# To Issues
+
+Break a plan into independently-grabbable issues using vertical slices (tracer bullets).
+
+The issue tracker and triage label vocabulary should have been provided to you — run `/setup-matt-pocock-skills` if not.
+
+## Process
+
+### 1. Gather context
+
+Work from whatever is already in the conversation context. If the user passes an issue reference (issue number, URL, or path) as an argument, fetch it from the issue tracker and read its full body and comments.
+
+### 2. Explore the codebase (optional)
+
+If you have not already explored the codebase, do so to understand the current state of the code. Issue titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.
+
+### 3. Draft vertical slices
+
+Break the plan into **tracer bullet** issues. Each issue is a thin vertical slice that cuts through ALL integration layers end-to-end, NOT a horizontal slice of one layer.
+
+Slices may be 'HITL' or 'AFK'. HITL slices require human interaction, such as an architectural decision or a design review. AFK slices can be implemented and merged without human interaction. Prefer AFK over HITL where possible.
+
+<vertical-slice-rules>
+- Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI, tests)
+- A completed slice is demoable or verifiable on its own
+- Prefer many thin slices over few thick ones
+</vertical-slice-rules>
+
+### 4. Quiz the user
+
+Present the proposed breakdown as a numbered list. For each slice, show:
+
+- **Title**: short descriptive name
+- **Type**: HITL / AFK
+- **Blocked by**: which other slices (if any) must complete first
+- **User stories covered**: which user stories this addresses (if the source material has them)
+
+Ask the user:
+
+- Does the granularity feel right? (too coarse / too fine)
+- Are the dependency relationships correct?
+- Should any slices be merged or split further?
+- Are the correct slices marked as HITL and AFK?
+
+Iterate until the user approves the breakdown.
+
+### 5. Publish the issues to the issue tracker
+
+For each approved slice, publish a new issue to the issue tracker. Use the issue body template below. Apply the `needs-triage` triage label so each issue enters the normal triage flow.
+
+Publish issues in dependency order (blockers first) so you can reference real issue identifiers in the "Blocked by" field.
+
+### 6. Tell the user how to consume them
+
+Each slice is meant to be picked up in **its own context**. Do not implement multiple slices in a single Claude session — context bloat undermines reviewability, blurs the per-slice commit discipline, and means a single mistake mid-stream contaminates everything that follows.
+
+After publishing, tell the user explicitly:
+
+> Each slice should be implemented in its own context. Either:
+>
+> - Run `/clear` between slices and pick them up one at a time in fresh sessions, OR
+> - Spawn one subagent per non-blocked slice and let them work in parallel (each subagent gets its own context).
+>
+> Don't pick up the next slice in the same session you finished the last one in.
+
+If the agent that ran `/to-issues` is the same agent that would naturally pick up slice #1: stop after publishing. Hand back to the user. Let them start a fresh session.
+
+<issue-template>
+## Parent
+
+A reference to the parent issue on the issue tracker (if the source was an existing issue, otherwise omit this section).
+
+## What to build
+
+A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation.
+
+## Acceptance criteria
+
+- [ ] Criterion 1
+- [ ] Criterion 2
+- [ ] Criterion 3
+
+## Blocked by
+
+- A reference to the blocking ticket (if any)
+
+Or "None - can start immediately" if no blockers.
+
+</issue-template>
+
+Do NOT close or modify any parent issue.

.claude/commands/to-prd.md

@@ -0,0 +1,73 @@
+---
+description: Turn the current conversation context into a PRD and publish it to the issue tracker.
+---
+
+Take the current conversation context and codebase understanding and produce a PRD. Do NOT interview the user — just synthesize what you already know.
+
+The issue tracker and triage label vocabulary should have been provided to you — run `/setup-matt-pocock-skills` if not.
+
+## Process
+
+1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the PRD, and respect any ADRs in the area you're touching.
+
+2. Sketch out the major modules you will need to build or modify to complete the implementation. Actively look for opportunities to extract deep modules that can be tested in isolation.
+
+A deep module (as opposed to a shallow module) is one which encapsulates a lot of functionality in a simple, testable interface which rarely changes.
+
+Check with the user that these modules match their expectations. Check with the user which modules they want tests written for.
+
+3. Write the PRD using the template below, then publish it to the project issue tracker. Apply the `needs-triage` triage label so it enters the normal triage flow.
+
+<prd-template>
+
+## Problem Statement
+
+The problem that the user is facing, from the user's perspective.
+
+## Solution
+
+The solution to the problem, from the user's perspective.
+
+## User Stories
+
+A LONG, numbered list of user stories. Each user story should be in the format of:
+
+1. As an <actor>, I want a <feature>, so that <benefit>
+
+<user-story-example>
+1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
+</user-story-example>
+
+This list of user stories should be extremely extensive and cover all aspects of the feature.
+
+## Implementation Decisions
+
+A list of implementation decisions that were made. This can include:
+
+- The modules that will be built/modified
+- The interfaces of those modules that will be modified
+- Technical clarifications from the developer
+- Architectural decisions
+- Schema changes
+- API contracts
+- Specific interactions
+
+Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
+
+## Testing Decisions
+
+A list of testing decisions that were made. Include:
+
+- A description of what makes a good test (only test external behavior, not implementation details)
+- Which modules will be tested
+- Prior art for the tests (i.e. similar types of tests in the codebase)
+
+## Out of Scope
+
+A description of the things that are out of scope for this PRD.
+
+## Further Notes
+
+Any further notes about the feature.
+
+</prd-template>

.claude/commands/toolbox-update.md

@@ -0,0 +1,43 @@
+---
+description: Rescan BOTH ~/.claude and the current workspace .claude and refresh the hardcoded list inside /toolbox.
+---
+
+Refresh the hardcoded listing inside `~/.claude/commands/toolbox.md` (and the workspace `./.claude/commands/toolbox.md` if present) so it matches the current state of disk. claude-sandbox's adapted `toolbox` enumerates BOTH locations — Claude actually loads from both, so the listing must reflect both.
+
+## Steps
+
+1. Enumerate user-global commands: every `*.md` file in `~/.claude/commands/`. The command name is the filename minus `.md`.
+
+2. Enumerate user-global skills: every `SKILL.md` under `~/.claude/skills/**/`. Take `name` from frontmatter.
+
+3. Enumerate workspace commands: every `*.md` file in `./.claude/commands/` (relative to the current working directory).
+
+4. Enumerate workspace skills: every `SKILL.md` under `./.claude/skills/**/`.
+
+5. For each file, extract the frontmatter `description` field. Trim to the first sentence (stop at the first `.` followed by space or end of string). If a description spans multiple sentences with extra detail, keep only the first.
+
+6. Build the new listing block in this exact format, sorted alphabetically within each section:
+
+   ```
+   **User-global commands (`~/.claude/commands/`)**
+   - `/<name>` — <description>
+   ...
+
+   **User-global skills (`~/.claude/skills/`)**
+   - `/<name>` — <description>
+   ...
+
+   **Workspace commands (`./.claude/commands/`)**
+   - `/<name>` — <description>
+   ...
+
+   **Workspace skills (`./.claude/skills/`)**
+   - `/<name>` — <description>
+   ...
+   ```
+
+   Show skill names with a leading `/` so they render with the same highlighting as commands, even though skills aren't slash-invocable. If a section is empty, write `- (none)`.
+
+7. Edit `~/.claude/commands/toolbox.md`. Replace everything **after** the line `Output exactly the following text verbatim, with no preamble, commentary, or trailing summary:` (and the blank line that follows) with the freshly-built listing. Preserve the frontmatter and the instruction line above it. If `./.claude/commands/toolbox.md` exists, do the same to it.
+
+8. Print a single line confirmation: `Updated toolbox.md — <N_user_commands>+<N_workspace_commands> commands, <M_user_skills>+<M_workspace_skills> skills.`

.claude/commands/toolbox.md

@@ -0,0 +1,27 @@
+---
+description: List the commands and skills available from BOTH the user-global ~/.claude/ toolkit AND the current workspace's .claude/ overrides (fast, hardcoded — refresh with /toolbox-update).
+---
+
+Output exactly the following text verbatim, with no preamble, commentary, or trailing summary. The two sections below correspond to the two directories Claude actually has access to: the user-global `~/.claude/` toolkit and the current workspace's `.claude/` overrides. If a name appears in both, the workspace copy wins for the running Claude (it's loaded later); both are listed here so you can see what's available at each scope.
+
+**User-global commands (`~/.claude/commands/`)**
+- `/grill-me` — Interview me relentlessly to stress-test a plan or design.
+- `/to-issues` — Break a plan/PRD into independently-grabbable issues using tracer-bullet vertical slices.
+- `/to-prd` — Turn the current conversation context into a PRD and publish it to the issue tracker.
+- `/toolbox` — List the user-scoped commands and skills in ~/.claude.
+- `/toolbox-update` — Rescan ~/.claude and the workspace .claude and refresh the hardcoded list inside /toolbox.
+- `/write-a-skill` — Create a new agent skill with proper structure and progressive disclosure.
+- `/zoom-out` — Zoom out and give a higher-level map of the surrounding code.
+
+**User-global skills (`~/.claude/skills/`)**
+- `/diagnose` — Disciplined diagnosis loop for hard bugs and performance regressions.
+- `/grill-with-docs` — Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation inline as decisions crystallise.
+- `/improve-codebase-architecture` — Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/.
+- `/tdd` — Test-driven development with red-green-refactor loop.
+- `/triage` — Triage issues through a state machine driven by triage roles.
+
+**Workspace commands (`./.claude/commands/`)**
+- `/verify-sandbox` — Run the 17-check sandbox PASS/FAIL battery against the live process.
+
+**Workspace skills (`./.claude/skills/`)**
+- (none unless installed via `claude-sandbox install-skill`)