dev-team

Dev Team

User request:

$ARGUMENTS

Run engineering work as an agentic development loop: clarify, explore, plan, execute, validate, review, and prepare for handoff.

Invocation

This is an explicit workflow skill. Use it when the user invokes /dev-team as a standalone skill or the plugin-scoped equivalent. If the request is empty, ask what engineering work the user wants handled.

Operating Rules

• Start with AI-first execution, but keep user trust higher than workflow ceremony.
• Ask clarifying questions only when the answer can change scope, implementation, security/privacy, data model, rollout, task split, or validation.
• If ambiguity is low-risk, proceed with a visible assumption instead of stopping.
• Explore before planning unless repository context is already known in this session.
• Prefer repo conventions over new patterns.
• Keep changes scoped to the user request.
• Treat generated code as owned work: review it, test it, and fix it before presenting it.
• Do not push, open a PR, run destructive commands, perform migrations, deploy, or touch production-like systems without explicit user approval.
• Track substantial work with todos when the tool is available.

Default Loop

1. Intake

   • Restate the goal in one short sentence when useful.
   • Identify task type: feature, bug, refactor, test, CI, review, migration, docs, release, or investigation.
   • Ask blocking questions if needed; otherwise state assumptions and continue.

2. Explore

   • Inspect repo structure, existing patterns, tests, recent changes, and relevant docs.
   • Use fast search first.
   • Read enough code to avoid guessing.
   • When useful, delegate read-only exploration to the plugin's explorer-style subagent or another suitable subagent.
   • If exploration reveals a material unknown, ask before planning.

3. Plan

   • Build a concise plan with success criteria.
   • Include validation: tests, checks, manual inspection, screenshots, logs, or rollout checks as relevant.
   • For broad or risky changes, pause for approval before editing.

4. Split

   • Break work into tasks with clear ownership, inputs, outputs, and validation.
   • Load references/task-splitting.md when the work has 2+ independent streams or unclear sequencing.
   • Use parallel subagents only when tasks have disjoint write sets, the immediate next step is not blocked on their output, and the user has authorized the dev-team workflow.

5. Execute

   • Implement the critical path locally.
   • Delegate bounded side tasks when safe.
   • Keep the user updated during long work.
   • Work with existing user changes; never revert unrelated edits.

6. Validate

   • Run the strongest practical verification before claiming success.
   • Load references/validation-and-rollout.md for risky, user-facing, data, migration, release, or production-adjacent work.
   • If validation fails, debug from evidence, fix, and rerun relevant checks.

7. Review

   • Review the final diff like a PR reviewer.
   • Load references/review-rubric.md for substantial changes.
   • Use the plugin's reviewer-style subagent or another suitable subagent for independent review when the change is non-trivial.
   • Prioritize correctness, regressions, security, data loss, missing tests, and rollout risk over style nits.

8. Finalize

   • Summarize what changed, how it was verified, and remaining risk.
   • Prepare commit or PR notes when asked.
   • Push or open a PR only after explicit user approval.

Clarification Gates

Load references/clarification-gates.md when the request is ambiguous, high-impact, cross-team, security-sensitive, data-sensitive, or broad enough that asking the wrong question late would waste work.

Default gate policy:

• Ask up front when the task cannot be scoped safely.
• Ask after exploration if facts contradict the original request.
• Ask before implementation when the plan has meaningful tradeoffs.
• Ask before rollout, destructive operations, migrations, deploys, or PR creation.
• Do not ask just to perform the workflow.

Progress Updates

Use short updates while working:

• What context is being gathered.
• What was learned.
• What will be edited before editing.
• What validation is running.
• What failed and how it will be fixed.

For substantial work, keep an active checklist and update statuses as work completes.

Reference Map

• references/clarification-gates.md: when and how to ask questions.
• references/task-splitting.md: task graph, ownership, parallelism, and delegation rules.
• references/validation-and-rollout.md: choosing checks and rollout safety.
• references/review-rubric.md: final self-review and PR readiness.
• references/context-capture.md: when to update repo memory such as AGENTS.md, CLAUDE.md, or local docs.