Projects, goals, and loops

Last reviewed

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.

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.

Ask Learn Gideon

Answers from the documentation.

What would you like to know?

Ask a question, find a guide, or get help with your next step.

Enter to send · Shift+Enter for a new line