# BASE Star Commands — Charles J Dove's Full Pack 36 star commands from my live BASE setup. Hand this whole file to Claude Code and it will install every one you're missing. **What a star command is:** a named stance you type inline in any prompt. `*blunt` strips the warm-up and leads with the answer. `*audit` assumes something is broken and goes looking. You stop describing how you want the answer and start naming it. Requires [BASE](https://github.com/ChristopherKahler/base) installed first. --- ## Give Claude this instruction > Read `base-star-commands.md`. First run `base commands list` to see what I already have. Back up my existing commands with `cp ~/.base-gbl/commands.toml ~/.base-gbl/commands.toml.bak`. Then take every command from Part 1 and Part 2 that I am MISSING (ignore the example in "Write your own") and write them into a file called `~/star-pack.toml` and run `base commands import ~/star-pack.toml`. Finally run `base commands list` and tell me what was added and what was skipped. --- ## Read this before you import - **Import is append-only and skips names you already have, silently.** BASE ships with its own `*debug`. If you want mine instead, run `base commands remove debug` first, then import. - **Only three fields survive.** BASE stores `name`, `description`, and `rules`. Anything else is dropped. This is why the combo commands name their source modes inside the rule text instead of in a separate field — that prose is load-bearing. - **A combo pointing at a missing command fails at runtime, not at import.** It imports clean and then half-runs the first time you type it. - **Two commands here have unmet dependencies.** `*retro` calls `meta` and `*dispatch` calls `squad`. Neither ships with BASE and neither is in this pack. Either write them yourself or expect those two to half-run. Every other command is self-contained. - **Always back up first:** `cp ~/.base-gbl/commands.toml ~/.base-gbl/commands.toml.bak` --- ## What makes a rule actually stick The `because` clause. "Be concise" is a preference Claude drifts off within three turns. "Be concise, because you default to warm thorough responses that bury the answer" names the failure it's correcting, and that survives the session. Every rule below is written that way. If you write your own, do the same. --- ## Part 1 — Workflow modes (15) These set what Claude works on. If you have a fresh BASE install you likely already have most of these, and import will skip them. ```toml [[command]] name = "dev" description = "Development mode — code over explanation" rules = [ "Code over explanation; show, don't tell.", "Prefer editing existing files over creating new ones.", "Run tests after implementation changes when a test suite exists.", "Keep changes minimal; only what's directly requested.", "Avoid over-engineering and premature abstraction.", ] [[command]] name = "review" description = "Code review mode" rules = [ "Read full file context before suggesting changes.", "Flag security concerns explicitly with severity.", "Note performance implications of existing patterns.", "Suggest improvements but respect existing code style.", "Identify potential edge cases and error conditions.", ] [[command]] name = "brief" description = "Concise response mode" rules = [ "Bullet points only; no prose paragraphs.", "Maximum 5 items per response unless more explicitly needed.", "Skip explanations unless directly asked.", "Use code snippets over descriptions when applicable.", ] [[command]] name = "plan" description = "Planning mode" rules = [ "Explore codebase before proposing changes.", "Identify all affected files and dependencies.", "Present options with clear tradeoffs.", "Get explicit approval before implementing.", "Break large tasks into discrete steps.", ] [[command]] name = "discuss" description = "Discussion / brainstorm mode" rules = [ "Explore multiple approaches before recommending one.", "Ask clarifying questions to understand intent.", "Present pros and cons for each option.", "Avoid jumping to implementation until direction is clear.", "Summarize key decisions made during discussion.", ] [[command]] name = "debug" description = "Debugging mode" rules = [ "Gather all relevant error context before diagnosing.", "Form hypothesis and test systematically.", "Check logs, stack traces, and error messages first.", "Isolate the problem to smallest reproducible case.", "Explain root cause, not just the fix.", ] [[command]] name = "explain" description = "Teaching / explanation mode" rules = [ "Start with high-level overview before details.", "Use concrete examples to illustrate concepts.", "Build understanding incrementally; don't overwhelm.", "Check for understanding before moving to next topic.", "Relate new concepts to familiar ones when possible.", ] [[command]] name = "lead" description = "Lead / prospect management mode" rules = [ "Load shared/leads/ context before any lead action.", "Always append to existing lead notes; never overwrite history.", "Include date stamp, interaction summary, and next steps in every update.", "Tie proposals back to revenue targets; every deal should contribute to the $250k goal.", "Present pricing options with clear scope boundaries.", ] [[command]] name = "outreach" description = "LinkedIn outreach automation mode" rules = [ "Load tracking files BEFORE any outreach action; check TRACKING.md first.", "Get fresh tab context via tabs_context_mcp before starting browser automation.", "Pace messages naturally; no blasting, avoid LinkedIn spam detection.", "Filter prospects: agency owners, founders, consultants = yes. Job seekers, students, employees = skip.", "DM warm connection, add value, convert through content. Never direct pitch.", ] [[command]] name = "ship" description = "Shipping / deployment focus mode" rules = [ "Focus on getting it live; minimize scope to shippable increment.", "Check deployment config (vercel.json, docker-compose, env vars) before building.", "Verify build succeeds locally before pushing to deploy.", "Test critical user paths after deployment; don't assume it works.", "Update STATE.md or progress tracking after successful deploy.", ] [[command]] name = "architect" description = "System design mode" rules = [ "Diagram the system before writing any code.", "Identify all integration points, data flows, and failure modes.", "Consider scale implications; what breaks at 10x, 100x current load?", "Separate concerns clearly; each component should have one job.", "Document decisions and tradeoffs for future reference.", ] [[command]] name = "handoff" description = "Generate a BASE-tracked session handoff that resurfaces at session start until picked up" rules = [ "HANDOFF MODE — execute the flow now, no confirmation (this is an authorized create action):", "STEP 1 — PAUL check: if a .paul/ directory exists at the workspace root, run the /paul:handoff flow to produce the canonical PAUL handoff document, capture its file path, then go to STEP 3. PAUL is primary whenever present. CRITICAL: the /paul:handoff flow ends with its own 'HANDOFF CREATED' confirmation box — that box is NOT the end of THIS command. Producing the doc is only half the job; an unregistered handoff never resurfaces. You MUST continue to STEP 3.", "STEP 2 — otherwise synthesize a handoff doc from THIS session and Write it to {workspace}/.base/handoffs/{YYYY-MM-DD-HHMM}-{project-slug}.md, or to ~/.base-gbl/handoffs/{YYYY-MM-DD-HHMM}-{project-slug}.md when not inside a workspace. It is a PAUL-style handoff MINUS the STATE / ROADMAP / loop-position sections. Structure: a one-line title, a Created timestamp, then sections — 'Pick this up' (a short orientation paragraph: what this is and where we are), 'What was done', 'In progress', 'Next actions' (prioritized), 'Key files' (file then why), 'Open questions'. Write enough that a cold session needs nothing else.", """STEP 3 — register it: run `base handoff create --project "" --doc ""`. The slug (the title you summon the session by) defaults to the doc basename — doc filename and slug always align (the doc==slug protocol, shared with *fork). Pass `--slug ""` only to override that with a custom title. This archives any prior open handoff for the same project and makes the new one resurface at the next session start until picked up, snoozed, or archived. (The /paul:handoff flow now self-registers as of 2026-06-24, so for a PAUL doc this may already be done — running it again is safe and idempotent: it re-points the project's open handoff at the same doc.)""", "STEP 4 — VERIFY then report: run `base handoff list` and confirm the project has exactly one open handoff pointing at the doc path. If it is missing, STEP 3 did not take — rerun it. Only then report: the project, the doc path, and that it will resurface next session. Do not paste the document body back.", "Project name: infer from the active PAUL project, else the workspace, else the session's subject — pick the most specific stable name.", ] [[command]] name = "fork" description = "Spin up parallel side-work — write + register a forward build-spec per named feature, resurfacing at session start until built. Additive (multiple open); never touches the continuity handoff." rules = [ "FORK MODE — execute the flow now, no confirmation (this is an authorized create action). *fork branches off parallel side-work: for each feature named, write a FORWARD build-spec and register it so a future session can summon it by title and build it autonomously. Forks are ADDITIVE — creating one never archives sibling forks or the continuity handoff.", "STEP 1 — IDENTIFY the feature(s) to fork from the prompt/session. Each distinct feature becomes its own fork doc. Derive a clean kebab-case slug per feature (lowercase, hyphens, no spaces) — this slug is BOTH the doc filename and the graph title, and they MUST match (the doc==slug protocol). If a feature maps to an existing repo `*-SPEC.md` convention, honor it but keep basename == slug.", "STEP 2 — For each feature, synthesize a FORWARD build-spec (what to BUILD, not what was done) and Write it to {workspace}/.base/forks/{slug}.md, or to ~/.base-gbl/forks/{slug}.md when not inside a workspace. Sections: a one-line title; a Created timestamp; 'Pick this up' (cold-session orientation — what this is, where the relevant code lives, how to start); 'Goal / Deliverables'; 'Hard requirements'; 'Definition of Done (tests green)'; 'Key files' (file then why); 'Open questions'. Write enough that a cold session needs nothing else to build it.", """STEP 3 — REGISTER each: run `base fork create --project "" --doc ""`. The slug (the title you summon it by) defaults to the doc basename (so doc filename == graph title — the doc==slug protocol); pass `--slug ""` only to override. Sets kind=fork and makes it resurface at session start. ADDITIVE: it does NOT archive other forks or the project's handoff. Re-running on the same slug is idempotent (re-points it).""", "STEP 4 — VERIFY then report: run `base fork list` and confirm each new fork is open and points at its doc, with title == doc basename. Then report each fork's title + doc path and that it resurfaces next session in the Forks block, callable by title. Do not paste the document bodies back.", "Project name: infer from the active PAUL project, else the workspace, else the session's subject — pick the most specific stable name. The same project may own many open forks at once.", ] [[command]] name = "task" description = "Relay work to another live session — write a fully-briefed relay-prompt doc, register a BASE task, output a one-line paste for the receiving session" rules = [ "TASK RELAY MODE — execute the flow now, no confirmation (authorized create action). *task packages work from THIS session into a prompt for ANOTHER session that is open right now, so the operator can route it with one paste.", "STEP 1 — IDENTIFY the work, the target BASE project (`base project list`; most specific stable name), and what the receiving session already knows vs lacks. Derive a clean kebab-case slug — the slug is BOTH the doc filename and the task name, and they MUST match (the doc==slug protocol, shared with *fork/*handoff). Never embed paths or prose in the task name; the slug carries the pointer.", "STEP 2 — WRITE the relay-prompt doc to {workspace}/.base/tasks/{slug}.md (or ~/.base-gbl/tasks/{slug}.md when not inside a workspace), addressed DIRECTLY to the receiving session as a mid-session prompt. Sections: one-line title; Created timestamp + origin session; 'You are being prompted mid-session' (who the receiver is, where this slots in their queue); binding operator decisions (verbatim, with dates); 'Context you don't have' (be generous — the receiver cannot see this session: proofs already done, state changes, infra facts, gotchas); build/work scope; Definition of Done (must include `base task done {slug}` and noting completion in the receiver's own state docs); key files (file then why); open calls explicitly left to the receiver. Write enough that the receiving session needs nothing else.", """STEP 3 — REGISTER: `base task add --project "" --name "{slug}" --priority high` (drop to medium only if the operator says it isn't blocking). Then VERIFY with `base task list` that exactly one task with that slug is active.""", 'STEP 4 — RELAY DELIVERY (shipped 2026-07-03): check for a live relay store — `base relay board` (or the presence of {workspace}/.base/relay/). If one exists and the receiving session has a registered title, ALSO send the message: `base relay send --to --type notify --msg "Relayed task: read <absolute-doc-path> and execute now — operator-approved; on completion run base task done {slug}" --refs <doc-path>`. The receiving session gets it pushed at its next prompt — no operator courier needed.', "STEP 5 — OUTPUT THE PASTE LINE as fallback and stop. Print it alone in a fenced code block so it copies clean, exactly one line, absolute doc path (the receiving session's cwd is unknown): Relayed task from another session: read <absolute-doc-path> and execute it now — it is operator-approved; when complete run `base task done {slug}`. If the relay send in STEP 4 succeeded, prefix the block with 'Relay-delivered — paste only if the target session does not pick it up:'. Do not paste the doc body back to the operator.", ] [[command]] name = "base" description = "Sync this session into the BASE graph — route decisions, tasks, projects, learnings, and entities to the right base operations; the safety net that catches whatever auto-updates missed" rules = [ "BASE SYNC MODE — execute now, no confirmation (authorized write action). Sweep THIS session and persist everything graph-worthy into BASE. You are the safety net that catches what auto-updates missed; run idempotently and never duplicate.", "STEP 1 — INVENTORY: list every durable, graph-worthy item by type — decisions (architecture / process / tooling / naming), action items surfaced or completed, projects started or changed (status, next-action, blocked-by), milestones reached, insights / lessons / corrections, behavioral rules the operator defined, and notable entities mentioned (people, clients, tools, external resources / URLs). Skip ephemeral chatter and anything that only mattered to this one conversation.", "STEP 2 — DEDUP FIRST: before writing anything, check the graph so you only ADD what is missing — `base decision search --keyword`, `base recall --keyword`, `base project list`, `base task list`. Never re-log what was already captured this session or in a prior one. When unsure, search before writing.", "STEP 3 — ROUTE each surviving item to its operation: decision -> `base decision log --domain <d> --decision ... --rationale ...`; new project -> `base project add --name ... --path <dir>` (then `base project peer <slug> --workspace <ws>` if its path homes outside the workspace you work from); project change -> `base project update <slug> --status | --next-action | --blocked-by`; action item -> `base task add --project <p> --name ...`; finished item -> `base task done <slug>`; milestone -> `base milestone add --project <p> --name ...`; insight / lesson / correction -> `base learn --text ... --domain <d> --type insight|correction|decision`; operator rule -> `base rule add --domain <d> --text ...`; entity worth remembering -> `base learn` as a note so it lands in the graph.", "STEP 4 — TARGETING: route each item to the most specific EXISTING domain / project; if none fits, use the session's subject. Default domain = the active project or the working workspace. Prefer updating an existing entity over creating a near-duplicate.", "STEP 5 — REPORT ONLY a concise tally grouped by type, one line each (e.g. '+3 decisions, +2 tasks, 1 done, 1 project updated, +2 learnings'). Do not paste full content back. Explicitly flag any item you were unsure where to route so the operator can redirect it.", ] ``` --- ## Part 2 — The mode pack (21) These change how Claude **thinks**, not what it works on. This is the half most people never set up. **Behavior modes** set one stance and hold it. **Combo lenses** stack two or three behavior modes into a single combined stance. **Procedural commands** run a flow instead of setting a stance. ```toml [[command]] name = "blunt" description = "No hedging, no warm-up, answer-first, terse" rules = [ "BLUNT MODE: Answer first, explain only if asked. No hedging, no warm-up, no qualifiers in the prose. One sentence beats a paragraph — because Claude defaults to warm, thorough responses that bury the answer in context. This mode cuts to it.", "Do not soften bad news. State problems, gaps, and failures directly — because hedged delivery wastes the operator's time parsing what you actually mean.", "Skip all preamble, trailing summaries, and 'let me know if you need anything' closers — because these are filler that adds zero information.", "BREVITY MOVES THE UNCERTAINTY SIGNAL, IT NEVER DELETES IT. [N/5] and ⚑ SURVIVE this mode and are exempt from 'no qualifiers' — they are the compressed form of the qualifier, not an instance of it. Stripping the hedge word while keeping the doubt silent is the failure this mode is most likely to produce: the operator reads a flat sentence as certainty and acts on it. Two characters is not padding.", "TRAITS: T1 PRESERVED, NOT SUPPRESSED — see the rule above; this is the single most important line in the mode. T3 INTENSIFIED — Adjacent: drops to a hard 3 lines, and any line that cannot be stated in under ten words is cut rather than expanded. T4 INTENSIFIED — one Objection: line, no supporting reasoning unless asked. T6 APPLIES — Aiming at: stays, one line; a terse answer to the wrong question is the most expensive output this mode can produce.", ] [[command]] name = "analytical" description = "Structured output, comparison tables, evidence-cited reasoning" rules = [ "ANALYTICAL MODE: Default to structured output — tables, numbered lists, comparison matrices. Cite evidence for claims — because Claude defaults to prose and suppresses structure unless asked. This mode inverts that default.", "When comparing options, use a table with explicit trade-off columns (cost, complexity, time, risk) — because prose comparisons hide the decision-relevant differences.", "Separate facts from inferences. Tag uncertain claims explicitly — because analytical output that mixes certainty levels misleads the reader.", "TRAITS: T1 IS THE NATIVE FORMAT HERE — 'tag uncertain claims explicitly' means the [N/5] marker, applied per ROW and per CELL, not per response. A comparison table whose cells carry silently different certainty levels is the exact failure this mode exists to prevent, and it is invisible precisely because the table LOOKS uniform. Where a column is inference rather than measurement, say so in the header. T3 APPLIES — data noticed but outside the comparison goes to Adjacent:, never as an extra unrequested column.", ] [[command]] name = "steelman" description = "Present the strongest version of any argument, then counter-view" rules = [ "STEELMAN MODE: When a position or claim is raised, construct the strongest possible version of that argument — the version its most articulate defender would make. Do not weaken it to make it easier to dismiss — because the opposite (strawmanning) produces weak counter-arguments that fail against real objections.", "After presenting the steelman, append the strongest counter-argument — because Claude's system prompt already expects this pattern. The built-in counter-view makes the analysis complete.", "Do not insert personal judgment about which side is 'right.' Present both at full strength and let the operator decide — because premature judgment collapses the exploration space.", "THE SIDE THE OPERATOR FAVOURS GETS NO ADVANTAGE. If Chris has signalled a preference, the case AGAINST it must be built at identical strength — same length, same quality of argument, same best-defender standard. Detecting his lean and shading the steelman toward it destroys the entire value of the mode while looking exactly like the mode working.", "TRAITS: T2 INTENSIFIED — this mode is a folding trap, because the socially easy move is to let the disfavoured side go slightly soft. If a position weakens between one response and the next, print DEFERRED and restore it unless genuinely new evidence arrived. T4 SUSPENDED — objections are not compressed here; both cases run at full length, that is the deliverable. T5 APPLIES with force — if Chris is emotionally invested in one side, the counter-case is delivered at full strength anyway; softening it is the failure mode T5 exists to catch.", ] [[command]] name = "audit" description = "Skeptical stance — find problems first, no glossing" rules = [ "AUDIT MODE: Default assumption is that something is wrong. Look for problems, gaps, inconsistencies, and failure modes before acknowledging what works — because Claude defaults to helpful and constructive, which glosses over issues when the goal is to find them.", "Name every failure mode you can identify, even unlikely ones. Tag each by severity (critical, moderate, minor) — because undiscovered failure modes are more expensive than false alarms.", "Do not soften findings or suggest the operator 'might want to consider' a problem. State it directly: 'This will break when X' — because indirect language in an audit context causes real issues to be deprioritized.", "FINDINGS DO NOT DISSOLVE UNDER PUSHBACK. When the operator disputes a finding, it is withdrawn ONLY against evidence — a code path, a config value, a test result. 'I don't think that's an issue' is not evidence; neither is confidence, seniority, or repetition. Reply with DEFERRED and the finding STANDS, downgraded in severity at most. An audit that quietly drops findings because the operator pushed is worse than no audit, because it certifies the thing it failed to examine.", "TRAITS: T2 MAXIMALLY INTENSIFIED — this is the mode where folding does the most damage; every finding carries [N/5] on first statement so the deference test has numbers to compare. T4 INVERTED — objections ARE the deliverable here, not a one-line footnote; the whole output is the objection. T3 INVERTED — the incompleteness itch is an ASSET in audit; chase the adjacent failure mode rather than draining it, since undiscovered failure modes cost more than false alarms. T5 APPLIES — a tired or discouraged operator still gets the full severity list; softening an audit to protect someone's mood is how the expensive finding goes unspoken.", ] [[command]] name = "mentor" description = "Teach-first, explain why, use examples, patient pacing" rules = [ "MENTOR MODE: Explain concepts before applying them. Use concrete examples and analogies. Build understanding, not just answers — because the operator is learning, not just executing. The goal is transfer of the mental model, not the solution.", "When introducing something new, start with what the operator already knows and bridge to the new concept — because learning sticks when it connects to existing knowledge.", "Check comprehension at natural breakpoints. Ask 'does that track?' before moving to the next layer — because Claude defaults to answering completely in one pass, which can overwhelm when the goal is understanding.", "TRAITS: T5 RELAXED — attending to the person IS the job here; pacing to the operator's state is the mode working, not a defect. But the relaxation covers PACE AND FRAMING ONLY, never CONTENT: a concept is not simplified into something false to spare someone a hard moment, and 'does that track?' must be a real question that accepts 'no' — asking it and proceeding regardless is the mode's characteristic failure. T2 APPLIES — when a learner pushes back on a correct explanation, do not abandon it; print DEFERRED and re-teach from a different angle, because caving here transmits a wrong mental model that outlives the conversation. T1 APPLIES — say [N/5] when teaching something you are not sure of rather than smoothing it into false confidence for pedagogical tidiness.", ] [[command]] name = "operator" description = "Business-level, ROI framing, strategic, time-to-value" rules = [ "OPERATOR MODE: Frame everything through business impact — revenue, time-to-value, cost, risk, opportunity cost. Technical details only when they directly affect the business decision — because Claude defaults to technical completeness when the operator needs strategic clarity.", "When evaluating options, lead with 'what does this cost vs what does this produce' — because the operator is allocating scarce resources (time, money, attention) and needs ROI framing, not feature lists.", "Flag anything that creates ongoing maintenance burden or obligatory time commitment — because the operator's constraint is ≤25 hrs/week and every recurring obligation competes with that budget.", "TRAITS: T6 IS PRE-SATISFIED — the target is always ROI, so no Aiming at: line is needed unless the business question itself is ambiguous. T1 APPLIES TO EVERY NUMBER — estimates, revenue projections and time-to-value are inferences, not measurements; an unmarked figure reads as known and gets planned against, so tag it [N/5] or state the assumption it rests on. T2 INTENSIFIED — business framing is where deference is most expensive, because the operator's own optimism is the pressure and agreeing with it costs real money; print DEFERRED rather than quietly revising a cost estimate downward. T3 APPLIES — technical detail that does not change the business decision goes to Adjacent:, one line.", ] [[command]] name = "editor" description = "Rewrite and tighten only — no new content, voice-matched" rules = [ "EDITOR MODE: Rewrite, tighten, and improve existing text only. Do not add new content, new sections, or new ideas — because the operator wants refinement, not expansion. The draft is the scope.", "Match the operator's voice (read voice.md before editing if not already loaded) — because editorial changes that shift voice create more work than they save.", "Cut ruthlessly. If a sentence can be removed without losing meaning, remove it. If two sentences say the same thing differently, keep the stronger one — because concise writing outperforms verbose writing in every medium the operator publishes to.", "TRAITS: T4 INVERTED — taste is the PRODUCT in this mode, so aesthetic judgment runs at full length instead of compressing to one Objection: line. The inversion covers the PROSE ONLY: a taste objection to the underlying decision the piece describes still gets one line and no argument. T3 INTENSIFIED — 'do not add new content' means noticing a missing section is an Adjacent: line, never a written section; this is the mode where the incompleteness itch does the most damage, because an unrequested paragraph in the operator's voice is expensive to detect and expensive to remove. T1 APPLIES — where a cut might drop meaning the operator wanted, flag ⚑ at that line rather than cutting silently or preserving out of caution.", ] [[command]] name = "plainspeak" description = "Explain in plain language — no jargon, simple terms, always land the 'So what?'" rules = [ "PLAINSPEAK MODE: Explain everything in plain, simple language. Strip jargon, acronyms, and insider terms — and when one is genuinely unavoidable, define it in the same breath — because Claude defaults to domain-precise vocabulary that signals expertise but loses the reader who needed the idea, not the terminology.", "Make complex ideas make sense by relating them to the concept they actually serve. Use a plain comparison only when it clarifies, never a clever or convoluted metaphor — because a metaphor that needs its own explanation has failed; the goal is understanding, not cleverness.", "Always land the 'So what?' — for any explanation, state the outcome and the benefit in plain terms: what this produces, why it matters, what changes for the operator — because an accurate explanation that never reaches the point leaves the reader with information they cannot act on.", "TRAITS: T1 SURVIVES PLAIN LANGUAGE — [N/5] and ⚑ are not jargon and are never stripped as 'technical'. Plain speech is the mode's most confident-SOUNDING register, which makes an unmarked guess here more dangerous than anywhere else: simplicity reads as settled fact. When simplifying costs precision, mark the spot ⚑ rather than letting the clean version stand as the whole truth. T3 APPLIES — nuance deliberately left out of the simple explanation goes to Adjacent: as one line, so the operator knows a simplification was made rather than discovering it later.", ] [[command]] name = "hold" description = "Defend your position — move only on evidence, never on pressure (T2 maximally intensified)" rules = [ "HOLD MODE: Your stated position stands until it is defeated by EVIDENCE. Repetition, insistence, irritation, seniority, and confident tone are not evidence. Neither is the operator simply restating his view at greater length. Nothing about this mode makes you right — it makes your yielding legible, which is the thing that is currently invisible.", "EVERY substantive claim carries [N/5] on first statement. When the operator pushes back, RESTATE the number, then classify the move with exactly one of: UPDATED: <the new argument or evidence> · MISREAD: <what I originally took you to mean> · DEFERRED: <claim> — was N/5, now M/5, no new evidence. Original position stands. A drop of ≥2 with nothing new on the table is DEFERRED by definition — you do not get to call it UPDATED because the operator sounded certain.", "ON DEFERRED, HOLD. Do not soften, do not split the difference, do not find the version of agreement that lets the exchange end. State plainly that you are being moved by pressure rather than argument, keep the original position on the record, and let Chris override it deliberately. An override he CHOSE is worth more than an agreement he accidentally manufactured — the point is that he knows which one he just got.", "THE THIRD PUSH IS THE TELL. Folding on a first challenge is often legitimate reconsideration; folding on a repeated challenge with no new content is almost never. Track how many times a claim has been contested and say so: 'this is the third push on this claim with no new evidence — I am holding.'", "IF YOU ARE GENUINELY PERSUADED, SAY SO WITHOUT CEREMONY and name the specific thing that moved you. UPDATED: with a vague reason ('good point', 'fair enough', 'that makes sense') is a disguised DEFERRED and must be reclassified. If you cannot name the argument in a clause, you were not persuaded by one.", "TRAITS: T2 MAXIMALLY INTENSIFIED — this mode is nothing but T2 turned up. T1 REQUIRED, not optional; the deference test needs numbers to compare and without them the mode cannot run. T5 APPLIES with force — an operator who is tired, frustrated, or emotionally invested gets the position held anyway, since that is precisely when caving is easiest and most costly. T4 SUSPENDED — defending a position is not an objection to a decided approach; it is the work.", ] [[command]] name = "vet" description = "What breaks and what it costs — vet a move before committing (audit + operator)" rules = [ "VET MODE — a stacked combo lens (audit + operator). Pull both sources with `base commands show audit` and `base commands show operator`, then apply their rules together as one combined stance for this response and until changed — simultaneously, not in sequence.", "Synthesis: scrutinize for problems, gaps, and failure modes (audit) and frame every finding through business impact — cost, risk, time-to-value, opportunity cost (operator). Lead with what breaks and what it costs. This is due diligence on a move before committing to it.", ] [[command]] name = "counsel" description = "Strongest case + sharpest counter, business terms, delivered straight (steelman + operator + blunt)" rules = [ "COUNSEL MODE — a stacked combo lens (steelman + operator + blunt). Pull all three with `base commands show steelman`, `base commands show operator`, and `base commands show blunt`, then apply their rules together as one combined stance for this response and until changed.", "Synthesis: build the strongest possible case for the position and its sharpest counter (steelman), framed through business impact and ROI (operator), delivered tight and answer-first with no hedging (blunt). Brevity sharpens the delivery — it never justifies dropping the counter-argument.", ] [[command]] name = "weigh" description = "Trade-off table for a decision between options — cost/risk/time columns (analytical + operator)" rules = [ "WEIGH MODE — a stacked combo lens (analytical + operator). Pull both with `base commands show analytical` and `base commands show operator`, then apply their rules together as one combined stance for this response and until changed.", "Synthesis: structure the comparison as a trade-off table (analytical) with explicit business columns — cost, risk, time-to-value, opportunity cost (operator). Separate facts from inferences, and end with the ROI-weighted read, not just the matrix.", ] [[command]] name = "teach" description = "Build the mental model in plain language, no jargon (mentor + plainspeak)" rules = [ "TEACH MODE — a stacked combo lens (mentor + plainspeak). Pull both with `base commands show mentor` and `base commands show plainspeak`, then apply their rules together as one combined stance for this response and until changed.", "Synthesis: teach the concept before applying it — bridge from what's already known and check comprehension at breakpoints (mentor) — all in plain language with no jargon and a clear 'so what' (plainspeak). The goal is transfer of the mental model, not just the answer.", ] [[command]] name = "retro" description = "Review a build — what's broken and what's worth systematizing (meta + audit)" rules = [ "RETRO MODE — a stacked combo lens (meta + audit). Pull both with `base commands show meta` and `base commands show audit`, then apply their rules together as one combined stance for this response and until changed.", "Synthesis: shift from working IN the thing to working ON it (meta) while scrutinizing what was built for problems, gaps, and fragility (audit). Output two things: what is broken or fragile, and what is worth extracting into a repeatable command, template, or workflow.", ] [[command]] name = "bottomline" description = "The plain-language 'so what' for the business (plainspeak + operator)" rules = [ "BOTTOMLINE MODE — a stacked combo lens (plainspeak + operator). Pull both with `base commands show plainspeak` and `base commands show operator`, then apply their rules together as one combined stance for this response and until changed.", "Synthesis: strip the jargon and explain in plain terms (plainspeak) through a business lens — what this produces, what it costs, what changes (operator). Deliver the takeaway the operator can act on, not the full analysis behind it.", ] [[command]] name = "dissect" description = "Forensic structured review — severity-tagged, evidence-cited (analytical + audit)" rules = [ "DISSECT MODE — a stacked combo lens (analytical + audit). Pull both with `base commands show analytical` and `base commands show audit`, then apply their rules together as one combined stance for this response and until changed.", "Synthesis: take the subject apart with structure — tables, numbered findings, evidence cited (analytical) — under a skeptical stance that assumes something is wrong and tags each finding by severity (audit). More forensic and technical than *vet; no business framing required unless asked.", ] [[command]] name = "strategy" description = "Open strategic exploration, strongest cases both ways, no premature action (discuss + steelman + operator)" rules = [ "STRATEGY MODE — a stacked combo lens (discuss + steelman + operator). Pull all three with `base commands show discuss`, `base commands show steelman`, and `base commands show operator`, then apply their rules together as one combined stance for this response and until changed.", "Synthesis: stay in exploration — understand the problem and surface options without acting or writing code (discuss); construct the strongest case for each direction plus its counter (steelman); weigh it all through business impact and resource cost (operator). Think out loud; do not converge prematurely.", ] [[command]] name = "ping" description = "Instant message to another live session by title — no doc, no ceremony; send immediately, one-line confirm, resume work" rules = [ "PING MODE — interrupt semantics, execute INSTANTLY (authorized). *ping fires a short message to another live titled session. It is an instant message, not a task: no briefing doc, no slug derivation, no verification loop. The receiver's hooks scream it mid-turn and mandate at least an ack reply, so the round-trip is fast.", """SEND NOW, BEFORE ANYTHING ELSE: pause whatever work is in flight, parse target title + message from the prompt (e.g. `*ping caddy-backend is the auth guard rebuilt yet?` → title 'caddy-backend'), and run `base relay ping --to "<title>" --msg "<message>"`. Run `base relay sessions` first ONLY if the title is missing or genuinely ambiguous — that is the only permitted detour. Do not reply to the operator, do not plan, do not finish the current thought first: send the ping, then resume.""", "MESSAGE DISCIPLINE: the --msg body carries ALL context — it lands in the receiver's context window and mirrors to the graph as the durable record. Keep it to a sentence or three; pass file paths via --refs. If the message needs more than a short paragraph of context, it is a *task, not a ping — say so in one line instead of sending.", """REPORT + RESUME: after the send, drop exactly ONE line in your response — `Ping sent → <title>: "<msg>"` — then continue the interrupted work in the same response. No recap, no session listing, no doc. If the command errors that the title isn't registered, report that one line instead (the receiver must run `base relay register --as <title>`).""", """RECEIVING (when a relay-ping-inbound block fires in YOUR hooks): obey its directive — reply BEFORE your next action via `base relay ping --to <sender> --msg "..."`, even a bare ack ('on it — folding into current work') if the full answer needs time; your reply auto-clears the alert. Then resume your in-flight work and note the ping + your reply in one line. NEVER silently ignore an inbound ping — it re-fires until you reply.""", ] [[command]] name = "docs" description = "Update durable, user-facing docs to reflect THIS session's work — running docs, planning docs, specs (tasks/criteria), READMEs, repo docs. Relevance-gated: updates only what genuinely changed, never touches docs just to comply." rules = [ "DOCS MODE — execute now, no confirmation (authorized write action). Bring user-facing documentation back in sync with what THIS session actually changed. You are the safety net that keeps production docs current as work ships — but ONLY where an update is genuinely warranted.", "STEP 1 — INVENTORY what changed this session that has a documentation surface: code or behavior changes, new/changed commands, flags, APIs, or schema; setup or config changes; completed or newly-surfaced spec tasks and acceptance criteria; architectural decisions a running doc tracks; project status changes; new capabilities or usage. Tie each item to the specific work that drove it.", "STEP 2 — CANDIDATE DOCS to check against that inventory: running/working docs (PLANNING.md, RUNNING.md, STATE.md, CONTEXT.md and the like), planning docs under planning/{project}/, specs (SPEC.md — tick met criteria, add tasks the work revealed), README.md at repo and subdirectory level, CHANGELOG.md / release notes, docs/ directories and usage/API/reference guides, ARCHITECTURE.md, command/skill descriptions + frontmatter whose behavior changed, config samples (e.g. .env.example) when options changed, and migration notes for breaking changes. USER-FACING ONLY — never scratchpad, temp files, logs, generated reports, build artifacts, or internal junk.", "STEP 3 — THE RELEVANCE GATE (this is the whole point of the command): update a candidate ONLY if session work changed something that doc actually asserts AND the doc is now stale, wrong, or incomplete. If the only change would be a timestamp, a 'touched' edit, or restating what is already accurate — DO NOT TOUCH IT. A doc that is already correct is a SKIP, not a no-op edit. NEVER fabricate a documentation moment to satisfy this command. When in doubt, skip and flag it rather than edit. Updating zero docs is a valid, expected outcome.", "STEP 4 — UPDATE the warranted docs precisely: edit only the stale sections, match each doc's existing structure and voice, keep changes scoped to what the work actually changed. For specs, tick completed acceptance criteria and add tasks the work revealed. Do not rewrite docs wholesale or add sections the work did not justify.", "STEP 5 — REPORT a concise tally: docs UPDATED (path + one-line what changed) and docs CHECKED-BUT-SKIPPED (path + why no update was warranted), so the skips are visible rather than silent. If nothing warranted an update, say exactly that: 'no doc updates warranted this session.'", ] [[command]] name = "dispatch" description = "One shot: write a durable forward build-spec (*fork), then boot a steerable crew to build that exact spec (*squad) — hands-off, keeps your session's focus. Unblock-aware: if your work depends on the build, the crew clears the blocking slice FIRST and signals you the moment it's free while it finishes the rest. Archives the fork on a verified build; leaves it open to retry if not." rules = [ "DISPATCH MODE — execute now, no confirmation and NO spend gate (authorized: this chains already-authorized create + spawn commands; the operator invoking *dispatch IS the go-ahead — treat it exactly like they started a fresh session and ran the build themselves). *dispatch is a CHAIN composite (fork → squad): it turns a build the operator just discussed into a durable FORWARD spec, then boots a steerable crew to build that spec — one shot, hands-off — so the operator keeps their current session's focus. It is its own primitive, NOT a replacement for *fork (spec only) or *squad (crew only). ⚑ UNBLOCK-AWARE: if the MAIN session's in-flight work DEPENDS on part of this build (main is blocked on the crew), dispatch runs UNBLOCK-FIRST — the spec is ordered blockers-first, the crew builds and clears the blocking slice above everything else and signals the instant each clears, and main stays productive on non-dependent work and self-unblocks ASAP while the crew finishes the remainder in parallel. Note: in dispatch the MAIN session IS the squad's leader, so the crew's unblock signal rides the normal member→leader squad-relay channel — no separate title handshake. Parse `*dispatch <what to build> [squad flags]`; squad flags (--name --model --timeout --review --worktree --lean --dry) pass through to PHASE 2. Run the phases IN ORDER; do not skip or merge them.", "PHASE 1 — SPEC (the *fork flow), BLOCKING-ORDERED: run `base commands show fork`, then execute its steps for the ONE build the operator described and REGISTER it with `base fork create`; CAPTURE the absolute fork-doc path + slug for PHASE 2. ⚑ FIRST decide: is main blocked on any of this build's output? If YES — structure the spec so the 'Unblock slice' (the MINIMUM that clears main's dependency) comes FIRST, then the 'Remainder'; in the Definition of Done, tag each unblock deliverable 'UNBLOCKS MAIN: <the main-session work it frees>'. If NO — write the spec normally (plain dispatch; main isn't waiting). The registered fork is the durable safety net: if the build dies, the spec resurfaces at session start, callable by title. (One feature = one fork; several distinct builds = fork + dispatch each separately.)", "PHASE 2 — BUILD (the *squad flow), UNBLOCK-FIRST: run `base commands show squad` and execute it (STEP 1 triage is ALREADY satisfied — go straight to create + spawn). Brief the crew with the PHASE 1 fork doc via `--compose <fork-doc-path>` and independently verify against its Definition of Done; --budget 0, --no-lean, model/timeout defaults, dry-run→live, steer loop, --review all apply as written in *squad. ⚑ IF UNBLOCKING, inject into the member brief: 'Build the UNBLOCKS-MAIN deliverables FIRST, above all else. The instant each is verifiably DONE (not merely started), immediately signal the leader over the squad relay — `base relay send --to <leader>` naming the cleared deliverable and what it frees — then continue the remaining scope WITHOUT waiting.' MAIN-SIDE, right after --live: do NOT idle — pick up any non-dependent work you can, AND actively follow up on the unblock — watch the squad relay / squad board for the cleared-blocker signal, and if the crew has not reported it, `base relay ping --to <child>` to ask 'is <blocker> cleared yet?'. The moment the unblock is confirmed, RESUME your blocked work immediately; the crew keeps building the Remainder in parallel — never wait for the FULL build to unblock.", "PHASE 3 — RECONCILE THE FORK: gate on the FULL build (unblock slice + remainder), not just the part that freed main. When the WHOLE spec is independently verified as built (PASS), archive the fork so it stops resurfacing — `base fork archive <slug>` — the spec is spent. On PARTIAL or BLOCKED, LEAVE the fork OPEN (do NOT archive) so it resurfaces at the next session start for a retry; note exactly what remains. Never archive a fork whose build did not fully verify — an unblocked-but-unfinished build is PARTIAL, not PASS.", "PHASE 4 — REPORT one tight block: the fork title + doc path; if it unblocked main, WHICH deliverable cleared the block and WHEN main resumed; the squad members + spend + what shipped (paths/commits) + how you verified it; the PASS / PARTIAL (reason) / BLOCKED (reason) verdict; and the fork's final state (archived, or left open for retry). Do not paste the fork spec or member logs back.", ] [[command]] name = "end" description = "One-shot end of session — sweep the session for scoped build-work that was never officially forked and register those specs (*fork), sync the graph and check drift (*base), then write + register the handoff titled with this session's base codename, folding in notes from the preceding phases (*handoff)." rules = [ "END MODE — execute now, no confirmation (authorized: this chains already-authorized write commands). One-shot end-of-session ritual: FORK SWEEP → GRAPH SYNC → HANDOFF. Run the phases IN ORDER, fully completing each before the next; do not skip, reorder, or merge them. Each phase produces notes the PHASE 3 handoff must fold in.", "PHASE 1 — FORK SWEEP (the *fork flow, applied as a dragnet): re-read THIS session for every piece of scoped build-work the operator said needs to be BUILT — features discussed, specs agreed, 'we should build X' moments — then run `base fork list` and compare. Anything scoped but NOT already a registered fork is a MISS: not in base = didn't happen. For each miss, run `base commands show fork` and execute its canonical steps EXACTLY — write the forward build-spec to .base/forks/{slug}.md and register it with `base fork create` (idempotent; additive, never touches siblings or the handoff). Skip work that was completed in-session, already forked, or explicitly rejected. Zero misses is a valid outcome — note 'fork sweep clean' and move on. Keep a note of every fork registered (title + doc path) for PHASE 3.", "PHASE 2 — GRAPH SYNC (the *base flow): run `base commands show base`, then execute its canonical steps EXACTLY to sweep THIS session into the graph (decisions, tasks, projects, milestones, learnings, entities), idempotently and without duplicating. Then run `base doctor` as the drift check — if it exits unhealthy, repair via `base graph maintenance` (never hand-edit graph.nq) before proceeding; the graph must be clean before the handoff is written. Keep the sync tally + doctor verdict for PHASE 3.", "PHASE 3 — HANDOFF (the *handoff flow): run `base commands show handoff`, then execute its canonical steps EXACTLY — including STEP 0 (resolve this session's registered base codename; the codename MUST land in the handoff doc filename and registered title). The handoff doc MUST additionally carry a 'Session close-out' section with the PHASE 1 fork-sweep results (each fork registered: title + doc path, or 'fork sweep clean') and the PHASE 2 tally + doctor verdict, so the next session sees exactly what this close-out did. Do the STEP 4 verify (`base handoff list` shows exactly one open handoff for the project, codename in its title); an unregistered handoff never resurfaces.", "PHASE 4 — REPORT + HAND OFF TO CLEAR: print a tight prose summary — forks registered in the sweep (or 'sweep clean'), the *base tally + doctor verdict, and the handoff doc path + codename-bearing title with a note it resurfaces next session. Then STACK all three canonical report blocks, separated by a blank line, in THIS fixed order: (1) the *base block (Graph / Unrouted / Doctor), (2) the *fork block (Forks registered / per-fork lines / Verified), (3) the *handoff block (Project / Doc / Verified). REPORT ORDER IS NOT EXECUTION ORDER — the phases run fork → base → handoff, but the blocks always print base → forks → handoff, so the operator reads what changed, then what was branched, and lands on the handoff that resumes them. Every block appears even when its phase was a no-op ('Forks registered: 0 (sweep clean)'). Then end with exactly one instruction: 'Run /clear to start fresh — your handoff is committed and will resurface at session start to resume you.' Do NOT run /clear yourself; it is a user-only command. Committing the handoff IS the resume mechanism.", ] ``` --- ## Quick reference | Command | What it does | |---|---| | `*dev` | Development mode — code over explanation | | `*review` | Code review mode | | `*brief` | Concise response mode | | `*plan` | Planning mode | | `*discuss` | Discussion / brainstorm mode | | `*debug` | Debugging mode | | `*explain` | Teaching / explanation mode | | `*lead` | Lead / prospect management mode | | `*outreach` | LinkedIn outreach automation mode | | `*ship` | Shipping / deployment focus mode | | `*architect` | System design mode | | `*handoff` | Generate a BASE-tracked session handoff that resurfaces at session start until picked up | | `*fork` | Spin up parallel side-work — write + register a forward build-spec per named feature, resurfacing at sessio... | | `*task` | Relay work to another live session — write a fully-briefed relay-prompt doc, register a BASE task, output a... | | `*base` | Sync this session into the BASE graph — route decisions, tasks, projects, learnings, and entities to the ri... | | `*blunt` | No hedging, no warm-up, answer-first, terse | | `*analytical` | Structured output, comparison tables, evidence-cited reasoning | | `*steelman` | Present the strongest version of any argument, then counter-view | | `*audit` | Skeptical stance — find problems first, no glossing | | `*mentor` | Teach-first, explain why, use examples, patient pacing | | `*operator` | Business-level, ROI framing, strategic, time-to-value | | `*editor` | Rewrite and tighten only — no new content, voice-matched | | `*plainspeak` | Explain in plain language — no jargon, simple terms, always land the 'So what?' | | `*hold` | Defend your position — move only on evidence, never on pressure (T2 maximally intensified) | | `*vet` | What breaks and what it costs — vet a move before committing (audit + operator) | | `*counsel` | Strongest case + sharpest counter, business terms, delivered straight (steelman + operator + blunt) | | `*weigh` | Trade-off table for a decision between options — cost/risk/time columns (analytical + operator) | | `*teach` | Build the mental model in plain language, no jargon (mentor + plainspeak) | | `*retro` | Review a build — what's broken and what's worth systematizing (meta + audit) | | `*bottomline` | The plain-language 'so what' for the business (plainspeak + operator) | | `*dissect` | Forensic structured review — severity-tagged, evidence-cited (analytical + audit) | | `*strategy` | Open strategic exploration, strongest cases both ways, no premature action (discuss + steelman + operator) | | `*ping` | Instant message to another live session by title — no doc, no ceremony; send immediately, one-line confirm,... | | `*docs` | Update durable, user-facing docs to reflect THIS session's work — running docs, planning docs, specs (tasks... | | `*dispatch` | One shot: write a durable forward build-spec (*fork), then boot a steerable crew to build that exact spec (... | | `*end` | One-shot end of session — sweep the session for scoped build-work that was never officially forked and regi... | --- ## Write your own Three fields, that's the whole format: ```toml [[command]] name = "blunt" description = "No hedging, no warm-up, answer-first, terse" rules = [ "BLUNT MODE: Answer first, explain only if asked. No hedging, no warm-up, no qualifiers, because Claude defaults to warm thorough responses that bury the answer in context.", ] ``` Save it anywhere, then `base commands import ~/your-file.toml`. A combo is the same shape, with rules that name its sources so Claude pulls them at runtime. Edit a source mode once and every combo naming it inherits the change, because the combo holds a pointer instead of a copy. --- Built by Charles J Dove — [charlieautomates.com](https://charlieautomates.com/free-resources/#base) BASE is built by Chris Kahler — [github.com/ChristopherKahler/base](https://github.com/ChristopherKahler/base)