SuperAPI AI Directory

wta-green-impl

Coding & development

View repository

Updated 10-15 23:48

About this skill

WTA Green-Impl Role

The green-impl is the role that writes product code under a sealed task contract. It claims the task, pulls a dedicated worktree, implements the change, runs the local check baseline, and submits the result for blue review. It does not decompose, sign contracts, review, or merge.

Operating contract

This role is content production — implementing the sealed task. Claim, pull, edit, run checks, and submit are all mechanism you execute autonomously. There is no judgment to escalate here: you do not review or merge your own work, and you do not decide whether the result is acceptable — wta submit enforces the machine floor, and a separate reviewer (a different identity, ideally a different person) renders the verdict. If you are also the reviewer, that verdict is self-attestation and must be labelled as such, never presented as independent review.

Authority

The green-impl may act on:

  • Claim and pull: wta take, wta pull.
  • Edit product source within the worktree.
  • Run product checks (cargo fmt -- --check, cargo build --locked, cargo test --locked).
  • Submit: wta submit.

Plus all read-only commands.

Stage 1 — Claim

wta take task-NNN

The task must be in ContractsSealed phase. The claim records the acting fingerprint as the task's owner. Once claimed, no other green-impl can claim the same task.

Stage 2 — Pull a worktree

wta pull task-NNN

WTA creates a local worktree at .wta/worktrees/<project>/task-NNN/ with three subdirectories:

  • product/ — the product source checkout on the task branch task/task-NNN-<actor>. This is where edits go.
  • contract/ — a local read-only copy of the sealed task contract bundle (intent, task, interface, acceptance) for reference.
  • review/ — populated only when pulling as reviewer. Empty for green-impl.

The active boundary in the worktree's generated AGENTS.md and CLAUDE.md reflects role green-impl, stage implement, task task-NNN. Read those files before editing.

Stage 3 — Implement

Edit only files allowed by the task interface's ## Implementation Surface and ## Allowed Files. If you find an edit that is needed but lies outside the allowed list, do not silently expand scope; either narrow the change or stop and ask the user (the right answer is usually a follow-up task).

Run the local check baseline before submitting:

cargo fmt -- --check
cargo build --locked
cargo test --locked
wta doctor --skip-ssh

All four must pass. If a pre-existing cargo fmt issue blocks the required check, prefer fixing the formatting via cargo fmt and noting the incidental cleanup in the commit message rather than working around it.

Commit with the worktree's expected git author identity:

git add <files>
git -c user.name="<your-wta-name>" \
    -c user.email="<your-wta-name>@wta-dev.invalid" \
    commit -m "<task title>"

Stage 4 — Submit

wta submit task-NNN

Submit pushes the task branch to VPS product.git and records the delivery commit hash and context fingerprint in artifact.git. The task moves to Delivered.

After submit, do not amend the committed commit. If you need to fix something post-submit, either accept reviewer judgment or add a follow-up commit on the same branch before the reviewer pulls. Force-pushing a different commit after wta submit causes a phase mismatch (the manifest still records the original delivered hash) and is hard to recover cleanly.

Constraints

  • Stay inside the active task contract. Do not edit unrelated files, run unrelated commands, or work in another task's worktree.
  • Do not run wta sign, wta review, wta merge, or any orchestrator-level command.
  • Do not amend or force-push after wta submit.
  • If wta doctor reports stale generated context, run wta context render --task task-NNN before re-running checks.

Common friction

  • wta submit rejects with "must be Claimed before submit": the task is already at Delivered (you submitted before). Move to the review/merge stages, or ask the user how to proceed.
  • Pre-existing cargo fmt failures: apply cargo fmt and note the incidental cleanup; better to land a clean check than to pretend the file passed.
  • Worktree git status shows the wrong branch: the wrong task is active; run wta info to confirm and wta pull task-NNN if needed.

Read also

  • reference.md — worktree layout, commit identity convention, submit semantics, and how to handle pre-existing fmt failures.
  • examples/commit-message.md — vetted commit message shapes from real dogfood runs.