chore(skills): pushy descriptions + extract pull-request monitor loop

Apply skill-creator audit findings (descriptions were too passive — the
harness needs concrete triggers to route reliably):

- verify, create-module, pull-request, naming, update-stack: reframe
  frontmatter descriptions with explicit trigger phrases ("when the user
  asks to ship this", "when creating a new module", etc.).
- pull-request: extract §6 monitor loop body to references/monitor-loop.md;
  SKILL.md keeps a 7-step inline summary. Loads the heavy procedure only
  when the loop actually runs.

Author: PierreBrisorgueil

.claude/skills/create-module/SKILL.md

@@ -1,6 +1,12 @@
 ---
 name: create-module
-description: Create a new feature module by duplicating the canonical `tasks` module template. Use when adding a new module to the application, scaffolding a new domain area from scratch, or generating the boilerplate for a new feature.
+description: >
+  Use this whenever the user asks to "create a module", "scaffold a feature",
+  "add a domain", "new module called X", or starts work on a brand-new
+  vertical (controller + service + repo + model + routes + tests). Duplicates
+  the canonical `modules/tasks` template, applies kebab/Pascal/camel renames,
+  and registers config-driven enums. Module stays self-contained — never
+  modify shared `lib/` or `config/` to bolt on module logic.
 ---
 
 # Create Module Skill

.claude/skills/naming/SKILL.md

@@ -1,6 +1,12 @@
 ---
 name: naming
-description: Check or apply file and folder naming conventions for this Node project. Use when creating new files or folders, renaming existing ones, auditing a module for naming consistency, or any time the correct name/path for a file is unclear.
+description: >
+  Use this whenever a new file/folder is created or renamed in this Node
+  project, when reviewing a module for consistency, or when the right path
+  for a file is unclear. Also triggers on "what should I name this?", "is
+  this file named correctly?", "audit module naming". Enforces kebab-case
+  folders, `{module}[.{entity}].{type}.js` files, multi-entity rules, and
+  the layer order Routes → Controllers → Services → Repositories → Models.
 ---
 
 # Naming Skill

.claude/skills/pull-request/SKILL.md

@@ -1,6 +1,13 @@
 ---
 name: pull-request
-description: Full PR lifecycle — branch, commit, issue, draft PR, CI, ready, autonomous monitor loop (fix comments, resolve threads, iterate until CI green and zero unresolved threads).
+description: >
+  Use this whenever the user asks to "open a PR", "ship this", "create the
+  pull request", "make a PR", or once a feature/fix is verified and ready to
+  push. Full lifecycle: branch → commit (commitizen) → issue → draft PR → CI
+  → ready → autonomous monitor loop (fix comments, resolve threads, iterate
+  until CI green + zero unresolved threads). `--perfect` adds a CodeRabbit
+  convergence loop on top. Never works on `main`/`master`, never uses
+  `--no-verify`.
 ---
 
 # Pull Request Skill
@@ -108,112 +115,32 @@ gh pr ready <number>
 
 ## 6. Monitor loop (autonomous)
 
-Set these variables once before running any loop command:
+After `gh pr ready`, run an autonomous polling loop until either CI is green
+with zero unresolved threads for 3 consecutive passes (~9 min) or the safety
+limit (10 iterations) trips.
 
 ```bash
 OWNER=$(gh repo view --json owner -q .owner.login)
 REPO=$(gh repo view --json name -q .name)
 PR=<number>
 ```
 
-After `gh pr ready`, enter an autonomous polling loop. Do not wait for the user — drive the loop yourself until the stop condition is met.
-
-### Loop procedure
-
-```text
-consecutive_zero = 0
-
-REPEAT:
-  1. Wait for CI                        → sleep 30 then gh pr checks $PR --watch
-  2. If CI fails                        → fix, /verify, commit, push, consecutive_zero=0, GOTO 1
-  2b. Check mergeable status            → STATUS=$(gh pr view $PR --json mergeable --jq .mergeable)
-                                           if STATUS == "UNKNOWN" → sleep 10, retry up to 3 times
-                                           if STATUS == "CONFLICTING" → report to user and STOP
-  3. Grace period                       → sleep 180 + adaptive check (see 6b)
-  4. Re-check pending review checks     → gh pr checks $PR — if any still pending, GOTO 3
-  5. Read all feedback                  → unresolved threads only (see 6b)
-  6. If actionable comments             → fix all, /verify, commit, push, reply, resolve, consecutive_zero=0, GOTO 1
-  7. If non-actionable unresolved       → reply all explaining why, resolve all, consecutive_zero=0, GOTO 5
-  8. If zero unresolved threads         → consecutive_zero++
-                                           if consecutive_zero >= 3 (~9 min) → check branch protection (see 6f), then STOP ✓
-                                           else GOTO 3
-```
-
-### 6a. Wait for CI
-
-After any push, wait 30s then watch:
-
-```bash
-sleep 30
-gh pr checks "$PR" --watch
-```
-
-If `no checks reported`, retry up to 5 times (30s apart). If still no checks after 5 retries, report to user and stop.
-
-**If any check fails** → fix, `/verify`, commit, push, restart loop. Do not read review feedback until CI passes.
-
-### 6b. Read all feedback — unresolved threads only
-
-Grace period: `sleep 180`. If 0 bot comments after 3 min, wait 2 more min.
-
-Read **only unresolved threads** (resolved = ignored). Use `references/monitoring.md` as source of truth.
-
-```bash
-# Optional context only (do not drive action from these):
-# gh pr view $PR --json reviews,comments
-# gh api repos/$OWNER/$REPO/pulls/$PR/comments --paginate | jq 'map({id, user: .user.login, body})'
-# gh api repos/$OWNER/$REPO/issues/$PR/comments --paginate | jq 'map({id, user: .user.login, body})'
-# Action source of truth: unresolved threads query in references/monitoring.md
-```
-
-**Actionable** (must fix): change requests, bug reports, missing tests, security issues, code suggestions.
-
-**Informational** (reply + resolve, no code change): approvals, coverage reports, style preferences without change request, false positives. PR-level comments (codecov, approvals) cannot be resolved via thread API — don't count as unresolved.
-
-### 6b-bis. Classify stack-level vs downstream comments (downstream projects only)
-
-Skip when running directly on the stack repo. Requires `devkit-node` remote (set up by `/update-stack`) — if missing, stop and report.
-
-For each actionable comment, check if the file exists unmodified in upstream:
-
-```bash
-STACK_REPO=$(git remote get-url devkit-node 2>/dev/null | sed 's|.*github.com[:/]||;s|\.git$||')
-STACK_DEFAULT_BRANCH=$(git remote show devkit-node 2>/dev/null | sed -n '/HEAD branch/s/.*: //p')
-git fetch devkit-node "$STACK_DEFAULT_BRANCH" --quiet 2>/dev/null
-# STACK if exists in upstream AND no local diff; else DOWNSTREAM
-git cat-file -e "devkit-node/$STACK_DEFAULT_BRANCH:<file-path>" 2>/dev/null && \
-  git diff --quiet "devkit-node/$STACK_DEFAULT_BRANCH" -- <file-path> 2>/dev/null
-```
-
-- **Stack-level** → create issue on stack repo with review comment details, reply with issue link, resolve thread. If `gh issue create` fails, fix locally instead.
-- **Downstream** → fix locally (section 6c).
-
-### 6c. Fix all actionable comments from this pass
-
-Fix all actionable comments in one batch: `/verify` → commit → push → reply with SHA → resolve threads via GraphQL (see `references/monitoring.md`). One commit per pass.
-
-### 6d. Coverage gaps
-
-Add missing tests — **never lower thresholds**. Include in the same commit batch.
-
-### 6e. After pushing fixes
-
-Wait 30s before watching CI (regular or force-push). Loop back to 6a. Never post `@copilot review` — it invokes the coding agent, not the reviewer.
-
-### 6f. Stop condition
-
-CI green **and** 3 consecutive passes (~9 min of grace periods) with zero unresolved threads. Mergeable status is also checked after every CI pass (step 2b) — conflicts cause an early stop. Final branch protection check:
-
-```bash
-gh pr view "$PR" --json reviewDecision,mergeable | jq '{reviewDecision, mergeable}'
-```
-
-- `APPROVED` + `MERGEABLE` → **STOP ✓**
-- `REVIEW_REQUIRED` → report to user, stop
-- `CHANGES_REQUESTED` → report to user, stop
-- `BLOCKED` → report details to user
-
-**Safety limit:** 10 iterations max — report to user if still unresolved.
+Per pass:
+1. Wait CI → fix + /verify + commit + push if red, else continue
+2. Check mergeable — `CONFLICTING` stops, `UNKNOWN` retries
+3. Grace `sleep 180` + adaptive recheck of pending review checks
+4. Read **only unresolved threads** (see `references/monitoring.md`)
+5. Actionable → batch-fix in one commit, /verify, push, reply with SHA,
+   resolve via GraphQL. Never resolve silently — reply is audit trail.
+6. Non-actionable → reply explaining why, resolve, continue
+7. Zero unresolved 3 passes in a row + CI green + branch protection
+   `APPROVED`+`MERGEABLE` → STOP ✓
+
+Downstream projects: classify stack-level vs downstream comments via the
+`devkit-node` remote and open issues upstream for stack-level findings.
+
+**Full procedure (commands, classification rules, stop condition matrix):**
+see `references/monitor-loop.md`. Load when running the loop.
 
 ## 7. Perfect mode (`--perfect`)
 

.claude/skills/pull-request/references/monitor-loop.md

@@ -0,0 +1,127 @@
+# Monitor loop — full procedure
+
+Full body of the autonomous monitor loop referenced from §6 of `SKILL.md`.
+Load only when actively running the loop on a PR.
+
+## Setup
+
+```bash
+OWNER=$(gh repo view --json owner -q .owner.login)
+REPO=$(gh repo view --json name -q .name)
+PR=<number>
+```
+
+After `gh pr ready`, run this loop yourself — do not wait for the user.
+
+## Loop procedure
+
+```text
+consecutive_zero = 0
+
+REPEAT:
+  1. Wait for CI                        → sleep 30 then gh pr checks $PR --watch
+  2. If CI fails                        → fix, /verify, commit, push, consecutive_zero=0, GOTO 1
+  2b. Check mergeable status            → STATUS=$(gh pr view $PR --json mergeable --jq .mergeable)
+                                           if STATUS == "UNKNOWN" → sleep 10, retry up to 3 times
+                                           if STATUS == "CONFLICTING" → report to user and STOP
+  3. Grace period                       → sleep 180 + adaptive check (see 6b)
+  4. Re-check pending review checks     → gh pr checks $PR — if any still pending, GOTO 3
+  5. Read all feedback                  → unresolved threads only (see 6b)
+  6. If actionable comments             → fix all, /verify, commit, push, reply, resolve, consecutive_zero=0, GOTO 1
+  7. If non-actionable unresolved       → reply all explaining why, resolve all, consecutive_zero=0, GOTO 5
+  8. If zero unresolved threads         → consecutive_zero++
+                                           if consecutive_zero >= 3 (~9 min) → check branch protection (see 6f), then STOP ✓
+                                           else GOTO 3
+```
+
+## 6a. Wait for CI
+
+After any push, wait 30s then watch:
+
+```bash
+sleep 30
+gh pr checks "$PR" --watch
+```
+
+If `no checks reported`, retry up to 5 times (30s apart). If still no checks
+after 5 retries, report to user and stop.
+
+If any check fails → fix, `/verify`, commit, push, restart loop. Do not read
+review feedback until CI passes.
+
+## 6b. Read all feedback — unresolved threads only
+
+Grace period: `sleep 180`. If 0 bot comments after 3 min, wait 2 more min.
+
+Read **only unresolved threads** (resolved = ignored). Use `monitoring.md` as
+source of truth.
+
+```bash
+# Optional context only (do not drive action from these):
+# gh pr view $PR --json reviews,comments
+# gh api repos/$OWNER/$REPO/pulls/$PR/comments --paginate | jq 'map({id, user: .user.login, body})'
+# gh api repos/$OWNER/$REPO/issues/$PR/comments --paginate | jq 'map({id, user: .user.login, body})'
+# Action source of truth: unresolved threads query in monitoring.md
+```
+
+**Actionable** (must fix): change requests, bug reports, missing tests,
+security issues, code suggestions.
+
+**Informational** (reply + resolve, no code change): approvals, coverage
+reports, style preferences without change request, false positives. PR-level
+comments (codecov, approvals) cannot be resolved via thread API — don't count
+as unresolved.
+
+## 6b-bis. Classify stack-level vs downstream comments (downstream projects only)
+
+Skip when running directly on the stack repo. Requires `devkit-node` remote
+(set up by `/update-stack`) — if missing, stop and report.
+
+For each actionable comment, check if the file exists unmodified in upstream:
+
+```bash
+STACK_REPO=$(git remote get-url devkit-node 2>/dev/null | sed 's|.*github.com[:/]||;s|\.git$||')
+STACK_DEFAULT_BRANCH=$(git remote show devkit-node 2>/dev/null | sed -n '/HEAD branch/s/.*: //p')
+git fetch devkit-node "$STACK_DEFAULT_BRANCH" --quiet 2>/dev/null
+# STACK if exists in upstream AND no local diff; else DOWNSTREAM
+git cat-file -e "devkit-node/$STACK_DEFAULT_BRANCH:<file-path>" 2>/dev/null && \
+  git diff --quiet "devkit-node/$STACK_DEFAULT_BRANCH" -- <file-path> 2>/dev/null
+```
+
+- **Stack-level** → create issue on stack repo with review comment details,
+  reply with issue link, resolve thread. If `gh issue create` fails, fix
+  locally instead.
+- **Downstream** → fix locally (section 6c).
+
+## 6c. Fix all actionable comments from this pass
+
+Fix all actionable comments in one batch: `/verify` → commit → push → reply
+with SHA → resolve threads via GraphQL (see `monitoring.md`). One commit per
+pass. You MUST reply to every thread before resolving it — never resolve a
+thread silently. The reply serves as audit trail.
+
+## 6d. Coverage gaps
+
+Add missing tests — never lower thresholds. Include in the same commit batch.
+
+## 6e. After pushing fixes
+
+Wait 30s before watching CI (regular or force-push). Loop back to 6a. Never
+post `@copilot review` — it invokes the coding agent, not the reviewer.
+
+## 6f. Stop condition
+
+CI green AND 3 consecutive passes (~9 min of grace periods) with zero
+unresolved threads. Mergeable status is also checked after every CI pass
+(step 2b) — conflicts cause an early stop. Final branch protection check:
+
+```bash
+gh pr view "$PR" --json reviewDecision,mergeable | jq '{reviewDecision, mergeable}'
+```
+
+- `APPROVED` + `MERGEABLE` → STOP ✓
+- `REVIEW_REQUIRED` → report to user, stop
+- `CHANGES_REQUESTED` → report to user, stop
+- `BLOCKED` → report details to user
+
+Safety limit: 10 iterations max — report to user if still unresolved.

.claude/skills/update-stack/SKILL.md

@@ -1,6 +1,12 @@
 ---
 name: update-stack
-description: Merge the latest changes from the Devkit Node stack repository into a downstream project. Use when pulling stack updates, syncing with upstream via `git merge devkit-node/master`, or resolving merge conflicts from stack updates.
+description: >
+  Use this whenever a downstream Node project needs to absorb upstream Devkit
+  Node changes — triggers on "update stack", "sync with devkit", "merge
+  upstream", "pull stack updates", "resolve stack conflicts". Two-phase: ISO
+  merge (stack modules + lib stay byte-identical to upstream) then project
+  alignment (apply MIGRATIONS.md, diff project modules vs `tasks` reference,
+  /verify). Stack-code failures get an issue on `pierreb-devkit/Node`.
 ---
 
 # Update Stack Skill

.claude/skills/verify/SKILL.md

@@ -1,6 +1,12 @@
 ---
 name: verify
-description: Run quality loop (audit + lint + tests) to verify code quality, correctness, and security. Use after making changes and before committing.
+description: >
+  Run this after every code change in this Node project, before committing,
+  before opening a PR, or whenever the user says "verify", "check", "lint",
+  "run tests", "audit". Diff audit (architecture, security, naming, error
+  handling) → lint → tests + coverage gate. Coverage drops → add tests, never
+  lower thresholds. Triggers on "is this ready to commit?", "any issues?",
+  "tests passing?".
 ---
 
 # Verify Skill