@fredericboyer/dev-team 0.6.0 → 0.8.0

package/templates/skill-recommendations.json

@@ -0,0 +1,169 @@
+{
+  "version": "1.0.0",
+  "description": "Curated allowlist of trusted Claude Code skill sources. Only official framework and tool maintainer skills are included.",
+  "trustedSources": [
+    "anthropic",
+    "vercel",
+    "microsoft",
+    "expo",
+    "prisma",
+    "supabase",
+    "playwright",
+    "vuejs",
+    "rust-lang"
+  ],
+  "ecosystems": {
+    "node": {
+      "detectFiles": ["package.json"],
+      "label": "Node.js / JavaScript / TypeScript"
+    },
+    "python": {
+      "detectFiles": ["requirements.txt", "pyproject.toml", "setup.py", "Pipfile", "setup.cfg"],
+      "label": "Python"
+    },
+    "ruby": {
+      "detectFiles": ["Gemfile"],
+      "label": "Ruby"
+    },
+    "go": {
+      "detectFiles": ["go.mod"],
+      "label": "Go"
+    },
+    "rust": {
+      "detectFiles": ["Cargo.toml"],
+      "label": "Rust"
+    },
+    "java": {
+      "detectFiles": ["pom.xml", "build.gradle", "build.gradle.kts"],
+      "label": "Java / Kotlin"
+    }
+  },
+  "skills": [
+    {
+      "id": "react",
+      "name": "React Documentation Lookup",
+      "description": "Search React documentation for components, hooks, and patterns",
+      "source": "vercel",
+      "detectDeps": ["react", "react-dom"],
+      "detectFiles": [],
+      "ecosystem": "node"
+    },
+    {
+      "id": "nextjs",
+      "name": "Next.js Documentation Lookup",
+      "description": "Search Next.js docs for routing, data fetching, and deployment",
+      "source": "vercel",
+      "detectDeps": ["next"],
+      "detectFiles": ["next.config.js", "next.config.mjs", "next.config.ts"],
+      "ecosystem": "node"
+    },
+    {
+      "id": "vue",
+      "name": "Vue.js Documentation Lookup",
+      "description": "Search Vue.js docs for components, composition API, and reactivity",
+      "source": "vuejs",
+      "detectDeps": ["vue"],
+      "detectFiles": ["vue.config.js", "vite.config.ts"],
+      "ecosystem": "node"
+    },
+    {
+      "id": "expo",
+      "name": "Expo Documentation Lookup",
+      "description": "Search Expo docs for React Native, EAS Build, and native modules",
+      "source": "expo",
+      "detectDeps": ["expo"],
+      "detectFiles": ["app.json", "app.config.js", "app.config.ts"],
+      "ecosystem": "node"
+    },
+    {
+      "id": "prisma",
+      "name": "Prisma Documentation Lookup",
+      "description": "Search Prisma docs for schema modeling, migrations, and client usage",
+      "source": "prisma",
+      "detectDeps": ["prisma", "@prisma/client"],
+      "detectFiles": ["prisma/schema.prisma"],
+      "ecosystem": "node"
+    },
+    {
+      "id": "supabase",
+      "name": "Supabase Documentation Lookup",
+      "description": "Search Supabase docs for auth, database, storage, and edge functions",
+      "source": "supabase",
+      "detectDeps": ["@supabase/supabase-js"],
+      "detectFiles": ["supabase/config.toml"],
+      "ecosystem": "node"
+    },
+    {
+      "id": "playwright",
+      "name": "Playwright Test Runner",
+      "description": "Search Playwright docs for browser automation, selectors, and test patterns",
+      "source": "microsoft",
+      "detectDeps": ["@playwright/test", "playwright"],
+      "detectFiles": ["playwright.config.ts", "playwright.config.js"],
+      "ecosystem": "node"
+    },
+    {
+      "id": "angular",
+      "name": "Angular Documentation Lookup",
+      "description": "Search Angular docs for components, services, and dependency injection",
+      "source": "microsoft",
+      "detectDeps": ["@angular/core"],
+      "detectFiles": ["angular.json"],
+      "ecosystem": "node"
+    },
+    {
+      "id": "django",
+      "name": "Django Documentation Lookup",
+      "description": "Search Django docs for models, views, templates, and ORM",
+      "source": "anthropic",
+      "detectDeps": ["django", "Django"],
+      "detectFiles": ["manage.py"],
+      "ecosystem": "python"
+    },
+    {
+      "id": "fastapi",
+      "name": "FastAPI Documentation Lookup",
+      "description": "Search FastAPI docs for endpoints, dependency injection, and async patterns",
+      "source": "anthropic",
+      "detectDeps": ["fastapi"],
+      "detectFiles": [],
+      "ecosystem": "python"
+    },
+    {
+      "id": "flask",
+      "name": "Flask Documentation Lookup",
+      "description": "Search Flask docs for routing, blueprints, and extensions",
+      "source": "anthropic",
+      "detectDeps": ["flask", "Flask"],
+      "detectFiles": [],
+      "ecosystem": "python"
+    },
+    {
+      "id": "rails",
+      "name": "Ruby on Rails Documentation Lookup",
+      "description": "Search Rails docs for ActiveRecord, controllers, and migrations",
+      "source": "anthropic",
+      "detectDeps": ["rails"],
+      "detectFiles": ["config/routes.rb", "bin/rails"],
+      "ecosystem": "ruby"
+    },
+    {
+      "id": "rust-analyzer",
+      "name": "Rust Documentation Lookup",
+      "description": "Search Rust docs for ownership, traits, async, and crate APIs",
+      "source": "rust-lang",
+      "detectDeps": [],
+      "detectFiles": ["Cargo.toml"],
+      "ecosystem": "rust"
+    },
+    {
+      "id": "spring-boot",
+      "name": "Spring Boot Documentation Lookup",
+      "description": "Search Spring Boot docs for auto-configuration, REST APIs, and data access",
+      "source": "anthropic",
+      "detectDeps": ["spring-boot-starter"],
+      "detectFiles": [],
+      "ecosystem": "java"
+    }
+  ]
+}

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

@@ -0,0 +1,167 @@
+---
+name: dev-team:assess
+description: Audit the health of your project's dev-team knowledge base — learnings, agent memory, and CLAUDE.md. Finds stale entries, contradictions, enforcement gaps, and promotion opportunities. Use periodically or after major changes.
+---
+
+Assess the health of the dev-team knowledge base for: $ARGUMENTS
+
+## Scope
+
+This skill audits **only update-safe files** — files that survive `dev-team update`:
+
+- `.dev-team/learnings.md` — shared project learnings
+- `.dev-team/agent-memory/*/MEMORY.md` — per-agent calibration memory
+- Project `CLAUDE.md` — project instructions (content outside `<!-- dev-team:begin/end -->` markers)
+
+**NEVER modify** agent definitions (`.dev-team/agents/`), hook scripts (`.dev-team/hooks/`), skill definitions (`.dev-team/skills/`), or settings (`.claude/settings.json`). These are managed by templates and get overwritten on `dev-team update`.
+
+## Setup
+
+1. Read the following files to build a complete picture:
+   - `.dev-team/learnings.md`
+   - 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)
+
+2. If `$ARGUMENTS` specifies a focus area (e.g., "learnings", "memory", "claude.md"), scope the audit to that area only. Otherwise, audit all three.
+
+## Phase 1: Learnings audit (`.dev-team/learnings.md`)
+
+Check for:
+
+### Staleness
+- Entries that reference removed files, deprecated patterns, or old tool versions
+- Entries contradicted by current code (e.g., "We use Express" when the codebase uses Fastify)
+- Date-stamped entries older than 6 months without recent revalidation
+
+### Contradictions
+- Entries that contradict each other (e.g., one says "always use snake_case" and another says "we adopted camelCase")
+- Entries that contradict the project's `CLAUDE.md` instructions
+- Entries that contradict agent memory files
+
+### Enforcement gaps
+- Learnings that state a rule but have no corresponding hook, linter rule, or agent check to enforce it
+- Learnings about process that are not reflected in `CLAUDE.md`
+
+### Promotion opportunities
+- Learnings that are mature enough to become formal project instructions in `CLAUDE.md`
+- Learnings that should be elevated to an ADR in `docs/adr/`
+- Learnings that are really agent-specific calibration and should move to the appropriate agent's `MEMORY.md`
+
+## Phase 2: Agent memory audit (`.dev-team/agent-memory/*/MEMORY.md`)
+
+Check each agent's memory file for:
+
+### Empty or boilerplate files
+- Memory files that are empty or contain only the initial template header
+- Agents that have been active (based on learnings references or git history) but have no memory entries
+
+### Staleness
+- Memory entries that reference files, patterns, or decisions that no longer exist
+- Calibration notes about overruled findings when the underlying code has since changed
+- Entries that duplicate what is already in `.dev-team/learnings.md` (should be deduplicated)
+
+### Inconsistencies
+- Agent memory that contradicts `.dev-team/learnings.md`
+- Agent memory that contradicts another agent's memory (e.g., Szabo says "auth uses sessions" but Voss says "auth uses JWT")
+- Agent memory that contradicts `CLAUDE.md`
+
+### Coverage gaps
+- Installed agents (from `config.json`) with no meaningful memory — suggests the agent has not been calibrated
+- Agents referenced in learnings but missing a memory file
+
+## Phase 3: CLAUDE.md audit
+
+Check the project's `CLAUDE.md` for:
+
+### Accuracy
+- Instructions that do not match actual project behavior (verify claims against code)
+- Workflow descriptions that reference tools, commands, or patterns not present in the repo
+- Agent descriptions or hook triggers that are outdated
+
+### Completeness
+- Important patterns from `.dev-team/learnings.md` that should be in `CLAUDE.md` but are not
+- Missing sections that a new developer would need (build commands, test commands, architecture overview)
+- Installed agents or hooks not mentioned in `CLAUDE.md`
+
+### Staleness
+- Content outside the `<!-- dev-team:begin/end -->` markers that references old patterns
+- References to removed dependencies, deprecated APIs, or old file paths
+
+### Learnings promotion
+- Mature learnings that have been stable for multiple sessions and should be promoted to `CLAUDE.md` instructions
+
+## Report
+
+Produce a structured health report:
+
+### Executive summary
+
+One paragraph: overall knowledge base health, number of issues found by severity.
+
+### Findings by area
+
+For each area (learnings, agent memory, CLAUDE.md), list findings using classified severity:
+
+```
+**[DEFECT]** area — description
+Concrete impact: what goes wrong if this is not fixed.
+Suggested fix: specific action to take.
+```
+
+```
+**[RISK]** area — description
+Why this matters and what could go wrong.
+```
+
+```
+**[SUGGESTION]** area — description
+Specific improvement with expected benefit.
+```
+
+### Cross-cutting issues
+
+Issues that span multiple files:
+- Contradictions between learnings and agent memory
+- Information that exists in the wrong file
+- Patterns documented in multiple places with divergent descriptions
+
+### Recommended actions
+
+Numbered list of concrete actions, ordered by priority:
+
+1. **Fix [DEFECT] items** — these represent actively wrong information
+2. **Address [RISK] items** — these will cause problems soon
+3. **Consider [SUGGESTION] items** — these improve overall health
+
+For each action, specify which file to edit and what change to make.
+
+### Health score
+
+Provide a simple health score:
+
+| Area | Status | Issues |
+|------|--------|--------|
+| 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 |
+| **Overall** | **status** | **total** |
+
+Thresholds:
+- **Healthy**: 0 defects, 0-2 risks
+- **Needs attention**: 0 defects, 3+ risks OR 1 defect
+- **Unhealthy**: 2+ defects
+
+## Completion
+
+After the health report is delivered:
+1. Spawn **@dev-team-borges** (Librarian) to review memory freshness and capture any learnings from the assessment findings. This is mandatory.
+2. Include Borges's recommendations in the final report.
+
+## When to run
+
+- **Periodically** — monthly or after a burst of activity
+- **After major refactors** — code changes may invalidate learnings
+- **Before onboarding** — ensure the knowledge base is accurate for new team members
+- **After resolving many review findings** — learnings and memory may need cleanup
+- **On request** — `/dev-team:assess`

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

@@ -22,7 +22,7 @@ Run a comprehensive audit of: $ARGUMENTS
 1. Spawn all three agents as **parallel background subagents** using the Agent tool with `subagent_type: "general-purpose"`.
 
 2. Each agent's prompt must include:
-   - The agent's full definition (read from `.claude/agents/<agent>.md`)
+   - The agent's full definition (read from `.dev-team/agents/<agent>.md`)
    - The scope (directory/pattern or "full codebase")
    - Instruction to produce classified findings: `[DEFECT]`, `[RISK]`, `[QUESTION]`, `[SUGGESTION]`
    - Instruction to read the actual code and tests for full context
@@ -84,8 +84,13 @@ Same grouping. Include actionable recommendations.
 
 Numbered list of concrete actions, ordered by priority. Each action should reference the specific finding it addresses.
 
+### Security preamble
+
+Before starting the audit, check for open security alerts: run `/dev-team:security-status` if available, or check `gh api repos/{owner}/{repo}/code-scanning/alerts?state=open` and `gh api repos/{owner}/{repo}/dependabot/alerts?state=open`. Include these in the audit scope.
+
 ### Completion
 
 After the audit report is delivered:
-1. Spawn **@dev-team-borges** (Librarian) to review memory freshness and capture learnings from the audit findings. This is mandatory.
-2. Include Borges's recommendations in the final report.
+1. You MUST spawn **@dev-team-borges** (Librarian) as the final step to review memory freshness and capture learnings from the audit findings. Do NOT skip this.
+2. If Borges was not spawned, the audit is INCOMPLETE.
+3. Include Borges's recommendations in the final report.

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

@@ -0,0 +1,95 @@
+---
+name: dev-team:merge
+description: Merge a PR with monitoring -- checks Copilot comments, sets auto-merge, monitors until complete, triggers next steps.
+user_invocable: true
+---
+
+Merge a pull request with full monitoring: $ARGUMENTS
+
+## Setup
+
+1. Determine the PR number:
+   - If provided as argument, use it directly
+   - Otherwise, detect from current branch: `gh pr view --json number --jq .number`
+   - If no PR found, report error and stop
+
+2. Capture repo context:
+   - `gh repo view --json nameWithOwner --jq .nameWithOwner` to get {owner}/{repo}
+
+## Step 1: Check for Copilot review comments
+
+Before proceeding with merge, check for Copilot (and other automated) review comments:
+
+```
+gh api repos/{owner}/{repo}/pulls/{number}/reviews
+gh api repos/{owner}/{repo}/pulls/{number}/comments
+```
+
+Filter for reviews/comments from bot accounts (especially `copilot` and `github-actions`).
+
+- If Copilot has left comments or suggestions:
+  1. Display each finding with file, line, and comment body
+  2. For actionable suggestions: apply the fix in code, commit, and push
+  3. For each comment thread: reply acknowledging the finding and resolve the thread using `gh api repos/{owner}/{repo}/pulls/{number}/comments/{id}/replies`
+  4. After addressing all findings, re-push and wait for CI to restart
+
+- If no Copilot comments: proceed to Step 2
+
+## Step 2: Set auto-merge
+
+```bash
+gh pr merge {number} --squash --auto --delete-branch
+```
+
+This tells GitHub to merge automatically once all required checks pass.
+
+## Step 3: Check CI status and monitor
+
+Check current CI status:
+
+```bash
+gh pr checks {number}
+```
+
+**If all checks are passing:**
+- The PR will merge immediately (or within seconds)
+- Verify by checking: `gh pr view {number} --json state --jq .state`
+- If state is `MERGED`, proceed to Step 4
+
+**If checks are pending:**
+- Inform the user that auto-merge is set and CI is running
+- Spawn a background monitoring agent to poll until completion:
+  - Poll every 30 seconds: `gh pr view {number} --json state --jq .state`
+  - If state becomes `MERGED`: report success and proceed to Step 4
+  - If checks fail: report the failure with details from `gh pr checks {number}`
+  - Timeout after 15 minutes of polling
+
+**If checks are failing:**
+- Report which checks failed: `gh pr checks {number}`
+- Do NOT proceed with merge
+- Suggest investigating the failures
+
+## Step 4: Post-merge actions
+
+After merge is confirmed:
+
+1. **Switch to main and pull latest:**
+   ```bash
+   git checkout main
+   git pull origin main
+   ```
+
+2. **Report the merge commit:**
+   ```bash
+   git log -1 --format="%H %s"
+   ```
+
+3. **Check for next work:**
+   - If there is a known next issue in the current milestone or the user mentioned follow-up work, suggest starting it
+   - If the branch was a worktree, note that the worktree can be cleaned up
+
+## Error handling
+
+- If `gh` commands fail, check authentication: `gh auth status`
+- If merge conflicts are reported, inform the user -- do not attempt automatic resolution
+- If branch protection rules block the merge, report which rules are not satisfied

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

@@ -19,7 +19,7 @@ Run a multi-agent parallel review of: $ARGUMENTS
 | `auth`, `login`, `password`, `token`, `session`, `crypto`, `secret`, `permission`, `oauth`, `jwt`, `cors`, `csrf` | @dev-team-szabo | Security surface |
 | `/api/`, `/routes/`, `schema`, `.graphql`, `.proto`, `openapi` | @dev-team-mori | API/UI contract |
 | `docker`, `.env`, `config`, `migration`, `database`, `.sql`, `deploy` | @dev-team-voss | Infrastructure |
-| `.github/workflows`, `.claude/`, `tsconfig`, `eslint`, `prettier`, `package.json` | @dev-team-deming | Tooling |
+| `.github/workflows`, `.dev-team/`, `tsconfig`, `eslint`, `prettier`, `package.json` | @dev-team-deming | Tooling |
 | `readme`, `changelog`, `.md`, `/docs/` | @dev-team-tufte | Documentation |
 | `/adr/`, `architecture`, `/core/`, `/domain/` | @dev-team-brooks | Architecture |
 | `package.json`, `version`, `changelog`, release workflows | @dev-team-conway | Release artifacts |
@@ -32,7 +32,7 @@ Run a multi-agent parallel review of: $ARGUMENTS
 1. Spawn each selected agent as a **parallel background subagent** using the Agent tool with `subagent_type: "general-purpose"`.
 
 2. Each agent's prompt must include:
-   - The agent's full definition (read from `.claude/agents/<agent>.md`)
+   - The agent's full definition (read from `.dev-team/agents/<agent>.md`)
    - The list of changed files relevant to their domain
    - Instruction to produce classified findings: `[DEFECT]`, `[RISK]`, `[QUESTION]`, `[SUGGESTION]`
    - Instruction to read the actual code — not just the diff — for full context
@@ -67,8 +67,15 @@ Group by severity:
 
 State the verdict clearly. List what must be fixed for approval if requesting changes.
 
+### Security preamble
+
+Before starting the review, check for open security alerts: run `/dev-team:security-status` if available, or check `gh api repos/{owner}/{repo}/code-scanning/alerts?state=open` and `gh api repos/{owner}/{repo}/dependabot/alerts?state=open`. Flag any critical findings in the review report.
+
 ### Completion
 
 After the review report is delivered:
-1. Spawn **@dev-team-borges** (Librarian) to review memory freshness and capture any learnings from the review findings. This is mandatory.
-2. Include Borges's recommendations in the final report.
+1. You MUST spawn **@dev-team-borges** (Librarian) as the final step to review memory freshness and capture any learnings from the review findings. Do NOT skip this.
+2. If Borges was not spawned, the review is INCOMPLETE.
+3. **Borges memory gate**: If Borges reports that any participating agent's MEMORY.md is empty or contains only boilerplate, this is a **[DEFECT]** that blocks review completion. The agent must write substantive learnings before the review can be marked done.
+4. Include Borges's recommendations in the final report.
+5. **If the verdict is Approve** and this review is for a PR that is ready to merge, invoke `/dev-team:merge` to set auto-merge, monitor CI, and verify the merge completes. The PR lifecycle does not end at approval -- it ends at merge.

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

@@ -1,6 +1,6 @@
 ---
 name: dev-team:task
-description: Start an iterative task loop with adversarial review gates. Use when the user wants a task implemented with automatic quality convergence — the loop continues until no [DEFECT] challenges remain or max iterations are reached.
+description: Start an iterative task loop with adversarial review gates. Use when the user wants a task implemented with automatic quality convergence -- the loop continues until no [DEFECT] challenges remain or max iterations are reached.
 ---
 
 Start a task loop for: $ARGUMENTS
@@ -11,25 +11,15 @@ Start a task loop for: $ARGUMENTS
    - `--max-iterations N` (default: 10)
    - `--reviewers` (default: @dev-team-szabo, @dev-team-knuth)
 
-2. Create the state file `.claude/dev-team-task.json`:
-```json
-{
-  "prompt": "<the original task description>",
-  "iteration": 1,
-  "maxIterations": <N>,
-  "reviewers": ["dev-team-szabo", "dev-team-knuth"]
-}
-```
-
-3. Determine the right implementing agent based on the task:
-   - Backend/API/data work → @dev-team-voss
-   - Frontend/UI work → @dev-team-mori
-   - Test writing → @dev-team-beck
-   - Tooling/config → @dev-team-deming
-   - Documentation → @dev-team-tufte
-   - Release/versioning → @dev-team-conway
-
-4. **Architect pre-assessment** (skip for bug fixes, typo fixes, config tweaks):
+2. Determine the right implementing agent based on the task:
+   - Backend/API/data work -> @dev-team-voss
+   - Frontend/UI work -> @dev-team-mori
+   - Test writing -> @dev-team-beck
+   - Tooling/config -> @dev-team-deming
+   - Documentation -> @dev-team-tufte
+   - Release/versioning -> @dev-team-conway
+
+3. **Architect pre-assessment** (skip for bug fixes, typo fixes, config tweaks):
    Spawn @dev-team-brooks to assess:
    - Does this task introduce a new pattern, tool, or convention?
    - Does it change module boundaries, dependency direction, or layer responsibilities?
@@ -39,20 +29,26 @@ Start a task loop for: $ARGUMENTS
 
    If an ADR is needed, include "Write ADR-NNN: <title>" in the implementation task. The implementing agent writes the ADR file. Architect reviews it post-implementation alongside code review.
 
+## Pre-implementation: best-practices research
+
+Before the first iteration, the implementing agent should research current best practices relevant to the task — checking official documentation for the tools, frameworks, and platforms involved. This ensures decisions are based on current ecosystem recommendations, not stale assumptions. When current best practices conflict with established codebase conventions, prefer consistency and flag the newer approach as a `[SUGGESTION]` with a migration path.
+
 ## Execution loop
 
-Each iteration:
+Track iterations in conversation context (no state files). For each iteration:
+
 1. The implementing agent works on the task.
 2. After implementation, spawn review agents in parallel as background tasks.
 3. Collect classified challenges from reviewers.
 4. If any `[DEFECT]` challenges exist, address them in the next iteration.
-5. If no `[DEFECT]` remains, output `<promise>DONE</promise>` to exit the loop.
+5. If no `[DEFECT]` remains, output DONE to exit the loop.
+6. If max iterations reached without convergence, report remaining defects and exit.
 
-The Stop hook (`dev-team-task-loop.js`) manages iteration counting and re-injection.
+The convergence check happens in conversation context: count iterations, check for `[DEFECT]` findings, and decide whether to continue or exit.
 
 ## Parallel mode
 
-When multiple issues are being addressed in a single session, the task loop switches to parallel orchestration (see ADR-019). Drucker coordinates all phases.
+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.
 
 ### Phase 0: Brooks pre-assessment (batch)
 Spawn @dev-team-brooks once with all issues. Brooks identifies:
@@ -63,22 +59,10 @@ Spawn @dev-team-brooks once with all issues. Brooks identifies:
 Issues in the same conflict group execute sequentially. Independent issues proceed in parallel.
 
 ### Phase 1: Parallel implementation
-Drucker spawns one implementing agent per independent issue, each on its own branch (`feat/<issue>-<description>`). Agents work concurrently without awareness of each other. Track state in `.claude/dev-team-parallel.json`:
-```json
-{
-  "mode": "parallel",
-  "issues": [
-    { "issue": 42, "branch": "feat/42-add-auth", "agent": "dev-team-voss", "status": "implementing" },
-    { "issue": 43, "branch": "feat/43-fix-nav", "agent": "dev-team-mori", "status": "implementing" }
-  ],
-  "phase": "implementation",
-  "conflictGroups": [[42, 55]],
-  "reviewWave": null
-}
-```
+Drucker spawns one implementing agent per independent issue, each on its own branch (`feat/<issue>-<description>`). Agents work concurrently without awareness of each other. Drucker tracks which issues are assigned to which agents and branches in conversation context.
 
 ### Phase 2: Review wave
-Reviews do **not** start until **all** implementation agents have completed. 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.
+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.
@@ -90,13 +74,19 @@ Borges runs **once** across all branches after the final review wave clears. Thi
 Parallel mode is complete when:
 1. All branches have zero `[DEFECT]` findings, OR the per-branch iteration limit (default: 10) is reached
 2. Borges has run across all branches
-3. `.claude/dev-team-parallel.json` is deleted
+
+## Security preamble
+
+Before starting work, check for open security alerts: run `/dev-team:security-status` if available, or check `gh api repos/{owner}/{repo}/code-scanning/alerts?state=open` and `gh api repos/{owner}/{repo}/dependabot/alerts?state=open`. Flag any critical findings before proceeding.
 
 ## Completion
 
 When the loop exits:
-1. Delete `.claude/dev-team-task.json`.
-2. Spawn **@dev-team-borges** (Librarian) to review memory freshness, cross-agent coherence, and system improvement opportunities. This is mandatory.
-3. Summarize what was accomplished across all iterations.
-4. Report any remaining `[RISK]` or `[SUGGESTION]` items, including Borges's recommendations.
-5. Write key learnings to agent MEMORY.md files.
+1. **Create PR and merge**: If changes are on a feature branch, create the PR (body must include `Closes #<issue>`) and invoke `/dev-team:merge` to set auto-merge, monitor CI, handle Copilot review comments, and verify the merge completes. Work is NOT done until the PR is merged. If merge fails (CI failures, merge conflicts, branch protection), report the blocker to the human rather than leaving the PR 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 to review memory freshness, cross-agent coherence, and system improvement opportunities. Do NOT skip this.
+4. If Borges was not spawned, the task is INCOMPLETE.
+5. **Borges memory gate**: If Borges reports that any implementing agent's MEMORY.md is empty or contains only boilerplate after a task, this is a **[DEFECT]** that blocks task completion. The implementing agent must write substantive learnings before the task can be marked done. Empty agent memory after a task means the enforcement pipeline failed.
+6. Summarize what was accomplished across all iterations.
+7. Report any remaining `[RISK]` or `[SUGGESTION]` items, including Borges's recommendations.
+8. Write key learnings to agent MEMORY.md files.