Accord Cross-Team Unified Specification Writing

Problem

Cross-team requirements often live in separate artifacts: product documents, engineering notes, design flows, and ad-hoc conversations. Product focuses on why, engineering on how, design on who and what flow, and QA on what is acceptable. The result is repeated rework: requirements change, downstream decomposition happens again, tests are added late, and it becomes hard to see which requirement is covered or which acceptance case is missing.

How Accord works

Accord organizes requirements into one shared specification package and elaborates them in stages: L0 -> L1 -> L2 -> L3. L0 controls scope and goals, L1 extracts user stories and requirements, L2 provides business, development, and design views, and L3 defines testable BDD acceptance criteria.
Key practices include:
- Identify audiences before choosing Full, Standard, or Lite scope.
- Keep one source of truth instead of maintaining conflicting team-specific documents.
- Use stable IDs such as REQ, AC, and SC for bidirectional requirement-to-test traceability.
- Write Given / When / Then scenarios in business language, without DOM, SQL, or API implementation details.
- Route overloaded requirements to Sherpa for decomposition before implementation, testing, or documentation.

Boundaries

Accord is useful when a task needs a shared spec, cross-team review, BDD acceptance criteria, or structured input for downstream agents. It does not write implementation code, create visual mockups, or make architecture decisions. If the task is only a standalone PRD/SRS/HLD/LLD, test execution, or design production, use the corresponding specialist skill.