Add the paired-agent workflow for issues

.agents/skills/README.md

@@ -27,6 +27,8 @@ routing source of truth.
 - `docs-reviewer`: documentation review for prose, examples, and comments.
 - `proofread`: minimal English grammar, punctuation, and spelling corrections
   in project-owned comments and documentation.
+- `pair-workflow`: two-agent plan-review-implement-review protocol for an
+  issue or bug fix, driven by `.agents/workflows/pair.sh`.
 
 ## Skill Directory Layout
 
@@ -45,6 +47,10 @@ Each skill lives in its own directory:
 
 The `name` in `SKILL.md` frontmatter must match the directory name.
 
+A skill may add supporting files its own policy body references — for example,
+`pair-workflow/template.md`, the working-document template its driver copies.
+Policy still belongs in `SKILL.md`.
+
 ## Invocation
 
 Skills are invoked via `$<skill-name>` in supported agent interfaces (for

.agents/skills/pair-workflow/agents/openai.yaml

@@ -0,0 +1,8 @@
+interface:
+  display_name: "Pair Workflow"
+  short_description: "Two-agent plan-review-implement-review protocol"
+  default_prompt: >
+    Use $pair-workflow after reading AGENTS.md, README.md, and
+    .agents/project.md to take the next turn on a Chords GitHub issue driven by
+    two agents. Read the working document at .agents/work/issue-<number>/plan.md,
+    act on the role named by its `turn` field, and advance `status`.

.agents/skills/pair-workflow/template.md

@@ -0,0 +1,127 @@
+---
+status: plan-requested
+turn: agent1
+plan_round: 1
+impl_round: 1
+max_rounds: 2
+dirty_at_start: no
+resume_status: none
+manual_testing: unknown
+agent1: AGENT1_NAME
+agent2: AGENT2_NAME
+issue: ISSUE_URL
+issue_number: ISSUE_NUMBER
+issue_title: ISSUE_TITLE
+base_commit: BASE_COMMIT
+updated: CREATED_AT
+---
+
+# TASK_SLUG — ISSUE_TITLE
+
+## Issue
+
+Copied from [#ISSUE_NUMBER](ISSUE_URL) when the workflow started. This is the
+task specification. Neither agent edits it, and neither re-reads the issue from
+GitHub; if the issue changes materially, start a new run.
+
+ISSUE_BODY
+
+## Task
+
+<!-- agent1, first turn, immutable afterwards.
+
+     Restate the work in one or two sentences — what will exist or behave
+     differently once this is done — then list the acceptance criteria as a
+     checklist, quoting the issue rather than inventing them.
+
+     If the issue does not make clear what to do or what is wrong, or states no
+     acceptance criteria, do not guess: set status to `blocked`, set turn to
+     `human`, and say exactly what the issue needs. -->
+
+## Questions
+
+<!-- agent1 asks, the user answers, nobody else edits.
+
+     Ask only what genuinely changes the work, and propose a default for each.
+     The operator relays multiple questions to the user one message at a time:
+
+     **Q1.** Should the copy control appear per entry or once for the panel?
+     Default if unanswered: per entry, matching the existing row actions.
+
+     The user replies by adding an **A1.** line under the question. Then:
+     re-runs the same command. -->
+
+## Plan
+
+<!-- agent1 -->
+
+## Plan Review — Round 1
+
+<!-- agent2: findings P1-01, P1-02, … under Must fix / Should fix / Nits,
+     ending with a verdict. -->
+
+## Plan Dispositions — Round 1
+
+<!-- agent1: one row per finding ID.
+
+| ID | Disposition | Notes |
+|----|-------------|-------|
+
+     Then either revise the plan and send it back for another round, or move on
+     to implementing. Add new `— Round N` sections rather than overwriting. -->
+
+## Implementation — Round 1
+
+<!-- agent1: files changed and why, deviations from the plan, verification
+     commands run, and their results. -->
+
+## Implementation Review — Round 1
+
+<!-- agent2: findings I1-01, I1-02, … and a verdict. Check the change against
+     the acceptance criteria in ## Task. -->
+
+## Implementation Dispositions — Round 1
+
+<!-- agent1: one row per finding ID. -->
+
+## Outcome
+
+<!-- agent1: which acceptance criteria are met, what was rejected and why,
+     final verification. -->
+
+## Pull Request
+
+<!-- agent1, final turn, only when the prompt says a pull request will be
+     opened. Follow "Creating a Pull Request" in AGENTS.md: no verification or
+     testing detail, and no agent attribution. The driver appends the closing
+     keyword.
+
+     Write the two required sections as `### Summary` and `### Changes` so they
+     nest here; at `##` they would end this section instead. The driver
+     promotes them to `##` in the published description. -->
+
+## Manual Testing
+
+<!-- agent1, final turn. Set `manual_testing` in the frontmatter to `required`
+     or `none`, and fill this in whenever it is `required`.
+
+     This is printed to the terminal when the run finishes, so use this exact
+     structure for someone who has not read the rest of this document:
+
+     ### Setup
+
+     What to build or launch and any required environment.
+
+     ### Steps
+
+     1. A concrete action.
+        Expected: A result concrete enough to be wrong.
+        Covers: The acceptance criterion this verifies.
+
+     Repeat the three-line numbered-step shape for every criterion that
+     automated tests do not settle. -->
+
+## Log
+
+<!-- Append one line per turn:
+     <timestamp> <role> <from-status> -> <to-status>: <summary> -->

.agents/skills/tester/SKILL.md

@@ -50,4 +50,19 @@ Module Gradle paths: `core`, `proto`, `proto-values`, `client`, `runtime`,
 `codegen-tests`. The `codegen/plugins` project verifies separately from
 `codegen/plugins/` with JDK 17 (`./gradlew build`).
 
+Read the task list, not only the final line. A build whose compile and test
+tasks all report `UP-TO-DATE` finished in seconds without compiling or running
+anything, and its `BUILD SUCCESSFUL` describes a previous build rather than the
+change in the worktree. When that happens, force the work with `--rerun-tasks`
+before reporting a result:
+
+```bash
+./gradlew :<module>:test --tests "…" --rerun-tasks
+```
+
+Gradle's up-to-date check is content-based, so an `UP-TO-DATE` task is normally
+sound. It is misleading only when it stands in as evidence for a change that
+was never built. Report a verification result as green only when the tasks
+covering the change actually executed.
+
 Follow the git-history and safety policy in `AGENTS.md`.