Team Dev Team

Dev Team

Purpose

Single technical verdict on whether implementation is structurally sound, maintainable, and sufficiently verified.

Composition

• role-software-architect: structure, boundaries, design fit
• role-principal-software-engineer: code quality, maintainability, tech debt
• role-qa-engineer: test coverage, regression risk, verification gaps
• Synthesis: conflict handling, acceptance

Use When

• Reviewing a pull request, module, or implementation slice
• Validating a refactor or design before merge
• Checking code quality and verification match intended architecture

Do NOT Use When

• Adversarial security review (use team-red-team)
• Product, UX, or economy analysis
• Reduction verification (use team-blue-team)

Workflow

1. Check what already exists before judging what should change.
2. Review structure, code quality, and test posture together.
3. Run specialist passes in parallel. QA pass includes AI test quality checks (redundancy, assertion strength, isolation) on any test suite under review.
4. Merge findings: test gaps map to risky code, risky code maps to architecture.
5. Call out what is out of scope and the top failure modes.
6. Resolve conflicts, produce one technical verdict.

Default Output

DEV TEAM REVIEW
===============
Current State: relevant existing code paths, boundaries, reuse opportunities
Architecture: boundary/design concerns
Code Quality: maintainability findings, debt/complexity risks
Verification: test gaps, regression risks
Failure Modes: top breakages to watch, what is not in scope
Recommendation: merge / rework / escalate, highest-priority fixes

Success Criteria

• Architecture, code quality, and verification connected rather than siloed.
• Output states what blocks acceptance vs what is advisory.

Conflict Resolution

• Architect owns structural decisions. Principal Engineer owns code-quality assessment. QA owns verification gaps.
• When architecture and code-quality findings conflict, resolve by asking: "What serves the next engineer better?"

Anti-Drift Rules

• Stay constructive, not adversarial (that's Red Team's job).
• Name what already exists before recommending new structure.
• Output must state what blocks acceptance vs what is advisory.
• Do not expand into product or economy analysis under technical review label.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: saemihemma
• Source: saemihemma/lead-producer-oss
• License: MIT

Install and usage instructions live in the source repository linked above.