choiyounggi

loop-implement

The single implementation loop. It plans via wiki-plan (step 2, required) into an ordered, wiki-navigated task list, then executes those tasks in order, each loading only its named wiki pages, writing tests first, getting an independent test-quality audit, and judging against done; on failure it reflects and retries (bounded). Use for a non-trivial task or feature. Skip typos, config values, and simple renames.

Code & Development Solid

orchestrate

Orchestrate one natural-language goal into parallel tmux Claude Code sessions. It decomposes the goal (with your approval), plans each task with wiki-plan, implements and reviews, runs an integration test, and merges after your confirmation. Use to build a goal across multiple sessions. For a single task, use loop-implement instead.

Code & Development Solid

wiki-lint

Health-check the bundled wiki. Detect unsourced claims, bare prohibitions, broken links, index and page trigger mismatches, vague qualifiers, oversized pages, and stale dates, then fix them; reports a numeric health score (0-100). Use to keep the wiki healthy before drift compounds.

Code & Development Solid

knowledge-flush

Drain queued ★ Insight candidates (harvested from your sessions) into the wiki as a reviewed PR. For each candidate it researches and verifies the best-practice against real sources, checks existing wiki layers for duplicates and links, decides the target layer/category (or justifies a new one), runs wiki-ingest, then opens ONE PR per flush for you to review and merge/reject. Never auto-merges. Use when asked to "flush knowledge", "process the insight queue", "ingest what I learned", or "/dev-loop:knowledge-flush".

configure

Set up dev-loop's capability-role tool profile — map `knowledge` (your domain wiki / MCP), `verify` (your project's test/build/QA command), `explore` (code search), `tacit` (past incidents), and `design` (Figma/visual spec) to the actual tools this environment has, then write ~/.claude/dev-loop/tools.json (global) or <repo>/.dev-loop/tools.json (per-repo). Use when asked to "configure dev-loop", "set up tools", "map my wiki/test command", or "/dev-loop:configure".

wiki-ingest

Add one verified lesson or edge case to the bundled wiki. Route it to the right domain and category, merge into an existing page before creating a new one, and enforce sourcing and positive-guidance rules. Use when capturing a documented best practice or a production edge case.

wiki-plan

The fixed planning methodology for a capable model. Make every design decision grounded in a bundled wiki page (recording a decision-to-page map), then decompose the work into ordered, self-contained tasks, each naming the exact wiki pages that govern it. Runs as loop-implement step 2.

wiki-query

Answer a development question from the wiki with citations, loading only the pages whose triggers match. If the answer required synthesis across multiple pages and the question is likely to recur, file the synthesis back as a new page so knowledge compounds.

consolidate

Periodically merge the memory index and long-tier memory files — deduplicate, resolve contradictions to the current truth, absolutize dates — and propose the result for your confirmation before any write. Use when MEMORY.md grows large (~120+ lines) or long-tier memories accumulate duplicates, contradictions, or stale facts.

habit

Distill a lesson — a mistake, a user correction, or a praised behavior — into HABITS.md as a positive practice or a hard line. Use after the user corrects you, after an incident, or when the learning-nudge hook fires.

remember

The save gate for persistent memories — confirm tier (long/short) and expiry with the user before writing, so hallucinated or transient facts never enter long-term memory. Use whenever saving a memory file, and when the expiry sweep reports archived memories.

setup

First-time memory-loop setup — offer identity names, create HABITS.md from the template, write an initial config, and verify the hooks respond. Use right after installing the memory-loop plugin, or when asked to "set up memory-loop".

self-test

Prove the guardrails Bash guard is live — runs a simulation that feeds representative dangerous commands (curl|sh, rm -rf, DROP TABLE, kubectl delete, cloud deletes, …) through the real guard and shows the block/ask decision for each, WITHOUT executing any of them. Use when asked to "test guardrails", "is the guard working", "guardrails self-test", or right after installing guardrails.

identity

Set, change, or decline the user/assistant names that memory-loop injects at session start. Use when the user wants to set up names, rename either party, ask the assistant to pick its own name, or stop the name-setup offer from appearing.