Beginner track10 min · Step 3 of 3

Creating and completing a task

This is the core galdr loop: create a task, implement it, then have a fresh agent session verify it. Two sessions, one result you can trust.

Task lifecycle

[ ] pending→[🔄] in-progress→[🔍] awaiting-verification→[✅] complete

The critical rule: the agent that implements marks [🔍], never [✅]. Only a separate verification session can mark [✅].

Create a task with @g-task-new

Open your AI tool and run:

@g-task-new

The agent will ask you to describe what needs building. Be specific about the objective and acceptance criteria. Here's an example of what a good task description looks like:

Your description to the agent
Add a user authentication page to the app.

Acceptance criteria:
- /login route exists with email + password form
- Validates both fields before submit
- Shows error state on failed login
- Redirects to /dashboard on success
- Responsive, matches existing design system

The skill creates a task file in .galdr/tasks/ and adds it to TASKS.md with status [📋] (pending/specced).

Start an implementation session

Open a new chat session with your AI tool (or continue this one) and run:

@g-go-code

The agent loads context (PROJECT.md, CONSTRAINTS.md, BUGS.md, TASKS.md), picks the highest-priority task, and begins implementing. It works autonomously through the task, walks every acceptance criterion, and then marks the task:

Result in TASKS.md
- [🔍] Task 001: Add user authentication page

The [🔍]status means "implemented — awaiting independent verification." The agent does NOT mark it done — that's the gate.

Open a NEW session to verify

This is the most important step. Close your current chat or open a new window. You want a completely fresh context — no memory of what the implementing agent did.

In the new session, run:

@g-go-review

The reviewer agent reads the task's acceptance criteria and independently checks the implementation. It does not trust what the previous agent said — it reads the actual files.

If verification passes, the reviewer marks the task:

Result in TASKS.md
- [✅] Task 001: Add user authentication page

If the reviewer finds issues, it creates a bug entry and leaves the task at [🔍]. The cycle repeats.

Commit the completed work

Once a task is [✅], commit it:

@g-git-commit

The skill reads TASKS.md for recently completed items, writes a conventional commit message with the task reference, and commits. The galdr files commit alongside your code — so the task history travels with the project.

Why the two-session gate matters

The implement → verify split sounds like overhead. Here's what it actually prevents:

What goes wrong without the gate	What the gate catches
Agent hallucinates working tests	Reviewer runs tests independently and finds the failures
Task AC is half-met	Reviewer reads the original spec and checks each criterion
Agent ignores a constraint	Fresh context loads CONSTRAINTS.md without prior bias
Regression in related feature	Reviewer looks at blast radius, not just the changed files

Beginner track complete ✓

You've installed galdr, configured a project, and run the full implement → verify task cycle. That's the core loop. Everything else in galdr — skills, agents, PCAC, hooks — builds on this foundation.