A small museum uses an internal web page to import its collection inventory. A maintainer asks Claude Code to fix an importer that counts a blank CSV row as a valid object. Each session begins with another explanation of the directories and a large log paste, then ends with questions about which checks actually ran. Improve the complete path from the request to a reviewable result. Use fictional collection records and a practice branch to compare project configuration, context selection and engineering method on one observable defect.
Establish a comparable task
Create a CSV containing three valid objects, one blank row and a record missing its identifier. Confirm the contract with the inventory owner: skip the blank row, report the missing identifier and show three valid objects. Preserve the build, input revision, import settings and observed count. Run the investigation once with the current workflow and note time spent locating files, supplying missing context, checking the repair and correcting mistakes. Include human review and rework in the elapsed time. A faster first answer can leave more work for the next maintainer.
For a comparison, restore the same starting branch and fixture and keep the acceptance conditions unchanged. Record the model configuration, tools and available usage indicators with their measurement source. Note existing context, caching and network variation. A single faster trial is an observation about that run, not a prediction for all projects. Repeated trials can also become easier because the investigator knows the answer. Compare correctness and handoff quality alongside elapsed time and usage.
Configure around stable project facts
Map the actual parser, preview component and test entry point. Verify the startup and check commands against the current files before recording them. Use the current Claude Code memory documentation to choose the scope of project instructions. Keep enduring rules concise: where fixtures live, what an accepted import means, which files may change and how a contributor verifies the result. Put a long procedure in a document or skill that can be read when needed and leave a clear entry point in the project instructions. Incident-specific logs belong with the incident.
Start a fresh practice session and ask the assistant to identify the applicable rules and trace the import path. Compare its answer with the current source. If it uses an obsolete command, establish whether the project note is outdated, the expected scope failed to load or another instruction conflicts with it. Update the responsible material and replay the same small task. Preserve the configuration revision so the next comparison has an identifiable starting point.
Enable integrations for a demonstrated need. When a service or interface is required, identify its destination, access scope, credential mechanism and data handling. Trial a read-only request in the isolated environment and inspect whether the returned information helps the investigation. Read setup scripts before they install dependencies or configure authentication, and preserve a restoration method. A configuration guide can explain an option, but its recommendation is separate from evidence that this machine successfully applied it.
Make each context item answer a question
Prepare an evidence card: three valid objects expected, four reported, five synthetic input rows, the parser entry point and a relevant test location. Ask where the blank row enters the valid-object count. Follow parsing, filtering and counting before expanding into unrelated code. Provide a few events from the same request with a request identifier and field definitions. Keep the full log at a known local location and retrieve a specific section when an observation calls for it. This preserves the route back to evidence without making every turn process the entire file.
For a handoff, record the confirmed causal chain, current diff, executed commands, useful output locations and open questions. A new session should inspect the working tree and replay a critical observation before continuing. Summaries can omit important details, so an assertion must still point to the fixture or source that supports it. If a shorter context repeatedly leads to the wrong entry point, restore the missing call relationship. Reducing irrelevant input should preserve the facts needed to make the decision.
Use local processing for verbose deterministic output. Extract failing test names, the first relevant error and the original log location before asking the model to interpret the failure. Preserve the raw output in case the summary hides an earlier cause. A repeatable helper should return an explicit status and a traceable artifact. A separate investigation can keep its own limited context, but extra calls, integration and conflict resolution have a cost. Measure their effect on the entire task rather than counting simultaneous sessions.
Repair through a failing example
Write a check that detects the historical defect. Assert the valid count, skipped blank row and missing-identifier error. Locate the responsible filtering or counting boundary and change the implementation that owns it. A check that only asserts a successful request does not establish the intended count. Replay the same fixture against old and repaired behavior, preserving the failure and pass. Add an ordinary file, a file containing only blank rows and representative newline variations. Confirm that reported row numbers still help the user find the invalid source record.
After the parser change, use Webapp Testing for the import-preview browser regression. The verified listing describes Python and Playwright against a running local app, producing scripts, screenshots and browser logs. Supply app startup instructions, the synthetic file and expected counts. Exercise the preview, missing-identifier message and retry behavior. Keep parser boundary assertions in the project test suite. A browser pass supports only the scenario exercised. Prepare the browser dependencies and review script access and destinations before execution.
Have a reviewer relate the diff to the proven cause, check whether the fixture detects the old behavior and examine adjacent behavior that should remain stable. Package the task contract, repair location, executed checks, page evidence and unavailable checks. Ask another maintainer to reproduce the critical result from that package. Only then capture the stable procedure for reuse. Add lasting project rules to the project instructions while keeping temporary diagnostic material in the incident record.
Choose documentation or scripts by the needed artifact
A documentation-oriented capability can help organize configuration choices and task cards. Its advice should point to the host contract and facts from this project. A script-oriented capability can generate a recurring fixture or run a fixed check consistently, provided its dependencies, input format and side effects fit the environment. Trial a labeled example and record the pinned source version. Replay the example after an upgrade and inspect changed behavior before adopting it. Similar names do not establish interchangeable scope.
Common questions
Which improvement should come first?
Use the baseline to find repeated rework. Missing entry points call for a clearer project map. Changing expectations call for agreement on acceptance. An unreliable test startup calls for environment repair. Choose the next action from those observations and repeat the task to assess it.
Does lower usage prove higher productivity?
Check correctness, human review and omissions as well. Less input can reduce calls while increasing a wrong repair or missed test. Compare the same input and acceptance conditions, record the metric source and include total delivery time and measurement limits.
Should prompts or skills come first?
Define the immediate goal, scope and acceptance conditions first. Capture a repeated, stable process in a skill when that becomes useful. The skill still needs this task's data, revision and constraints; it cannot supply a missing business rule.
How soon should benefits appear, and do download counts help?
There is no universal period. Compare complete handoff time and rework over similar tasks. A download count describes activity under a particular platform's definition and date. It does not establish fit for the museum importer or replace a labeled trial.