Choose how to start
Start with the result you want. Give the work enough structure to make its important decisions and checks clear. Goal-driven and spec-driven development are two ways to prepare that work.
Harness 1.7.0
| Approach | Useful when | What you review |
|---|---|---|
| Goal-driven development | The outcome is small and bounded, and the affected files and checks can be made clear in a short request. | The goal, scope, constraints, success criteria and proposed plan. |
| Spec-driven development | Several workflows, dependencies, consequential choices or competing requirements need to be settled before implementation. | A specification with requirements, exclusions, acceptance examples, dependencies and unresolved decisions. |
Start from a bounded goal
In this course, the useful result is a report of six synthetic activity entries. Its expected totals and file boundary are easy to inspect together. That makes a short goal-led request a useful starting point.
- Describe the result in ordinary language: a readable report of time by project and category.
- Have the assistant inspect the actual project and propose the file scope, constraints and independent checks.
- Resolve consequential questions and review the resulting request and plan.
- Accept the exact scope when it is ready. Authorize execution separately, then inspect the outcome and evidence.
Example request: “Create the activity report from this synthetic CSV. Keep the data and acceptance checks unchanged. Show me the plan and the expected totals before starting.”
Use Turn an idea into a useful result to define the request, then Build your first report to practice planning and execution. Read the current goal-driven guide for the source procedure.
Develop requirements before implementation
Suppose a later reporting product must accept several input formats, preserve saved reports and support shared access. Those are proposed extensions beyond this course’s local tool. Data compatibility, access rules and failure behavior need clearer decisions before building.
- Describe who needs the product, its useful outcome and the first complete workflow.
- Work with the assistant to draft numbered requirements, non-goals, concrete acceptance examples and dependencies. Mark unresolved choices visibly.
- Review alternatives and supporting evidence. Use consultation only when it can resolve a useful uncertainty and its selected scope and usage are authorized.
- Review and accept the requirements. Then ask the assistant to turn them into a Harness implementation plan, with exact files, permitted changes and protected checks.
- Review and accept that plan before separately authorizing execution.
Example request: “Help me write a reviewable spec for shared activity reporting. Identify the user workflows, data and access rules, dependencies, acceptance examples and open decisions. Keep implementation and model consultations pending while we review the requirements.”
A specification can explain more than a small task needs. Use the amount of structure the work requires. If a short goal exposes important unresolved requirements, develop the spec before accepting implementation scope.
Read the current spec-driven guide and supported plan-import guidance. An accepted prose spec is not automatically a build-ready task graph or permission to run participants.
Keep the same review points
- Scope: What result is wanted, and what may change?
- Checks: What independent evidence would establish success?
- Acceptance: Does the current request or plan match your decision?
- Execution: Are the selected participants, effects and usage authorized?
- Assessment: What actually happened, and what remains uncertain?
Choosing either approach grants no execution, spending or publication authority. Revisit the requirements and plan when the work changes.