📦 deps(thirdparty): update snapshots

matt-pocock-skills/.out-of-scope/mainstream-issue-trackers-only.md

@@ -4,11 +4,11 @@
 
 ## Why this is out of scope
 
-Every issue-tracker backend hard-codes a CLI shape into the skills (commands, flags, output parsing). Each new backend is permanent maintenance surface — it has to keep working as the tool's CLI evolves, and it has to keep being tested against `/to-spec`, `/to-tickets`, `/triage`, and friends. That cost is only worth paying for trackers a meaningful fraction of users actually have.
+Every issue-tracker backend hard-codes a CLI shape into the skills (commands, flags, output parsing). Each new backend is permanent maintenance surface, because it has to keep working as the tool's CLI evolves, and it has to keep being tested against `/to-spec`, `/to-tickets`, `/triage`, and friends. That cost is only worth paying for trackers a meaningful fraction of users actually have.
 
 "Mainstream" is a judgment call, not a numeric bar:
 
-- GitHub, GitLab, and Backlog.md are the kind of tools we'd consider mainstream — broadly known, widely used, well past the experimental phase.
+- GitHub, GitLab, and Backlog.md are the kind of tools we'd consider mainstream: broadly known, widely used, well past the experimental phase.
 - A brand-new agent-focused tool with a few hundred GitHub stars is not, no matter how interesting the design.
 
 Stars, age, and download counts are useful signals when making the call but none of them is the rule. The rule is: would a typical engineer recognise this tool and have plausibly chosen it for their team?
@@ -22,4 +22,4 @@ Neither requires the core skills to know about the specific tool.
 
 ## Prior requests
 
-- #99 — "Add dex as an issue tracker backend" (dex was ~3 months old and ~300 stars at the time of the request)
+- #99: "Add dex as an issue tracker backend" (dex was ~3 months old and ~300 stars at the time of the request)

matt-pocock-skills/.out-of-scope/question-limits.md

@@ -4,15 +4,15 @@ The `/grill-me` skill (and grilling sessions inside other skills) does not enfor
 
 ## Why this is out of scope
 
-Grilling is intentionally open-ended. The point is to keep digging until each branch of the decision tree is resolved — some plans need three questions, some need fifty. A fixed cap would either cut off useful exploration on hard problems or feel arbitrary on easy ones.
+Grilling is intentionally open-ended. The point is to keep digging until each branch of the decision tree is resolved: some plans need three questions, some need fifty. A fixed cap would either cut off useful exploration on hard problems or feel arbitrary on easy ones.
 
 If a session feels too long, the right escape hatches already exist:
 
 - The user can stop the session at any time and accept the current state of the plan.
-- The user can tell the model to wrap up, summarise, and move on — natural-language steering is the intended control surface, not a numeric limit.
+- The user can tell the model to wrap up, summarise, and move on, since natural-language steering is the intended control surface, not a numeric limit.
 
 Adding a hard cap would also conflate two different failure modes: a model that asks too many questions because the plan is genuinely under-specified (working as intended) vs. a model that asks redundant or low-value questions (a prompt-quality issue, not a quantity issue). The fix for the latter belongs in the skill prompt, not in a counter.
 
 ## Prior requests
 
-- #44 — "Codex just asked me 200 questions"
+- #44: "Codex just asked me 200 questions"

matt-pocock-skills/.out-of-scope/setup-skill-verify-mode.md

@@ -4,7 +4,7 @@ This project will not add a dedicated verify/check mode (or a separate verify sk
 
 ## 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.
+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.
 
@@ -12,4 +12,4 @@ Keeping configuration management to a single skill also avoids the maintenance c
 
 ## Prior requests
 
-- #106 — Feature request: verify/check mode for setup-matt-pocock-skills
+- #106: Feature request: verify/check mode for setup-matt-pocock-skills