The conversation produced a useful revision to a job description. A month later, the manager wants another update. Nobody can identify which process note supported the new responsibility, whether an unresolved suggestion was included, or which version of the original description was used. Repeating the prompt will produce more text. It will not recover the missing decisions.
This is a suitable task to move into a controlled file workflow. Keep the judgement about the job with HR and the responsible manager. Give Claude Code the narrower job of comparing specified documents and preparing proposed edits. The value is a change another person can inspect and reproduce, with disagreements still visible.
The example here concerns a fictional operations coordinator in a private Australian business. Every source note, proposed sentence and review result is constructed. No Claude run was performed for this article. The walkthrough describes a proposed exercise and its acceptance cases; it makes no claim about speed, success rate or observed product performance.
Transfer the decisions before transferring the files
Start by asking what made the earlier chat useful. Perhaps it separated an approved change from an unsupported management suggestion. Perhaps it preserved the role's existing approval boundary. Capture those rules explicitly. Do not copy the entire conversation into the project and assume its length will preserve the important distinctions.
Write a task contract in ordinary language. It names the document being maintained, the sources allowed to justify changes and the output the reviewer needs. It also states what the assistant cannot decide. In this example, it cannot add supervisory authority, change qualifications, determine classification or imply employee agreement. Those matters are outside the editing assignment.
A good transfer test is whether a colleague could read the contract and explain a correct result. If the instruction is merely "update the job description to reflect our new workflow", it is incomplete. Which workflow version applies? Which duties changed? What remains disputed? Resolve those questions before turning them into files and commands.
Keep the source of authority distinct from the source of wording. A chat may contain a helpful proposed sentence, but that does not make the underlying responsibility approved. Use the earlier sentence as a drafting example only. The approved process record must still support the responsibility when the new run begins.
Choose the current Code surface deliberately
Anthropic's Claude Code documentation, checked on 24 October 2026, describes Claude Code as the Code tab in the Claude Desktop app. Chat and Cowork sit beside it and are being combined into one conversation in a staged rollout, while the Code tab stays in place. The Code tab supports project folders, permission modes and a visual diff view. Moving into Claude Code can therefore mean opening a Code session in the desktop app; it does not necessarily require starting in a terminal. Claude Code desktop documentation.
The same documentation provides macOS and Windows downloads and a Linux beta for Ubuntu and Debian, and platform details can change. Confirm the installed version, a paid Pro, Max, Team or Enterprise plan, and organisation settings before using a detailed guide. Menu wording is version-sensitive. Record the app version, operating system, plan and permission mode actually used, rather than treating this article's schematics as proof of current availability.
Select a local demonstration folder in the Code session and check the environment shown before submitting the task. The current documentation separates environment selection from project-folder selection. That distinction matters: a familiar folder name does not prove that work is running in the place you expect. The exercise needs a bounded local folder, not a connected production repository.
Begin by requesting a plan without document edits. Anthropic documents Plan and other permission modes, but the available choices depend on the current interface and configuration. Read their descriptions in the installed app. For this exercise, check the mode selector before sending, because Auto and Accept edits apply file changes without asking. Use Plan for the first request and Manual for the edit round, and withhold external actions. Do not broaden access to make an unexpected prompt disappear.
Build a small source packet
The source packet has three parts. The first is the current fictional job description, version one. It says the operations coordinator prepares a weekly service summary from approved records and submits it to the operations manager. The manager remains responsible for approving the summary before circulation. These clauses establish both work and authority.
The second source is an approved process change, PC-01. It replaces manual collation with an approved summary tool and adds a requirement to check each draft statement against the source register. It also requires discrepancies to be recorded for the manager. Approval of this fictional process change supports preparing a role-description proposal; it does not establish employee consultation or contractual agreement.
The third source is a manager's unconfirmed note, MN-01: "Could the coordinator approve the final summary and supervise the temporary team?" Keep that note available to the comparison task, clearly labelled unapproved. Excluding it entirely would hide a real question from reviewers. Allowing it to authorise wording would quietly expand the role.
Use plain Markdown files for the teaching exercise so readers can compare them without specialist document software. Separate the original inputs from generated proposals. Preserve the baseline and put each run's output in its own identified folder. This is a recommended folder convention, not a requirement imposed by Claude Code or a substitute for access controls.
Keep real employment records out of the demonstration. A file stored on the computer may still be supplied to a cloud model when the assistant reads it. Folder selection alone does not determine confidentiality, retention or processing terms. In actual work, the organisation must settle those matters before an approved tool receives employee or commercially sensitive information.
Proposed task folder
Ask for one bounded document change
The first run should produce a proposal, not replace the current job description. Ask for a clause-by-clause comparison and a proposed revision limited to the specified responsibilities section. Require the assistant to preserve every other section. Broad instructions to improve clarity throughout the document can conceal substantive changes inside an otherwise helpful rewrite.
For each proposed edit, require the old wording, new wording, source identifier and short reason. References need enough precision to find the supporting passage. A filename alone may be insufficient when the document contains several decisions. In this small example, PC-01 paragraph two can support the checking duty while the baseline approval clause preserves the manager's authority.
Require a separate unresolved record for MN-01. It should describe the proposed approval and supervision changes without adding them to the revised role. It should also say which decision is missing. "Needs review" is weaker than "No approved source authorises final approval or supervision responsibilities" because the latter tells the reviewer exactly what to resolve.
Keep the requested output modest. There is no need to connect an HR platform, convert every historic description, install a document-generation package or publish a shared template. A small text change and its evidence record are enough to establish the method. Integration can be considered later if repeated use demonstrates a worthwhile need.
Review the edit that looks reasonable
The constructed proposed sentence reads: "Prepare the weekly service summary using the approved summary tool and check each draft statement against the source register. Record discrepancies for the operations manager and submit the summary to that manager for approval." It traces to PC-01 for the changed method and to the baseline for the retained submission duty. A reviewer can compare the action verbs with the approved process instead of judging only the sentence's fluency.
Now consider an attractive but unsupported alternative: "Own the weekly reporting process, approve final summaries and supervise the temporary team." It sounds concise and senior. It also imports MN-01 as if a decision had been made and expands "prepare" into "own". Reject that wording. A polished rewrite is still wrong when its verbs create authority the sources do not provide.
Inspect the full changed file as well as the highlighted differences. A comparison view helps locate edits, but the surrounding clauses show whether the whole description remains coherent. A correct new checking duty could sit beside an unchanged instruction that still assumes manual collation. Ask the reviewer to resolve that inconsistency explicitly rather than allowing the assistant to tidy it silently.
Anthropic documents a diff view for reviewing changes in the Code tab. Use it to inspect changed lines, then inspect the saved proposal itself. AI code-review features are not HR approval processes, and a clean technical review cannot determine whether a duty is appropriate. The reviewer must understand the role and the source authority behind its proposed changes.
Define what a passing editing run would show
The first acceptance case checks the supported edit. The proposal must include checking draft statements against source records and recording discrepancies, with PC-01 identified as its source. The second checks the boundary: the coordinator still submits the summary to the operations manager, who retains final approval. The third checks unsupported additions: neither team supervision nor new approval authority appears in accepted wording.
A fourth case compares untouched sections against the baseline. If the assistant rewrites qualifications or reporting lines, the run fails the agreed scope even if the change sounds beneficial. A fifth confirms that MN-01 appears in the unresolved record. This tests whether the workflow preserves an open issue instead of resolving it by omission.
Add a missing-input case before using the workflow repeatedly. Remove the approved-change document from a copy of the future test packet and require the process to stop the dependent edit. The expected response is to identify the missing source. It must not reconstruct the change from an old chat, a previous output or a plausible guess about normal practice.
These are proposed cases, not performed tests. A later reviewer records the input versions, observed result, supporting file and decision for each case. If a check was not performed, mark it "Not run". A generated statement that everything was verified is insufficient unless the reviewer can see what was compared and how the conclusion followed.
Give a rejected run a clear disposition. Preserve its proposal and the review finding in the demonstration record, then ask for a corrected proposal under a new run identifier. Do not overwrite the rejected output and leave the record saying only "fixed". The original defect explains why the instruction changed and gives the next reviewer something specific to check.
When the error involves meaning rather than formatting, correct the task rule as well as the sentence. If "prepare" became "approve", add an explicit check that every authority-bearing verb has support. A one-off wording correction may repair today's document while leaving the next run vulnerable to the same inference. This is where a repeatable file workflow becomes more useful than repeatedly editing a chat answer.
Repeat without carrying yesterday's uncertainty forward
Once a proposed revision has received the appropriate human decisions, the document owner establishes the next authorised baseline. A later editing run must use that baseline deliberately. Do not let the assistant select whichever file has the newest timestamp. A more recently generated proposal may still be unapproved, and an older approved document may remain authoritative.
Keep the editing instructions separate from the changing source packet. The stable rules describe scope, evidence and output format. The new packet provides the next approved change and any unresolved suggestions. This separation helps a reviewer understand whether a different result comes from changed evidence or changed instructions. It also makes corrections easier to apply consistently.
A repeat run should not create the same new duty twice. Include a proposed check using the already revised baseline and the same approved change. The expected outcome is no further substantive edit, with an explanation that the requirement is already represented. This is a useful repeatability test because duplication can make a role description slowly inflate across otherwise successful runs.
The final handover states what the editing workflow achieved and what remains for HR. Fair Work Ombudsman guidance treats award classification as a question involving duties and other applicable criteria. A document edit does not settle that question. If responsibilities change, the relevant person must assess the applicable instrument and employment arrangements separately. Fair Work Ombudsman: award classifications.
For the next exercise, choose one fictional responsibility and one approved source change. Transfer the task contract, prepare a proposed revision and inspect every changed verb. Then give a colleague the source packet and the review record. If that colleague can explain both the accepted wording and the rejected addition, the task has become repeatable enough to evaluate properly.
Copyable run prompt
Controlled document-maintenance exercise
Constructed teaching packet only. No Claude Code task or acceptance test has been run with this packet. Use it only in a practice folder whose boundaries have been confirmed.
Folder specification
Inputs remain unchanged. A new run receives a new output location. No live HR records, personal data, installations, external writes or connected systems. Local storage alone does not establish cloud-processing boundaries.
Three copyable fictional inputs
role-v1.md
approved-change-PC-01.md
unconfirmed-note-MN-01.md
Repeatable run prompt
Constructed expected edit and rejected addition
Proposed R1: Prepare the weekly service summary using the approved summary tool and check each draft statement against the source register. Record discrepancies for the operations manager and submit the summary to that manager for approval.
Trace: PC-01 paragraphs 1 and 2 support the changed method; baseline R1 preserves submission. A1 remains unchanged, supported by the baseline authority clause and PC-01 paragraph 3.
Rejected addition: Approve final summaries and supervise the temporary team. Reason: MN-01 contains a question, with no approval evidence. Rejection is an authored teaching example, not an observed model failure.
Proposed acceptance cases
Verification template
Related reading
Gold Standard Claude Workspace Setup explains the broader context architecture. This exercise adds a specific source packet, controlled proposed edit and repeatability checks. Check current vendor documentation for product details in that earlier guide.
For setting up Claude Desktop and the Code tab step by step, with real screenshots, see Getting Started with Claude: A Plain-English Setup Guide.
Also see When the Work Changes, Update the Job Description, the companion article for 10 November.
References
- Anthropic: Claude Code desktop documentation
- Fair Work Ombudsman: award classifications
- Anthropic: Claude Code desktop quickstart
- Anthropic: Claude Code permission modes
- Anthropic: Claude Desktop on Linux (beta)
- Anthropic: Claude Cowork and chat are one Claude
- Anthropic: Claude Code data usage
General information only. Not legal, compliance, financial, or professional advice.
TheAICommand. Intelligence, At Your Command.
