# Projects, goals, and loops

Give related work a project, then decide whether it needs a task, an iterative goal, or a repeatable workflow. Each serves a different purpose.

## Give work a home
Create or select a project and describe its outcome. Add relevant context and organize tasks into task lists. Tasks can have dependencies, priorities, an action plan, and exit criteria.

Write exit criteria you can inspect: “a report with cited sources and three open questions” is more useful than “research complete.” A task cannot be completed while its declared exit criteria remain unfinished.

## Use a loop for iterative work
A loop works toward a goal across cycles. Gideon supports general, goal, code, design, and research work. The work view exposes progress, findings, tasks, and artifacts. Provide a workspace when the work must act on an existing codebase.

Before starting, settle scope, relevant access, the expected deliverable, and how to stop. Review the planning walkthrough where offered. A monitoring goal is ongoing work; stopping it is not the same as finishing a finite deliverable.

## Use a workflow for a known process
A workflow defines the shape of the work in advance: steps, branches, parallel work, waits, and review gates. See [reusable workflows](/docs/workflows/overview).

## Keep your review concrete
Open the deliverables, check outstanding tasks, and read any request for input. A run that is waiting, stopped, or out of budget is not automatically a finished project.

> **Try this**
> Help me scope [goal]. List the deliverable, dependencies, access needed, and measurable exit criteria. Present the plan for review before beginning changes.