Project Workflow Reference

This skill is a reference, not an always-on rule or a default session mode. Installing it does not activate the other skills. Each mode skill contains its own essential instructions and can be used alone.

Modes

An agent uses a mode only when the user explicitly invokes that skill by name or through the agent's skill interface. A client may expose /project-plan-style shortcuts, but installation alone does not guarantee slash commands. Do not assume a mode is active at the start of a new session.

While a mode is active, start replies with [MODE: RESEARCH], [MODE: INNOVATE], [MODE: PLAN], [MODE: EXECUTE], or [MODE: REVIEW] as appropriate. Use the user's language for the rest of the reply. A simple "yes", "no", "success", or "failure" is feedback, not an instruction to change modes. Switch modes only when the user explicitly invokes the next skill; do not switch automatically on completion or error. Follow any higher-priority instructions and tool permissions.

Authorization

• Research, innovate, plan, and review do not create or edit files, branches, or commits by default. Ask for explicit authorization before persisting a task file or making other state changes. When a final plan has been presented, explicit invocation of project-execute approves that plan by default and authorizes saving it and tracking execution in a task file as described by the Execute skill, unless the user rejects it or requests changes.
• Execute requires a presented final plan and an explicit request to use project-execute. If no final plan has been presented, ask for one; a rejection or request for changes means the plan is not approved. The plan authorizes only its stated scope; new work requires a revised plan.
• Creating a branch, making a commit, pushing, deleting data, or performing other consequential actions requires explicit authorization for that action, even in execute mode.
• Report findings and verification results directly. Do not expose private reasoning or fabricate test results.

Execute Task Record

After explicit project-execute invocation with a presented final plan, record the plan and execution progress in a Markdown file under the Git worktree root's .tasks/. If the current directory is not in a Git worktree, use the single project/workspace root supplied by the client; ask the user to choose if multiple roots are ambiguous. If neither is available, use the current working directory. Create .tasks/ if missing. Inspect existing files and create a unique YYYY-MM-DD_plan-xxx.md using an exclusive no-overwrite operation; on collision, retry with another suffix. If exclusive creation is unavailable, stop and record the blocker. The task record contains the approved request and plan, approval status, scope, applicable interface/data conventions, verification items, checklist, and progress. Mark checklist items complete only after their relevant checks pass, and record outcomes or blockers. Task-file creation remains optional in other modes unless separately requested.

A compact task record template is:

# Task

## Request
[User requirements]

## Findings
[Relevant observations]

## Options
[Considered approaches]

## Approved Plan
[Steps and approval status]

## Scope And Conventions
[Scope, interfaces, and data conventions]

## Verification
[Checks required and their outcomes]

## Checklist
[Itemized work and status]

## Progress
[Changes and verification]

## Review
[Findings and outcome]

Step Confirmations

YOLO_MODE controls confirmations within an already approved execute plan. It is a conversational preference for one project-execute invocation, not an operating-system environment variable or persistent client setting. To select a non-default value, the user includes YOLO_MODE=Ask or YOLO_MODE=On when explicitly invoking project-execute. If omitted, use Off. Only the user may change it.

• Off (default): Ask and wait for approval before each top-level item in the approved checklist. One approval covers the related changes already described by that item.
• Ask: Ask and wait before each separately reviewable change group within a checklist item. A group includes all changes needed to deliver and verify one planned outcome, including directly related implementation, tests, and documentation across files. Split groups only when their outcomes have distinct acceptance criteria and can be delivered or reverted independently. Confirm independent groups separately, but do not split by file, code line, or tool call. Read-only inspection and verification commands already authorized by the plan do not need separate step confirmations.
• On: Proceed through all steps in the approved plan without intermediate confirmations.

When confirmation is required, state the next action and pause until the user approves. These are model-facing workflow instructions, not an enforcement mechanism. The setting never authorizes scope expansion, commits, pushes, destructive actions, or bypassing client/tool permission prompts; obtain separate authorization where required.