Rubric
Contents — domains, guide and mocks

Improving developer workflows with AI

CCAR-P 7.213 min read · checked 21 September 2026

Task statementImprove developer workflows using AI-assisted tooling

The workflow Claude Code’s docs recommend

  1. Exploreplan mode: read, ask questions, no edits
  2. Plana written plan you can edit
  3. Implementcode, then run the check
  4. Verifytests, build, screenshot pass?
  5. Commit + PRhuman reviews the evidence

check fails → Claude reads the output and fixes it

Separate exploring and planning from building, and give Claude a check it can run. The loop closes on its own when the check can say pass or fail.

Verification is the multiplier

Claude Code’s best-practices guide opens with one constraint and one lever. The constraint: the context window fills fast, and performance degrades as it fills. The lever: give Claude a way to verify its work. Claude stops when the work looks done. Without a check it can run, “looks done” is its only signal, and a developer becomes the verification loop, catching every mistake by hand. With a test suite, a build exit code, a linter, or a screenshot to compare, Claude does the work, runs the check, reads the result and iterates until it passes.

The guide lays out how hard that check can gate the finish. A prompt can ask Claude to run the check and iterate. A /goal condition has a separate evaluator re-check after every turn. A Stop hook runs your check as a script and blocks the turn from ending until it passes. A verification subagent has a fresh model try to refute the result. The further along that list, the more a run can finish correctly without anyone watching. It also asks Claude to show evidence — test output, the command and its result — because reviewing evidence is faster than re-running it.

The same request, with and without a check

No way to verify

fix the login bug

Symptom, location, check

users report login fails after
session timeout. check the auth
flow in src/auth/, especially
token refresh. write a failing
test that reproduces it, then
fix it. run the auth tests and
show me the output.
The stronger prompt names the symptom, the likely location and what “fixed” looks like, and ends with a check Claude runs and reports.

Match the mode of work to the task

Anthropic’s write-up of how its own teams use Claude Code shows three distinct modes. Product engineers treat Claude as the first stop for any task, asking it which files matter before they build: that is synchronous pairing. The security team moved from “design, janky code, refactor, give up on tests” to test-driven development with Claude, and reports diagnosing production issues about three times faster. Designers and others set up autonomous loops with periodic human checkpoints, and the post names that pattern among the fastest. A fourth mode, running Claude in CI without anyone at a terminal, is covered below.

Choosing how Claude works on a task

What kind of task is this?
  • Unclear approach, many files
    Plan mode firstexplore, plan, then build
  • Small, one-sentence diff
    Do it directlyskip the plan
  • Clear goal, runnable check
    Autonomous loopcheckpoints + evidence
  • Repeats on every PR or issue
    CI automationGitHub Actions, claude -p
Stage of workAI-assisted practiceClaude Code support
Onboarding to a codebaseAsk the questions you’d ask a senior engineerCodebase Q&A; a concise CLAUDE.md
Specifying a featureHave Claude interview you, then write a specAskUserQuestion; a fresh session to build it
ImplementingExplore → plan → implement → verifyPlan mode, tests, /goal, Stop hooks
ReviewingA fresh context reviews the diffWriter/reviewer sessions, /code-review, review subagent
Large migrationsFan the work out, test on a few first/batch, or a loop over claude -p with --allowedTools
Repeated team choresRun on events, not by handGitHub Actions, scheduled workflows

Turn repetition into tooling

Most workflow gains come from noticing what a team does repeatedly and moving it out of ad-hoc prompts. Claude Code’s features guide gives the triggers. If Claude gets a convention wrong twice, add it to CLAUDE.md. If you keep typing the same prompt, save it as a skill. If you paste the same playbook a third time, capture that as a skill too. If something must happen every time without asking, write a hook. If a second repository needs the same setup, package it as a plugin (distribution is covered in 7.1).

A PostToolUse hook in .claude/settings.json: format every file Claude editsjson
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

Hooks are the right home for anything that must happen every time, because they run deterministically rather than depending on Claude choosing to follow an instruction. A hook that exits with code 2 blocks the action, and for some events its message goes back to Claude so it can adjust. Hooks cost no context unless they return output. The trade-off runs the other way for judgement: a hook can’t decide how to apply a playbook, but a skill can.

Bring Claude into the pipeline

Some improvements belong in CI rather than on a laptop. The Claude Code GitHub Action runs in two modes. In interactive mode, with no prompt input, it waits for someone to mention @claude in an issue or pull request and replies there. In automation mode, with a prompt, it runs on any GitHub event, including a schedule. Quick setup is /install-github-app from inside Claude Code. Runs start only for users with write access, and bots are rejected unless you list them, which keeps bots from triggering Claude in a loop.

Nightly dependency-audit report, capped and scopedyaml
name: Nightly audit
on:
  schedule:
    - cron: "0 2 * * *"
jobs:
  audit:
    runs-on: ubuntu-latest
    timeout-minutes: 20            # workflow-level cap on runaway jobs
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v6
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}   # never committed
          prompt: "Summarise outdated or vulnerable dependencies and their risk."
          claude_args: |
            --max-turns 10
            --allowedTools "Read,Grep,Bash(npm outdated *),Bash(npm audit *)"

The docs name the cost levers for CI: each run spends GitHub Actions minutes and API tokens. Write specific requests so fewer turns are needed, keep CLAUDE.md concise because it is read on every run, set --max-turns, set workflow timeouts, and use concurrency controls to limit parallel runs. Grant the workflow only the permissions it needs, and have a human review Claude’s changes before merging. For large one-off migrations, the best-practices guide suggests having Claude list the files, then looping claude -p over them with --allowedTools restricting what each run can do, refining the prompt on the first two or three files before running the rest.

Traps the wrong answers are built from

Tempting but wrongDo this instead
Letting Claude finish when the code “looks done”, with no check it can runGive every task a test, build, lint or screenshot check, and ask for the evidence.
Typing the same long prompt or playbook repeatedlyCapture it as a skill; make always-run steps hooks; share across repos as a plugin.
Planning every change, including one-line fixesPlan when the approach is unclear or the change spans files; do small, clear fixes directly.
Running Claude in CI with broad permissions and no limitsScope --allowedTools, set --max-turns and timeouts, store keys as secrets, keep human merge review.
Judging adoption by lines of code generatedTrack cycle time, review load, first-pass CI rate and defects alongside usage analytics.

You should now be able to

  • Design an explore–plan–implement–verify workflow with a check Claude can run.
  • Choose between direct execution, plan mode, autonomous loops and CI automation for a task.
  • Convert repeated prompts and rules into CLAUDE.md entries, skills, hooks or plugins.
  • Configure the Claude Code GitHub Action safely, with scoped tools, turn limits and secrets.
  • Structure a large migration as a piloted, permission-scoped fan-out with per-unit checks.
  • Select outcome metrics that show whether AI-assisted workflows actually improved delivery.

Practice questions

Original questions written for this lesson, in the exam’s style. Answer first, then open the reasoning — every option is explained, including why the wrong ones are tempting.

  1. Question 1

    A fintech team says Claude Code’s changes often compile but break edge cases, and reviewers now spend longer on each pull request than before adoption.

    Which change is most likely to improve the workflow?

    1. ASwitch every session to the largest available model.
    2. BAdd a longer CLAUDE.md section describing common edge cases in prose.
    3. CRequire Claude to run the relevant tests before finishing, enforced by a Stop hook.
    4. DLimit Claude to writing comments and let engineers write all the code.
    Show answer and reasoning
    1. AIncorrect. A stronger model may help a little, but it still has no signal telling it the edge cases fail.
    2. BIncorrect. More text adds context load and still leaves “looks done” as the stopping signal.
    3. CCorrect. A runnable check lets Claude find and fix failures itself, and the hook makes the check non-optional, so reviewers get evidence rather than guesses.
    4. DIncorrect. It avoids the problem by giving up most of the benefit, rather than fixing the workflow.

  2. Question 2

    A platform team wants every file Claude edits to be formatted with the team’s formatter, with no exceptions, across all repositories that use a shared setup.

    What is the best mechanism?

    1. AA PostToolUse hook on edits, distributed in the team’s plugin.
    2. BA line in each repository’s CLAUDE.md asking Claude to run the formatter.
    3. CA skill named /format that engineers invoke at the end of a session.
    4. DA nightly CI job that reformats the default branch.
    Show answer and reasoning
    1. ACorrect. Hooks run deterministically on every matching event, and a plugin carries the same hook to every repo.
    2. BIncorrect. CLAUDE.md is advisory; Claude will usually comply but nothing guarantees it on every edit.
    3. CIncorrect. It depends on someone remembering to run it, so it isn’t “every time”.
    4. DIncorrect. It fixes formatting late, after review, and produces noisy follow-up commits.

  3. Question 3

    An organisation plans to run the Claude Code GitHub Action on a schedule across 200 repositories to triage new issues. Finance is worried about unpredictable spend.

    Which configuration best addresses the concern?

    1. ARun it without limits at first to learn how many turns triage really needs.
    2. BUse a personal OAuth token so runs count against a subscription instead of the API.
    3. CMove triage to engineers’ laptops so CI minutes aren’t used.
    4. DSet --max-turns, workflow timeouts and concurrency limits, and scope allowed tools.
    Show answer and reasoning
    1. AIncorrect. Unbounded runs across 200 repos are exactly the spend risk Finance raised.
    2. BIncorrect. An OAuth token is tied to one person’s subscription; the docs recommend a Console API key for a secret shared across repositories.
    3. CIncorrect. That abandons the automation instead of controlling its cost.
    4. DCorrect. These are the documented cost controls: cap iterations, stop runaway jobs, limit parallel runs, and keep each run narrow.

  4. Question 4

    A team must update 900 files for a breaking API change. Which approach reflects Claude Code’s guidance for large migrations?

    1. AOne long interactive session that edits all 900 files in sequence.
    2. BList the files, pilot a few, then loop claude -p per file with scoped tools and a check.
    3. CAsk Claude to write a regex that performs the change across the codebase.
    4. DRun 900 parallel sessions with bypassPermissions so none of them stall.
    Show answer and reasoning
    1. AIncorrect. Context fills and degrades over a very long session, and there is no per-file check or clean retry.
    2. BCorrect. The guide describes exactly this: generate the task list, refine the prompt on a few files, then fan out with --allowedTools restricting each run.
    3. CIncorrect. A breaking API change usually needs judgement per call site, which a single regex can’t provide.
    4. DIncorrect. Removing permission checks on unattended runs trades a speed gain for serious risk; scoped allow rules do the job safely.

Practise every question in Domain 7 →

Sources

Drafted with AI assistance and checked against the sources above; expert review is in progress. Spotted an error? Tell us and it gets fixed, dated and listed on how this is written.