task-pipeline-skill 1.16.0 → 1.16.1

package/CHANGELOG.md

@@ -1,5 +1,21 @@
 # Changelog
 
+## v1.16.1 — 2026-08-06
+
+### Fixed — frontmatter that a regex called valid and a YAML parser silently dropped
+
+`evidence-docs`'s description contained *"read as true: a decision record"*. A
+colon-space inside a plain YAML scalar makes the value a nested mapping, so the official
+plugin validator reported the skill **loads with empty metadata — every frontmatter field
+silently dropped**, which for a skill means it never triggers. v1.16.0 published in that
+state.
+
+The guard that was supposed to catch it checked the frontmatter with a regular
+expression and passed: a check proving less than it claims, shipped in the release that
+publishes canon 6. It now rejects a plain scalar carrying a colon-space, across **every**
+`SKILL.md` in the plugin rather than only the new one — the class, not the instance.
+Guards 112 → 113.
+
 ## v1.16.0 — 2026-08-06
 
 ### Added — `evidence-docs`: a second skill in this plugin, and the router row it fills

package/SKILL-CARD.md

@@ -12,7 +12,7 @@ harmless.
 |---|---|
 | **Purpose** | Runs a substantial task through ten gated delivery stages — intake grill, docs study, brainstorm, spec, plan, subagent build, tests, lint/deploy, post-deploy, docs+registers, acceptance — refusing to advance until each gate passes |
 | **Owner** | ssheleg ([github.com/ssheleg/task-pipeline](https://github.com/ssheleg/task-pipeline)) |
-| **Version** | 1.16.0 |
+| **Version** | 1.16.1 |
 | **Surface** | Claude Code (filesystem skill + plugin) and the vercel `skills` CLI. **Not** uploaded to the Skills API; custom Skills do not sync across surfaces |
 | **Dependencies** | None required. Optional: `context7` (MCP), `figma` (MCP), super-ux, agent-sync, graphify, obsidian-wiki. Every stage's doctrine ships in-repo; the one conditional requirement is super-ux for the stage-3 UX track on a user-facing task |
 | **Evaluation status** | Suite authored (15 evals, 5 categories). **Never executed** — see [`evals/RESULTS.md`](evals/RESULTS.md) |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "task-pipeline-skill",
-  "version": "1.16.0",
+  "version": "1.16.1",
   "description": "Full-cycle delivery pipeline for coding agents: a mandatory built-in intake grill, then 10 gated stages (docs, brainstorm+decompose, spec, plan, build, tests, lint/deploy, post-deploy, docs/wiki, acceptance). Every stage's doctrine ships inside the skill — no companion plugin required. This package is the installer CLI.",
   "bin": {
     "task-pipeline": "bin/task-pipeline.js"

package/plugins/task-pipeline/.claude-plugin/plugin.json

@@ -2,7 +2,7 @@
   "name": "task-pipeline",
   "displayName": "Task Pipeline",
   "description": "Runs a substantial task through a mandatory built-in intake grill, then 10 gated stages (docs, brainstorm+decompose, spec, plan, subagent build, tests, lint/deploy, post-deploy, docs/wiki, acceptance). Every stage's doctrine is built into the skill — no companion plugin required — with typed auto/manual gates, a frozen requirement spine that must close with evidence, a loop guard that breaks churn, one provider-agnostic model confirmed up front, and an optional super-ux UX track for user-facing work.",
-  "version": "1.16.0",
+  "version": "1.16.1",
   "author": {
     "name": "ssheleg",
     "url": "https://x.com/sshlg93"

package/plugins/task-pipeline/skills/evidence-docs/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: evidence-docs
-description: Applies the ten canons of evidence-backed documentation — what makes a claim documentation rather than an assertion — and routes to the doctrine that enforces each one. Use when writing or reviewing anything that will be read as true: a decision record, a README, an acceptance report, a runbook, a changelog entry, an audit finding, or any claim that something was verified. Also use when a project needs a documentation gate, a decision register, a propagation matrix, or a retrospective that outlives its author. Not for drafts, chat answers, commit messages or code comments.
+description: Applies the ten canons of evidence-backed documentation — what makes a claim documentation rather than an assertion — and routes to the doctrine that enforces each one. Use when writing or reviewing anything that will be read as true — a decision record, a README, an acceptance report, a runbook, a changelog entry, an audit finding, or any claim that something was verified. Also use when a project needs a documentation gate, a decision register, a propagation matrix, or a retrospective that outlives its author. Not for drafts, chat answers, commit messages or code comments.
 ---
 
 # Evidence-backed documentation