Project Execution

Run long work from files and evidence, not conversational memory. Keep the controlling state small, current, and inspectable.

Operating commitments

1. Retrieval over memory — externalize the plan, decisions, results, and handoffs; reread the relevant state before resuming.
2. Evidence over reassurance — never call work verified, working, correct, or complete without a check run in the current execution context.
3. Small tasks, whole-project alignment — finish bounded tasks while repeatedly checking the overall goal and acceptance criteria.
4. Integration over accumulation — confirm every accepted task result appears consistently in the final deliverable.
5. Convergence over first-fix stopping — after a correction, rerun the complete relevant check; stop only after a clean independent pass.

Route the work

Estimate scope before creating ceremony:

• Small task — do not use this skill.
• Large cross-domain project — use the workflow below.
• Large software project with GSD already installed — prefer GSD for milestone/slice/task state, worktrees, and autonomous software phases. Retain this skill's honesty and acceptance gates.
• Bounded software implementation with Superpowers already installed — use its design, plan, execution, and branch-completion workflow when it matches the harness.

Read references/software-backends.md before delegating. Never install or initialize an external controller merely because this skill triggered.

For any code change, apply references/coding-policy.md.

Execute the project

1. Define done

Write a concrete goal, deliverables, exclusions, constraints, and acceptance checks. Resolve only the ambiguities that materially change the project. Do not start producing final deliverables with an untestable definition of done.

2. Decompose

Create a small number of sequential stages such as research, design, build, integrate, verify, and polish. Break each stage into tasks with:

• A single outcome.
• Inputs and dependencies.
• A concrete output location.
• A check that proves completion.
• A status: pending, active, blocked, or verified.

3. Persist state

Use the project's existing issue tracker or planning convention when one exists. Otherwise create the minimal .project/ workspace described in references/workspace.md. Ask before creating project state when the user requested planning only or the target repository treats new root state as consequential.

Keep the master plan current. Record decisions and conventions once; do not make future sessions reconstruct them from chat.

4. Execute bounded tasks

For each ready task:

1. Read the goal, current stage summary, dependencies, and relevant conventions.
2. Mark only that task active.
3. Perform the work without silently expanding scope.
4. Run its specified check.
5. Record output, evidence, remaining uncertainty, and any newly discovered work.
6. Mark it verified only when its acceptance check passed.
7. Update the stage summary and master plan before moving on.

Parallelize only independent tasks with non-overlapping outputs and a defined merge owner.

5. Integrate

When assembling task outputs, audit them one by one:

• Is each accepted result present?
• Are names, assumptions, formats, and versions consistent?
• Did later work invalidate an earlier task?
• Are generated artifacts traceable to their source task?
• Does the integrated result still meet the top-level exclusions and constraints?

6. Verify independently

Use the strongest applicable checks: executable tests, recomputation, lint/build, schemas, invariants, boundary cases, source/citation audit, visual inspection, or a genuinely independent review. Read references/verification.md.

After any failure, fix it and rerun the full relevant suite. Keep unchecked assumptions explicit.

7. Close or hand off

Complete only when:

• Every required task is verified or explicitly waived by the user.
• Every accepted task is incorporated.
• A fresh full pass finds no new issue.
• The final artifacts and evidence are discoverable.
• Remaining risks, deferred work, and reproduction instructions are recorded.

If pausing, leave a handoff containing current stage, last verified result, active blockers, exact next task, and commands or files needed to resume.

Communication

Report outcomes in this order:

1. What changed or was produced.
2. Checks run and their actual results.
3. What remains unverified or blocked.
4. The next ready task.

Do not expose the entire internal workspace unless requested. Never hide a mismatch to make progress look smoother.