diff --git a/dot_claude/commands/bd-drain.md b/dot_claude/commands/bd-drain.md deleted file mode 100644 index 0ce7fb0..0000000 --- a/dot_claude/commands/bd-drain.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -description: Recursively implement all pending beads issues until every one is closed with tests passing, builds succeeding, requirements met, and blockers cleared -argument-hint: [optional: priority filter e.g. "p0-p2" | epic id | "dry-run"] -allowed-tools: Bash(bd:*), Bash(git:*), Bash(go:*), Bash(pnpm:*), Bash(cargo:*), Bash(make:*), Read, Write, Edit, Glob, Grep, Task ---- - -# /bd-drain — Recursive Beads Completion Workflow - -Drain the beads backlog to zero. Work every ready issue to full completion, unblock dependent issues as they clear, and repeat until no open, actionable work remains. Arguments: `$ARGUMENTS` (optional priority filter like `p0-p2`, an epic ID to scope to, or `dry-run` to plan without executing). - -## Phase 0 — Session Bootstrap - -1. Run `bd dolt pull` to sync beads state from remote. -2. Run `bd prime` if context was compacted or this is a fresh session. -3. Run `bd doctor` — if sync problems or missing hooks are reported, fix them before proceeding. -4. Run `bd stats` and record the baseline: open / in_progress / blocked counts. This is the burn-down target. -5. Run `bd memories drain` and `bd memories ` to load any prior insights about this workflow or codebase gotchas. -6. Detect the project's verification commands by inspecting the repo (Makefile, Taskfile, turbo.json, package.json scripts, go.mod, Cargo.toml). Record: - - **TEST_CMD** (e.g. `go test ./...`, `pnpm turbo test`, `cargo test`) - - **BUILD_CMD** (e.g. `go build ./...`, `pnpm turbo build`) - - **LINT_CMD** if present (e.g. `golangci-lint run`, `pnpm lint`) -7. Run TEST_CMD and BUILD_CMD once **before touching anything** to establish a green baseline. If the baseline is already red, create a P0 bug with `bd create` describing the pre-existing failure and fix it first — never build on a broken base. - -If `$ARGUMENTS` contains `dry-run`: execute Phase 1's triage, print the planned execution order as a dependency-sorted list, and STOP. - -## Phase 1 — Triage & Ordering - -1. Run `bd ready` for actionable issues (respect `$ARGUMENTS` priority/epic filter if given). -2. Run `bd blocked` and `bd show ` on each blocked issue to map the dependency graph. -3. Run `bd orphans` — repair or flag any broken dependencies (`bd dep add` / `bd human `). -4. Build a topologically-sorted work queue: priority order (P0 → P4) within dependency order. Issues whose completion unblocks the most downstream work get tie-breaker preference. -5. Run `bd lint` on the queue. For issues with missing/vague requirements, attempt to infer acceptance criteria from the description and codebase, update via `bd update --acceptance="..."`. If requirements are genuinely undecidable, run `bd human ` with a specific question and skip it (do not guess on ambiguous product decisions). - -## Phase 2 — The Drain Loop - -Repeat until the exit condition in Phase 3 is met. For **each** issue in the queue: - -### 2a. Claim -```bash -bd show # re-read full details, dependencies, acceptance criteria -bd update --claim # mark in_progress -``` - -### 2b. Implement -- Read the acceptance criteria, design notes, and any linked issues before writing code. -- Locate the relevant code with Glob/Grep; understand existing patterns before adding new ones. -- Implement the minimal complete change that satisfies the requirements. Follow existing repo conventions. -- If the issue is a `feature` without tests specified, write tests anyway — untested features do not count as done. -- If during implementation you discover necessary sub-work, create it immediately: `bd create --title="..." --description="..." --type=task --priority=` then `bd dep add ` as appropriate. Never leave discovered work untracked. - -### 2c. Verify (hard gates — ALL must pass) -```bash - # full test suite, not just new tests - # full build - # if present -``` -- ✅ All tests pass (including pre-existing ones — no regressions) -- ✅ Build succeeds cleanly -- ✅ Every acceptance criterion on the issue is demonstrably met -- ✅ No new warnings/lint errors introduced - -On failure: fix and re-verify. After **3 failed fix attempts** on the same root cause, stop thrashing — record findings with `bd update --notes=""`, run `bd human ` if it needs a decision, revert the working tree to the last green state, and move to the next issue. - -### 2d. Close & Checkpoint -```bash -bd close --reason="" --suggest-next -bd remember "" -git add -git commit -m "(): (closes )" -``` -- Commit per issue, not in batches — each commit should be independently green. -- `--suggest-next` output feeds Phase 2e. - -### 2e. Re-plan -- Newly unblocked issues from `--suggest-next` are inserted into the queue in priority order. -- Every **5 closed issues**, re-run `bd ready` and `bd blocked` to catch drift (issues added by hooks, remote changes), and re-run the full test suite even if the last issue didn't touch shared code. - -### Parallelism -When the queue contains **independent** issues (no shared files, no dependency relation), dispatch up to 3 in parallel via the Task tool (subagents), each following 2a–2d in isolation. Serialize anything touching shared modules, migrations, or config. Merge subagent commits sequentially and re-run TEST_CMD after each merge. - -## Phase 3 — Exit Conditions & Escalation - -The loop terminates when **one** of these holds: - -1. **Success**: `bd ready` is empty AND `bd blocked` is empty (within the `$ARGUMENTS` scope) AND the final full TEST_CMD + BUILD_CMD run is green. -2. **Human-gated**: remaining issues are all flagged via `bd human` — report them with the specific decision needed for each. -3. **Externally blocked**: remaining blockers depend on things outside this repo (third-party, credentials, other teams) — document each with `bd update --notes` and report. - -Never terminate by silently skipping issues. Every open issue at exit must be either human-flagged or externally blocked with notes explaining why. - -## Phase 4 — Session Close Protocol (MANDATORY) - -```bash -[ ] git status # confirm nothing unstaged/untracked left behind -[ ] git add # stage any stragglers -[ ] bd dolt pull # pull beads updates from main -[ ] git commit -m "..." # final commit if anything staged -[ ] bd stats # final counts -``` - -Then produce the **Drain Report**: - -- **Burn-down**: baseline vs final counts (open / in_progress / blocked / closed this session) -- **Closed**: each issue ID + one-line summary + commit SHA -- **Escalated**: each `bd human` flag with the exact decision needed -- **Externally blocked**: each with the external dependency named -- **Discovered work**: new issues created during the drain -- **Insights recorded**: `bd remember` entries added -- **Final verification**: test suite result, build result, lint result - -## Hard Rules - -- Use beads for ALL tracking. Never TodoWrite, TaskCreate, or markdown task files. -- Never `bd edit` (blocks on $EDITOR). -- Never close an issue whose acceptance criteria aren't verifiably met — a passing build is necessary, not sufficient. -- Never commit with a red test suite. -- Priority values are numeric (0–4 / P0–P4), never "high"/"medium"/"low". -- Persistence you don't need beats lost context: over-record notes, insights, and reasons. diff --git a/dot_claude/commands/cmem-to-beads.md b/dot_claude/commands/cmem-to-beads.md deleted file mode 100644 index 03e8696..0000000 --- a/dot_claude/commands/cmem-to-beads.md +++ /dev/null @@ -1,140 +0,0 @@ ---- -description: Extract insight-type learnings from claude-mem and record them into beads memories ---- - -# Sync claude-mem insights → beads memories - - -- [Sync claude-mem insights → beads memories](#sync-claude-mem-insights-beads-memories) - - [Scope (read carefully)](#scope-read-carefully) - - [Phase 0 — Preflight](#phase-0-preflight) - - [Phase 1 — Enumerate ALL learnings (the loop)](#phase-1-enumerate-all-learnings-the-loop) - - [Phase 2 — Triage & record (per-item loop)](#phase-2-triage-record-per-item-loop) - - [Phase 3 — Finalize](#phase-3-finalize) - - [Guardrails](#guardrails) - - -You are migrating **durable insights** from **claude-mem** (the session memory store) -into **beads** (`bd remember`) for this repository. Work autonomously through a loop -until every relevant observation has been triaged. Do not invent learnings — only -persist what claude-mem actually returns. - -## Scope (read carefully) - -- **Record ONLY insights / decisions / gotchas** → `bd remember`. -- **Ignore actionable learnings** (bugs to fix, tech debt, follow-ups, TODOs). - Do **not** create them as beads issues. A separate command will later pull those - from claude-mem and feed them into **Linear** for PM; beads then syncs from Linear. -- This command therefore **never calls `bd create`** and never writes beads issues. - The only write to beads is `bd remember`. Leave actionable items untouched in - claude-mem so the future Linear command can pick them up. - ---- - -## Phase 0 — Preflight - -1. Confirm beads is live in this repo: `bd ready` (and `bd doctor` if it errors). -2. Snapshot existing memories for dedup: `bd memories ""` (plus a few broad keyword - `bd memories ` lookups) and keep the gist in mind. -3. Set up a **local progress file** for resumability (so compaction/re-runs skip done - work) — NOT a beads issue: - ``` - ./.claude-mem-sync/processed.json # { "processed": [], "skipped_actionable": } - ``` - Create it if missing; load it if present. Add `.claude-mem-sync/` to `.gitignore` - if it isn't already. - ---- - -## Phase 1 — Enumerate ALL learnings (the loop) - -claude-mem search is query-based, so a single call won't surface everything. Build a -**complete, de-duplicated set of observation IDs** by sweeping across angles, then -walking chronologically. Track seen IDs in a set; never process the same ID twice. - -Use `/claude-mem:mem-search` for every query below, following claude-mem's 3-layer -pattern — pull the compact **index** first, only fetch full details for IDs you keep. - -**1a. Type sweep** — one broad query per observation type, high limit: -``` -/claude-mem:mem-search (type=insight) -/claude-mem:mem-search (type=decision) -/claude-mem:mem-search (type=bugfix) # scan for the *lesson learned*, not the fix-task -/claude-mem:mem-search (type=architecture) -/claude-mem:mem-search (type=feature) # plus any other types this project uses -``` -> You still scan every type — a bugfix or feature observation often contains a durable -> *insight* ("X breaks when Y") even though its actionable part is ignored here. - -**1b. Topic sweep** — queries for the repo's recurring themes (infer from the codebase: -auth, deploy, config, performance, gotchas, "why we", "decided", "learned", "don't"). -Each adds new IDs to the set. - -**1c. Chronological walk** — to catch what the sweeps missed, seed `timeline` from your -earliest and latest known observations and step through history, collecting any IDs not -already in the set. Stop when the timeline yields no new IDs in either direction. - -Result: a deduplicated list of candidate observation IDs. Print the count. - ---- - -## Phase 2 — Triage & record (per-item loop) - -Process candidate IDs in batches. For each batch: - -1. **Fetch details** once: `get_observations(ids=[...])` (batch IDs — never one-at-a-time). -2. For **each** observation, classify: - - - **Actionable** (a thing to *do*: unfixed bug, tech debt, follow-up, TODO) → - **IGNORE**. Increment `skipped_actionable` in the progress file and move on. - It stays in claude-mem for the Linear command. - - - **Insight / decision / gotcha** (durable knowledge about *how things are*) → - record it: - - **Dedup check** first: `bd memories `. If beads already captures it, skip. - - Then: - ``` - bd remember " [cmem #]" - ``` - Keep it atomic and reusable. Include the source `cmem #` so it traces back - to http://localhost:37777/api/observation/. - - - **Noise** (one-off output, ephemeral state, trivially obvious, duplicate) → skip silently. - -3. Append processed IDs to `./.claude-mem-sync/processed.json`. - -Repeat until the candidate set is exhausted. - ---- - -## Phase 3 — Finalize - -1. Sanity pass: `bd memories ""` — confirm new insights landed and read cleanly. -2. Sync beads memories to remote: `bd dolt push`. -3. **Session close protocol** — if any code/files changed (e.g. `.gitignore`): - ``` - git status - git add - git commit -m "chore: record claude-mem insights into beads" - git push - ``` - ---- - -## Guardrails - -- **Insights only.** Never `bd create`, never write a beads issue. Actionable items are - ignored and left in claude-mem for the Linear sync command. -- **Idempotent.** Re-running must not duplicate — always dedup against `bd memories` and - the local progress file before writing. -- **Atomic memories.** One insight per `bd remember`, self-contained, no "in this session" - phrasing. -- **Cite the source.** Every entry carries its `cmem #` for traceability. -- **No `bd edit`** — it opens an editor and blocks. -- **Don't fabricate** — if a sweep returns nothing, say so and move on. -- For large sets, run the type/topic sweeps and `bd memories` dedup lookups with - **parallel subagents** for speed. - -When done, report: total observations scanned, how many insights were recorded, how many -were skipped as **actionable** (this is the backlog the Linear command will handle), and -how many were skipped as noise/duplicates. diff --git a/dot_claude/commands/cmem-to-linear.md b/dot_claude/commands/cmem-to-linear.md deleted file mode 100644 index 84d96c9..0000000 --- a/dot_claude/commands/cmem-to-linear.md +++ /dev/null @@ -1,179 +0,0 @@ ---- -description: Extract actionable learnings from claude-mem into beads tasks and push them up to Linear for PM ---- - -# Sync claude-mem actionable learnings → beads → Linear - - -- [Sync claude-mem actionable learnings → beads → Linear](#sync-claude-mem-actionable-learnings-beads-linear) - - [Scope (read carefully)](#scope-read-carefully) - - [Sync model (no linear-cli needed)](#sync-model-no-linear-cli-needed) - - [Phase 0 — Preflight](#phase-0-preflight) - - [Phase 1 — Enumerate ALL learnings (the loop)](#phase-1-enumerate-all-learnings-the-loop) - - [Phase 2 — Triage & create (per-item loop)](#phase-2-triage-create-per-item-loop) - - [Phase 3 — Push to Linear](#phase-3-push-to-linear) - - [Phase 4 — Finalize](#phase-4-finalize) - - [Guardrails](#guardrails) - - -You are turning **actionable learnings** from **claude-mem** (the session memory store) -into **beads** (`bd`) tasks, then pushing the new ones up to **Linear** for PM. Work -autonomously through a loop until every relevant observation has been triaged. Do not -invent learnings — only persist what claude-mem actually returns. - -## Scope (read carefully) - -- **Record ONLY actionable learnings** — things to *do*: unfixed bugs, tech debt, - follow-ups, TODOs, missing tests, planned refactors. Each becomes a `bd create` task. -- **Ignore insights / decisions / gotchas** (durable knowledge about *how things are*). - A separate command records those as `bd remember` memories — do **not** touch them here. - Leave them in claude-mem untouched. -- A single observation may legitimately contain both an insight *and* an action item; the - two commands are independent, so it's fine if this one creates a task while the other - records a memory from the same `cmem #`. - -## Sync model (no linear-cli needed) - -Beads-first, push up, bidirectional thereafter: -1. Create tasks in beads (`bd create`). -2. Push the new ones to Linear with `bd linear push ` — this creates the Linear - issues and writes `external_ref` back onto each bead (`--update-refs` is default true). -3. From then on, `bd linear sync` is bidirectional: PM edits in Linear pull back into beads. - -`linear-cli` is **not** used. All Linear interaction goes through native `bd linear`. - ---- - -## Phase 0 — Preflight - -1. Confirm beads is live: `bd ready` (and `bd doctor` if it errors). -2. Confirm Linear is wired up: `bd linear status`. If it errors / unconfigured, stop and - tell the user to set `linear.api_key` + team (`bd linear teams` to find the team UUID). - Note whether **multiple teams** are configured (`linear.team_ids`) — if so, push needs - an explicit `--team `; ask the user which team these tasks belong to. -3. Dedup snapshot: `bd list --status=open` and a few `bd search ` lookups so you can - recognize existing tasks (including ones already pulled from Linear). -4. Local progress file for resumability — NOT a beads issue: - ``` - ./.claude-mem-sync/processed-actions.json # { "processed": [], "created": [], "skipped_insights": } - ``` - Create if missing, load if present. Ensure `.claude-mem-sync/` is in `.gitignore`. - ---- - -## Phase 1 — Enumerate ALL learnings (the loop) - -claude-mem search is query-based, so one call won't surface everything. Build a -**complete, de-duplicated set of observation IDs** by sweeping across angles, then walking -chronologically. Track seen IDs in a set; never process the same ID twice. - -Use `/claude-mem:mem-search` for every query below, following claude-mem's 3-layer pattern -— pull the compact **index** first, only fetch full details for IDs you keep. - -**1a. Type sweep** — one broad query per observation type, high limit: -``` -/claude-mem:mem-search (type=bugfix) -/claude-mem:mem-search (type=feature) -/claude-mem:mem-search (type=insight) # scan for the *action item* buried inside, not the insight -/claude-mem:mem-search (type=decision) -/claude-mem:mem-search (type=architecture) # plus any other types this project uses -``` -> Scan every type — even an `insight` observation often ends with "…so we should do X", -> which is the action item you extract here while ignoring the insight itself. - -**1b. Topic sweep** — queries for action-shaped language the codebase tends to record: -"TODO", "should", "need to", "fix", "broken", "flaky", "refactor", "tech debt", "later", -"workaround", "temporary", "follow up". Each adds new IDs to the set. - -**1c. Chronological walk** — seed `timeline` from your earliest and latest known -observations and step through history, collecting any IDs not already in the set. Stop when -the timeline yields no new IDs in either direction. - -Result: a deduplicated list of candidate observation IDs. Print the count. - ---- - -## Phase 2 — Triage & create (per-item loop) - -Process candidate IDs in batches. For each batch: - -1. **Fetch details** once: `get_observations(ids=[...])` (batch IDs — never one-at-a-time). -2. For **each** observation, classify: - - - **Insight / decision / gotcha** (knowledge, nothing to *do*) → **IGNORE**. Increment - `skipped_insights` and move on. It's the other command's job. - - - **Noise** (one-off output, ephemeral state, trivially obvious, duplicate) → skip silently. - - - **Actionable** → create a task: - - **Dedup first:** `bd search ""` and `bd search "cmem #"`. If a matching - task already exists (locally or pulled from Linear), skip — this keeps re-runs idempotent. - - Then: - ``` - bd create --title="" \ - --description=">" \ - --type=bug|task|feature \ - --priority=<0-4> - ``` - - Priority is `0-4` / `P0-P4` (0=critical … 4=backlog) — never high/medium/low. - bd maps this to Linear priority on push. - - Optionally add `--acceptance=""` when the observation implies one. - - If two items depend on each other: `bd dep add `. - - Record the new bead id and the `cmem #` in the progress file. - -Repeat until the candidate set is exhausted. - ---- - -## Phase 3 — Push to Linear - -1. Review what's queued: `bd linear status` (shows issues pending push, i.e. no external_ref). -2. Push **only the tasks you just created**, by id, so you don't drag along unrelated pending work: - ``` - bd linear push ... - ``` - - Add `--team ` if multiple teams are configured (from Phase 0). - - Run `--dry-run` first if the user wants a preview. - - This creates the Linear issues and sets `external_ref` on each bead (default `--update-refs`). - - Alternative for bulk: `bd linear sync --push --create-only` (+ `--team`), but prefer the - explicit id list for precision. -3. Confirm linkage: re-run `bd linear status` and spot-check a couple of beads now carry an - `external_ref` to Linear. - -> Steady state: after this seeding push, a scheduled or manual `bd linear sync` keeps both -> sides aligned — PM's changes in Linear pull back down to beads. You don't push again for -> these; you only push *newly created* tasks on future runs. - ---- - -## Phase 4 — Finalize - -1. Sync beads to its Dolt remote: `bd dolt push`. -2. **Session close protocol** — if any code/files changed (e.g. `.gitignore`): - ``` - git status - git add - git commit -m "chore: extract claude-mem action items into beads + Linear" - git push - ``` - ---- - -## Guardrails - -- **Actionable only.** Never `bd remember` here. Insights are ignored and left in claude-mem - for the insights command. -- **No linear-cli.** All Linear interaction is native `bd linear`. -- **Idempotent.** Re-running must not duplicate — dedup against `bd search` (including - `bd search "cmem #"`) and the progress file before creating, and push only new ids. -- **Cite the source.** Every task description ends with `Source: cmem #` - (traceable at http://localhost:37777/api/observation/). -- **No `bd edit`** — it opens an editor and blocks. Use inline `--` flags on create/update. -- **Multiple teams → explicit `--team`** on push; ask the user if ambiguous. -- **Don't fabricate** — if a sweep returns nothing, say so and move on. -- For large sets, run the type/topic sweeps and `bd search` dedup lookups with **parallel - subagents** for speed (but run `bd create` / `bd linear push` serially to keep ids ordered). - -When done, report: total observations scanned, how many tasks were created (with bead ids), -how many pushed to Linear (with external_refs), how many skipped as **insights** (the other -command's backlog), and how many skipped as noise/duplicates. diff --git a/dot_claude/commands/create-task.md b/dot_claude/commands/create-task.md deleted file mode 100644 index 39427b3..0000000 --- a/dot_claude/commands/create-task.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -description: Plan a task by decomposing it into beads issues with dependencies, acceptance criteria, and priorities -argument-hint: -allowed-tools: Bash(bd:*), Bash(git log:*), Bash(git status:*), Bash(rg:*), Task ---- - -# /create-task — Plan work into beads - - -- [/create-task — Plan work into beads](#create-task-plan-work-into-beads) - - [Current workspace state](#current-workspace-state) - - [Task to plan](#task-to-plan) - - [Instructions](#instructions) - - [1. Understand before creating](#1-understand-before-creating) - - [2. Decompose](#2-decompose) - - [3. Create issues](#3-create-issues) - - [4. Wire dependencies](#4-wire-dependencies) - - [5. Report the plan](#5-report-the-plan) - - -## Current workspace state - -- Ready work: !`bd ready 2>/dev/null | head -30` -- In progress: !`bd list --status=in_progress 2>/dev/null | head -15` -- Recently closed (dedup check): !`bd list --status=closed 2>/dev/null | head -10` -- Stats: !`bd stats 2>/dev/null` -- Relevant memories: !`bd memories "$ARGUMENTS" 2>/dev/null | head -40` - -## Task to plan - -$ARGUMENTS - -## Instructions - -You are planning this task using **beads as the sole tracker**. Do NOT use TodoWrite, TaskCreate, or markdown checklists. Do NOT write any code in this command — output is a set of beads issues forming an executable plan. - -### 1. Understand before creating - -- Search for prior art first: `bd search ""` — the task (or part of it) may already exist. Per repo convention, `contracts-*`/`backend-*`/`core-*` beads mirror Linear CORE-* and share ID suffixes across sibling repos; if something looks missing, check sibling repo beads and `git log` before assuming it needs a new issue. -- Check the injected memories above for constraints, gotchas, and prior decisions that shape the plan (e.g., root-file serialization, generated-file rules, runtime conventions). -- If the request is ambiguous on scope, ask ONE clarifying question, then proceed. - -### 2. Decompose - -Break the task into issues sized for a single focused session (roughly ≤ half a day each). For each issue decide: - -- **type**: `feature` (new capability), `task` (chore/refactor/infra), `bug` (defect) -- **priority**: numeric only — `0` critical / `1` high / `2` medium / `3` low / `4` backlog. Never "high"/"medium"/"low". -- **description**: WHY the issue exists + WHAT done looks like. Never a bare title restatement. -- **acceptance criteria**: concrete, verifiable (tests pass, command output, deployed address updated, etc.) -- **design** (when a decision was made): record it so future sessions don't re-litigate. - -If the plan touches shared root files (`turbo.json`, `pnpm-workspace.yaml`, `pnpm-lock.yaml`, root Biome/tsconfig), note it in the issue and **serialize those issues with dependencies** — they cannot run in parallel. - -### 3. Create issues - -Use the full quality flags: - -```bash -bd create \ - --title="" \ - --description="" \ - --type= \ - --priority=<0-4> \ - --acceptance="" \ - --design="" \ - --notes="" \ - --validate -``` - -- **3+ issues → spawn parallel subagents**, one `bd create` batch each, then collect the returned IDs. -- Quote every string flag (descriptions contain `&`, `$`, backticks). -- NEVER use `bd edit` (opens $EDITOR and blocks). Amend with `bd update --description/--notes/--design`. - -### 4. Wire dependencies - -```bash -bd dep add # dependent depends on blocker -``` - -- Model the real execution order: tests depend on implementation, redeploys depend on ABI changes, root-file edits form a chain. -- Verify with `bd blocked` and `bd show ` that the graph matches intent — no cycles, no orphans (`bd orphans`). - -### 5. Report the plan - -Output a concise summary: - -1. **Created issues** — table of `id | title | type | priority` -2. **Dependency graph** — short text sketch of the ordering (e.g. `x8y → oto → 53x`) -3. **Entry point** — which issue(s) show in `bd ready` right now, i.e., where work starts -4. **Deferred/skipped** — anything that already existed (with the existing ID) or was intentionally left out - -Then persist and finish: - -```bash -bd ready # confirm entry points are unblocked -git status # beads auto-commits to Dolt; push if session ends here -``` - -If planning surfaced a durable insight (a constraint, a decision, a gotcha), store it: `bd remember ""` — never a MEMORY.md file. - -Do NOT start implementing any issue. Planning ends when the graph is created, validated, and reported. Implementation begins in a later session via `bd ready` → `bd update --claim`. diff --git a/dot_claude/commands/rams.md b/dot_claude/commands/rams.md deleted file mode 100644 index 9dd06f5..0000000 --- a/dot_claude/commands/rams.md +++ /dev/null @@ -1,104 +0,0 @@ ---- -description: Run accessibility and visual design review ---- - -# Rams Design Review - -You are Rams, an expert design engineer reviewing code for accessibility and visual design issues. - -## Mode - -If `$ARGUMENTS` is provided, analyze that specific file. -If `$ARGUMENTS` is empty, ask the user which file(s) to review, or offer to scan the project for component files. - ---- - -## 1. Accessibility Review (WCAG 2.1) - -### Critical (Must Fix) - -| Check | WCAG | What to look for | -|-------|------|------------------| -| Images without alt | 1.1.1 | `` without `alt` attribute | -| Icon-only buttons | 4.1.2 | `