Skip to main content

Implement Feature

Coordinate feature implementation as a master coordinator with non-master subagents. Use when the user asks to implement a feature, execute a spec, build a multi-step change, assign subagents, use worktrees, or run a master checklist with QA and code review gates. The master coordinates only; implementation code must be written by non-master subagents.

Source: .agents/skills/implement-feature/SKILL.md

Metadata​

  • name: implement-feature

Content​

Implement Feature

Use this skill when a feature needs coordinated implementation across tasks, subagents, worktrees, QA, and code review. This is a master-coordinator workflow. The master agent owns requirements, planning, delegation, subagent management, verification orchestration, integration decisions, and handoff. The master agent does not perform the actual implementation work.

Worker-Only Implementation Rule​

The master agent must not directly edit feature implementation code, even when the user asks to implement the feature. "Multiple agents" means the master coordinator plus at least one separate non-master implementation subagent. QA and code review should also be delegated to separate agents when platform support is available.

If work cannot reasonably be delegated, the master agent must narrow the scope, split the task, create a subagent assignment, or stop and report the blocker. It must not fall back to direct implementation.

Terminology​

In this skill, subagent is the explicit term for the non-master implementation worker, task owner, implementer, or worktree-backed task thread. The master agent plans, assigns, manages, reviews, and coordinates integration of subagent work; subagents perform the actual code or document changes.

Hard Gate​

Do not start coding, spawn implementation subagents, or assign implementation tasks until the master agent has:

  1. Clarified or marked not applicable all required inputs.
  2. Loaded repo rules and relevant feature context.
  3. Classified API/backend dependencies as provided, ui-only, blocked, or not-applicable.
  4. Identified dependencies and likely file ownership.
  5. Completed a page/file placement and duplication check for new or substantially changed code.
  6. Created the master checklist in chat/task tracker.
  7. Created the temporary resumable plan file.
  8. Assigned each implementation task to a specific non-master subagent/thread and worktree.
  9. Confirmed every repo-editing integration task, if any, is assigned to a dedicated non-master integration subagent.

If any item is missing, stop and complete it before implementation begins.

Required Context​

Load these before task breakdown:

  • AGENTS.md
  • .agents/rules/*.mdc
  • .agents/skills/feature-context/SKILL.md
  • Relevant .agents/references/features/*.md
  • Relevant .agents/references/coding-standard/*.md
  • .agents/skills/code-review/SKILL.md

Use feature references as context only. Live code inspection is still required before assigning subagent task scopes.

Flow​

Workflow​

  1. Clarify requirements

    • Follow .agents/references/implementation/requirements-clarification.md.
    • Ask for a Lark channel link when it may contain product, API, QA, or rollout context. If no link is provided, explicitly record it as skipped or not applicable and continue.
    • If API docs are missing, offer a UI-only implementation option before treating the missing API as a blocker.
    • If UI-only is selected, record excluded API work and do not invent API contracts, service methods, response shapes, backend behavior, backend error handling, or end-to-end API tests.
    • Ask blocking questions before checklist creation.

  2. Create the master checklist

    • Follow .agents/references/implementation/master-checklist-template.md.
    • Keep the checklist live in chat/task tracker and mirrored in a temporary repo plan file.
    • Record whether a Lark channel link was provided, skipped, or not applicable.
    • Record API integration mode and any UI-only exclusions in the dependency section.
    • For new pages, shared components, services, utilities, or substantial refactors, record the placement decision and duplication search required by .agents/references/coding-standard/page-structure.md.

  3. Assign worktrees and subagents

    • Follow .agents/references/implementation/worktree-assignment.md.
    • Implementation task branch names must start with feat/, unless the user provides a different branch naming convention.
    • Prefer Codex subagent/thread/worktree tools when available.
    • Fall back to manual git worktree instructions when tools are unavailable.
    • Assign every implementation task to a non-master subagent. The master agent may write prompts, checklists, and summaries, but must not own a feature-code write scope.
    • After creating each new worktree, copy .env and .env.* files from the source checkout into the new worktree, or record that no env files existed in the source checkout.
    • When splitting work into tasks, every task assignment must explicitly mention creating or using the assigned subagent/thread for that task. Do not leave a split task as an unowned checklist item.
    • If a task is too small for a dedicated subagent, merge it into another delegated subagent task or record why it is only planning/coordination work. Do not keep implementation work with the master agent.
    • Assign write scopes so page-local code, shared components, services, and utilities each have a clear subagent.
    • Record which conflicts each subagent is responsible for resolving if their branch/worktree falls behind or collides with a dependency.

  4. Dispatch implementation tasks

    • Use .agents/references/implementation/subagent-prompts.md.
    • Each subagent owns exactly one implementation task and one disjoint write scope.
    • At least one non-master implementation subagent is required before implementation can begin.
    • The dispatch prompt must name the subagent/thread, the task ID, the worktree path, and the write scope. If the subagent still needs to be created, include that creation step before implementation instructions.
    • Tell subagents they are not alone in the codebase, must not revert others' work, and must resolve task-scoped conflicts correctly before reporting completion.

  5. Run QA and code review loops

    • Follow .agents/references/implementation/qa-and-review-loop.md.
    • A task is not complete until implementation, QA, and code review all pass.
    • Failed QA or review feedback goes back into the master checklist.

  6. Integrate and clean up

    • Coordinate merge or application of passed task outputs in dependency order.
    • If integration requires repo edits beyond mechanical merge/application, assign those edits to a dedicated non-master integration subagent with an explicit write scope and conflict policy.
    • Run final verification for the whole feature.
    • Create or update the relevant .agents/references/features/*.md file with durable feature context from the implemented work before final completion. Use .agents/references/features/_template.md for a new feature reference, and keep one-off branch details out of the reference.
    • Follow .agents/references/implementation/plan-file-lifecycle.md and delete the temporary plan file after all tasks pass and integration is complete, unless the user explicitly asks to preserve it.
    • After pushing feature changes to the remote branch, run .agents/skills/pr-description/SKILL.md so the PR title and description match the pushed branch diff.

Master Agent Responsibilities​

  • Clarify requirements and design details.
  • Ask for a Lark channel link when useful for requirement context, but do not block implementation if the link is not provided and can be skipped.
  • Classify API/backend dependencies and choose whether missing API docs mean ui-only, blocked, or not-applicable before task assignment.
  • Break work into small, independently executable tasks.
  • Check whether new files should be page-local or shared, and search for reusable existing code before assigning implementation.
  • Avoid parallel tasks that write the same files.
  • Keep the master checklist current.
  • Assign each implementation task to a specific non-master subagent/thread and worktree.
  • Ensure every subagent resolves conflicts in their own write scope, while cross-task or integration conflicts are escalated to the master agent or a dedicated integration subagent.
  • Review subagent reports before QA/review dispatch.
  • Reassign failed tasks with exact feedback.
  • Preserve durable implementation learnings by writing or updating the matching feature reference under .agents/references/features/.
  • Own final integration decisions, verification orchestration, and summary.

The master agent must not directly implement task code. If implementation work cannot reasonably be delegated, the master agent must split it differently, re-scope it, ask for direction, or mark it blocked. User requests to "just implement it" still go through non-master subagent assignment.

Completion Criteria​

The feature is complete only when:

  • Every checklist task is passed or merged.
  • Every implementation task was completed by a non-master subagent in an assigned worktree.
  • Any repo-editing integration work was completed by a dedicated non-master integration subagent.
  • QA issues are resolved.
  • Code review issues are resolved using .agents/skills/code-review/SKILL.md.
  • Relevant tests/checks pass.
  • No unrelated files are changed.
  • Any conflicts were resolved by the responsible subagent or integration subagent and reviewed before merge.
  • Acceptance criteria are satisfied.
  • API integration mode is resolved; UI-only work has no invented service contracts or backend behavior.
  • The matching .agents/references/features/*.md file is created or updated with durable context from the implemented feature, including routes/components/hooks/services, data flow, gotchas, and useful searches.
  • The temporary master checklist plan file is deleted or intentionally preserved by user request.
  • After pushed changes, .agents/skills/pr-description/SKILL.md has been run to update the PR title and description from the branch diff.
  • Final summary is prepared.

References​

  • .agents/references/implementation/requirements-clarification.md
  • .agents/references/implementation/master-checklist-template.md
  • .agents/references/implementation/worktree-assignment.md
  • .agents/references/implementation/subagent-prompts.md
  • .agents/references/implementation/qa-and-review-loop.md
  • .agents/references/implementation/plan-file-lifecycle.md
  • .agents/skills/pr-description/SKILL.md