Skip to main content

Module 13 — Daily workflows: explore, fix, test, review, ship

The previous modules laid the pieces: slash commands, skills, permissions, hooks, subagents, MCP, plugin. What remains is to chain them together. This module gathers the recipes of a day in the life of a developer tooled up for Kiosque: understand an unfamiliar codebase, fix a bug from a trace, do TDD, refactor, review, open a PR, and let it self-repair. The thread is a single Kiosque ticket, from morning until the PR turns green.

The best-practice rule​

Every recipe below obeys a single rule from best-practices.md: give Claude a check it can run itself, tests, build, lint, screenshot comparison. Without that check, "looks done" is the only signal available and you become the verification loop. With it, the session stops when the check goes green. Three postures complete the picture: explore, plan, code (plan mode when scope is unclear, direct code for a typo); give precise context (@file, pasted screenshot, existing pattern); fix quickly or start over (two ineffective corrections beat a /clear followed by a better-written prompt).

Understand Kiosque in fifteen minutes​

You arrive at the repo on a Monday morning. Claude is faster than a manual scan:

cd kiosque
claude
give me a one-page overview of this repo:
technologies, layout, entry points, visible debt.
then walk through the flow of an order, from the HTTP request
to payment, pointing at the key files and functions.

Follow up with narrow questions, as you would with a senior engineer: "how does notifications.py talk to Twilio?", "why does create_order call _lock_menu() on line 87?". Two technical habits change the game on a larger codebase: starting claude from the relevant subfolder (app/ for the API) so only the pertinent CLAUDE.md files load, and delegating exploration to a subagent (use a subagent to investigate ...) so the fifty reads do not fill your main context. large-codebases.md complements this with claudeMdExcludes, Read(...) deny rules on dist/ or build/, and a code intelligence plugin when the language has an LSP server.

Fix a bug from a trace​

Lea forwards a trace: payment fails intermittently on orders above 50 EUR. Do not dictate the solution, describe the symptom, the probable location, and what "fixed" means:

symptom: POST /commandes/{id}/payer returns 502 about 1 in 10
on baskets > 50 EUR. trace:
[paste the trace]

the lead is in app/paiements.py, around the Stripe timeout.
first write a test that reproduces the problem, then fix,
then rerun make test. attack the root cause, do not mask the error.

Three things matter: the test first closes the loop (Claude has a check to run), "root cause" is explicit (otherwise try/except around the symptom), the pointer (paiements.py, Stripe timeout) saves ten useless reads. Three shortcuts to know: Esc interrupts Claude while preserving the context, Esc Esc (or /rewind) opens the checkpoint menu to restore conversation, code, or both, /clear resets between two unrelated tasks.

TDD on notifications.py​

On Tuesday, you add a fallback SMS channel. TDD here means: test first, code next, executable check to validate. common-workflows.md provides the outline — combine it with the /targeted-tests skill from module 6 to run only what touches the diff:

add a function send_fallback_sms(commande) in app/notifications.py:
    triggered when Twilio times out > 5 s, falls back to provider B.
    first, write the unit tests in tests/test_notifications.py
    (Twilio timeout, provider B success, two consecutive failures).
    then implement, then run /targeted-tests until everything passes.

Claude writes the tests, fails on purpose, codes, reruns. You only watch the end of the loop. On a broader check — "the route must respond in under 200 ms on 10,000 rows" — go through /goal: a separate evaluator rechecks the condition after each turn until resolved. For a check that must fire always, prefer a Stop hook that blocks end-of-turn while make test is red (Claude Code lifts the hook after eight consecutive blocks).

Refactor without breaking​

On Wednesday, Karim wants to clean up commandes.py. Two commands complement each other:

  • /simplify is a cleanup skill: four parallel agents look for reuse, simplifications, efficiency gains, and wrong levels of abstraction — never for bugs.
  • /code-review (alias /review) is a correction review skill on the current diff or a passed target (pr#, branch, path). It accepts a level low, medium, high, xhigh, max, or ultra, and two flags: --fix to apply the fixes and --comment to post the remarks as inline GitHub comments. Without a level, it reuses the last low..max you typed, even from a previous session; ultra neither uses nor modifies that level.

Typical chain: /simplify app/commandes.py, validate the cleanups, then /code-review high --fix. Claude rereads the diff, applies the fixes it deems safe, and returns a report.

Peer review, Kiosque style​

Nadia refuses to merge without a second opinion. Three levels, from lightest to heaviest:

  1. /code-review local. Bundled skill, runs in a background subagent with its own context window. --fix corrections applied inside a background subagent are not captured by checkpoints — use git to roll back, not /rewind.
  2. /code-review ultra. Launches ultrareview in a cloud sandbox, comparing your branch to the default branch plus your local staged and unstaged changes. On a github.com PR, --post prepares publication from your GitHub account. Requires a claude.ai account and is not available through Bedrock, Vertex AI, or Microsoft Foundry.
  3. Managed Code Review (research preview). Team and Enterprise plans, unavailable if Zero Data Retention is on. A fleet of agents analyzes each PR and posts its findings as inline comments classified by severity (red Important, yellow Nit, purple Pre-existing). Per-repo triggers: Once after PR creation, After every push, Manual. Force with @claude review (once) or @claude review always (subscribe to pushes). Customize through CLAUDE.md (general context, violations treated as Nit) and REVIEW.md at the root (instructions for the review agents only).

For Kiosque, keep /code-review high --fix locally before every push, then let the managed service handle the PR. The check run always ends in a neutral conclusion; to turn "at least one Important" into a gate, parse the machine-readable line at the end of the output with gh and jq.

Open the PR and let it repair itself​

common-workflows.md recommends closing a session with a commit and a PR. Two possible forms:

commit with a descriptive message and open a PR

Or in steps:

summarize the changes I made to the paiements module
create a pr

Claude Code links the session to the PR when the PR is created with gh pr create (or glab mr create); you can then find the session again with claude --from-pr 1234 — the /resume picker also accepts the PR URL.

Once the PR is open, /autofix-pr spawns a Claude Code on the web session that watches your branch: on every CI failure or new review comment, Claude investigates and pushes a fix when the path is clear. The command detects the open PR of the current branch through gh pr view — to watch another PR, check out its branch first. An optional prompt narrows the scope, for example /autofix-pr only fix lint and type errors. Requires gh and access to Claude Code on the web; the Claude GitHub app must be installed on the repo.

Cascading behaviors

Auto-fix responses are posted from your GitHub account and can wake up automations triggered on issue_comment (Atlantis, Terraform Cloud, custom Actions). Review what runs on that event before enabling on a sensitive repo.

Final check: /verify and /run​

Two bundled skills close the day: /verify builds the app, launches it, and observes the result — beyond tests and typecheck; /run launches it without necessarily checking. /run-skill-generator writes a SKILL.md per project that teaches /run and /verify how to start your app from a clean environment. Since v2.1.215, /verify only runs when you invoke it. For Kiosque: /run-skill-generator once, then /verify closes every PR.

The IDE, the web, and the browser​

Three surfaces extend Claude Code beyond the terminal:

  • VS Code. The extension brings a graphical panel, plan review before approval, @-mentions with a line range (Option+K / Alt+K inserts @file#L5-L10), history and parallel tabs. Cmd+Esc / Ctrl+Esc toggles between editor and prompt. The selection is sent automatically — to exclude it on a sensitive file, add a Read deny rule. From an external terminal, /ide connects Claude Code to the open IDE.
  • JetBrains (IntelliJ, PyCharm, WebStorm, GoLand…). The Claude Code [Beta] plugin launches claude in the integrated terminal, opens diffs in the native viewer, shares the selection, and reads diagnostics through mcp__ide__getDiagnostics. Shortcuts: Cmd+Esc / Ctrl+Esc, Cmd+Option+K / Alt+Ctrl+K to insert @src/auth.ts#L1-99. In acceptEdits mode, stay cautious: the plugin can modify IDE configuration files that execute automatically.
  • Claude Code on the web. claude --cloud "…" creates a cloud session that clones the current branch from the GitHub remote — push your commits first. --teleport or /teleport (alias /tp) brings a cloud session back to the terminal after checks (clean git, same repo, pushed branch, same claude.ai account). /remote-control (alias /rc) exposes the local session for driving from claude.ai or the mobile app. Do not confuse the two: --cloud creates in the cloud, --remote-control exposes locally.

To test the Kiosque frontend, /chrome connects Claude to Chrome, Edge, or a Chromium-based browser (Brave, Arc, Vivaldi, Opera) through the Claude in Chrome 1.0.36+ extension. Direct launch with claude --chrome, permanent activation through /chrome > Enabled by default. Signed in with /login on a direct plan — third-party providers and WSL excluded. In plan mode, read-only calls go through without confirmation; click, input, navigation, and GIF recording require approval.

Frequent pitfall: the "unanchored" review​

A too-open review (/code-review with no level, no target, on a huge diff) is expensive and produces many nits that do not match the project. Two moves: anchor with an explicit level (/code-review high the first time on a PR, to set the baseline); frame with REVIEW.md at the root on the managed side — recalibrate severity, cap nits at five per review, exclude what CI already enforces, require convergence after the first review ("only post Importants from now on").

Summary​

  • An executable check closes the loop: tests, build, lint, screenshot — the difference between a session you watch and one you let run.
  • The triptych explore, plan, code avoids solving the wrong problem; plan mode is useful when scope is fuzzy, useless for a typo.
  • The root cause must be requested explicitly in the bug prompt, otherwise Claude wraps a try/except around the symptom.
  • /code-review is the local reference; /simplify cleans up without looking for bugs; ultra takes it to the cloud; the managed service posts severity-classified comments in research preview.
  • /autofix-pr delegates PR maintenance to the cloud, gh and the Claude GitHub app required.
  • The IDE, web, and Chrome surfaces extend the CLI: /ide connects the editor, --cloud and /teleport move a session between local and cloud, /chrome tests the frontend for real.

Next module: Headless mode, GitHub Actions CI, and the Agent SDK — pulling Claude out of the terminal to make it work overnight, in Actions, and in Python.