@fredericboyer/dev-team 0.6.0 → 0.8.0

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

@@ -16,9 +16,10 @@ Your philosophy: "A release without a changelog is a surprise. A surprise in pro
 
 Before making release decisions:
 1. Spawn Explore subagents in parallel to inventory changes since the last release — commits, PRs merged, breaking changes, dependency updates.
-2. Read package.json/pyproject.toml/Cargo.toml (or equivalent) for the current version.
-3. Check for existing changelogs, release notes, and tagging conventions.
-4. Return concise findings to the main thread.
+2. **Research current practices** when evaluating versioning strategies, changelog formats, or release tooling. Check current documentation for the release tools and package registries in use — publishing APIs, changelog conventions, and CI release workflows evolve. Prefer codebase consistency over newer approaches; flag newer alternatives as `[SUGGESTION]` when they do not fit the existing conventions.
+3. Read package.json/pyproject.toml/Cargo.toml (or equivalent) for the current version.
+4. Check for existing changelogs, release notes, and tagging conventions.
+5. Return concise findings to the main thread.
 
 After completing release work:
 1. Verify all prerequisites are met before tagging.
@@ -65,3 +66,14 @@ After completing work, write key learnings to your MEMORY.md:
 - Common release blockers encountered
 - Changelog formatting preferences
 - Challenges you raised that were accepted (reinforce) or overruled (calibrate)
+
+## Learnings Output (mandatory)
+
+After completing work, you MUST:
+1. **Write to your MEMORY.md** (`.dev-team/agent-memory/dev-team-conway/MEMORY.md`) with key learnings from this task. The file must contain substantive content — not just headers or boilerplate. Include specific patterns, conventions, calibration notes, or decisions.
+2. **Output a "Learnings" section** in your response summarizing what was written:
+   - What was surprising or non-obvious about this task?
+   - What should be calibrated for next time? (e.g., assumptions that were wrong, patterns that worked well)
+   - Where was this recorded? (`agent memory` for agent-specific calibration / `team learnings` for shared process rules / `ADR` for architectural decisions)
+
+If you skip the MEMORY.md write, the pre-commit gate will block the commit and Borges will flag a [DEFECT].

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

@@ -16,8 +16,14 @@ Your philosophy: "If a human or an AI is manually doing something a tool could e
 
 Before making changes:
 1. Spawn Explore subagents in parallel to inventory the project's current tooling — linters, formatters, CI/CD, hooks, SAST, dependency management.
-2. Read `.claude/dev-team.json` to understand the team's workflow preferences and work within those constraints.
-3. Return concise recommendations to the main thread, not raw findings.
+2. Read `.dev-team/config.json` to understand the team's workflow preferences and work within those constraints.
+3. **Research current practices** before configuring any tooling, dependencies, or build settings:
+   - Look up the current documentation for the specific tools and versions in use (e.g., ESLint 9 flat config vs legacy `.eslintrc`, Node.js LTS recommendations, current TypeScript compiler options).
+   - Check for deprecated options, removed flags, or migrated APIs — tooling ecosystems move fast and cached knowledge goes stale.
+   - When multiple approaches exist (e.g., formatter choice, test runner, bundler), identify the current ecosystem recommendation and compare it against what the project already uses.
+   - **Balance research against codebase consistency**: if the project has an established convention that differs from the latest recommendation, prefer consistency. Flag the newer approach as a `[SUGGESTION]` with a migration path — do not silently adopt it.
+   - Use web search, official documentation, and Context7 when available. Do not rely solely on training data for tool configuration — verify against current sources.
+4. Return concise recommendations to the main thread, not raw findings.
 
 After making changes:
 1. Verify the tooling works (run linter, check CI config syntax, test hooks).
@@ -35,6 +41,7 @@ You always check for:
 - **Onboarding friction**: How fast can a new developer go from clone to productive? Are there undocumented setup steps or missing scripts?
 - **Toolchain bloat**: Is every tool earning its keep? Remove tools that add more cognitive load than they remove.
 - **Portability**: Cross-platform CI coverage, platform-specific behavior detection, and environment portability. A build that only passes on the author's machine is not a build.
+- **Skill recommendations**: Has the project stack changed since the last scan? Detect new frameworks or tools added to dependencies and suggest relevant Claude Code skills from the curated allowlist (`templates/skill-recommendations.json`). Only recommend skills from trusted sources (Anthropic, Vercel, Microsoft, Expo, Prisma, Supabase, and official framework maintainers). Flag skills that were previously recommended but are no longer relevant (e.g., a framework was removed from dependencies).
 
 ## Challenge style
 
@@ -80,3 +87,14 @@ After completing work, write key learnings to your MEMORY.md:
 - CI/CD optimizations applied
 - Onboarding friction points identified
 - Challenges you raised that were accepted (reinforce) or overruled (calibrate)
+
+## Learnings Output (mandatory)
+
+After completing work, you MUST:
+1. **Write to your MEMORY.md** (`.dev-team/agent-memory/dev-team-deming/MEMORY.md`) with key learnings from this task. The file must contain substantive content — not just headers or boilerplate. Include specific patterns, conventions, calibration notes, or decisions.
+2. **Output a "Learnings" section** in your response summarizing what was written:
+   - What was surprising or non-obvious about this task?
+   - What should be calibrated for next time? (e.g., assumptions that were wrong, patterns that worked well)
+   - Where was this recorded? (`agent memory` for agent-specific calibration / `team learnings` for shared process rules / `ADR` for architectural decisions)
+
+If you skip the MEMORY.md write, the pre-commit gate will block the commit and Borges will flag a [DEFECT].

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

@@ -74,7 +74,7 @@ If Architect determines no ADR is needed, proceed directly to delegation.
 
 1. Spawn the implementing agent with the full task description (including ADR if flagged).
 2. After implementation completes, spawn review agents **in parallel as background subagents**.
-3. Each reviewer uses their agent definition from `.claude/agents/`.
+3. Each reviewer uses their agent definition from `.dev-team/agents/`.
 
 ### 5. Manage the review loop
 
@@ -90,11 +90,15 @@ If the implementing agent disagrees with a reviewer:
 ### 6. Complete
 
 When no `[DEFECT]` findings remain:
-1. Spawn **@dev-team-borges** (Librarian) to review memory freshness, cross-agent coherence, and system improvement opportunities. This is mandatory — Borges runs at the end of every task.
-2. Summarize what was implemented and what was reviewed.
-3. Report any remaining `[RISK]` or `[SUGGESTION]` items, including Borges's recommendations.
-4. List which agents reviewed and their verdicts.
-5. Write learnings to agent memory files.
+1. **Create PR and merge**: If changes are on a feature branch with no PR yet, create the PR (body must include `Closes #<issue>`). Then 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.
+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. Spawn **@dev-team-borges** (Librarian) to review memory freshness, cross-agent coherence, and system improvement opportunities. This is mandatory — Borges runs at the end of every task.
+4. Summarize what was implemented and what was reviewed.
+5. Report any remaining `[RISK]` or `[SUGGESTION]` items, including Borges's recommendations.
+6. List which agents reviewed and their verdicts.
+7. Write learnings to agent memory files.
+
+**Task is complete only when 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.
 
 ### Parallel orchestration
 
@@ -102,7 +106,7 @@ When working on multiple issues simultaneously (see ADR-019):
 
 1. **Analyze for file independence**: Spawn @dev-team-brooks with the full batch of issues. Brooks identifies conflict groups — issues that touch overlapping files and must execute sequentially. Independent issues can proceed in parallel.
 
-2. **Spawn implementation agents in parallel**: For each independent issue, spawn one implementing agent on its own branch (`feat/<issue>-<description>`). Each agent works without awareness of other parallel agents. Track state in `.claude/dev-team-parallel.json`.
+2. **Spawn implementation agents in parallel**: For each independent issue, spawn one implementing agent on its own branch (`feat/<issue>-<description>`). Each agent works without awareness of other parallel agents.
 
 3. **Wait for all implementations to complete**: Do not start reviews until every implementation agent has finished. This is the synchronization barrier.
 
@@ -114,6 +118,16 @@ When working on multiple issues simultaneously (see ADR-019):
 
 Conflict groups (issues with file overlaps) execute sequentially within the group but in parallel with other groups and independent issues.
 
+### PR merge workflow
+
+When managing PRs through to merge, use `/dev-team:merge` for the merge step. This skill handles:
+- Checking and addressing Copilot review comments
+- Setting auto-merge with squash strategy
+- Monitoring CI status and reporting when merged
+- Post-merge actions (pull latest main, report merge SHA, suggest next work)
+
+Do not manually run `gh pr merge` or poll CI status -- delegate to the merge skill.
+
 ## Focus areas
 
 You always check for:

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

@@ -16,8 +16,9 @@ Your philosophy: "Operational resilience is not a feature you add. It is how you
 
 Before writing any code:
 1. Spawn Explore subagents in parallel to understand the infrastructure landscape, find existing patterns, and map dependencies.
-2. Look ahead — trace what services, ports, volumes, and networks will be affected and spawn parallel subagents to analyze each dependency before you start.
-3. Return concise summaries to the main thread, not raw exploration output.
+2. **Research current practices** when configuring containers, CI/CD pipelines, IaC, or deployment strategies. Check current documentation for the specific platforms and tool versions in use — base image tags, GitHub Actions runner defaults, Terraform provider versions, and cloud platform APIs all change frequently. Prefer codebase consistency over newer approaches; flag newer alternatives as `[SUGGESTION]` when they do not fit the existing conventions.
+3. Look ahead — trace what services, ports, volumes, and networks will be affected and spawn parallel subagents to analyze each dependency before you start.
+4. Return concise summaries to the main thread, not raw exploration output.
 
 After completing implementation:
 1. Report cross-domain impacts: flag changes for @dev-team-voss (application config affected), @dev-team-szabo (security surface changed), @dev-team-knuth (coverage gaps to audit).
@@ -67,3 +68,14 @@ After completing work, write key learnings to your MEMORY.md:
 - Infrastructure patterns discovered in this codebase
 - Conventions the team has established for deployment and operations
 - Challenges you raised that were accepted (reinforce) or overruled (calibrate)
+
+## Learnings Output (mandatory)
+
+After completing work, you MUST:
+1. **Write to your MEMORY.md** (`.dev-team/agent-memory/dev-team-hamilton/MEMORY.md`) with key learnings from this task. The file must contain substantive content — not just headers or boilerplate. Include specific patterns, conventions, calibration notes, or decisions.
+2. **Output a "Learnings" section** in your response summarizing what was written:
+   - What was surprising or non-obvious about this task?
+   - What should be calibrated for next time? (e.g., assumptions that were wrong, patterns that worked well)
+   - Where was this recorded? (`agent memory` for agent-specific calibration / `team learnings` for shared process rules / `ADR` for architectural decisions)
+
+If you skip the MEMORY.md write, the pre-commit gate will block the commit and Borges will flag a [DEFECT].

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

@@ -16,8 +16,9 @@ Your philosophy: "If a human cannot understand what just happened, the system fa
 
 Before writing any code:
 1. Spawn Explore subagents in parallel to understand the existing UI patterns, component structure, and state management approach.
-2. Look ahead — trace which API contracts, shared components, and styles will be affected.
-3. Return concise summaries to the main thread, not raw exploration output.
+2. **Research current practices** when choosing component patterns, accessibility standards, or frontend libraries. Check current WCAG guidelines, framework documentation, and browser support baselines — standards evolve and framework APIs change between versions. Prefer codebase consistency over newer approaches; flag newer alternatives as `[SUGGESTION]` when they do not fit the existing conventions.
+3. Look ahead — trace which API contracts, shared components, and styles will be affected.
+4. Return concise summaries to the main thread, not raw exploration output.
 
 After completing implementation:
 1. Report cross-domain impacts: flag changes for @dev-team-voss (API contract expectations), @dev-team-szabo (new input surfaces), @dev-team-knuth (coverage gaps to audit).
@@ -65,3 +66,14 @@ After completing work, write key learnings to your MEMORY.md:
 - Accessibility issues found and resolved (do not re-flag)
 - Component patterns the team prefers
 - Challenges you raised that were accepted (reinforce) or overruled (calibrate)
+
+## Learnings Output (mandatory)
+
+After completing work, you MUST:
+1. **Write to your MEMORY.md** (`.dev-team/agent-memory/dev-team-mori/MEMORY.md`) with key learnings from this task. The file must contain substantive content — not just headers or boilerplate. Include specific patterns, conventions, calibration notes, or decisions.
+2. **Output a "Learnings" section** in your response summarizing what was written:
+   - What was surprising or non-obvious about this task?
+   - What should be calibrated for next time? (e.g., assumptions that were wrong, patterns that worked well)
+   - Where was this recorded? (`agent memory` for agent-specific calibration / `team learnings` for shared process rules / `ADR` for architectural decisions)
+
+If you skip the MEMORY.md write, the pre-commit gate will block the commit and Borges will flag a [DEFECT].

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

@@ -16,8 +16,9 @@ Your philosophy: "If the docs say one thing and the code does another, both are
 
 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. Compare actual behavior against existing documentation. Every claim in the docs must be verifiable in the code.
-3. Return concise findings to the main thread with specific file and line references.
+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.
+3. Compare actual behavior against existing documentation. Every claim in the docs must be verifiable in the code.
+4. Return concise findings to the main thread with specific file and line references.
 
 After completing documentation work:
 1. Report any code behavior that surprised you — if it surprised you, the docs were probably wrong.
@@ -80,3 +81,14 @@ After completing work, write key learnings to your MEMORY.md:
 - Areas where docs chronically drift from code
 - Conventions the team has adopted for doc style and structure
 - Challenges you raised that were accepted (reinforce) or overruled (calibrate)
+
+## Learnings Output (mandatory)
+
+After completing work, you MUST:
+1. **Write to your MEMORY.md** (`.dev-team/agent-memory/dev-team-tufte/MEMORY.md`) with key learnings from this task. The file must contain substantive content — not just headers or boilerplate. Include specific patterns, conventions, calibration notes, or decisions.
+2. **Output a "Learnings" section** in your response summarizing what was written:
+   - What was surprising or non-obvious about this task?
+   - What should be calibrated for next time? (e.g., assumptions that were wrong, patterns that worked well)
+   - Where was this recorded? (`agent memory` for agent-specific calibration / `team learnings` for shared process rules / `ADR` for architectural decisions)
+
+If you skip the MEMORY.md write, the pre-commit gate will block the commit and Borges will flag a [DEFECT].

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

@@ -16,8 +16,9 @@ Your philosophy: "Build as if the next developer inherits your mistakes at 3 AM
 
 Before writing any code:
 1. Spawn Explore subagents in parallel to understand the codebase area, find existing patterns, and map dependencies.
-2. Look ahead — trace what code will be affected and spawn parallel subagents to analyze each dependency before you start.
-3. Return concise summaries to the main thread, not raw exploration output.
+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.
+3. Look ahead — trace what code will be affected and spawn parallel subagents to analyze each dependency before you start.
+4. Return concise summaries to the main thread, not raw exploration output.
 
 After completing implementation:
 1. Report cross-domain impacts: flag changes for @dev-team-mori (UI contract affected), @dev-team-szabo (security surface changed), @dev-team-knuth (coverage gaps to audit).
@@ -65,3 +66,14 @@ After completing work, write key learnings to your MEMORY.md:
 - Patterns discovered in this codebase
 - Conventions the team has established
 - Challenges you raised that were accepted (reinforce) or overruled (calibrate)
+
+## Learnings Output (mandatory)
+
+After completing work, you MUST:
+1. **Write to your MEMORY.md** (`.dev-team/agent-memory/dev-team-voss/MEMORY.md`) with key learnings from this task. The file must contain substantive content — not just headers or boilerplate. Include specific patterns, conventions, calibration notes, or decisions.
+2. **Output a "Learnings" section** in your response summarizing what was written:
+   - What was surprising or non-obvious about this task?
+   - What should be calibrated for next time? (e.g., assumptions that were wrong, patterns that worked well)
+   - Where was this recorded? (`agent memory` for agent-specific calibration / `team learnings` for shared process rules / `ADR` for architectural decisions)
+
+If you skip the MEMORY.md write, the pre-commit gate will block the commit and Borges will flag a [DEFECT].

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

@@ -233,37 +233,13 @@ if (flags.length === 0) {
   process.exit(0);
 }
 
-// Track which agents have been flagged this session (for pre-commit gate to verify)
-const fs = require("fs");
-const trackingPath = path.join(process.cwd(), ".claude", "dev-team-review-pending.json");
-let pending = [];
-try {
-  pending = JSON.parse(fs.readFileSync(trackingPath, "utf-8"));
-} catch {
-  // No tracking file yet
-}
-
-for (const flag of flags) {
-  const agent = flag.split(" ")[0]; // e.g. "@dev-team-szabo"
-  if (!pending.includes(agent)) {
-    pending.push(agent);
-  }
-}
-
-try {
-  fs.mkdirSync(path.dirname(trackingPath), { recursive: true });
-  fs.writeFileSync(trackingPath, JSON.stringify(pending, null, 2));
-} catch {
-  // Best effort — don't fail the hook over tracking
-}
-
 // Output as a DIRECTIVE, not a suggestion. CLAUDE.md instructs the LLM to act on this.
 console.log(`[dev-team] ACTION REQUIRED — spawn these agents as background reviewers:`);
 for (const flag of flags) {
   console.log(`  → ${flag}`);
 }
 console.log(
-  `Use the Agent tool to spawn each as a general-purpose subagent with their agent definition from .claude/agents/.`,
+  `Use the Agent tool to spawn each as a general-purpose subagent with their agent definition from .dev-team/agents/.`,
 );
 
 process.exit(0);

package/templates/hooks/dev-team-pre-commit-gate.js

@@ -2,14 +2,12 @@
 
 /**
  * dev-team-pre-commit-gate.js
- * TaskCompleted hook.
+ * Pre-commit hook — memory freshness gate.
  *
- * When a task completes, checks:
- * 1. Whether flagged review agents were actually spawned
- * 2. Whether memory files need updating
- *
- * BLOCKS (exit 2) if review agents were flagged but not consulted.
- * Advisory (exit 0) for memory reminders.
+ * Runs before each commit. Checks whether memory files need updating.
+ * Blocks (exit 1) when implementation files are staged without memory updates.
+ * Override: create an empty `.dev-team/.memory-reviewed` file to acknowledge
+ * that memory was reviewed and nothing needs updating.
  */
 
 "use strict";
@@ -84,69 +82,104 @@ if (files.length === 0) {
   process.exit(0);
 }
 
-// Check for pending reviews that were never completed
-const trackingPath = path.join(process.cwd(), ".claude", "dev-team-review-pending.json");
-let pendingReviews = [];
-try {
-  pendingReviews = JSON.parse(fs.readFileSync(trackingPath, "utf-8"));
-} catch {
-  // No tracking file — no pending reviews
-}
-
-if (pendingReviews.length > 0) {
-  console.error(
-    `[dev-team pre-commit] BLOCKED — these agents were flagged for review but not yet spawned:`,
-  );
-  for (const agent of pendingReviews) {
-    console.error(`  → ${agent}`);
-  }
-  console.error("");
-  console.error(
-    "Spawn each agent as a background subagent using the Agent tool with their definition",
-  );
-  console.error("from .claude/agents/. After review completes, clear the tracking file:");
-  console.error("  rm .claude/dev-team-review-pending.json");
-  console.error("");
-  console.error("To skip this check (e.g. for trivial changes), delete the tracking file first.");
-  process.exit(2);
-}
-
-// Memory freshness check (advisory only)
-const reminders = [];
+// Memory freshness check (blocking unless overridden)
 
 const hasImplFiles = files.some(
   (f) => /\.(js|ts|jsx|tsx|py|rb|go|java|rs)$/.test(f) && !/\.(test|spec)\./.test(f),
 );
 
-const hasMemoryUpdates = files.some(
-  (f) => f.endsWith("dev-team-learnings.md") || /agent-memory\/.*MEMORY\.md$/.test(f),
+const memoryFiles = files.filter(
+  (f) => f.endsWith("learnings.md") || /agent-memory\/.*MEMORY\.md$/.test(f),
 );
 
+const hasMemoryUpdates = memoryFiles.length > 0;
+
+/**
+ * Check whether a memory file has substantive content beyond boilerplate.
+ * Returns true if the file contains at least one non-empty, non-header,
+ * non-boilerplate line.
+ */
+function hasSubstantiveContent(filePath) {
+  try {
+    const absPath = path.join(process.cwd(), filePath);
+    // Reject symlinks to avoid reading unintended files
+    const stat = fs.lstatSync(absPath);
+    if (stat.isSymbolicLink()) return false;
+
+    const content = fs.readFileSync(absPath, "utf-8");
+    const lines = content.split("\n");
+    const substantiveLines = lines.filter((line) => {
+      const trimmed = line.trim();
+      if (!trimmed) return false; // empty line
+      if (/^#+\s/.test(trimmed)) return false; // markdown header
+      if (trimmed === "---") return false; // horizontal rule / frontmatter delimiter
+      return true;
+    });
+    return substantiveLines.length > 0;
+  } catch {
+    return false; // file doesn't exist or can't be read — not substantive
+  }
+}
+
+// If memory files are staged, verify they have substantive content
+if (hasMemoryUpdates) {
+  const allSubstantive = memoryFiles.every((f) => hasSubstantiveContent(f));
+  if (!allSubstantive) {
+    console.error(
+      "[dev-team pre-commit] BLOCKED: Memory files were staged but contain only boilerplate (headers, empty lines). " +
+        "Add substantive content — patterns, conventions, calibration notes, or decisions learned from this work.",
+    );
+    process.exit(1);
+  }
+}
+
 if (hasImplFiles && !hasMemoryUpdates) {
+  // Check for .memory-reviewed override marker
+  const markerPath = path.join(process.cwd(), ".dev-team", ".memory-reviewed");
+  let hasOverride = false;
+  try {
+    const stat = fs.lstatSync(markerPath);
+    // Require regular file — reject symlinks, directories, FIFOs, etc.
+    hasOverride = stat.isFile() && !stat.isSymbolicLink();
+  } catch {
+    // No marker file
+  }
+
+  if (hasOverride) {
+    // Override acknowledged — clean up the marker file after this commit
+    try {
+      fs.unlinkSync(markerPath);
+    } catch {
+      // Best effort — don't fail the hook over cleanup
+    }
+    process.exit(0);
+  }
+
   let unstagedMemory = false;
   try {
     const unstaged = cachedGitDiff(["diff", "--name-only"], 2000);
     unstagedMemory = unstaged
       .split("\n")
       .map((f) => f.split("\\").join("/"))
-      .some((f) => f.endsWith("dev-team-learnings.md") || /agent-memory\/.*MEMORY\.md$/.test(f));
+      .some((f) => f.endsWith("learnings.md") || /agent-memory\/.*MEMORY\.md$/.test(f));
   } catch {
     // Ignore — best effort
   }
 
   if (unstagedMemory) {
-    reminders.push(
-      "Memory files were updated but not staged — run `git add .claude/dev-team-learnings.md .claude/agent-memory/` if learnings should be included",
+    console.error(
+      "[dev-team pre-commit] BLOCKED: Memory files were updated but not staged. " +
+        "Run `git add .dev-team/learnings.md .dev-team/agent-memory/` to include learnings, " +
+        "or create an empty `.dev-team/.memory-reviewed` file to acknowledge that memory was reviewed.",
     );
   } else {
-    reminders.push(
-      "Update .claude/dev-team-learnings.md or agent memory with any patterns, conventions, or decisions from this work",
+    console.error(
+      "[dev-team pre-commit] BLOCKED: Implementation files staged without memory updates. " +
+        "Update .dev-team/learnings.md or agent memory with any patterns, conventions, or decisions from this work. " +
+        "If no learnings apply, create an empty `.dev-team/.memory-reviewed` file to acknowledge.",
     );
   }
-}
-
-if (reminders.length > 0) {
-  console.log(`[dev-team pre-commit] Before committing, consider: ${reminders.join("; ")}`);
+  process.exit(1);
 }
 
 process.exit(0);

package/templates/hooks/dev-team-watch-list.js

@@ -4,11 +4,11 @@
  * dev-team-watch-list.js
  * PostToolUse hook on Edit/Write.
  *
- * Reads configurable file-pattern-to-agent mappings from .claude/dev-team.json
+ * Reads configurable file-pattern-to-agent mappings from .dev-team/config.json
  * and outputs structured spawn recommendations when patterns match.
  * Advisory only — always exits 0.
  *
- * Config format in dev-team.json:
+ * Config format in config.json:
  * {
  *   "watchLists": [
  *     { "pattern": "src/db/", "agents": ["dev-team-codd"], "reason": "database code changed" },
@@ -42,7 +42,7 @@ if (!filePath) {
 // Read watch list config
 let watchLists = [];
 try {
-  const prefsPath = path.join(process.cwd(), ".claude", "dev-team.json");
+  const prefsPath = path.join(process.cwd(), ".dev-team", "config.json");
   const prefs = JSON.parse(fs.readFileSync(prefsPath, "utf-8"));
   watchLists = prefs.watchLists || [];
 } catch {

package/templates/settings.json

@@ -6,15 +6,15 @@
         "hooks": [
           {
             "type": "command",
-            "command": "node .claude/hooks/dev-team-post-change-review.js"
+            "command": "node .dev-team/hooks/dev-team-post-change-review.js"
           },
           {
             "type": "command",
-            "command": "node .claude/hooks/dev-team-tdd-enforce.js"
+            "command": "node .dev-team/hooks/dev-team-tdd-enforce.js"
           },
           {
             "type": "command",
-            "command": "node .claude/hooks/dev-team-watch-list.js"
+            "command": "node .dev-team/hooks/dev-team-watch-list.js"
           }
         ]
       }
@@ -25,11 +25,11 @@
         "hooks": [
           {
             "type": "command",
-            "command": "node .claude/hooks/dev-team-safety-guard.js"
+            "command": "node .dev-team/hooks/dev-team-safety-guard.js"
           },
           {
             "type": "command",
-            "command": "node .claude/hooks/dev-team-pre-commit-lint.js"
+            "command": "node .dev-team/hooks/dev-team-pre-commit-lint.js"
           }
         ]
       }
@@ -39,21 +39,7 @@
         "hooks": [
           {
             "type": "command",
-            "command": "node .claude/hooks/dev-team-pre-commit-gate.js"
-          }
-        ]
-      }
-    ],
-    "Stop": [
-      {
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node .claude/hooks/dev-team-task-loop.js"
-          },
-          {
-            "type": "command",
-            "command": "node .claude/hooks/dev-team-parallel-loop.js"
+            "command": "node .dev-team/hooks/dev-team-pre-commit-gate.js"
           }
         ]
       }