@fredericboyer/dev-team 0.5.0 → 0.7.0

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,13 @@ 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. Include Borges's recommendations in the final report.

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

@@ -0,0 +1,43 @@
+---
+name: 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
+---
+
+# Security Status Check
+
+Proactively monitor all GitHub Advanced Security signals for this repository.
+
+## Steps
+
+1. **Run all checks in parallel** using the Bash tool with `gh api`. Derive {owner}/{repo} from `gh repo view --json nameWithOwner --jq .nameWithOwner`:
+
+   - Code scanning alerts (CodeQL, code quality): `gh api --paginate repos/{owner}/{repo}/code-scanning/alerts?state=open`
+   - Dependabot alerts (vulnerable dependencies): `gh api --paginate repos/{owner}/{repo}/dependabot/alerts?state=open`
+   - Secret scanning alerts: `gh api --paginate repos/{owner}/{repo}/secret-scanning/alerts?state=open`
+   - Pending Dependabot PRs: `gh pr list --label dependencies`
+   - Copilot review status on open PRs: check reviews on each open PR
+
+2. **Report findings** in a summary table:
+
+| Signal | Status | Details |
+|--------|--------|---------|
+| Code Scanning (CodeQL) | X open alerts | severity breakdown |
+| Dependabot Security | X open alerts | affected packages |
+| Dependabot Updates | X pending PRs | age of oldest |
+| Secret Scanning | X open alerts | types |
+| Copilot Review | X comments on open PRs | blocking? |
+
+3. **Classify findings:**
+   - `[DEFECT]` — Critical/high severity security alerts, exposed secrets
+   - `[RISK]` — Medium severity alerts, stale Dependabot PRs (>7 days)
+   - `[SUGGESTION]` — Low severity, informational
+
+4. **Recommend actions** for any open alerts — who should fix, urgency, and whether it blocks the current work.
+
+## When to run
+
+- **Every session start** — quick baseline check
+- **Before creating a release** — compliance gate
+- **After merging Dependabot PRs** — verify alerts resolved
+- **On request** — `/dev-team:security-status`

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,16 @@ 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.
+1. 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.
+2. If Borges was not spawned, the task is INCOMPLETE.
 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.

package/templates/hooks/dev-team-task-loop.js

@@ -1,73 +0,0 @@
-#!/usr/bin/env node
-
-/**
- * dev-team-task-loop.js
- * Stop hook — implements iterative task loop with adversarial review gates.
- *
- * When a task loop is active (.claude/dev-team-task.json exists):
- * - Intercepts session exit
- * - Checks if completion criteria are met (no [DEFECT] challenges)
- * - If not met, feeds the task back for another iteration
- * - Respects max iteration limit
- *
- * State file: .claude/dev-team-task.json (created by /dev-team:task skill)
- */
-
-"use strict";
-
-const fs = require("fs");
-const path = require("path");
-
-const STATE_FILE = path.join(process.cwd(), ".claude", "dev-team-task.json");
-
-// No state file means no active task loop — allow normal exit
-if (!fs.existsSync(STATE_FILE)) {
-  process.exit(0);
-}
-
-let state;
-try {
-  state = JSON.parse(fs.readFileSync(STATE_FILE, "utf-8"));
-} catch {
-  // Corrupted state file — clean up and allow exit
-  try {
-    fs.unlinkSync(STATE_FILE);
-  } catch {
-    /* ignore */
-  }
-  process.exit(0);
-}
-
-const { prompt, iteration = 1, maxIterations = 10, sessionId: _sessionId } = state;
-
-// Check iteration limit
-if (iteration >= maxIterations) {
-  console.log(
-    `[dev-team task-loop] Max iterations (${maxIterations}) reached. Exiting loop. Review remaining issues manually.`,
-  );
-  try {
-    fs.unlinkSync(STATE_FILE);
-  } catch {
-    /* ignore */
-  }
-  process.exit(0);
-}
-
-// Increment iteration and update state
-state.iteration = iteration + 1;
-try {
-  fs.writeFileSync(STATE_FILE, JSON.stringify(state, null, 2));
-} catch {
-  // Can't write state — allow exit
-  process.exit(0);
-}
-
-// Block exit and re-inject the task prompt
-const output = JSON.stringify({
-  decision: "block",
-  reason: prompt,
-  systemMessage: `[dev-team task-loop] Iteration ${iteration + 1}/${maxIterations}. Review findings and address any [DEFECT] challenges. When no [DEFECT] remains, output <promise>DONE</promise> to exit the loop. To cancel: delete .claude/dev-team-task.json`,
-});
-
-console.log(output);
-process.exit(0);