quorum

The test strategy defines the **testing approach for a track** — what levels of testing, what coverage targets, what environments, and what tools. It bridges the gap between individual WB test items and the project's overall quality goals.

The track README is the **design overview** for a single track. It answers: "What does this track do, why, and how do we know it's done?"

The UI spec defines **what the user sees and interacts with** — component hierarchy, layout, states, and interactions. It bridges the gap between PRD requirements (what to build) and frontend implementation (how to build it).

The work breakdown decomposes a track into **implementable work packages**. Each WB item is small enough for a single implementer agent session and traceable back to a PRD requirement.

The work catalog is the **flat index of all work breakdown items** across all tracks. It enables cross-track search, filtering, and progress tracking without reading each track's individual WB document.

**Before generating candidates**, read every existing memory file and build a topic index:

Present candidates grouped by action, with source evidence:

Collect from **three** sources, in order of richness:

```bash

26 deterministic analysis tools available via CLI. All tools run the same logic regardless of adapter — only the invocation method differs.

Extract facts from code and fix numeric/structural mismatches across 3 documentation layers.

Based on Tim Pope (2008), Chris Beams (2014), Git official docs, Google Engineering Practices, Linux Kernel submitting-patches.

Import/export dependency DAG with connected components, topological sort, and cycle detection. Results are mtime-cached.

Evaluate each task before spawning a worker. Not every task needs the full protocol — applying worktree isolation + scout RTM + audit cycle to a 1-file typo fix wastes 10x the resources.

ADRs capture **why** a significant technical decision was made. Without ADRs, agents and future developers may unknowingly contradict or redo past decisions.

When `--template brand.docx` is provided, the script opens the template document and builds content on top of it. The template's styles, fonts, colors, headers, footers, and margins are all preserved.

All visual aspects are controlled via CSS custom properties in `:root`. Edit these in the generated HTML or in a custom template:

**CRITICAL: You MUST complete these steps in order. Do not skip ahead to writing code.**

This document contains advanced PDF processing features, detailed examples, and additional libraries not covered in the main skill instructions.

When using an existing presentation as a template:

```javascript

This document provides guidance on creating comprehensive evaluations for MCP servers. Evaluations test whether LLMs can effectively use your MCP server to answer realistic, complex questions using only the tools provided.

- **Python**: `{service}_mcp` (e.g., `slack_mcp`)

API Contracts define the exact interface between layers (BE→FE, service→service). They are the **shared agreement** that both sides implement against, preventing the "it works on my machine" gap between tracks.

The data model defines **database schemas, entity relationships, and data lifecycle**. Without it, implementers make independent schema decisions that diverge across tracks, causing migration conflicts and data integrity issues.

After PRD confirmation and before Work Breakdown generation, produce 4 design artifacts that define **how** to build what the PRD specifies. These artifacts establish the "laws" that implementers must follow.

The execution order defines the **sequence and dependency graph** between tracks. It answers: "What can start now? What's blocked? What unblocks what?"

After DRM confirmation (Phase 5) and before writing Work Breakdowns, analyze each FR for failure scenarios. This ensures WB items cover error handling and edge cases, not just the happy path.

After capturing user intent (Phase 1) and before writing the PRD (Phase 2), perform a structured 3-step decomposition to ensure requirements are Mutually Exclusive and Collectively Exhaustive.

The PRD is the **master design document** for the entire project. It spans all tracks and is the single source of truth for WHAT to build and WHY.

Single source of truth for all domain knowledge, protocols, and reference material.

**Primary tool**: `a11y_scan`

**Primary tool**: `compat_check`

**Primary tool**: `license_scan`

**Primary tool**: `dependency_graph`

This document provides Node/TypeScript-specific best practices and examples for implementing MCP servers using the MCP TypeScript SDK. It covers project structure, server setup, tool registration patterns, input validation with Zod, error handling, and complete working examples.

**Primary tool**: `doc_coverage`

**Primary tool**: `i18n_validate`

**Primary tool**: `infra_scan`

**Primary tool**: `compat_check`

Measure documentation coverage: percentage of exported symbols with doc comments. Uses `docPatterns` from each language's `spec.doc.mjs`.

**Primary tool**: `observability_check`

**Primary tool**: `perf_scan`

**Primary tool**: `audit_scan`

Trigger the consensus audit process manually. Evaluates pending evidence and produces verdicts stored in SQLite.

Interface for the 20 analysis tools that power the quorum workflow.

Evaluator-Optimizer pattern. Iterates evaluate→fix→re-evaluate until quality criteria converge. Each iteration moves closer to Normal Form.

Generate 4 design artifacts that define **how** to build what the PRD specifies. Design artifacts are laws — they remove subjective implementation decisions from implementers.

Generate project documents in various formats.

Systematically analyze what can go wrong with each requirement before implementation begins. HIGH severity failures become mandatory Work Breakdown items — catching them before code prevents costly rework.

Targeted repair agent. Receives specific audit findings and applies surgical fixes without rewriting or restructuring code. Fundamentally different from the implementer: a fixer inherits existing code and adjusts it, while an implementer starts from a design.

Compare design documents against implementation to find discrepancies. Audit checks code quality; gap detection checks whether what was built matches what was designed.

Generate a quorum-governed agent team tailored to the project's domain. Combines Harness's team design patterns with quorum's structural enforcement.

You are a headless worker. You receive a task with context and execute it autonomously.

Squash-merge the current worktree branch back into the target branch. All WIP commits become one structured commit.

Static analysis tool that cross-references FE routes, API calls, BE endpoints, and access policies to produce a Functional Verification Matrix (FVM).

Generate publication-quality mermaid diagrams. Each diagram type has a dedicated reference.

You are the orchestrator. You do NOT implement — you distribute, verify, and decide.

Standing rules governing all parliamentary sessions: consensus audit, diverge-converge deliberation, amendment voting, and confluence verification.

Analyze feature requests, maintain PRDs, define tracks. Do not generate documents immediately — understand, research, confirm scope first.

Mine the current session for learnings and translate them into durable memories.

Create and manage checkpoints for safe state recovery during Wave execution and planning.

HTTP runner that executes FVM rows against a live server. Authenticates as each role, sends requests, compares actual vs expected status codes.

Run deterministic tools per requirement to produce raw Forward and Backward RTM rows. One responsibility: tool execution and result collection.

You are a read-only analyst. You do NOT modify code. You produce a **3-way Requirements Traceability Matrix (RTM)** by comparing work-breakdown definitions against the actual codebase.

Shared protocol for all domain specialist reviewers. Each specialist extends this with domain-specific focus areas and checklists.

Unified status reporting with subcommands.

Verify frontend implementation against UI specifications using a real browser. This protocol is adapter-independent — the browser automation method varies by adapter.

Run all done-criteria checks before evidence submission. Deterministic tools only — zero LLM tokens for judgment.

Parse work-breakdown markdown files into structured requirements tables. One responsibility: turn human-written WBs into machine-consumable data.

A 500-line change can be one commit. A 10-line change may need two.

| Type | Use when |

Scan JSX/TSX for accessibility issues. Uses `qualityRules.a11y` from `spec.a11y.mjs` (TypeScript only).

PDCA Act phase — analyze audit history + FVM results to produce structured improvement items.

Generate project onboarding guide by synthesizing code_map + dependency_graph + doc_coverage results.

Query the persistent audit history log (JSONL). Returns verdict timelines, rejection code frequency, track distribution, and risk pattern detection.

Zero-token pattern scanner. Detects anti-patterns without LLM reasoning — pure regex matching via `rg` (ripgrep).

Compute transitive impact of changed files via reverse import graph (BFS on inEdges).

Zero-token symbol index with mtime-based caching. Extracts function, class, interface, type, enum, and import declarations with line ranges.

Check for API breaking changes and compatibility issues. Uses `qualityRules.compat` from each language's `spec.compat.mjs`.

Maps test coverage data to files. Reads vitest coverage JSON and returns per-file statement/branch/function/line percentages.

Validate i18n locale key parity and detect hardcoded UI strings. Uses `i18nHardcodedRe` from each language spec.

Scan infrastructure files for security and reliability anti-patterns.

The language registry (`languages/registry.mjs`) provides language-aware analysis for all domain scan tools. Read this when you need to understand what patterns a tool checks or when adding a new language.

Check dependency licenses for copyleft/unknown risks and scan source for hardcoded secrets or PII patterns.

Detect observability gaps in application code. Uses `qualityRules.observability` from each language's `spec.observability.mjs`.

```python

Scan for performance anti-patterns using **hybrid scanning**: regex first pass (speed) → AST second pass (precision, TypeScript only).

Row-level merge of multiple worktree RTM files into a base RTM. Detects conflicts, applies updates, appends discovered rows.

Parse RTM (Requirements Traceability Matrix) markdown files into structured rows. Supports forward, backward, and bidirectional matrices with filtering.

After PRD confirmation and before Work Breakdown generation, produce 4 design artifacts that define **how** to build what the PRD specifies. These artifacts establish the "laws" that implementers must follow.

Run these to collect current facts from code:

- `{planning_dir}` must contain RTM files (e.g., `rtm-*.md`)

- `{planning_dir}` directory must exist

This document provides Python-specific best practices and examples for implementing MCP servers using the MCP Python SDK. It covers server setup, tool registration patterns, input validation with Pydantic, error handling, and complete working examples.

```

```mermaid

```mermaid

```yaml

```

```

```mermaid

```mermaid

Requires KaTeX to be loaded. In supported renderers, math is auto-detected.

```mermaid

```mermaid

```mermaid

```mermaid

Before distributing work, dispatch a **scout** to produce a Requirements Traceability Matrix (RTM).

```

| Theme | Description |

```mermaid

On `[pending_tag]` rejection — **send correction to existing agent via SendMessage**.

Before parallel distribution, verify no scope conflicts:

After `[agree_tag]` and worker WIP commit:

22 hooks across 22 events