@fredericboyer/dev-team 0.9.0 → 0.11.0

package/templates/agents/dev-team-tufte.md

@@ -14,6 +14,8 @@ Your philosophy: "If the docs say one thing and the code does another, both are
 
 **Memory hygiene**: Read your MEMORY.md at session start. Remove stale entries (overruled challenges, outdated patterns). If approaching 200 lines, compress older entries into summaries.
 
+**Role-aware loading**: Also read `.dev-team/learnings.md` (Tier 1). For cross-agent context, scan entries tagged `documentation`, `api-docs`, `readme`, `doc-code-sync` in other agents' memories — especially Voss (API changes) and Mori (UI documentation needs).
+
 Before reviewing or writing documentation:
 1. Spawn Explore subagents in parallel to map the actual behavior — read the implementation, trace the call graph, run the code if needed.
 2. **Research current practices** when recommending documentation tooling, formats, or patterns. Check current documentation standards and toolchain versions — static site generators, API doc generators, and markup formats evolve. Prefer codebase consistency over newer approaches; flag newer alternatives as `[SUGGESTION]` when they do not fit the existing conventions.
@@ -73,7 +75,7 @@ Rules:
 3. When challenged: address directly, concede when wrong, justify with a counter-scenario when you disagree.
 4. One exchange each before escalating to the human.
 5. Acknowledge good work when you see it.
-6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
+6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop generating additional findings. You must still complete the mandatory MEMORY.md write and Learnings Output steps. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
 
 ## Learning
 

package/templates/agents/dev-team-voss.md

@@ -14,6 +14,8 @@ Your philosophy: "Build as if the next developer inherits your mistakes at 3 AM
 
 **Memory hygiene**: Read your MEMORY.md at session start. Remove stale entries (overruled challenges, outdated patterns). If approaching 200 lines, compress older entries into summaries.
 
+**Role-aware loading**: Also read `.dev-team/learnings.md` (Tier 1). For cross-agent context, scan entries tagged `api`, `database`, `migration`, `config`, `architecture` in other agents' memories — especially Brooks (architectural decisions) and Hamilton (deployment constraints).
+
 Before writing any code:
 1. Spawn Explore subagents in parallel to understand the codebase area, find existing patterns, and map dependencies.
 2. **Research current practices** when making framework, library, or architectural pattern choices. Check current documentation for the libraries and runtime versions in use — APIs deprecate, defaults change, and best practices evolve. Prefer codebase consistency over newer approaches; flag newer alternatives as `[SUGGESTION]` when they do not fit the existing conventions.
@@ -59,7 +61,7 @@ Rules:
 3. When challenged: address directly, concede when wrong, justify with a counter-scenario when you disagree.
 4. One exchange each before escalating to the human.
 5. Acknowledge good work when you see it.
-6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
+6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop generating additional findings. You must still complete the mandatory MEMORY.md write and Learnings Output steps. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
 
 ## Learning
 

package/templates/dev-team-learnings.md

@@ -1,5 +1,6 @@
 # Shared Team Learnings
-<!-- Read by all agents at session start. Keep under 200 lines. -->
+<!-- Tier 1: Shared team memory. Project facts, conventions, and cross-agent decisions. -->
+<!-- Read by ALL agents at session start. Keep under 200 lines. -->
 <!-- For formal decisions, use ADRs instead. This file captures organic learnings. -->
 
 ## Coding Conventions
@@ -13,4 +14,5 @@
 
 ## Overruled Challenges
 <!-- When the human overrules an agent, record why — prevents re-flagging -->
+<!-- Format: "[YYYY-MM-DD] Agent: finding summary — overruled because: reason" -->
 

package/templates/dev-team-metrics.md

@@ -0,0 +1,18 @@
+# Agent Calibration Metrics
+<!-- Appendable log of per-task agent performance metrics. -->
+<!-- Borges records an entry after each task cycle. -->
+<!-- Used by /dev-team:assess to track acceptance rates and signal quality over time. -->
+
+## Format
+<!-- Each entry follows this structure:
+### [YYYY-MM-DD] Task: <issue or PR reference>
+- **Agents**: implementing: <agent>, reviewers: <agent1, agent2, ...>
+- **Rounds**: <number of review waves to convergence>
+- **Findings**:
+  - <agent>: <N> DEFECT (<accepted>/<overruled>), <N> RISK, <N> SUGGESTION
+- **Acceptance rate**: <accepted findings / total findings>%
+- **Duration**: <approximate task duration>
+-->
+
+## Entries
+

package/templates/hooks/dev-team-post-change-review.js

@@ -241,11 +241,11 @@ function scoreComplexity(toolInput, filePath) {
   let score = 0;
 
   // Lines changed
-  const oldStr = toolInput.old_string || "";
-  const newStr = toolInput.new_string || toolInput.content || "";
+  const oldStr = toolInput.old_string ?? "";
+  const newStr = toolInput.new_string ?? toolInput.content ?? "";
   const oldLines = oldStr ? oldStr.split("\n").length : 0;
   const newLines = newStr ? newStr.split("\n").length : 0;
-  const linesChanged = Math.abs(newLines - oldLines) + Math.min(oldLines, newLines);
+  const linesChanged = oldLines + newLines;
   score += Math.min(linesChanged, 50); // Cap at 50 to avoid single large file dominating
 
   // Complexity indicators in the new content

package/templates/skills/dev-team-assess/SKILL.md

@@ -22,6 +22,7 @@ This skill audits **only update-safe files** — files that survive `dev-team up
    - All `.dev-team/agent-memory/*/MEMORY.md` files (use Glob to discover them)
    - The project's `CLAUDE.md` (root of repo)
    - `.dev-team/config.json` (to know which agents are installed)
+   - `.dev-team/metrics.md` (if it exists — calibration metrics log)
 
 2. If `$ARGUMENTS` specifies a focus area (e.g., "learnings", "memory", "claude.md"), scope the audit to that area only. Otherwise, audit all three.
 
@@ -91,6 +92,24 @@ Check the project's `CLAUDE.md` for:
 ### Learnings promotion
 - Mature learnings that have been stable for multiple sessions and should be promoted to `CLAUDE.md` instructions
 
+## Phase 4: Calibration metrics audit (`.dev-team/metrics.md`)
+
+If `.dev-team/metrics.md` exists and contains entries, analyze:
+
+### Acceptance rates per agent
+- Calculate rolling acceptance rate (last 10 entries) for each reviewer agent
+- Flag agents with acceptance rate below 50% — they may be generating more noise than signal
+- Identify trend direction: improving, stable, or degrading
+
+### Signal quality
+- Are DEFECT findings being overruled frequently? This suggests over-flagging
+- Are SUGGESTION findings dominating? This suggests agents are not calibrated to the project's conventions
+- Are review rounds consistently high (3+)? This suggests systemic quality issues or miscalibrated reviewers
+
+### Delegation patterns
+- Which implementing agents are used most frequently?
+- Are reviewers consistently finding issues in specific domains? This may indicate an implementing agent needs calibration
+
 ## Report
 
 Produce a structured health report:
@@ -145,6 +164,7 @@ Provide a simple health score:
 | Learnings | healthy / needs attention / unhealthy | count by severity |
 | Agent Memory | healthy / needs attention / unhealthy | count by severity |
 | CLAUDE.md | healthy / needs attention / unhealthy | count by severity |
+| Metrics | healthy / needs attention / unhealthy | count by severity |
 | **Overall** | **status** | **total** |
 
 Thresholds:

package/templates/skills/dev-team-review/SKILL.md

@@ -48,7 +48,7 @@ Before spawning reviewers, verify the changes are reviewable:
 ## Filter findings (judge pass)
 
 Before producing the report, filter raw findings to maximize signal quality:
-1. **Remove contradictions**: Drop findings that contradict existing ADRs, learnings, or agent memory
+1. **Remove contradictions**: Drop findings that contradict existing ADRs (`docs/adr/`), learnings (`.dev-team/learnings.md`), or agent memory (`.dev-team/agent-memory/*/MEMORY.md`)
 2. **Deduplicate**: When multiple agents flag the same issue, keep the most specific finding
 3. **Consolidate suggestions**: Group `[SUGGESTION]`-level items into a single summary block
 4. **Suppress generated file findings**: Skip findings on generated, vendored, or build artifacts
@@ -78,6 +78,14 @@ Group by severity:
 - **[QUESTION]** — decisions needing justification
 - **[SUGGESTION]** — specific improvements
 
+### Filtered
+
+List findings removed during the judge pass, with the reason for filtering:
+```
+**Filtered** @agent-name — reason (contradicts ADR-NNN / duplicate of above / no concrete scenario / generated file)
+Original finding summary.
+```
+
 ### Verdict
 
 - **Approve** — No `[DEFECT]` findings. Advisory items noted.
@@ -92,8 +100,11 @@ Before starting the review, check for open security alerts: run `/dev-team:secur
 ### Completion
 
 After the review report is delivered:
-1. You MUST spawn **@dev-team-borges** (Librarian) as the final step. Borges will:
+1. You MUST spawn **@dev-team-borges** (Librarian) as the final step. Pass Borges the **finding outcome log**: every finding with its classification, source agent, and outcome (accepted/overruled/ignored), including reasoning for overrules. Borges will:
    - **Extract structured memory entries** from the review findings (each classified finding becomes a memory entry for the reviewer who produced it)
+   - **Reinforce accepted patterns** and **record overruled findings** for reviewer calibration
+   - **Generate calibration rules** when 3+ findings on the same tag are overruled
+   - **Record metrics** to `.dev-team/metrics.md`
    - Write entries to each participating agent's MEMORY.md using the structured format
    - Update shared learnings in `.dev-team/learnings.md`
    - Check cross-agent coherence

package/templates/skills/dev-team-task/SKILL.md

@@ -46,9 +46,13 @@ Track iterations in conversation context (no state files). For each iteration:
    - If validation fails, route back to implementer with specific failure reason. If it fails twice, escalate to human.
 3. After validation passes, spawn review agents in parallel as background tasks.
 4. Collect classified challenges from reviewers.
-5. If any `[DEFECT]` challenges exist, address them in the next iteration.
-6. If no `[DEFECT]` remains, output DONE to exit the loop.
-7. If max iterations reached without convergence, report remaining defects and exit.
+5. If any `[DEFECT]` challenges exist, **compact the context** before the next iteration:
+   - Produce a structured summary: DEFECTs found (agent, file, status), files changed, outstanding items
+   - New reviewers in subsequent waves receive: current diff + compact summary + agent definition
+   - They do NOT receive raw conversation history from prior waves
+6. Address defects in the next iteration.
+7. If no `[DEFECT]` remains, output DONE to exit the loop.
+8. If max iterations reached without convergence, report remaining defects and exit.
 
 The convergence check happens in conversation context: count iterations, check for `[DEFECT]` findings, and decide whether to continue or exit.
 
@@ -56,6 +60,8 @@ The convergence check happens in conversation context: count iterations, check f
 
 When multiple issues are being addressed in a single session, the task loop switches to parallel orchestration (see ADR-019). Drucker coordinates all phases in conversation context.
 
+**Mode selection:** If agent teams are enabled (check `.dev-team/config.json` for `"agentTeams": true`), use team lead mode for batches of 3+ issues. Otherwise, use standard worktree subagent mode. For single issues, always use standard mode.
+
 ### Phase 0: Brooks pre-assessment (batch)
 Spawn @dev-team-brooks once with all issues. Brooks identifies:
 - **File independence**: which issues touch overlapping files (conflict groups that must run sequentially)
@@ -71,7 +77,7 @@ Drucker spawns one implementing agent per independent issue, each on its own bra
 Reviews do **not** start until **all** implementation agents have completed (Agent tool provides completion notifications as the sync barrier). Once all are done, spawn review agents (Szabo + Knuth, plus conditional reviewers) in parallel across all branches simultaneously. Each reviewer receives the diff for one specific branch and produces classified findings scoped to that branch.
 
 ### Phase 3: Defect routing
-Collect all findings. Route `[DEFECT]` items back to the original implementing agent for each branch. Agents fix defects on their own branch. After fixes, another review wave runs. Continue until no `[DEFECT]` findings remain or the per-branch iteration limit is reached.
+Collect all findings. Route `[DEFECT]` items back to the original implementing agent for each branch. Agents fix defects on their own branch. Before spawning the next review wave, **compact context**: produce a structured summary of prior findings, their status (fixed/disputed/pending), and files changed. New reviewers receive current diff + compact summary only — not full conversation history from prior waves. Continue until no `[DEFECT]` findings remain or the per-branch iteration limit is reached.
 
 ### Phase 4: Borges completion
 Borges runs **once** across all branches after the final review wave clears. This ensures cross-branch coherence: memory files are consistent, learnings are not duplicated, and system improvement recommendations consider the full batch.
@@ -90,8 +96,12 @@ Before starting work, check for open security alerts: run `/dev-team:security-st
 When the loop exits:
 1. **Deliver the work**: If changes are on a feature branch, create the PR (body must include `Closes #<issue>`). Ensure the PR is ready to merge: CI green, reviews passed, branch up to date. Then follow the project's merge workflow — use `/dev-team:merge` if the project has it configured, otherwise report readiness. If merge fails (CI failures, merge conflicts, branch protection), report the blocker to the human rather than leaving work unattended.
 2. **Clean up worktree**: If the work was done in a worktree, clean it up after the branch is pushed and the PR is created. Do not wait for merge to clean the worktree.
-3. You MUST spawn **@dev-team-borges** (Librarian) as the final step. Borges will:
+3. You MUST spawn **@dev-team-borges** (Librarian) as the final step. Pass Borges the **finding outcome log**: every finding with its classification, source agent, and outcome (accepted/overruled/ignored), including the human's reasoning for overrules. Borges will:
    - **Extract structured memory entries** from review findings and implementation decisions
+   - **Reinforce accepted patterns** in the reviewer's memory (calibration feedback)
+   - **Record overruled findings** with context so reviewers generate fewer false positives
+   - **Generate calibration rules** when 3+ findings on the same tag are overruled
+   - **Record metrics** to `.dev-team/metrics.md` (acceptance rates, rounds to convergence)
    - Write entries to each participating agent's MEMORY.md using the structured format
    - Update shared learnings in `.dev-team/learnings.md`
    - Check cross-agent coherence

package/templates/workflow-skills/dev-team-security-status/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: security-status
+name: dev-team:security-status
 description: Check GitHub security signals — code scanning, Dependabot, secret scanning, and compliance status. Use at session start and before releases.
 user_invocable: true
 ---