feature-delivery

어떤 스킬인가요?

Classify software work from T0 trivial through T4 critical, then orchestrate repository-grounded planning, specialized delegation, adversarial architecture review, implementation, testing, visual work, debugging, documentation, and acceptance with dynamic escalation. Use when the user asks to build, implement, fix, refactor, continue, or plan software work and wants quality, speed, and cost balanced automatically.

설치 방법

프로젝트 폴더에서 아래 명령어를 실행하고, 설치할 에이전트를 선택하세요.

설치 명령을 직접 실행해야 적용됩니다. 지원 에이전트와 필요한 권한·라이선스는 제작자의 안내를 확인하세요.

스킬 원문 파일

interface:
  display_name: "Feature Delivery"
  short_description: "Classify, orchestrate, and verify feature delivery"
  default_prompt: "Use $feature-delivery to classify this request from T0 to T4 and run the appropriate verified delivery workflow."

# Repository-driven API artifact synchronization gate

Use this reference only when API endpoints, contracts, authentication, requests, responses, or errors change **and** the repository designates an authoritative API artifact or workflow. This gate is tool-agnostic: it may cover Postman, OpenAPI, Bruno, or another artifact only when that artifact is authoritative in the repository.

Follow repository policy for the target artifact, commands, skills, approvals, and access. Update the designated artifact only when authorized. Do not create a duplicate collection, specification, workspace, or replacement workflow; do not infer a preferred tool or guess a target. Keep examples non-secret and synchronize the changed contract, authentication behavior, requests, responses, errors, and dependency-ordered flows that repository policy requires.

Verify synchronization using the repository-designated command or integration. If the repository has no authoritative API artifact, or the change does not trigger synchronization, record `API artifact gate: not applicable`. If a required authoritative artifact exists but access is unavailable, report the gate as blocked rather than passed.

# Effective fleet routing and preflight

`delegate-fleet.v1` is the source of truth for lane bindings and relay dials. It does not decide task tier or workflow order; this skill does.

## Load without mutation

Locate the installed `delegate-setup` skill and run its read-only loader for the target repository:

```bash
node "<delegate-setup-skill>/scripts/config.mjs" load --cwd "/path/to/repo"
```

Use the effective merged lanes. Project lanes replace same-named global lanes. If project config exists but is untrusted, do not dispatch it; ask the user to review and approve it through `$delegate-setup`. Never edit fleet files during feature delivery.

## Expected responsibility lanes

| Responsibility | Preferred lane | Expected implementer |
| --- | --- | --- |
| Repository evidence | `explore` | Kimi |
| Tiny/fast implementation | `fast` | Kimi |
| Main implementation and fixes | `feature` | Kimi |
| Tests and bounded mechanical work | `tests` | OpenCode |
| Difficult debugging | `debug` | OpenCode with Z.AI GLM-5.2 model |
| UI/responsive/visual QA | `ui` | Antigravity (`agy`) |
| Images/icons/illustrations/assets | `assets` | Antigravity (`agy`) |
| Independent implementation review | `review` | Codex |
| Adversarial architecture critique | `architecture` | Codex GPT-5.6 Sol, high effort |
| Post-stability documentation | `docs` | OpenCode capable free model |

These are responsibility contracts, not permission to rewrite the fleet. Manual user lane/model overrides win when safe. If a preferred lane is absent, inspect the effective map for an explicit compatible equivalent. Ask before substituting when independence, cost, or capability would change.

## Dispatch rules

Load only the selected `*-delegate` skill immediately before use. Preflight that lane's executable, authentication, model, and dials; do not probe unrelated tools. Dispatch with the configured lane so the relay resolves and validates its own binding:

```bash
node "<delegate-skill>/scripts/relay.mjs" --brief brief.txt --lane "<lane>" --cd "/path/to/repo"
```

Do not invent model identifiers or bypass an unavailable/untrusted lane with an implicit CLI default. Preserve these ownership rules:

- Kimi is the default explorer, implementer, and fixer. Prefer its standalone subscription/configured alias rather than routing Kimi through OpenCode.
- Codex is an independent challenger/reviewer, not the default implementation worker. T3/T4 architecture critique requires verified `gpt-5.6-sol` with high effort; stop for an explicit override if the active binding cannot provide it.
- OpenCode owns tests, bounded low-cost work, difficult GLM debugging, and free-model documentation according to its lane binding.
- GLM-5.2 runs through OpenCode/Z.AI Coding Plan; never treat it as a standalone CLI.
- Antigravity owns visual/UI/assets work when applicable. Prefer existing suitable assets over generating replacements.
- Claude remains outside the fleet as the top-level orchestrator and decision-maker.

## Failure and escalation

Return implementation or review findings to the same responsible implementer. Do not dispatch multiple premium agents to implement the same surface. Run independent Codex critique/review in a separate delegated process/session; the orchestrator's own reasoning cannot satisfy that gate. Invoke the debug lane when a meaningful failure persists after one evidence-based correction and rerun, or standard inspection/output cannot localize a cross-component/runtime cause. A failed or unavailable optional docs/visual lane does not authorize undocumented behavior or unverified visuals; report the limitation and complete only what can be accepted safely.

## `delegate-fleet.v1` limitations

The schema stores named lane → implementer plus optional model/effort/variant/timeout/read-only dials. It cannot encode:

- T0–T4 classification or detection rules;
- workflow sequencing, conditions, escalation, or stop criteria;
- Claude's orchestrator role or final decision authority;
- architecture-debate rounds and objection dispositions;
- independence requirements between implementation and review;
- “docs only if affected” or “debug only if stuck” semantics;
- shared state, outputs, or acceptance criteria between stages.

Those behaviors therefore live in `feature-delivery` instructions and are enforced by the active orchestrator. Fleet validation can prove a lane binding is syntactically valid and trusted; it cannot prove the workflow was followed.

# Tiered orchestration workflows

Claude owns classification, routing, decisions, acceptance criteria, and final verification. If the user explicitly overrides the orchestrator, references to Claude in this document mean that active orchestrator for the run. Keep stages conditional and avoid orchestration work that cannot improve the result.

## T0 — Ultra fast

`Claude route → Kimi fast implementation → targeted validation → done`

- Use the `fast` lane.
- Skip exploration reports, architecture debate, Codex review, GLM debugging, and OpenCode tests unless repository evidence makes one genuinely necessary.
- Kimi may update the minimal directly affected test at this level. Targeted validation means diff inspection plus the narrowest existing relevant check; do not add broad test infrastructure for a literal mechanical change.
- Update documentation only when documented behavior changed.

## T1 — Fast

`Claude route → Kimi implementation → relevant checks/tests → Kimi fixes failures → docs if affected → Claude acceptance → done`

- Use `fast` or `feature` according to the effective fleet.
- Kimi may update directly affected localized tests at this level.
- Keep validation targeted. Do not invoke expensive reasoning unless findings force escalation.

## T2 — Standard

`Kimi explore → Claude plan → Kimi implement → OpenCode tests → Antigravity visual/UI/assets work when applicable → Codex independent review → Kimi fixes validated findings → Claude acceptance → docs if affected`

- Exploration is evidence gathering, not architecture design.
- Use the `explore`, `feature`, `tests`, optional `ui`/`assets`, `review`, and optional `docs` lanes.
- OpenCode owns new or changed tests at T2+; Kimi must not independently duplicate that test work.
- Do not run the Claude–Codex architecture debate for ordinary T2 work.
- If Antigravity owns a UI/visual surface, Kimi must not independently implement the same surface. Re-run affected checks after visual work.
- Claude's acceptance at this stage establishes implementation stability. Run one final landing check after any affected documentation is updated.

## T3/T4 — Full

1. Kimi explores through the `explore` lane and produces repository evidence only.
2. Claude writes the initial architecture proposal.
3. Codex uses the `architecture` lane as an adversarial reviewer with verified `gpt-5.6-sol`, effort `high`. If that required binding is unavailable, stop for an explicit override instead of silently weakening the debate.
4. Claude labels every objection `ACCEPT`, `PARTIALLY ACCEPT`, or `REJECT` with repository evidence and rationale.
5. Codex receives one final challenge round.
6. Claude makes the authoritative decision and writes the implementation plan and acceptance criteria.
7. Kimi performs the main nonvisual implementation through `feature`.
8. OpenCode owns tests through `tests`.
9. Antigravity owns applicable UI, responsive, visual, image, icon, illustration, and asset surfaces through `ui` or `assets`.
10. Run repository build, analysis, and tests.
11. Invoke `debug` only for difficult unresolved build, test, runtime, log, or root-cause failures. The expected binding is OpenCode with Z.AI Coding Plan `zai-coding-plan/glm-5.2`; GLM is not a standalone CLI.
12. Codex performs an independent final implementation review through `review`.
13. Kimi fixes findings that Claude validates.
14. Claude verifies every acceptance criterion.
15. If documentation is affected, use `docs` after stability; the expected low-cost binding is `opencode/deepseek-v4-flash-free`.
16. Run a final landing check after documentation. The implementation acceptance decision remains Claude's.

The authoritative plan must assign non-overlapping surfaces such as backend behavior, migration tooling, deployment configuration, tests, and UI. Kimi may fix implementation defects in its owned surfaces; OpenCode owns T2+ test files; Antigravity owns assigned visual surfaces.

An independent Codex critique or review must run in a separate delegated process/session with a fresh bounded brief and repository evidence. The active orchestrator's own reasoning never counts as the required independent Codex pass, even when Codex is the manually overridden orchestrator.

### Bounded architecture debate

Kimi's exploration report must identify relevant modules/files/symbols, current architecture, similar implementations, state/data flow, APIs, tests, platform/flavor behavior, regression areas, and constraints from code. Kimi must not design the solution in this phase.

Codex must try to disprove Claude's proposal: challenge assumptions, architecture, accidental complexity, simpler alternatives, regressions, state/concurrency, security, performance, edge cases, and tests. Ground disagreements in repository evidence whenever possible.

Allow at most two Codex challenge rounds: the initial critique and one final challenge after Claude's evaluation. Stop after Claude's final decision; agreement is not required.

## Dynamic escalation

- T0/T1 → T2 when the change reaches shared behavior, multiple coupled surfaces, or needs independent review.
- T2 → T3 when architectural, cross-module, state/data-flow, concurrency, or substantial regression complexity appears.
- Any level → T4 when a critical trigger is discovered.
- Any implementation → `debug` when the same meaningful build/test/runtime failure persists after one evidence-based correction and rerun, or when standard code inspection and command output cannot localize a cross-component/runtime cause. A first ordinary failure alone is not enough.
- Any level → `ui`/`assets` when UI, responsive behavior, visual QA, screenshots, images, illustrations, or icons become necessary.

On escalation, stop dispatching under the old workflow, record the evidence, re-run prerequisites, preserve verified work, and resume at the first missing stage of the stronger workflow. Do not repeat already sufficient work or duplicate implementation.

# Delegated task brief

Read this reference only immediately before writing or dispatching a delegated task. Write one compact English XML brief for the current task:

```xml
<task id="...">
  <goal>One bounded outcome.</goal>
  <current_state>Relevant repository evidence only.</current_state>
  <prerequisites>Passed prerequisites and landed dependencies.</prerequisites>
  <scope>Exact files or narrow surfaces allowed to change.</scope>
  <leave_untouched>Forbidden surfaces and confirmed decisions.</leave_untouched>
  <requirements>Deterministic behavior, edge cases, and constraints.</requirements>
  <acceptance_criteria>Observable pass conditions.</acceptance_criteria>
  <verification_loop>Real repository commands; fix failures.</verification_loop>
  <action_safety>No unrelated refactor; no git add, commit, push, deploy, or remote migration.</action_safety>
  <report_contract>At most eight bullets: changed files, behavior, tests, deviations, blockers.</report_contract>
</task>
```

The brief must include the selected lane, resolved delegate and fleet dials, routing reason, applicable gates, and actual repository verification commands. Omit unresolved optional dials rather than inventing a model or alias. Direct the implementer to stop on contradictions or newly missing prerequisites instead of guessing, expanding scope, changing confirmed architecture, or adding workarounds. Give exact target paths and leave-untouched surfaces, preserve unrelated changes, and keep a fresh brief below 600 words unless safety requires more; split it otherwise.

One brief covers one independently verifiable behavior or artifact and one review boundary. Stronger models do not justify broader briefs. The implementer edits; the orchestrator independently reviews, requests correction from the same implementer when needed, verifies, and lands.

# T0–T4 task classification

Use the highest triggered level. File count is supporting evidence, not a classifier by itself.

| Level | Detection signals | Priority |
| --- | --- | --- |
| T0 — Trivial | Mechanical, isolated, obvious change such as typo, copy, spacing, rename, tiny UI adjustment, or very small config edit; no behavior ambiguity, shared contract, data/schema, security, concurrency, or meaningful regression surface | Maximum speed |
| T1 — Simple | Localized bug, validation, mapping, UI behavior, or straightforward modification with a known pattern and narrow blast radius; targeted checks can establish correctness | Speed with targeted validation |
| T2 — Standard | Normal feature or contained business logic/integration spanning related files; needs planning, implementation tests, and independent review but not architecture debate | Balanced quality, speed, and cost |
| T3 — Complex | Cross-module behavior, significant state/data-flow change, major refactor, architectural decision, unfamiliar integration, concurrency, or substantial regression surface | Quality and architectural correctness |
| T4 — Critical | Authentication/authorization, payments/refunds, security-sensitive behavior, database migrations, destructive or irreversible operations, sensitive data flows, core architecture, or failure with serious production impact | Maximum correctness and independent verification |

## Decision rules

1. Apply T4 hard triggers first. A tiny code diff does not lower authentication, payment, migration, destructive-operation, or sensitive-data work below T4.
2. Otherwise choose T3 when correctness depends on cross-module or architectural reasoning rather than a contained implementation plan.
3. Otherwise choose T2 when ordinary feature work benefits from separate exploration/planning, tests, and review.
4. Otherwise choose T1 when the behavior changes but remains isolated and directly testable.
5. Use T0 only when the change is mechanical and its risk is genuinely negligible.

Classify from request evidence, then confirm after grounding. Upgrade at any time. Downgrade only before the first dispatch when repository evidence disproves the original risk signal, and record why. A manual user override can select a stronger workflow or preferred lane; it cannot suppress mandatory safety gates.

Examples are illustrative, not exhaustive. Consider blast radius, coupling, novelty, reversibility, production exposure, data/security sensitivity, and the cost of a false pass.

# Repository-driven UI delivery gate

Use this reference only when the canonical specification changes user-facing UI/UX and repository policy makes a UI gate relevant. The repository defines the authoritative design, instructions, skills, assets, commands, approvals, and verification expectations; do not invent a replacement workflow.

Load only the repository-required design/UI skill or instructions. Obtain required shape approval before mutation unless an approved shape already exists. Put measurable layout, spacing, typography, color, responsive behavior, RTL/LTR behavior, accessibility, interaction, loading, empty, error, and permission states in bounded component briefs. Add required assets to the repository first and cite their exact paths.

Verify the repository-required viewport sizes, states, real flows, keyboard access, and RTL/LTR behavior as applicable. If the trigger is absent, record `UI gate: not applicable` without loading this reference or adding UI process.

---
name: feature-delivery
description: Classify software work from T0 trivial through T4 critical, then orchestrate repository-grounded planning, specialized delegation, adversarial architecture review, implementation, testing, visual work, debugging, documentation, and acceptance with dynamic escalation. Use when the user asks to build, implement, fix, refactor, continue, or plan software work and wants quality, speed, and cost balanced automatically.
---

# Feature Delivery

Claude is the default primary orchestrator: understand the natural-language request, classify it, choose the workflow, make architecture decisions, and perform final acceptance. Do not ask the user to select lanes for ordinary work. Honor an explicit workflow, tier, lane, delegate, model, or orchestrator override when it does not violate repository or safety constraints. When another host explicitly invokes this skill, treat that as a manual orchestrator override; do not pretend that host is Claude.

Optimize quality, speed, and cost together. Specialize agents instead of paying multiple premium agents to implement the same behavior.

## 1. Ground and gate

Preserve the request and discuss it in the user's language. Before planning or delegation, read the nearest `AGENTS.md`; repository status and relevant diff; named architecture, ERD, product, design, status, and execution docs; and relevant code, tests, migrations, configuration, and deployment setup. Repository and user rules are authoritative. Preserve unrelated changes and confirmed architecture/schema decisions.

Identify required earlier delivery steps, migrations, APIs, config, credentials, infrastructure, UI foundations, tests, fixtures, observability, security, and deployment dependencies. If a prerequisite is missing, stop before planning or delegation and state what is missing, why it is required, the correct order, and the needed decision or access. Ask only blocking ambiguity questions; state safe reversible assumptions.

## 2. Classify before dispatch

Read [task-classification.md](references/task-classification.md). Assign the highest applicable T0–T4 level using blast radius, coupling, novelty, reversibility, data/security sensitivity, and verification burden—not estimated file count alone. Record the level and a one-sentence evidence-based reason. Classification is provisional until repository grounding finishes.

Upgrade immediately when execution reveals higher risk or complexity. Re-run the prerequisite gate and switch to the stronger workflow from the next safe boundary. Never use a user override to bypass required security, data, migration, or architecture safeguards.

## 3. Resolve the effective fleet

Before the first planned dispatch, use the installed `delegate-setup` helper to load the effective `delegate-fleet.v1` map for the repository. Do not rewrite bindings during delivery. Read [delegation-routing.md](references/delegation-routing.md) to map workflow responsibilities onto the current lanes and preflight only a lane immediately before using it.

If a required lane is absent, unavailable, unauthenticated, or bound incompatibly, use an explicitly approved equivalent lane if present; otherwise stop or omit only an optional stage. Never infer authorization from an installed CLI, silently change the fleet, or silently replace a required independent reviewer with the implementer.

## 4. Specify and execute the tier workflow

Create a compact canonical English specification:

```text
Outcome:
Users and behavior:
In scope / out of scope:
Repository evidence and constraints:
Acceptance criteria:
Assumptions and resolved decisions:
Verification expectations:
```

Read [orchestration-workflows.md](references/orchestration-workflows.md) and execute the selected T0–T4 sequence. Present only the level, reason, material stages, and meaningful conditional gates; do not expose internal overhead for tiny work. Keep one implementation owner per surface. Parallelize only independent work with no shared files or decisions.

Immediately before each dispatch, read [task-brief-template.md](references/task-brief-template.md). Give the delegate one bounded English brief with exact scope, acceptance criteria, repository constraints, and real verification commands. The orchestrator reviews and lands; delegates do not commit, push, deploy, or run remote migrations unless separately authorized.

## 5. Apply conditional gates

- For material UI composition, responsive behavior, visual QA, image, icon, illustration, or asset work, read [ui-delivery.md](references/ui-delivery.md). Use the visual lane without duplicating the same implementation in Kimi. Keep a tiny isolated T0 UI adjustment on `fast` unless repository policy or discovered visual risk requires escalation.
- For API changes, read [api-synchronization.md](references/api-synchronization.md) only when the repository identifies an authoritative API artifact.
- Invoke difficult debugging only after ordinary diagnosis or checks fail, not preemptively.
- Update documentation only after implementation and verification are stable, and only when observable behavior, setup, API, environment variables, architecture notes, changelog, or useful comments changed.

## 6. Review, correct, verify, and land

Treat every delegate report as an unverified claim. Inspect changed tests and the full diff for scope creep, architecture drift, weakened coverage, regressions, swallowed errors, security/performance/concurrency issues, speculative abstractions, duplication, and unverified APIs. Re-run relevant repository checks yourself.

Return validated defects to the responsible implementer first. Do not have another premium agent reimplement the same feature. If failures expose higher risk, escalate the tier; if runtime/build/test diagnosis becomes genuinely difficult, invoke the debug lane. After correction, re-review the affected surface.

Claude performs the final acceptance check against the authoritative plan and criteria. Land only verified work. Commit only when authorized; push, deploy, alter external tracking, or mutate remote data only with explicit authorization. Report the final tier, any escalation, lane/model summary, delivered outcome, verification, affected documentation, landing state, blockers, and any `delegate-fleet.v1` limitation encountered.