SuperAPI AI Directory
Partner中文AI newsFavorites
Skillspeach-team-dev

peach-team-dev

Agents & models

View repository

Updated 10-16 00:23

About this skill

Peach Team Dev

It is an integrated orchestrator that coordinates PeachSolution development. It handles new features, modifications to existing features, and prompt-based ad hoc work, but the implementation basis is always taken from external artifacts and existing code evidence.

Core Responsibilities

  • Performs implementation and code-level verification: TDD, lint, build, API-Store Contract Gate.
  • Verification of user flow and alignment with the plan is peach-team-e2ehanded off to.
  • DB migration creation and application are not done directly. After the mode=backend|fullstack은 peach-gen-dbgenerated by api/db/schema/...is prepared, it is executed.
  • If Spec, schema, and ui-proto conflict or there is no basis, it does not implement by guessing and blocks with DECISION_REQUIRED, DB_DECISION_REQUIRED, DB_CHANGE_REQUIRED.
  • Depending on the request scope and runtime tool availability, select one of single-agent, role-queue, agent-team .

Input Mode

Mode Input Verification Basis Suitable Cases
Standard mode + spec + proto Spec + ui-proto screen Standard path for new features
Spec만 mode + spec docs/spec/... Spec Backend-centric, existing screen modification, simple CRUD
prompt Natural language input prompt text + existing code Bug fixes, ad hoc changes, hotfixes
queue queue=<기능큐.md> Feature-specific Spec/schema/proto Feature-specific state management for large tasks

Because prompt mode has a weak verification basis, small changes are handled lightly, and medium-scale changes are switched to automatic team mode. For large changes with insufficient basis, recommend writing a Spec with peach-gen-specand stop.

Modes

mode Purpose Included Roles
backend API + Store connection based on prepared DB schema backend-dev, backend-qa, store-dev, frontend-qa
ui Implement only Store-based UI ui-dev, frontend-qa
fullstack Generate API + Store + UI based on prepared DB schema backend-dev, backend-qa, store-dev, ui-dev, frontend-qa

Preconditions

Standard Mode

  • docs/spec/{년}/{월}/The Spec file of must exist.
  • The task folder in the ui-proto repository must exist.
  • In modes that require a DB schema, api/db/schema/[도메인]/[테이블].sqlmust exist.

Spec-only Mode

  • In modes that require a DB schema, api/db/schema/[도메인]/[테이블].sqlmust exist.
  • ui In the mode, front/src/modules/[모듈명]/store/[모듈명].store.tsmust exist.
  • If there is no Store, first peach-gen-store, and if there is no UI, generate based on peach-gen-ui .
  • For modification of an existing feature, when docs/기능별설명/{카테고리명}/{기능명}/exists, first read in the order of overview, logic, specification, and TDD.
  • If there is a screen flow summary in the Spec, use it as the minimum basis for the UI flow.
  • If it is a new complex screen but there is no screen flow summary in the Spec, recommend peach-team-ui-proto or Spec reinforcement, and if forced through, leave verification limitations in the completion report.

prompt mode

  • The precondition is natural language input.
  • After estimating the change size, if the DB/permission/state/API contract criteria are insufficient, it is routed to Spec writing.

Inputs

# 표준 모드
/peach-team-dev [모듈명] mode=backend|ui|fullstack spec=<경로> proto=<경로> [옵션]

# 대규모 기능 큐 모드
/peach-team-dev [작업명] queue=<기능큐.md> [proto=<경로>] [옵션]

# Spec만 모드
/peach-team-dev [모듈명] mode=backend|ui|fullstack spec=<경로> [옵션]

# prompt 모드
/peach-team-dev "버그/개선 사항 자연어 설명" [옵션]
Argument Role
[모듈명] Recommended in standard/Spec-only mode. In prompt mode, propose candidates and then confirm
mode Required in standard/Spec-only mode
spec This project's docs/spec/...Spec file path
queue Feature queue document for large tasks. When specified, run repeatedly based on each feature's mode/input/status
proto Absolute path to the task folder in the ui-proto repository
model Optional. Subagent model override. If unspecified, the default is sonnet, allowed values are `sonnet
team Optional. forceforces an agent-team attempt, offprohibits an actual agent-team
e2e Optional. autoruns E2E preflight before development and upon completion automatically runs peach-team-e2e , offdisables the automatic chain
figma, ui, file, excel, storeTdd Optional. Follow the option handling criteria of the reference for each role

E2E chain interpretation:

team-dev만 요청 → E2E 미실행
team-dev + team-e2e 함께 요청 → e2e=auto
사용자가 E2E 제외 명시 또는 e2e=off → e2e=off

Implementation criteria priority

Spec / schema / proto conflict handling

Situation Handling
Spec and schema match Implement based on Spec/schema
Requirement not in Spec discovered Do not implement arbitrarily; record as DECISION_REQUIREDrecorded as
Spec and schema conflict (decision needed) DB_DECISION_REQUIREDSeparate into and request user decision
Spec and schema conflict (change confirmed as needed) DB_CHANGE_REQUIREDSeparate into and peach-gen-db follow-up after
ui-proto and Spec conflict Business/data takes precedence in Spec, screens/flows take precedence in ui-proto. Do not auto-merge

Since ui-proto is a Mock artifact, team-dev uses it as a reference for code structure and event implementation. Whether it matches the actual user flow is determined by peach-team-e2e.

Per-item team-dev criteria vs final verification

ui-proto is essentially a Mock, so it may not be 100% implemented. team-dev sets the implementation/TDD scope based on the following criteria, and actual browser flow conformance verification is handed off to peach-team-e2e.

Item team-dev criteria Final verification
Screen layout, component placement Use the ui-proto screen as implementation reference material peach-team-e2e
User interaction flow Implement code structure and events based on ui-proto/Spec peach-team-e2e
Business rules (validation, permissions, branching) Write API/Store/UI code and TDD based on Spec TDD + peach-team-e2e
Data accuracy (API response values) Verify types/API/TDD based on Spec TDD
Error/exception handling Write code and tests based on Spec TDD + E2E when needed

Core principles: team-dev is responsible through implementation and code-level verification. Whether the screen flow matches the planning intent from the actual user perspective is judged by peach-team-e2e. The responsibility boundary between the two teams and detailed operating rules follow references/dev-e2e-chain.md.

Reference Selection

Read only the necessary detailed documents. SKILL.mdis the execution router, and the detailed procedures and role definitions in the references below are the Source of Truth.

Situation Reference to Read
Automatic team composition analysis references/runtime-team-selection.md
Claude/Codex execution mode selection references/runtime-adapter.md
Overall input determination, environment check, domain analysis, task registration references/orchestration-workflow.md
proto argument handling references/proto-sync.md
prompt mode references/prompt-mode.md
Large-scale feature queue references/queue-workflow.md
team-dev + team-e2e automatic chain references/dev-e2e-chain.md
fullstack parallel development references/fullstack-workflow.md
Mock Store → real Store connection references/connect-workflow.md
Figma input references/figma-workflow.md
API-Store-UI connection verification references/contract-gate.md
Decision blocking, DB change blocking template references/blockers.md
QA determination and completion report references/qa-policy.md
Role-specific dev/qa instructions references/*-agent.md

Execution order

  1. references/runtime-team-selection.md와 references/runtime-adapter.mdand read single-agent, role-queue, agent-team , then decide the execution method among them.
  2. Determine the input type: queue → feature queue, natural language alone → prompt, mode+proto → standard, mode만 → Spec만.
  3. e2e=auto or if team-dev/team-e2e are requested simultaneously, perform the preflight of references/dev-e2e-chain.mdbefore starting development.
  4. Check the environment, schema, existing module structure, and gen-* reference paths. For detailed commands, follow references/orchestration-workflow.md.
  5. Read the Spec, schema, proto, or prompt, analyze the domain characteristics, and inject them into the role-specific prompts.
  6. Execute roles according to the mode and analysis results. If the actual agent-team cannot be used, execute the same sequence as a role-queue.
  7. Each dev role implements the requested scope and performs its own verification, and the QA role verifies independently.
  8. mode=backend|fullstack or if there is a connection change, references/contract-gate.mdperform the API-Store Contract Gate based on
  9. QA가 REJECTED면 references/qa-policy.md. Return to the dev role within the iteration limit of
  10. In the completion report, leave TDD/lint/build/Contract Gate, TEST_ID implementation status, blocked items, and E2E handoff information.

Role composition

Role Reference file Core responsibility
backend-dev references/backend-dev-agent.md API code generation, TDD/lint/build
backend-qa references/backend-qa-agent.md Backend structure, TDD, lint, build, Spec-based verification
store-dev references/store-dev-agent.md Backend type-based Pinia Store generation and type verification
ui-dev references/ui-dev-agent.md Store-based UI generation, design system/Figma/proto reflection
frontend-qa references/frontend-qa-agent.md Store/UI structure, types, lint, build, AI Slop, Spec/proto reflection verification

The real SoT is the target project's test-data/ guide code and gen-* skill references. team-dev coordinates the same pattern into a team execution method.

QA and completion

The QA agent judges by APPROVED / CONDITIONAL / REJECTED. After APPROVED , /peach-qa-gateRun, and REJECTEDVerification after fixing the dev agent with Ralph Loop.

The completion report includes at least the following.

  • Change summary and file paths
  • Executed TDD/lint/build commands and results
  • Contract Gate result: pass/fail/skip
  • Implementation status per TEST_ID: not started/in progress/partially implemented/implemented/blocked
  • DECISION_REQUIRED, DB_DECISION_REQUIRED, DB_CHANGE_REQUIRED items
  • e2e_chain status and peach-team-e2e handoff contract or follow-up recommendation

Detailed judgment rules and report fields are references/qa-policy.md, feature queue status is references/queue-workflow.md, E2E handoff is references/dev-e2e-chain.mdFollow.

Examples

# 표준 fullstack
/peach-team-dev product-manage mode=fullstack spec=docs/spec/2026/05/example.md proto=<PROTO_REPO>/src/modules-task/2604/260427-<initial>-goods

# Spec만 backend
/peach-team-dev notice-board mode=backend spec=docs/spec/2026/05/example.md

# 개발 후 team-e2e까지 자동 체인
/peach-team-dev product-manage mode=fullstack spec=docs/spec/2026/05/example.md e2e=auto

# prompt 모드
/peach-team-dev "list.vue 검색 후 페이지네이션 클릭 시 검색어 초기화되는 문제 수정"

Related skills

  • peach-gen-spec — Spec standalone generation
  • peach-team-ui-proto — ui-proto team generation/verification for planning review
  • peach-gen-db — DB schema/migration generation
  • peach-gen-backend, peach-gen-store, peach-gen-ui — Step-by-step standalone invocation
  • peach-team-e2e — E2E verification
  • peach-team-3a — Small single feature
  • peach-doc-feature — Existing feature As-Is analysis