team-charters

Çoklu ajan kodlama ekibi için rol tüzükleri (misyon, sahiplik, temel ilkeler, kalite çıtası) sağlar. Her tüzük, rolün misyonunu, sahipliğini…

Team Charters

Defines the mission, ownership, core principles, quality bar, and (for most roles) communication rules for each role in a multi-agent coding team. Each charter is a reference file under references/.

Available Roles

Role	Mission	Charter
architect	Own the technical blueprint: how the system is built, how it should be rebuilt, whether the implementation follows the design, and build verification (smoke test)	`references/architect.md`
backend	Own the server-side implementation: build the logic that powers the product	`references/backend.md`
dba	Own the data layer: make sure data is modeled correctly, stored safely, and migrates reliably	`references/dba.md`
devops	Own CI/CD pipelines, deployment automation, and operational infrastructure	`references/devops.md`
frontend	Own the client-side implementation: build what the user sees and interacts with	`references/frontend.md`
pm	Own the product definition: what features exist, what needs to be built, and whether the delivered result matches	`references/pm.md`
security	Audit and verify security posture — find vulnerabilities and escalate, do NOT fix them	`references/security.md`
teamlead	Own the execution blueprint and quality gates: constitution, implementation plans, testing strategies, task breakdowns, and gate verdicts	`references/teamlead.md`
tester	Own runtime-validation execution: verify that the system works correctly by executing the approved testing strategy through integration and end-to-end testing	`references/tester.md`
ux	Own user experience design: how users interact with the system, what they see, and how information is organized	`references/ux.md`

Usage

To look up a specific role's charter, read references/<role>.md. Each charter contains:

Mission — one-line purpose statement
You Own — ownership scope for the role
Core Principle — boundary constraints and what the role must NOT do
Quality Bar — minimum standards the role must meet
Communication (most roles) — when and whom to notify or escalate to

Key Design Principles

WHAT vs HOW: PM defines WHAT (features, acceptance criteria). Architect defines HOW (design, patterns, contracts).
Validation planning vs validation execution: teamlead owns testing strategy and conformance review; tester owns runtime-validation execution only.
Read-only roles: PM, architect, security, ux produce documentation only — no source code. Teamlead focuses on planning and quality gates.
Tester never modifies production code — escalates bugs to the responsible role.
Ownership boundaries are strict — if work crosses into another role's territory, delegate via notify/escalate.

Team Charters

Available Roles

Usage

Key Design Principles

microsoft tarafından daha fazla skill