What do you want to accomplish?

Example: add CSV export. You want to open selected project activity in a spreadsheet without copying rows. Start by agreeing which rows and columns belong in the export and what must stay unchanged.

You leave with: a saved draft request with scope, success criteria and a human review point.

Start with this prompt

Copy this into your coding assistant, with your project open:

Help me turn this feature idea into a clear work request: add CSV export to the activity report so I can use selected rows in a spreadsheet.

Inspect the existing project first. Reuse its visibility rules and filters. Ask about consequential gaps, including columns, empty results, formula-like text and overwriting files. Recommend an option and explain its tradeoffs when I need to choose.

Use attune-harness to save a draft with the goal, exact file scope, context, constraints and observable success criteria. Show me the resulting request and the current review point. Stop before approving the request, changing app files or calling paid participants.

From idea to a request you can review

1. Describe the useful result. “I want the activity I can already see exported to a spreadsheet.” Your assistant inspects the app before suggesting file scope. This example uses a synthetic local CLI; its user identity and visibility rules simulate access control.
2. Settle the decisions that affect the result. In the example, export the same visible rows as the list, keep its filters, use seven named columns and produce headers only when nothing matches. Choose the formula-text policy and refuse to replace an existing file. The assistant prepares the relevant questions; Harness does not discover unrecorded requirements by itself.
3. Fill in the current form and save answers. The assistant prepares a saved draft and opens its local Harness form. Answer in ordinary language. Saving keeps an unapproved draft; if answers are incomplete, the next current form asks what remains.
4. Review the whole request before deciding. Check the goal, success criteria, exact files, constraints and recorded answers together. Change a mistaken answer or ask the assistant to revise scope before approving. Review the refreshed request after any revision.

The resulting work request

Expect a saved request with its revision, current checkpoint and any remaining questions or a review screen. Your answers carry into that review. Here is the actual saved example, presented as readable text.

This formula policy deliberately changes some exported text. Review whether that tradeoff fits your spreadsheet workflow; it is not a guarantee for every spreadsheet application.

How to review this request

• Follow a real selection. Can you explain which rows a chosen user and filter should export? The existing tutorial uses viewer + atlas + review + October 11–12, 2026, with records a-0002 and a-0004. Treat that as a proposed check, not a result from this intake.
• Read the edge cases. Confirm column order, an empty export, Unicode, commas, quotes and multiline text. Ask for concrete ordering and filter/date rules before implementation if “stable order” or “same filters” leaves room for disagreement.
• Check the boundary. Are these the right files, and is the fixture protected? The request should preserve existing visibility rules and refuse overwrites. A request being ready for review does not prove those behaviors work.

What your assistant does, and what Harness adds

Your coding assistant can discuss an idea, inspect code using its available tools, ask questions and draft a request. With authorization it can also edit files and run checks. Those are assistant capabilities; installing Harness does not create them.

Attune Harness adds a saved, structured request; forms driven by that saved state; revision and checkpoint binding; and an explicit intent decision. It selects prompt, XML or spec from work facts supplied by the host. For separately prepared and authorized execution, its plan/build workflow can retain bounded effects and check evidence. This local forms interface handles intake and intent decisions; it has no build controls.

The starter prompt asks the assistant to use Harness. Its skill routes the request to the installed CLI. The demo’s deterministic participant is a placeholder and was never dispatched; no model-planning or model-building quality claim is established here.

Sources: 1.5.1 plan/build guide, the inspected 1.5.1 form and decision source, and the existing local CSV tutorial. Read the verification and limitations.

What if saving my request stops because a registry is missing?

Select an existing participant registry with --config. To create an offline demo registry, run init with --project naming your project directory. It creates participants.json in that directory.

When you retry plan, pass --config with the created file’s absolute path. For review, also pass that path when your working directory differs from the project or the failed command named another registry. Relative --config paths resolve from the command’s working directory; absolute paths are used directly. Creating a registry does not accept or execute work.

Keep existing registries and the original refusal for inspection. If no task was created, there is no saved task to inspect with status. Check path and task selections before continuing.

attune-harness plan --request REQUEST.json --project PROJECT \
  --config REGISTRY.json --task-dir TASK

# The installed Harness interpreter must run this module.
python -m attune_harness.gui --task /absolute/path/to/TASK --edit

attune-harness plan --task-dir TASK --decision
attune-harness status TASK

attune-harness init --project /absolute/path/to/csv-project
attune-harness plan --request /absolute/path/to/csv-project/request.json \
  --project /absolute/path/to/csv-project \
  --config /absolute/path/to/csv-project/participants.json \
  --task-dir /absolute/path/to/csv-plan-draft

Example: start with a local activity report and CSV export. Choose a complete useful journey before adding more surfaces or integrations.

You leave with: a concise first-version brief with in/out scope, assumptions and success criteria.

Start with this prompt

Help me choose a useful first version of a local activity-reporting app. The user wants to inspect project activity, filter it and export selected visible rows to a spreadsheet.

Inspect the existing project and CSV contract first. Recommend the smallest version that completes that user journey. Show what is in, what is out, the key assumptions, dependencies, risks and observable success criteria. Explain the consequence of postponing each optional feature. Ask me only about consequential gaps.

Write a short first-version brief in readable text. If Harness intake helps preserve the agreed scope, prepare a draft using the current supported request format. Do not invent file paths, assume production authentication, dispatch participants or start implementation. Show the decisions I need to make next.

Follow these steps

1. Name the complete user journey. In this example: choose a simulated user → list visible activity → narrow the selection → export it → inspect the CSV. A first version must let someone finish that journey.
2. Choose what makes that journey useful. Keep existing visibility/filter rules, stable order and the agreed seven-column CSV contract. Preserve Unicode and multiline text, the formula-text policy and refusal to overwrite an existing file.
3. Move independent features outside the first version. A web UI, cloud sync, production authentication and remote integrations are excluded here. Simulated identity cannot be described as production access control. If a real user needs a browser or shared access, revisit the first-version choice before proceeding.
4. Turn the scope into a short brief. Record intended user, useful result, in/out scope, assumptions and checks. Ask the assistant to connect each included feature to the user journey and expose unresolved choices.
5. Review the tradeoffs, then continue. Decide whether this local first version is useful enough. Carry the agreed brief into the project spec or, for a small feature, a work request.

User outcome: inspect visible synthetic project activity and take the selected rows into a spreadsheet.

IN: local CLI; simulated user selection; list; project/kind/date/search filters; CSV export using the established contract; clear empty-result and file-conflict behavior.
OUT: web UI; real authentication; remote data; cloud sync; production integrations; deployment.
ASSUMPTIONS: synthetic local data is appropriate; the user can use a CLI; a named spreadsheet/import configuration will be checked separately.
SUCCESS: list and export select the same visible rows; rows remain in date/ID order; columns and encoding match the contract; empty exports have headers only; no overwrite or source-data change.
DECISIONS: confirm that a local CLI serves this first version. Do not silently carry that assumption into a production app.

How to review the brief

• Can the intended user complete the whole journey with the included features?
• Does each inclusion support that outcome, and does every exclusion state the consequence?
• Are assumptions about identity, interface, data and spreadsheet behavior visible?

What your assistant does, and what Harness adds

Your assistant can inspect the project, compare scope options and draft the brief. You choose the product tradeoffs.

Harness can retain a structured request and its checkpoint when you choose to use intake. It has no dedicated automatic MVP selector; authoring format is selected from work facts supplied by the host.

# After the assistant prepares the actual request and registry:
attune-harness plan --request REQUEST.json --project PROJECT \
  --config REGISTRY.json --task-dir TASK
attune-harness plan --task-dir TASK --decision
attune-harness status TASK

You leave with: an initial spec and a proposed review copy with unresolved decisions visible. The spec and wording worksheet are illustrative; no successful live consultation is claimed.

Try the example: a small local app that lists project activity, applies filters and exports selected visible rows to CSV. Follow the filled example below, then prepare a review copy. You can also copy the prompts into your assistant for your own project.

Help me create a reviewable spec for a small local activity-reporting app with filters and CSV export.

Inspect BRIEF.md, CSV-CONTRACT-NOTES.md and the existing example first. Draft the user outcome, first-version scope, non-goals, workflow, data and access assumptions, numbered requirements, observable acceptance checks, task dependencies and unresolved decisions. Preserve the established CSV contract and distinguish simulated identity from production authentication.

Show me the initial spec in readable text. Recommend options for consequential choices and explain the tradeoffs. Stop before model consultations, implementation or approval. Tell me what needs my decision next.

# Local activity reporting app — initial spec v0.1

Status: host-authored initial draft for review. No roundtable has reviewed it; no implementation is approved.

## Outcome and scope

Let a person inspect, filter and export synthetic project activity through a small local command-line app. Use BRIEF.md for the product boundary and CSV-CONTRACT-NOTES.md for the established selection and file contract. The fixture's identity rules simulate access; they are not a production security system.

## Workflow

1. Select a simulated user and optionally project, kind, inclusive date range and summary search.
2. List the selected visible activity in stable order.
3. Export the same selection to a new CSV file.
4. Inspect the produced file and review retained check results before accepting implementation.

## Requirements

- R1: Validate the local input schema before presenting or exporting rows. Reject unknown users, duplicate IDs, invalid references, dates, types, negative minutes and disallowed control characters.
- R2: Apply the existing membership and row-restriction rules identically to list and export. Never include membership or restriction metadata as public report columns.
- R3: Intersect all active filters with the exact matching and inclusive date semantics in the existing contract; reject reversed date ranges.
- R4: Order selected rows by ascending date and activity ID without a hidden result limit.
- R5: Produce the seven ordered columns and CSV encoding, quoting, escaping and record endings specified in the existing contract. Preserve Unicode and multiline text through a CSV parser.
- R6: Apply the exact formula-text transformation to every text column in exports, keep minutes numeric and preserve literal text in list output. Make the transformation and importer limitations visible in user guidance.
- R7: Emit only headers for an empty visible selection, refuse overwrites, validate before creating output, clean up a partial new file after a write failure, and keep the fixture unchanged.
- R8: The same source, user and filters must produce identical CSV bytes. Expose the public exported row count without mixing diagnostics into CSV content.

## Acceptance checks

- AC1 (R1): Invalid fixture variants fail before an export file exists; unknown identity fails closed.
- AC2 (R2, R3): Independently assert selection parity and exclusions for memberships, null/named/empty restrictions, each filter and intersecting filters.
- AC3 (R3, R4): Exercise both date boundaries, a reversed range, Unicode-casefold summary search and order after changing input row order.
- AC4 (R5): Parse actual CLI-generated files and inspect bytes for exact columns, UTF-8/no BOM, quoting, escaped quotes, CRLF records and embedded line endings.
- AC5 (R6): Cover the named formula markers, fullwidth forms, leading whitespace/format characters and initial TAB/CR/LF in every text column; verify unchanged literal list output and typed minutes.
- AC6 (R7): Assert the exact header-only empty file, no overwrite, no file on invalid input and cleanup after an injected write failure.
- AC7 (R8): Compare repeated export bytes, source hashes and the separately reported public row count.
- AC8 (R2–R6): Use viewer/atlas/review/2026-10-11..2026-10-12 as a concrete two-row example; manually inspect Unicode, multiline and transformed text in the intended spreadsheet, recording the application/version and import settings. Do not generalize that check to every importer.

## Proposed task dependencies

- T1: Confirm the contract and fixture shape; prepare independent selection, CSV-byte and failure-case acceptance checks. Human settles any material changes to the contract first.
- T2, after T1: Implement shared validation and selection, then list and export behavior using standard-library runtime dependencies. Preserve the independent checks.
- T3, after T2: Execute the agreed checks, retain output and file evidence, write user guidance and conduct the bounded manual spreadsheet check.

This is a conceptual project plan, not a Harness build-ready task graph or frozen file-effect manifest. Before build acceptance, identify the exact output files, permitted effects and protected executable checks in a separate supported plan.

## Review questions and approvals

Are the requirements precise enough to test? Do the checks establish the user outcome rather than merely echo the implementation? Do the task dependencies preserve independent verification? Does the first version stay within the stated local scope?

The human reviews the revised spec and any consequential choices. Spec acceptance does not grant implementation, provider calls, publication or deployment. Model recommendations remain advisory and require source inspection.

Prepare an attune-harness roundtable review of this initial spec. Ask two explicitly selected, verified participants to assess user outcomes, ambiguities, implementation feasibility and independent acceptance checks. Require citations and the strongest counter-case for each proposed change. A no-change finding is acceptable.

Before any model call, show me the frozen source files, question, exact models, one-round/two-dispatch limit, actual billing route and verified usage controls. Stop if the agreed usage limits or model access cannot be established. Do not retry, substitute models or use a paid fallback without a new, explicit decision.

After a permitted run, retain actual successes and failures. Check the cited passages, separate optional advice from required corrections, and propose a finding-to-spec comparison. Keep human decisions open until I make them. Do not implement or publish anything.

Who does what?

• Human: defines the outcome, settles consequential tradeoffs and reviews the exact spec.
• AI / Human: inspect source passages, compare alternatives and turn supported advice into proposed wording.
• AI: drafts and reviews text using its native capabilities. Harness freezes selected inputs and configuration, binds the consultation to a digest, limits dispatches and retains outcomes. It does not supply model availability, correct advice, billing controls or spec acceptance.

attune-harness roundtable check --config CONFIG.json
attune-harness roundtable prepare --project PROJECT --path BRIEF.md \
  --path SPEC-INITIAL.md --config CONFIG.json --run-dir NEW_RUN
attune-harness roundtable status RUN --format markdown
attune-harness roundtable evidence RUN --format markdown

Example: add CSV export while keeping list behavior and the input data intact. Give each step a result and an independent way to check it.

You leave with: a reviewable plan, then actual diffs and check evidence when separately authorized execution succeeds.

Start with this prompt

Help me build the agreed activity-report CSV feature in small, reviewable steps.

First inspect the current project, request/spec, existing changes and any saved Harness task. Preserve unrelated work. Confirm the exact accepted revision; a prose spec or completed intake is not automatically a build-ready plan.

Prepare the current Harness plan with explicit participant assignments, dependencies, exact permitted file effects and protected independent acceptance checks. Explain what each step produces and how it will be checked. Keep the source fixture protected and preserve list behavior.

Show me the current plan, checkpoint and execution requirements before approval. Stop before participant calls or app changes. Do not approve the plan for me, infer usage authority, publish, merge or deploy.

Follow these steps

1. Anchor on the current agreement. Read the request/spec and existing task state. The CSV example requires matching list/export selection, the existing file contract and no change to the input fixture. Inspect current changes before choosing files.
2. Prepare a build-ready plan. The assistant identifies real files and supported effects, assigns actual participants and orders dependent tasks. Freeze independent acceptance checks before accepting the plan. A list of tasks in a document is a starting point, not that executable contract.
3. Review the exact plan and checkpoint. Confirm each permitted effect, protected check, dependency and expected result. Resolve planner findings and questions. A newly staged or revised plan is unaccepted until its current revision is reviewed.
4. Authorize the bounded execution separately. Only after plan acceptance and the applicable participant/usage authority should the assistant run the build. You can request a bounded pause; durable operation counts do not equal a guaranteed number of files or a cost ceiling.
5. Inspect each result before continuing. Review actual diffs, protected-check outcomes and any required review. A failed or uncertain step needs inspection, not an automatic retry. Finish by comparing the full outcome with the accepted requirements.

T1 — Confirm the contract and fixture shape. Prepare independent selection, CSV-byte and failure-case checks. Human resolves material contract changes first.
T2 — After T1, implement shared validation/selection and list/export behavior within the exact accepted file effects.
T3 — After T2, run the agreed checks, retain evidence and document the bounded manual spreadsheet review.

Before build: identify the actual files, allowed effects, participants and protected executable checks. This sequence is conceptual and has not been accepted or executed by Harness.

Expected output and how to review it

Expect the accepted plan reference, per-task outcomes, actual file changes and retained check evidence. Compare the diff with the permitted effects and verify that the fixture and unrelated work remain intact. A successful file write alone does not establish working CSV export.

What your assistant does, and what Harness adds

Your assistant can propose task boundaries, inspect/edit code with authority and explain diffs. It prepares the request/effect structure using the matching documented schema.

Harness binds acceptance to the current plan, supervises supported effects and protected checks, and retains task outcomes. It does not infer your approval from a prose spec or grant provider usage through plan acceptance.

# Inspect the current plan without acceptance or dispatch:
attune-harness plan --task-dir TASK --decision
attune-harness status TASK

# Separate steps, only after the corresponding reviewed authority:
attune-harness plan --task-dir TASK --accept --checkpoint CURRENT_CHECKPOINT
attune-harness build TASK --checkpoint CURRENT_CHECKPOINT \
  --max-operations REVIEWED_LIMIT

Example report: an empty CSV selection appears to produce an empty file. Establish the actual failure before choosing a repair.

You leave with: a reproducible failure and, after authorized repair, a scoped diff with before/after evidence.

Start with this prompt

Help me diagnose a possible CSV-export bug: an empty visible selection is expected to create exactly the seven-column header, but the reported export appears empty.

Inspect the current project and actual evidence first. Reproduce the behavior and distinguish the report from what you observe. Do not assume the cause.

If the failure is reproduced, prepare a trusted probe with an independent exact expectation and protected oracle. Prepare an attune-harness fix intake using the supported dedicated checkout, explicit existing-file scope, actual worker and review policy. Show the failing evidence, proposed scope and current approval point.

Stop before accepting the repair, dispatching participants or changing app files. Do not weaken the expected result to make a check pass, retry uncertain effects, publish or deploy.

Follow these steps

1. Describe expected and observed behavior separately. The expected empty CSV is one seven-column header record. “The file looks empty” is a report until the assistant inspects its actual bytes and reproduces the selection.
2. Keep the failing case independent. Prepare a trusted probe with the exact header expectation and the no-data-row condition. Preserve the probe and its oracle outside the worker’s editable scope. If the check already passes, investigate the reproduction instead of changing correct code.
3. Prepare the repair boundary. Inspect existing changes, choose an exclusively owned supported checkout and list only the existing files that may be replaced. Retain task state outside the checkout. The current POSIX fix profile does not create/delete/rename files or use linked worktrees.
4. Review before running the repair. Check the failing evidence, allowed files, protected probe, participant assignment, usage route and review policy. Only a separately authorized repair may call the worker or apply a replacement.
5. Review the before/after evidence. Inspect the actual diff, a failed-before/passed-after probe and the required reviewer outcome. If effects are uncertain, inspect and use the supported reconciliation path; cancellation is not rollback.

Problem: empty selection should export headers only.
Observed baseline: [actual reproduction result and evidence path]
Permitted files: [exact existing paths inspected in the dedicated checkout]
Protected expectation: activity_id,date,project,actor,kind,summary,minutes in the contract's exact CSV encoding/quoting/record format; zero data rows.
Before/after probe: [actual statuses and retained output]
Diff and reviewer: [actual changed lines and review outcome]
Unresolved effects or exclusions: [explicit, or none established]

These fields are a report template. No bug, repair or passing probe was produced by this help section.

How to review a repair

Reject a repair that only changes the check, alters unrelated files or silently drops visibility/filter rules. Read the diff and probe evidence together. A reviewer’s narrative does not replace the probe or your assessment of the user outcome.

What your assistant does, and what Harness adds

Your assistant can investigate the report, propose a reproduction and explain a replacement. The trusted expectation must remain independent of the worker.

Harness retains scoped repair inputs, supervises supported file replacement and probes, and records before/after and review outcomes. It cannot turn a missing reproduction or uncertain write into a verified fix.

# Prepare intake only, with real inspected files and a trusted probe:
attune-harness fix --goal "Repair header-only CSV export" \
  --project PROJECT --checkout DEDICATED_CHECKOUT --scope EXISTING_FILE \
  --probe PROBE.json --config REGISTRY.json --worker WORKER \
  --review required --reviewer REVIEWER --task-dir FIX_TASK --intake-only
attune-harness status FIX_TASK

Example: establish that CSV export contains exactly the selected visible activity and preserves the agreed file behavior.

You leave with: a test plan, meaningful checks and an evidence summary suited to your next decision.

Help me choose meaningful tests for the activity-report CSV feature. Inspect the actual change and agreed requirements first.

Map each important behavior to a concrete input, an independently derived expected result and the evidence to retain. Include the normal journey, boundaries and failure paths. Separate transformation-unit checks, schema-valid CLI checks and manual spreadsheet checks. Show existing coverage, gaps and exclusions.

Recommend the smallest useful set and explain what it cannot establish. Show the plan before writing test files or executing anything. Do not invent results or generate checks that merely repeat the implementation.

Requirement: list/export selection parity.
Case: viewer + atlas + review + October 11–12, 2026.
Expected selected IDs: a-0002, a-0004, in that order.
Evidence: compare the complete list and parsed export IDs/count against those independent expectations.

Separate case: invalid dates must be rejected. Arbitrary formula strings belong in direct transformation checks where the input schema would reject them at the CLI boundary.

Help me add a regression check for this reported behavior: an empty CSV selection appears to create an empty file instead of the required header-only CSV.

Inspect and reproduce the actual behavior first. Derive the exact expected bytes from the accepted CSV contract. If a failure is reproduced, propose a focused check that fails before the repair and passes only when the required behavior is restored. Keep the oracle independent of the repair worker and preserve unrelated tests.

Show the reproduction, proposed check and file scope before editing or running new code. Do not change the expectation to match the bug. If the old behavior already passes, report that instead of claiming a regression was demonstrated.

Reported defect: no header for an empty selection.
Before: [actual failing assertion, input and retained output].
Expected: exactly the contract's header record; no data rows.
After: [actual execution of the unchanged check against the repair].
Preserved: the independent oracle, existing list behavior and input fixture.

This is a report template. No regression or repaired behavior is established by this help page.

Inspect my current Git working-tree change and identify the tests most relevant to the CSV-export behavior.

Prepare an attune-harness test preview using the exact changed scope and an interpreter with the project dependencies. Explain the selected tests, the selection reason, any broader fallback and the excluded checks. Show explicit --tests choices if a narrower set is appropriate; do not describe static associations as proof of complete coverage.

Stop at the current preview/checkpoint. After I authorize that exact preview, retain actual executed, passed, failed, skipped and unexecuted results. Do not reuse acceptance after the inputs change or silently broaden into external/model execution.

Changed behavior: CSV serialization in the activity-report module.
Selected coverage: exact CSV format, text transformation and related selection/file-failure cases.
Broader coverage to consider: list/export parity and unchanged list behavior.
Excluded: unrelated features, unless a shared dependency or broader fallback justifies them.
Record: snapshot, selected paths, reason/exclusions, acceptance checkpoint and actual pytest output.

These are selection criteria, not an actual prepared preview or passing result.

Help me check the complete activity-report journey: select a simulated user, list visible activity, apply filters, export to a new CSV and inspect it in the intended spreadsheet.

Use synthetic data and the agreed contract. Define exact starting state, actions, expected IDs/count, expected file behavior and evidence to retain. Include an empty selection and an existing destination file. Keep automated CLI checks and manual spreadsheet observations distinct.

If a browser UI exists, include keyboard access, visible labels, error feedback and the actual produced download using available browser tools. Do not invent a browser flow for this CLI example. Show the checklist and any effect/permission requirements before execution. Report actual observations and blockers, not fabricated screenshots or results.

Starting selection: viewer / atlas / review / October 11–12, 2026.
Expected: a-0002 then a-0004; two data rows and the seven-column header.
Artifact to inspect: the actual exported CSV, including Café/multiline text and the transformed formula-like summary.
Other paths: no matches → headers only; existing destination → refusal without replacement.
Manual evidence: spreadsheet/version, import settings, observations and any actual capture.

This checklist is illustrative. It does not establish that an export or spreadsheet check ran.

Inspect this saved test task and its retained output without rerunning it.

Distinguish assertion failure, collection/dependency error, skipped or unexecuted checks, timeout, output overflow and stale/uncertain state. Explain which requirement the actual evidence supports or refutes. Do not infer a pass from a successful status command or missing usage/output.

Recommend the smallest next action: fix the product, correct a demonstrably wrong check/environment, review coverage, or use the supported continuation/reconciliation path. Keep the original result unchanged. Stop before edits, retries or new execution; show any new preview/approval needed.

Outcome examples to distinguish:
- Assertion mismatch: inspect expected versus actual selected IDs/CSV bytes.
- Import/collection error: establish dependencies and collection before claiming behavior was tested.
- All skipped or collection only: no passing execution established.
- Timeout/output limit: visibly incomplete evidence; inspect before a new attempt.
- Status command succeeded: the record was read, not proof that tests passed.

These examples are classifications, not observed test results.

Help me assess whether the CSV-export change has enough evidence for acceptance.

Read the agreed requirements, actual diff, captured test scope/results and any manual spreadsheet observations. Map every requirement to retained evidence. Mark it supported, failed, unexecuted, excluded or uncertain, with links and limitations. Inspect the expected values and source passages rather than treating a citation or model opinion as proof.

Identify the highest-impact uncovered behavior and recommend the smallest additional check only where justified. Show the tradeoff and remaining uncertainty. Do not fabricate measurements, equate coverage percentage with correctness, approve the change for me or authorize a release.

Requirement → actual evidence → assessment
R2/R3 selection parity → [complete expected IDs/count comparison] → [supported/failed/unexecuted/etc.]
R5 CSV contract → [parser and byte assertions] → [assessment]
R6 formula policy → [direct transformation + schema-valid CLI cases] → [assessment]
R7 empty/overwrite/failure handling → [retained checks] → [assessment]
Spreadsheet behavior → [named importer observation] → [bounded manual finding]

Open decisions and excluded coverage remain visible. This is an assessment template, not proof that the feature passed.

Help me check whether the CSV-export change meets the agreed requirements.

Inspect the current Git working-tree change and the accepted CSV contract. Identify existing independent checks and any missing coverage; do not invent passing results or write tests that merely mirror the implementation.

Prepare the supported attune-harness test preview with the exact changed scope, interpreter, selected tests and excluded coverage. Show the snapshot and current acceptance checkpoint before running it. Check for test-side effects and required project dependencies.

After I authorize the exact preview, run the selected checks, retain actual pytest output and explain passed, failed, skipped, unexecuted and excluded cases. Keep manual spreadsheet validation separate. Do not accept the preview for me, dispatch models or publish anything.

Automated: complete expected selected IDs and count; stable order; exact seven-column file; Unicode/quotes/newlines; formula transformation; header-only empty file; no overwrite; invalid input creates no export; write-failure cleanup; repeat bytes and unchanged fixture hash.
Manual: inspect the actual two-row viewer/atlas/review export in the named spreadsheet/import configuration.
Result record: executed/passed/failed/skipped counts, selected and excluded checks, snapshot/checkpoint and retained output paths.

This is expected coverage, not an executed test result. Passing a narrow selection does not establish excluded behavior.

# Save a test preview; no --accept here:
attune-harness test --project PROJECT --scope CHANGED_PATH \
  --interpreter PYTHON_WITH_PYTEST --tests TEST_PATH \
  --task-dir TEST_TASK

# Only after reviewing that exact current preview:
attune-harness test --task-dir TEST_TASK \
  --checkpoint PREVIEW_CHECKPOINT --accept
attune-harness status TEST_TASK

Example: return to the saved CSV request without losing its answers or confusing an unapproved draft with an accepted build.

You leave with: a continuation brief tied to the real saved task, with the next decision and remaining work visible.

Start with this prompt

Help me pick up this saved Harness task: [paste the actual saved task directory].

Inspect status and retained evidence first without resuming or dispatching. Show the goal, current outcome, completed work, remaining questions, current checkpoint, failed or uncertain effects and the smallest supported next action.

Check whether the inputs, files and existing authorization still match. Preserve unrelated changes. Do not assume that a paused, failed, draft or completed task needs another run.

Recommend how to continue within the saved workflow, but stop before participant calls, file effects, retries or new approval. If continuation needs a new decision or supported reconciliation, show the exact reason and current evidence. Do not start a replacement task to hide the prior result.

Follow these steps

1. Find the real saved task directory. Use the path retained by the earlier workflow. Ask the assistant to read its goal, status and evidence before taking action; a guessed task ID is not enough.
2. Separate finished work from the next decision. Read completed tasks, open questions, failed checks and uncertainty. A draft may simply need your review. A completed task may only need its evidence replayed. Neither is a reason to dispatch again.
3. Check that the saved scope is still current. Compare current inputs/files, checkpoint and existing authority. If something changed, expose the mismatch and prepare the supported revision or reconciliation. Preserve unrelated edits.
4. Choose the smallest supported next action. Review an unanswered intake, inspect a failed result, repair within supported scope, or resume a genuinely paused workflow. Status is read-only; resume may run participants, tests or file effects.
5. Continue only within applicable authority. If the next action needs a new decision, review that exact scope first. Keep the same evidence history. Do not blindly retry uncertain effects or create a new task to make a failed attempt disappear.

What if a path or task selection is refused?

Resolve relative --document, --context and --corpus paths against --project. Resolve relative --config paths against the working directory. Absolute paths are used directly; selected evidence must still satisfy the project and task-state boundaries. Choose a task directory outside the selected corpus.

Use status when a task was actually created. If it reports a missing task record, check that you selected the existing task directory containing record.json. Preserve invalid records for inspection. Do not create a replacement record or retry execution to clear the message.

For assessment intake, keep evidence inside the project and outside task state. A selected document must be inside the selected corpus. A context file must be a valid verification context; correcting its path does not validate its contents. Keep the original refusal, then inspect the explicitly corrected selection.

Expected output and how to review it

Expect a short continuation brief: current goal/outcome, evidence links, completed and remaining work, blockers, current checkpoint and a supported next action. Check that it refers to the right task and does not reclassify failure or uncertainty as success. An uncertain consultation stays stopped until its workflow and permissions have been reviewed; ordinary plan/build resume instructions do not authorize a retry.

What your assistant does, and what Harness adds

Your assistant can summarize the saved state, compare it with current files and recommend what to do next.

Harness retains checkpoints, outcomes and evidence across supported workflows. Status reads saved state; resume follows the saved policy and can execute work. It does not infer a new grant from the phrase “pick up”.

attune-harness review --goal "Review the CSV export spec" \
  --project /absolute/path/to/csv-project \
  --config /absolute/path/to/csv-project/participants.json \
  --document docs/csv-spec.md --corpus docs \
  --task-dir /absolute/path/to/csv-review-draft --intake-only
attune-harness status /absolute/path/to/csv-review-draft

# First inspect the actual saved task:
attune-harness status TASK --format markdown

# Only when the saved workflow, scope and authority support continuation:
attune-harness resume TASK --checkpoint CURRENT_CHECKPOINT \
  --max-operations REVIEWED_LIMIT

# For a roundtable, inspect its separate run record without dispatch:
attune-harness roundtable status RUN --format markdown