Turn an idea into a useful result

See where the work went

Six activity entries can answer a useful question: how much time went to each project and category?

Click Open formatted report. Find the total, one project and one category. A readable report lets you explain where the time went without adding every row again.

In this course, you direct the outcome and decisions. Your assistant helps inspect the project and prepare the work. Harness retains the agreed request, checks and execution evidence for supported workflows.

Start by defining what would make the report useful. You do not need to design its code. Opening the supplied report does not mean that you have built a new one.

Check the six entries

The projects and activity are synthetic. The small input makes the target result easy to check yourself.

Read the actual activity CSV, which also includes the dates. Add Orion's rows: 90 + 30 + 45 + 15 = 180 minutes. Lumen has 60 + 30 = 90 minutes. Together they account for 270 minutes, or 4 hours 30 minutes.

Pick a category and add its rows before looking at the report. Development should total 150 minutes, Documentation 75 and Testing 45. These expected answers come from the input, not from trusting the reporting code.

Describe what the person needs

A good goal explains the useful result. It does not force you to specify the implementation.

That goal tells the assistant why the report matters. It also gives you a way to assess the result: can a reader find the totals and connect them to the input?

1. Name the input: the supplied synthetic CSV.
2. Name the reader's useful result: understand where the time went.
3. Name what the output must show: entry count, total minutes, project totals and category totals.
4. Ask what remains unclear before accepting the work.

Your assistant can recommend an approach and explain its tradeoffs. You settle choices that change the result, such as the intended reader or output format.

Choose your starting path: this bounded reporting exercise starts from a clear goal. If your real project has several workflows or unresolved requirements, use the goal-driven and spec-driven reference to choose the preparation it needs before accepting a plan.

goal prompt

Help me define a useful reporting task from the supplied synthetic activity CSV. The reader should understand where the time went without manually adding the rows. Inspect the input and retained example first. Propose a short goal, observable success criteria and the smallest useful scope. Explain consequential choices. Keep this preparation read-only; do not approve or execute work.

Keep one complete useful journey

The first version should read the sample, produce a report and help someone recognize invalid input.

Choose the output you need before preparing a task. The supplied example includes text and HTML output; the agreed task must identify the output being built and checked.

Have the assistant identify the actual files that may change and the inputs and checks that stay protected. Check that its proposed scope fits this first version and preserves unrelated work. A course example does not supply acceptance for a task in your own project.

Say how you will recognize success

Use concrete examples and a failure case. A polished appearance alone cannot establish that the totals are right.

• Completeness: all six valid entries appear in the count, without a hidden filter.
• Totals: the report shows 270 minutes; Orion 180 and Lumen 90.
• Categories: Development 150, Documentation 75 and Testing 45.
• Invalid input: an invalid row produces a helpful error and no misleading partial report.
• Preservation: the input and protected checks remain unchanged.

Ask your assistant to connect each criterion to an independent check. Later you will inspect the actual results and separate review, including concerns the chosen checks may miss.

A saved draft records what you intend. Approval records your decision about the reviewed scope. Starting execution remains a separate action.

Change the reader, then explain the consequence

Suppose a colleague only wants to compare the two projects. Does that require a new feature?

The existing project table already supplies that comparison. A useful next step might be clearer instructions about where to look, rather than adding a filter or rewriting the tool.

Now consider a different request: “Show only Orion's activity.” That changes selection behavior. Keep it as a proposed later change until its goal, permitted files and checks are reviewed.

Your reader and first-version decision

Write your answer in your own notes, or use the interactive lesson.

These practice notes stay in this browser when storage is available. They are not a saved Harness request, approval or execution record. Copy anything important into your actual project brief.

Explain why your chosen scope completes a useful journey. If the existing report already answers the question, keeping the scope unchanged is a valid decision.

Prepare a brief you can review

You are ready for planning when you can explain the goal, the boundary and what would establish success.

Ask your assistant to prepare the actual request and explain its proposed files and checks. If it uses a form, inspect the whole current request before making its decision.

Next: Open Build your first report to follow planning, scope approval, separately authorized execution and evidence inspection.

brief handoff prompt

Use my reviewed reporting brief to prepare the next planning step. Show the actual goal, current files, proposed allowed changes, protected inputs and independent checks. Explain any unresolved decisions and the current approval point. Preserve my wording and existing work. Stop before accepting scope, starting execution or making provider calls.