Trw Team Playbook

Check $ARGUMENTS for a sprint document path:

• If a valid file path is provided, read it as the sprint context document.
• If empty or "active", look for the sprint doc in sprints/active/ (sibling of prds_relative_path). If exactly one file exists, use it. If multiple exist, list them and ask the user to pick one.
• If no sprint doc is found anywhere, ask the user to provide: (a) the sprint doc path, or (b) a list of PRD IDs and teammate names to generate playbooks for directly.

Step 2: Read Sprint Document

Parse the sprint doc to extract:

• Sprint name and goals
• PRD assignments table (PRD ID, title, priority, track, assigned role)
• Track structure (Track A = implementer-1, Track B = implementer-2, etc.)

Build a teammate list. Each entry has:

• name: lowercase hyphenated (e.g., implementer-1, tester-1, reviewer)
• role: one of implementer, tester, reviewer, researcher
• assigned_prds: list of PRD IDs this teammate is responsible for

If roles are not assigned in the sprint doc, apply these defaults based on team composition rules:

Step 3: Read Each PRD

For each assigned PRD, read the PRD file and extract:

• Functional requirements: FR ID, priority (P0/P1/P2/P3), description (1-sentence summary)
• Technical Approach section: Any file paths, module names, or class names mentioned
• Key Files table (if present): explicit source-to-test file mappings
• Acceptance criteria: per-FR success conditions
• Dependencies: other PRDs or external components this PRD depends on

If an execution plan exists at docs/requirements-aare-f/exec-plans/EXECUTION-PLAN-{PRD-ID}.md, read it and use its micro-task decomposition, wave plan, and file ownership mapping as the primary source for task and file assignments. This eliminates the need to re-derive file ownership from the PRD's Technical Approach section.

Group the extracted FRs by teammate based on the sprint doc's PRD assignments.

Step 4: Determine File Ownership

For each teammate, derive their exclusive file set:

• Implementer: source files from the PRD's Key Files table or Technical Approach section. If no files are listed explicitly, use Glob to find files matching the module paths mentioned in the PRD, then assign by functional area.
• Tester: test files corresponding to the implementer's source files. Convention: tests/test_{module_name}.py for each src/trw_mcp/{module_name}.py.
• Reviewer: no owned files -- read-only access to all in-scope files.
• Researcher: no owned files -- read-only access to all in-scope files.

Validate zero overlap (source AND test files):

• Build a flat set of ALL ownership claims: owns + test_owns from every teammate.
• Check for any file appearing in more than one teammate's owns OR test_owns lists.
• If overlap detected in source files (owns): STOP. Report and ask user to resolve.
• If overlap detected in test files (test_owns): STOP. Report and ask user to resolve. Common resolution: assign the test file to ONE teammate (typically the one whose PRD scope covers more of the file's test cases), and have the other teammate's tests go in a NEW test file (e.g., test_module_fr01.py and test_module_fr02.py).
• Test files are NOT shared resources. Sprint 66 showed that two agents editing the same test file causes 4+ merge iterations and cascading failures.
• If no overlap: continue.

Also check: every source file in scope is assigned to exactly one owner. Report any unassigned files and ask the user whether to assign them or mark them as shared read-only.

Step 5: Generate file_ownership.yaml

Write scratch/team-playbooks/file_ownership.yaml:

# file_ownership.yaml -- generated by /trw-team-playbook