team-charters

ให้กฎบัตรบทบาท (ภารกิจ ความเป็นเจ้าของ หลักการสำคัญ มาตรฐานคุณภาพ) สำหรับทีมเขียนโค้ดแบบหลายเอเจนต์ กฎบัตรแต่ละฉบับกำหนดภารกิจของบทบาท ความเป็นเจ้าของ…

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

Skills เพิ่มเติมจาก microsoft