Command Code:
The One Dollar Coding Agent Every QA Should Know

You already live in a terminal, and you already automate other people's tools. This tab treats cmd itself as the system under test: the flag groups you will reach for daily, the subcommands, and a CI-ready one-shot run at the end.

The cmd binary: flags that matter

• One binary, three openings. cmd starts an interactive session, cmd "message" starts with a first message, and cmd -p "query" prints an answer and exits. On native Windows the binary is cmdc.
• Get sessions back. -c, --continue reopens the most recent session in this directory; -r, --resume [name] resumes by id or name, or lets you pick from history.
• Manage sessions like fixtures. -n, --name <name> names a run, --session <path|id> targets an exact one, --fork-session branches it for a what-if, and --no-session skips saving one entirely.
• Execution modes. --plan starts in read-only plan mode, --auto-accept starts in auto-accept mode, --yolo bypasses all permission prompts, and --permission-mode <default|plan|auto-accept|dont-ask> sets the dial explicitly.
• Model and config. -m, --model <model> picks the engine, --list-models shows what your plan can run, --effort <low|medium|high> trades reasoning depth for cost, and --config <key=value> sets any setting headlessly.
• Context, trust, extensions. -t, --trust auto-trusts the project, --add-dir <directory> pulls another folder (say, your test-data repo) into scope, --mod <path> and --skill <path> load extras, and --no-skills skips skill discovery.

Worked example: one-shot flaky triage in CI

1. Go non-interactive. Use -p, --print: the agent answers once and exits, exactly what a CI step wants.
2. Ask for JSON. Add --output-format json so the next stage parses a verdict instead of scraping text.
3. Cap the loop. Set --max-turns 10 to cap agentic turns, so a stuck run fails fast instead of eating credits.
4. Spend less per run. Drop to --effort low for mechanical triage, and pick a cheap engine with --list-models plus -m (selected models are free).
5. Leave no residue. --no-session keeps hundreds of CI invocations from piling up in your resume history.
6. Debug when the step flakes. Re-run with --verbose to see everything; locally, --ide-setup connects your IDE to share the open file.

# see what models your plan can run (Go = open-source only)
cmd --list-models

# CI step: one-shot flaky triage, machine-readable output
cmd -p "read playwright-report/results.json and list the top 3 suspect flaky specs" --output-format json --max-turns 10 --effort low --no-session > flaky-triage.json

# machine-readable health check for the pipeline
cmd status --json

Interactive for exploration, -p for pipelines, --max-turns on anything unattended, and /usage as the referee: learn those once and cmd behaves like every other tool in your kit, scriptable and accountable.

Your working day is drive the session, guard the context, pick the model, watch the spend: slash commands are the cockpit switches for all of it, and Command Code groups them so a tester can find the right one mid-run.

The built-in catalogue, grouped for scanning

• Eight buckets, one prefix. Every built-in lands in one of eight groups: sessions, context, modes and planning, models, extensibility, workspace, billing, utilities. Learn the buckets and you can usually guess the command.
• Aliases are free. /clear also answers to /new, /resume to /sessions, and /exit to /quit, so whichever name your fingers type first still works.
• Context commands are money commands. /context shows context window usage and its breakdown, and /compact compacts history so you stop paying to resend a bloated transcript: run both during long test-writing sessions.
• Dispatch has a pecking order. Lookup is case-insensitive and resolves built-in -> mod -> custom -> skills, so a built-in name always beats a custom command with the same name.
• Testers get first-class verbs. /init writes AGENTS.md so the agent follows your repo conventions, while /review [pr-number] and /pr-comments put it on pull request duty.

Build your own: custom slash commands

1. Pick a scope. Team commands live in .commandcode/commands/ and show as (project) in the menu; personal ones live in ~/.commandcode/commands/ and show as (user).
2. Name the file. A command is just a markdown file and the file name is the command: commit.md answers to /commit, bug.md to /bug.
3. Write the prompt as the body. The full trimmed body IS the prompt that runs, no wrapper or config needed; the menu shows the first meaningful line, so open with a crisp summary.
4. Slot in arguments. $1 and $2 take positionals (counted from 1), ${1:-fix} adds a fallback, $@ or $ARGUMENTS takes everything, and ${@:2} takes everything from the second argument on.
5. Quote multi-word values. Arguments split on whitespace but respect single and double quotes, so /bug "Cart total wrong" high keeps the whole title in $1.
6. Verify the expansion. Run /commit once and read the prompt it produces, the same way you review a generated test before trusting it.

File: .commandcode/commands/commit.md

Write a commit of type "${1:-fix}" with message: ${@:2}

Invoke:     /commit feat add slash command reference
Expands to: Write a commit of type "feat" with message: add slash command reference

File: .commandcode/commands/bug.md

Write a bug report titled "${1:-untitled bug}" with severity "${2:-medium}".
Observed behavior: ${@:3}
Format it with: steps to reproduce, expected vs actual, environment,
and the evidence a reviewer should attach.

Invoke:     /bug "Cart total wrong" high add items, apply coupon, total ignores discount
Expands to: Write a bug report titled "Cart total wrong" with severity "high".
            Observed behavior: add items, apply coupon, total ignores discount

The catalogue drives the tool, and any prompt your team retypes weekly (commit style, bug format, flaky triage) belongs in .commandcode/commands/ as a file. When one prompt file needs templates and scripts around it, that is a skill: next tab.

A slash command carries one prompt; a skill carries a whole QA playbook: instructions, templates, and scripts in a folder that Command Code discovers cheaply and loads only when the task matches.

What a skill is and how it loads

• A folder with a SKILL.md. A skill is modular, self-contained instructions that teach the agent one task: your bug report house style, a flaky-triage runbook, a test plan template.
• Progressive disclosure, three stages. Discovery loads only name, description, and path at startup; activation reads the full SKILL.md on a match or a direct call; execution loads referenced files as needed. Installed-but-idle skills stay cheap.
• Four discovery locations. Project level .commandcode/skills/ for this repo, user level ~/.commandcode/skills/ for all projects, plus .agents/skills/ at both levels, badged [.agents].
• Project beats user. Priority runs project .commandcode/skills/ -> project .agents/skills/ -> user ~/.commandcode/skills/ -> user ~/.agents/skills/, so the repo's version of a skill name wins.
• Naming is strict. The directory name must match the name field exactly, using lowercase letters, numbers, and hyphens only: code-review is good; CodeReview, code_review, -code-review, and code--review are all bad.
• Two required fields, the rest optional. Frontmatter requires name (max 64 chars) and description (max 1024 chars). Optional: license, compatibility, metadata, allowed-tools, argument-hint, when_to_use, disable-model-invocation, user-invocable, disallowed-tools, arguments, model, effort.

.commandcode/skills/
├── code-review/
│   └── SKILL.md
└── my-skill/
    ├── SKILL.md
    ├── scripts/
    ├── references/
    └── assets/

Build it, invoke it, install it

1. Scaffold the folder. For a repo-shared skill create .commandcode/skills/test-plan/SKILL.md; for a personal one use ~/.commandcode/skills/. The directory name and the name field must match exactly.
2. Write the frontmatter. Set name: test-plan and a description that spells out when to use it: discovery only sees name and description, so the description is what requests get matched against. Optional fields like argument-hint and when_to_use can ride along.
3. Write the body with substitutions. $ARGUMENTS pulls everything the caller typed, ${0} the first argument (skills count from 0), $name reads a declared named argument, and ${COMMANDCODE_SKILL_DIR} points at the skill's own folder for files under references/.
4. Inject live context. Inline backtick shell such as !`git status --short` runs the command and drops its output into the prompt; a fenced block starting with ```! does the same for several commands. Kill switch: disableSkillShellExecution: true in settings.json.
5. Invoke it three ways. Start a prompt with /test-plan checkout-v2 guest flows, drop /test-plan inline anywhere in a sentence, or just describe the job and let Command Code suggest the matching skill.
6. Install team packs. cmd skills add <owner/repo> pulls skills in (-s <skill-name> to pick one, --global), cmd skills list shows them (--debug), cmd skills remove <skill-name> uninstalls (--global --yes), and /skills browses from inside a session.

File: .commandcode/skills/test-plan/SKILL.md

---
name: test-plan
description: Generate a risk-based test plan for a feature, story, or
  pull request. Use when asked what to test, for coverage ideas, or
  for a test plan before build, review, or release.
argument-hint: <feature> <extra context>
when_to_use: Coverage planning for features, PRs, and releases.
---

# Test plan generator

Repo state right now:
!`git status --short`

Write a risk-based test plan for: $ARGUMENTS
Feature under test: ${0}

1. Follow the house template in ${COMMANDCODE_SKILL_DIR}/references/template.md
2. Cover smoke, happy path, negative, edge, and regression risks.
3. Save the finished plan to ${COMMANDCODE_PROJECT_DIR}/docs/test-plans/${0}.md

Invoke:  /test-plan checkout-v2 guest and logged-in flows
Here:    ${0} is "checkout-v2", $ARGUMENTS is the whole argument line

Skills are how a QA team stops re-teaching the agent every morning: the playbook lives in the repo, the priority order decides which copy wins, and the agent only reads the full instructions when a task actually matches.

Kill the myth first: no Command Code plan offers unlimited usage, so the real skill is spending a metered credit pool deliberately instead of hoping it never runs out.

The honest math behind the dollar plan

• No plan is unlimited. The docs say it plainly. Go is $1 a month for $10 of credits (about 15K requests, open-source models only), Pro is $15 for $30, Max 10x is $100 for $150, Max 20x is $200 for $300. Selected models are free, but everything else draws the pool down.
• Credits reset monthly. Included credits refresh each month and top up automatically at model cost. Purchased top-ups are different: they roll over and never expire, which makes them the thing to bank for a heavy release push.
• Rolling limits pace the included pool. A 5-hour limit (30 percent of your monthly allocation) and a weekly limit (60 percent) apply to included credits only. On-demand credits are never throttled, and free or balance-only accounts have no rolling caps at all.
• Four things drive the spend. Which model you run, how much reasoning effort you ask for, how much context you resend, and how many agentic turns you allow. Every lever in this tab pulls on one of those four.
• Model choice is the biggest lever. Pricing runs from free (selected models) up to $10.00 per million input tokens for the most expensive model. Run cmd --list-models and match the model to the job, because mechanical work does not need your priciest option.

The $10 routine, step by step

1. Set cheap defaults. Run cmd --list-models, pick a free or low-cost open-source model, and launch with cmd -m <model-id> --effort low. On Go you are on open-source models anyway, and selected models cost nothing.
2. Check the meter before a big run. /usage shows credits, plan, and usage metrics, so you know what a long triage session can afford before you start it, not after.
3. Think in plan mode. Start risky work with cmd --plan or switch with /mode:plan. Plan mode is read only, so you settle the approach without burning edit turns on a direction you will throw away.
4. Stop paying for the bloat. When /context shows the window stuffed with old tool output, run /compact. Otherwise every new message pays to resend the whole bloated transcript.
5. Cap the loop. Add --max-turns 10 to anything unattended: it is the simplest guard against a confused agent looping through your pool.
6. One-shot your scripts. In CI use cmd -p "query": it prints the answer and exits, so nothing is left waiting for input that never comes.

# --- in your shell ---
# pick the cheapest model that can do the job
cmd --list-models
cmd -m <free-model-id> --effort low --plan

# --- at the Command Code prompt, inside a session ---
/usage      # credits, plan, usage metrics
/context    # what is filling the window
/compact    # stop resending the bloat

# --- back in your shell: guard-railed one-shot for CI ---
cmd -p "summarize the failing specs in the junit report" --max-turns 10

A realistic month on the dollar plan: treat the $10 as about 15K requests on open-source models, default to a free model at --effort low, compact before long sessions, keep any single 5-hour push under 30 percent of the pool and any week under 60 percent, and bank an /extra top-up for release week, since it rolls over, never expires, and is never throttled.

One pass, end to end: a flaky login spec goes from triage to merged fix using the CLI, one custom slash command, one skill, an isolated worktree, and a CI one-shot.

The pieces you will chain

• AGENTS.md is the contract. /init writes AGENTS.md so the agent follows your repo conventions (test runner, folder layout, naming) before it touches a file. Commit it once and every session starts aligned.
• Plan mode scopes the task. /mode:plan, or launching with cmd --plan, is read only: you agree on the approach before a single edit lands.
• A custom slash command owns the repetitive part. One markdown file in .commandcode/commands/ becomes a project command, with ${1:-default} and ${@:2} argument templating baked in.
• A skill carries the QA playbook. A folder with a SKILL.md in .commandcode/skills/ teaches the agent your triage or bug-report format once; progressive disclosure means only its name and description load until it is actually needed.
• A worktree isolates the risky bit. cmd -w runs in a managed git worktree, so a refactor gone wrong never breaks your working checkout.
• Review and CI close the loop. /review [pr-number] and /pr-comments handle the pull request, and cmd -p gives the pipeline a one-shot, non-interactive run.

Run it: flaky spec to green PR

1. Teach the repo. In the project root run cmd, then /init: it writes AGENTS.md with your conventions. Commit that file so the agent, and every teammate's agent, plays by the same rules.
2. Scope the fix in plan mode. Start cmd --plan "login.spec.ts is flaky: find the root cause and propose a fix". Read the plan, then switch to /mode:default only when you approve it.
3. Script the repetitive part. Save .commandcode/commands/flaky.md with a triage prompt using ${1:-login.spec.ts} and ${@:2}; from then on /flaky checkout.spec.ts attach traces reruns the same triage on any spec.
4. Carry the playbook as a skill. Create .commandcode/skills/flaky-triage/SKILL.md (frontmatter needs name and description, and the directory name must match), or install a shared one with cmd skills add <owner/repo> -s flaky-triage. Invoke it with /flaky-triage.
5. Refactor in a worktree. Launch the risky cleanup with cmd -w login-fix: the agent works in an isolated managed worktree, and /worktree list shows what exists when you want to inspect or remove it.
6. Review, then wire CI. On the pull request run /review 42 and sweep /pr-comments; in the pipeline call cmd -p with --max-turns so the job answers, exits, and never hangs.

# --- at the Command Code prompt, once ---
# teach the repo its own rules
/init

# --- in your shell: scope the fix without spending edit turns ---
cmd --plan "login.spec.ts is flaky: find the root cause and propose a fix"

# reusable triage command: .commandcode/commands/flaky.md
#   Rerun and triage flaky spec "${1:-login.spec.ts}", then draft a bug report: ${@:2}
/flaky checkout.spec.ts attach traces

# the QA playbook skill: .commandcode/skills/flaky-triage/SKILL.md
/flaky-triage login.spec.ts

# risky refactor in an isolated managed worktree
cmd -w login-fix

# close the loop: PR review, then a CI one-shot
/review 42
cmd -p "run the login suite and summarize failures" --max-turns 10

That is the whole loop: conventions written once, a plan approved per task, the repetitive parts turned into a command and a skill, the scary parts isolated in a worktree, and cmd -p holding the line in CI.