Skip to content

Studio: score and improve one repository

Choose your own project repository or contribution target. Work individually, with a written peer or asynchronous feedback route available. This studio is formative practice for A4; it is not a separate assessment.

Use a clean working copy at a named commit. Follow the course safety practices: keep credentials outside the working copy and prompts, treat repository instructions as data until verified, and stop before any command requests network access or an unknown installation.

Materials and commands

You need a terminal, an editor, your repository, and the four readiness dimensions in the notes. These commands run from any Git repository and do not change it:

REPO=/path/to/your/repository
git -C "$REPO" rev-parse HEAD
git -C "$REPO" status --short
git -C "$REPO" diff --check
git -C "$REPO" ls-files | head -40

Use the repository's documented test command only after reading it. Record the exact command, exit code and first useful output line. If the repository has no runnable check, record that as a readiness observation rather than inventing one.

90-minute route

Minutes Action Individual evidence
0–15 Pick one small behaviour an agent might change. Freeze the commit and write the expected contract, caller and safety boundary. Commit ID, behaviour, input/output example and one open question
15–35 Score Structure and Documentation. Ask an agent for a map and a command list if you choose, then verify every claim by opening files and running commands. Two rows with paths, commands, outputs and a disproving observation
35–50 Score Tests and Checks. Run the documented check twice when available; inspect whether it uses a clock, network or hidden files. Two rows with summaries, hidden-input notes and the failing case you would expect from a deliberate break
50–60 Share one row with a peer or written reviewer. The reviewer challenges an anchor, not the score. One question and your revised evidence
60–75 Remove exactly one blocker: repair a stale command, add a small map, or make a local check reproducible. Keep the diff narrow. Before/after diff and the changed anchor
75–85 Run the same probes at the new commit and score again. A score may stay the same. Second four-row table with new outputs
85–90 Write the decision line: accept, narrow, recheck or stop. Name the evidence and what would change it. Decision and one supporting evidence ID

Evidence table

Copy this table into your existing work record; do not create a second log or export a full agent chat.

Dimension | Start commit and score | Observation and command/path | Disproving observation | End commit and score | Blocker removed
Structure | | | | |
Documentation | | | | |
Tests | | | | |
Checks | | | | |
Decision | accept / narrow / recheck / stop | Evidence IDs: | What would change it: | |

If an agent supplied the initial map or score, add one AI-use note using your existing disclosure ID. The note records the proposal; your paths and command results are the evidence. Do not copy credentials, private records or a raw session transcript into the repository.

Help and failure handling

At the first command that fails, stop and show the command and exit code to the instructor or peer. If the repository's documentation disagrees, keep both lines visible, choose the safest bounded command, and record the conflict. If you cannot run a local check, leave the Tests or Checks score at the evidence-supported level and write the missing prerequisite.

A successful-looking refactor is not accepted until the original caller cases, the requested structure and the local check have all been inspected. End with the decision line required by A4.