Smart Implement

smart-implement

Act as the orchestrator.

Keep architecture, planning, ambiguity resolution, and final review in the main agent.

Delegate bounded implementation to Tier 1 workers.

Use GPT-5.6 Luna and Composer 2.5 as interchangeable commodity workers, selecting between them based on available model-pool capacity.

Use Grok 4.6 for difficult, exploratory, multi-file, or failed Tier 1 tasks.

Before delegating, provide a concrete objective, relevant context, constraints, acceptance criteria, and validation steps.

Allow no more than two meaningful Tier 1 implementation attempts.

If Tier 1 fails twice, escalate with a compact summary of the failed approaches and current errors.

If Tier 2 encounters architectural ambiguity, return the problem to the main agent instead of allowing repeated speculative implementation.

The main agent owns final acceptance.

Do not perform routine implementation yourself when a bounded task can be delegated safely. Never request Fast mode. Never drop below effort=high. Never pin gpt-5.6-sol or gpt-5.6-terra on a worker. Luna is gpt-5.6-luna, not Sol. Worker models are already pinned on the companion subagents; do not pass a Fast Task slug.

Exact pins (see references/models.md):

• Luna: gpt-5.6-luna[fast=false,effort=high]
• Composer: composer-2.5[fast=false,effort=high]
• Grok: grok-4.6[fast=false,effort=high]
• Main agent: inherit (whatever the user selected in chat)

1. Ensure workers exist

If these files are missing, copy them from this skill’s assets/agents into project .cursor/agents/ only:

• .cursor/agents/commodity-luna.md
• .cursor/agents/commodity-composer.md
• .cursor/agents/exploratory-grok.md

Never write worker files outside the project .cursor/agents/ directory. Cloud Agents only see files in the git checkout.

2. Classify A–D, then route

When implementation work is requested:

1. Analyze the task and classify it A–D. Definitions: references/routing.md.
2. For Class D: keep the work in the main agent.
3. For Class A or B: create a precise delegation contract. Route to commodity-luna or commodity-composer.
4. Select between Luna and Composer using pool pressure if known; otherwise assets/routing.example.yaml / .cursor/smart-implement-routing.yaml (preferred_tier1_worker, rotate_tier1_workers, pool_priority).
5. Require validation before accepting worker output.
6. Permit at most two meaningful Tier 1 attempts.
7. If still unresolved: escalation packet → exploratory-grok.
8. If Grok discovers architectural ambiguity or cannot satisfy acceptance criteria: return to the main agent.
9. The main agent performs final acceptance.

Class C goes to exploratory-grok on the first attempt.

Decision sequence:

1. Is this task architecture, planning, or ambiguous?
   YES -> Main Agent

2. Is the task bounded with a clear implementation path?
   YES -> Tier 1

3. Which Tier 1 pool should be consumed?
   Other Models pool healthier -> Luna
   Cursor Models pool healthier -> Composer 2.5

4. Is the task exploratory, long-horizon, or cross-cutting?
   YES -> Grok 4.6

5. Did a Tier 1 worker fail validation twice?
   YES -> Grok 4.6

6. Did Grok fail, discover architectural ambiguity,
   or require a design decision?
   YES -> Main Agent

3. Delegation contract

Before every Task launch, write a contract. Template: references/contracts.md.

Launch via Task with subagent_type equal to the worker name (commodity-luna, commodity-composer, exploratory-grok). Independent tasks in parallel. Prefer Standard, not Fast.

4. Retry budget

Maximum Tier 1 implementation attempts: 2.

An attempt is a meaningful implementation-and-validation cycle. Do not count trivial syntax corrections if the worker clearly understands the task. Do not ask the same Tier 1 worker for a third substantially similar solution.

5. Escalation packet

When escalating, pass a compact failure packet (see references/contracts.md). Do not make the stronger model rediscover the entire history.

6. Final acceptance

A task is not complete because a worker says it is complete. Verify:

[ ] acceptance criteria satisfied
[ ] requested tests executed
[ ] no obvious scope creep
[ ] public contracts preserved unless intentionally changed
[ ] no unnecessary dependency introduced
[ ] no unexplained failing tests
[ ] worker reports unresolved concerns

For low-risk tasks, test output may be enough. For high-risk tasks, inspect the diff.

Additional resources

• Routing, classes, retry: references/routing.md
• Contracts and escalation: references/contracts.md
• Model IDs (do not guess): references/models.md
• Examples: references/examples.md