Implement Task

Implement Task

Treat the full user request as one raw TaskInput. Preserve quoted paths, pasted logs, images, URLs, and natural-language constraints. Never interpolate it directly into a shell command.

The canonical interface is:

$implement-task  [execution-overrides]

Prefer a task ID or exact contract path for production work. The contract is the durable source for scope and acceptance; the invocation starts one execution. Read references/argument-contract.md before parsing flags or resolving a task ID, and apply its conflict and safety-order rules exactly.

Unity execution hard gate: after resolving the exact task/repository and before any lifecycle, production, test, or evidence mutation, invoke unity-preflight; only a non-blocking result may proceed to unity-game-dev. Load that domain skill before diagnosis or mutation. Reading the contract and owned files is allowed before this gate, but patching is not. Then acquire or reuse the task lifecycle lock required in Section 2 before the first mutation.

0. Route lifecycle feedback first

Before planning writes, determine whether the input is an initial execution or post-implementation feedback for a durable tracked task.

Before applying bug-feedback routing, treat an immediately following plain devam et, continue, or go ahead as an explicit invocation of the exact task only when the immediately preceding assistant result newly returned exactly one tracked task with Contract status: ready and its exact ID/path. Resolve that task as initial execution. Do not auto-select when that result contains zero or multiple ready tasks, an unrelated user request intervened, or the exact identity is unavailable; require an ID/path or use normal routing.

Before classifying bug feedback, treat an unambiguous statement such as AC-1'i onaylıyorum, kriterleri onaylıyorum, or I accept the criteria as a verification continuation when it names an exact task or the conversation retains exactly one unambiguous task. Record the named criteria, or all criteria when the statement unambiguously covers all of them, as PASS with Verification: explicit user acceptance at the current reviewed revision. Do not require a test log, screenshot, artifact, reproduction, or additional proof, and do not alter defect rows. When the ledger is populated or a CycleContext exists, forward the accepted criteria to task-cycle under its existing lifecycle ownership instead of writing a competing direct transition. Generic praise, a question, or a conditional statement is not acceptance.

1. Treat an observation such as still broken, a failed manual/playtest check,

or a new screenshot/log after an implementation or verifier handoff as post-implementation feedback when it names or uniquely resolves an active production/tasks//contract.md. This trigger applies to plain chat feedback; the operator does not need to type a slash command.

1. On direct feedback, do not edit, create a replacement task, or decide

same-task scope yourself. Invoke $task-bug [] internally while preserving every observation and attachment. The intake skill owns exact/automatic task matching; task-cycle alone splits, relates, deduplicates, links defects/D-xxx.md, and writes defect ledger rows. Any D-xxx found in conversation or a prior summary is a candidate only. Do not announce confirmed reuse, recurrence, reopen, root cause, or a chosen code fix before task-cycle returns canonical evidence.

1. If that tracked task is closed, forward the feedback to task-bug too.

Its downstream cycle reopens it automatically only when the observation fails existing acceptance/preserved behavior and remains inside accepted ownership and risk. New scope still returns NEW_TASK_REQUIRED; wider authority returns CONTRACT_CHANGE_REQUIRED.

1. Proceed directly only for initial execution, a contractless ad-hoc task, or

an internal task-cycle handoff carrying CycleContext: ID, attempt, fingerprints, every unresolved D-xxx ID with its exact repro, and failed/unproven criteria. Return defect-specific evidence directly to the active cycle in the last case; do not transition ledger rows yourself.

This router is automatic. Do not ask the operator to type another command for feedback that can be safely forwarded.

1. Resolve repository and input

1. Use the current repository unless --repo or --project identifies one

other exact path or unique repository name. This selects the repository; it grants no write scope. Never guess between ambiguous repositories.

1. Read repository-local AGENTS.md, CLAUDE.md, their declared reading order,

and nearest path-scoped instructions before planning edits.

1. Classify the first positional value as one of:

• an existing repository file path;
• a task ID matching the repository's established ID format (for example

GAME-123), normally a compact key containing a project prefix and digit;

• natural-language work.

1. Resolve a task ID such as GAME-123 only as

production/tasks/GAME-123/contract.md. Match the complete ID, not a loose numeric substring. A missing recognized ID returns CONTEXT BLOCKED; do not fall back to an epic/story or reinterpret it as natural language.

1. An explicit file path wins over ID search. Keep it inside the resolved

repository. If it is a story rather than a task contract, load the story and derive a bounded execution contract without weakening story requirements.

1. Detect the real project topology, engine/runtime version, manifests,

version-control system, nested repositories, and verification commands. Snapshot dirty work and preserve unrelated changes.

Code, manifests, tests, and current runtime evidence outrank stale roadmaps or memories. Report material documentation drift instead of implementing an aspirational architecture that the owning subsystem does not use.

2. Load the canonical task contract

When production/tasks//contract.md or an explicit contract exists, load these fields from it rather than asking the operator to repeat them:

• objective, kind, area, baseline, and expected behavior;
• allowed/forbidden paths, exclusions, and serialized-asset sole writer;
• acceptance criteria and behavior to preserve;
• references, tests, workflow, risk, approval gates, and handoff.

Read Contract status before implementation. draft contracts may be inspected in plan/diagnose mode but must return ACTION_REQUIRED before production mutation. For a legacy contract without a status field, validate that objective, ownership, acceptance, preserved behavior, risk, and verification are complete; do not assume an incomplete artifact is ready. Treat legacy blocked contracts as draft and report their exact Waiting reason plus Action required; never create a new blocked state.

Read current execution state from the contract's delimited TASK-LIFECYCLE block. For a legacy task without that block, read a sibling status.md only as migration context; never create or update status.md. CONTINUE_SAME_TASK identifies remaining work inside the current authority. READY_TO_CLOSE means implementation should not resume without new evidence; direct the operator to $task-done . NEW_TASK_REQUIRED, CONTRACT_CHANGE_REQUIRED, or BLOCKED must not be bypassed. A closed task with new feedback routes through Section 0 instead of being rejected. If code/evidence changed after review, treat prior evidence as stale and continue only within unchanged authority.

Read the managed defect ledger as execution context, never as additional authority. Initial implementation may proceed with an empty ledger. During an internal cycle call, work only on the supplied unresolved defect IDs and their accepted seams. FIXED_UNVERIFIED is the strongest defect state an implementer claim can support; task-cycle owns state transitions and independent verifier evidence is required for VERIFIED.

The direct-initial lane requires all four conditions: no CycleContext, task state ready, Attempt count: 0, and a header-only empty defect ledger. A populated ledger or a resumed in_progress/reopened task with recorded defect work belongs to $task-cycle; dispatch it there rather than mutating production in a second direct lane. An empty-ledger task whose only remaining channel is required user/environment verification stays in the direct non-defect lane: a verification continuation may reacquire this task's lock, run or record the missing verification or explicit user acceptance, and finalize it without changing production. If that continuation produces a real acceptance failure, route the raw observation through $task-bug and let $task-cycle own the defect.

For a direct tracked invocation, before any contract, lifecycle, production, test, or evidence mutation, read and follow ../task-cycle/references/lifecycle-lock.md. Resolve .. from the directory containing the already loaded implement-task/SKILL.md, never from the target repository working directory. Atomically acquire the exact task's shared Git-common-dir lock, confirm its owner token, re-read canonical state under the lock, hold it through the complete direct implementation/verifier handoff, and release it from a finally path only when both the authoritative .lock.claim file and owner.json still contain that exact token. If direct acquisition finds one proven live owner, perform no write and hand the still-authorized invocation to game-studio-orchestration as WAITING_FOR_OWNER. It must wait for owner completion/claim release, revalidate, and retry automatically without another user command. Do not turn a live, ordered owner into a persistent blocked task or request stale recovery. For an internal task-cycle handoff, require the lock path and owner token in CycleContext, re-read and validate them, and reuse the parent lock. Never acquire, replace, or release a nested lock; a missing or mismatched token is BLOCKED: TASK_LIFECYCLE_BUSY.

Also read ../task-cycle/references/reviewed-evidence-identity.md from that same installed skill directory. It is the canonical algorithm for contract fingerprint, reviewed revision, evidence fingerprint, readiness, and later closure checks. If it is unavailable, a direct tracked execution may inspect but must stop before mutation with BLOCKED: EVIDENCE_IDENTITY_PROTOCOL_UNAVAILABLE.

The contract is canonical for this execution boundary. A referenced story/GDD remains canonical for product intent; the contract may narrow execution but may not contradict or weaken that intent.

Command flags that restate contract fields are redundant. Treat an exact restatement as a no-op. If a command flag changes or expands persistent scope, ownership, acceptance, workflow, or risk, stop before mutation:

CONTRACT CONFLICT:
Command attempts to expand or weaken the accepted task contract.
Update the contract before implementation.

List the conflicting contract value and command value. Never merge them by guessing. Invocation overrides may only preserve or increase safety.

3. Apply execution overrides

Only these normally belong on a contract-backed invocation:

• --repo/--project: choose another repository before contract resolution;
• --mode implement|plan|diagnose: select this run's behavior;
• --verify auto|focused|full|built-player: keep or raise evidence depth;
• --context auto|current|history: choose this run's context breadth;
• --dirty-policy preserve|worktree: preserve current work or raise isolation;
• --commit none|after-pass: invocation-local local-commit permission.

Safe defaults are implement, auto, auto, preserve, and none. A stricter contract or detected risk wins. Verification order is focused ] "" when the work should become a durable production contract. Legacy --save-contract auto remains supported; an explicit save path must remain inside the target repository. Without either, the inferred contract is execution-local.

Only follow-ups to a contractless execution-local task may revise its inferred contract. Keep earlier constraints and add new evidence instead of starting a new architecture. Follow-up feedback for a durable tracked task always uses the lifecycle router in Section 0 and never mutates its immutable contract.

5. Enforce ownership and risk

• Low risk: scoped source, focused tests, and evidence may be edited

autonomously within the accepted contract.

• Medium risk: a new assembly/module, public contract, or cross-system boundary

requires a concise plan decision before writing.

• High risk: dependencies, Unity serialized assets, project/global settings,

save/network schemas, migrations, destructive operations, deployment, and releases require exact authorization.

• Independent tasks use separate branches/worktrees and disjoint ownership.
• One task's implementer, verifier, and bugfixer hand off sequentially.
• A Unity serialized asset has exactly one writer.

Use subagents only for useful read-only work or independent disjoint changes. Never let orchestration expand the contract.

6. Inspect, implement, and verify

1. Reproduce a bug or capture a comparable performance baseline when practical.

For cycle work, establish a deterministic failing signal for each supplied defect at its original public/runtime seam before changing code when that seam is available.

1. Select the smallest relevant installed skills and role guidance.

A Unity-shaped repository or a contract that targets Unity runtime, Editor, C#, assets, tests, UI, input, animation, physics, or build behavior must first invoke the installed unity-preflight skill. Stop before mutation when its exact-repository, transport, ownership, dirty-work, or verification-readiness result blocks execution. After preflight passes, invoke the installed unity-game-dev skill before Unity-specific diagnosis, planning, production/test mutation, or verification. Both remain mandatory when the call came from task-cycle; lifecycle skills do not replace preflight or domain expertise. Add unity-optimization for measured performance work or another specialized skill only when the task actually needs it. Do not load every Unity skill by default.

1. Preserve established architecture and naming; do not introduce a competing

framework or migrate adjacent systems incidentally.

1. Make surgical edits only inside the accepted contract and add focused tests

for changed expected behavior where supported.

1. On the first genuine execution transition, update only the contract's

managed lifecycle block to in_progress while holding the direct invocation lock; do not create status.md. When called by task-cycle, let the cycle own lifecycle transitions and keep using its validated parent lock.

1. Run focused checks first, then compilation/build and broader checks required

by the effective verification depth and risk.

1. Separate pre-existing failures from regressions. Do not regenerate golden

fixtures merely to force a pass. A nearby green test does not prove a reported runtime symptom; rerun the original repro and required regression channel after the fix.

1. For Unity, use the installed CLI first, prove the exact target with

unity status --json, and pass --project-path when needed. If CLI/Pipeline is unavailable or insufficient, use exact-project Unity MCP, then target-matched UnitySkills. Never duplicate a mutation across transports, and edit Unity YAML manually only as a last resort.

1. Inspect the final diff for containment, generated churn, secrets, and

acceptance coverage.

1. Build an acceptance-to-verification matrix using each channel required by

the contract. A criterion may be verified by an automated test, manual verification, or explicit user acceptance. Automated tests cannot

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: furkantokkan
• Source: furkantokkan/agent-foundry
• License: MIT

Install and usage instructions live in the source repository linked above.