paseo-workloop git:20261028.e2bb844A

Immutable. This exact content never changes and is served at /api/v1/blob/96dd62e4b2a297b1.

---
name: paseo-workloop
description: Take a development task from conversation to verified work. Handle small clear changes directly, or coordinate scoped tickets, independent review and integration with Paseo agents. Also use for run recovery, retrospective and archival.
---

# Paseo Workloop

Choose enough process for the task. Keep the user's goal and existing authorization in view; routine choices belong to you, while material scope and design questions belong in the conversation.

## Choose a route

Discussion and read-only investigation can stay in the conversation. For implementation, use these defaults:

| Route | A useful fit | How it works |
| --- | --- | --- |
| **Quick** | Clear goal, local reversible change, straightforward verification | Work in this session; no ticket or Paseo workers required. |
| **Direct** | A bounded change benefits from a delegated executor and independent review | One scoped ticket, reviewed and integrated through Paseo. |
| **Full** | Design choices, dependencies or parallel work need coordination | A spec and tickets, independent reviews, serial integration, and an independent final review of the whole run. |

Judge uncertainty and impact, not line count. A wording fix usually fits Quick; a one-line authorization change may deserve independent review. These are defaults, not a scoring system.

If the request already supplies the goal, scope and acceptance, proceed. When important questions remain, use [grill-me](../grill-me/SKILL.md), or [grill-with-docs](../grill-with-docs/SKILL.md) for domain and architectural decisions. Scale the discussion to what is missing; there is no minimum question count or repeated route approval.

Read relevant project instructions and ADRs. Resolve material conflicts with the user. Carry decisions into the work rather than asking the same questions again at ticket creation.

## Quick

Make the authorized change while preserving existing work. Choose verification that demonstrates the requested result: a focused test for behavior, or content/link/diff checks for a small document edit. Independent review is useful when the risk warrants it, rather than mandatory for every edit.

Explain what changed, what you checked and any remaining limit. Quick needs neither a run directory nor a ticket, and does not require a Paseo daemon. If hidden dependencies or design choices expand the task, carry the existing work and findings into Direct or Full; do not silently drop the changes or restart discovery.

## Direct and Full

Read [the run procedure](reference/run.md) when starting or continuing a ticketed run. It covers runtime prerequisites, briefs, dispatch, reviews and integration. The script owns state and Git operations; you make the judgment calls.

Before integration, rework continues with the original executor, session and worktree. After integration, defects get a new repair ticket, new session and new worktree from the current integration tip. Prior sessions remain available as evidence.

For interrupted operations or an unrecoverable session, read [recovery](reference/recovery.md). For notifications and heartbeat reconciliation, read [async supervision](reference/async-supervision.md).

## Finish, retro and archive

`finish` verifies delivery and retains sessions. In a full run it accepts only the independent final reviewer's report for the current integration tip: a pass, or a `changes_requested` whose blocking findings the user let through. Assess the whole run for recurring problems or repeated wasted effort using [retro](../retro/SKILL.md). Record findings with `retro --file <report>`, or a brief no-retro decision with `retro --skip --reason <why>`. Then `archive` preserves activity transcripts and archives the sessions together. The user's decision on suggestions does not hold archival open.

Users can request retro at any point, including during Quick or after archival. A mid-run retro covers evidence so far and does not stop execution. Retro produces findings and suggestions only; adopting them is a separate user decision.

## Writing and maintaining documents

When writing or editing agent-facing instructions, skills, specs, tickets or briefs, read [writing-for-agents](../writing-for-agents/SKILL.md). Prefer useful defaults, decision cues and examples; reserve hard constraints for actual failure boundaries. Human-facing docs should fit their readers.

For `/tidy-docs`, read [document organization](reference/tidy-docs.md). It governs classification and location; writing-for-agents governs how agent-facing content is written.