Add structured sections for 'what-to-do' and 'supporting-info' in SKILL.md

Co-authored-by: Copilot <copilot@github.com>

.out-of-scope/setup-skill-verify-mode.md

@@ -0,0 +1,15 @@
+# Verify/Check Mode for `setup-matt-pocock-skills`
+
+This project will not add a dedicated verify/check mode (or a separate verify skill) for `setup-matt-pocock-skills`.
+
+## Why this is out of scope
+
+A second skill — or a `--verify` flag — for checking whether `docs/agents/*.md` artifacts still match the seed-template schema would duplicate work the existing setup skill already handles in conversation.
+
+The intended workflow is: **run `/setup-matt-pocock-skills` and tell it to verify your current setup.** The skill is prompt-driven, so the maintainer can scope it to a verification pass ("don't rewrite anything, just check my existing files against the current seed templates and report drift") without needing a separate code path. Adding a flag or a sibling skill would split the surface area of a feature that's already expressible through the natural-language entry point.
+
+Keeping configuration management to a single skill also avoids the maintenance cost of two skills drifting from each other when seed templates evolve.
+
+## Prior requests
+
+- #106 — Feature request: verify/check mode for setup-matt-pocock-skills

scripts/list-skills.sh

@@ -0,0 +1,7 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+REPO="$(cd "$(dirname "$0")/.." && pwd)"
+
+cd "$REPO"
+find . -name SKILL.md -not -path '*/node_modules/*' | sed 's|^\./||' | sort

skills/engineering/grill-with-docs/SKILL.md

@@ -1,15 +1,20 @@
 ---
 name: grill-with-docs
 description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
-disable-model-invocation: true
 ---
 
+<what-to-do>
+
 Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
 
 Ask the questions one at a time, waiting for feedback on each question before continuing.
 
 If a question can be answered by exploring the codebase, explore the codebase instead.
 
+</what-to-do>
+
+<supporting-info>
+
 ## Domain awareness
 
 During codebase exploration, also look for existing documentation:
@@ -79,3 +84,5 @@ Only offer to create an ADR when all three are true:
 3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
 
 If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](./ADR-FORMAT.md).
+
+</supporting-info>