cool-workflow 0.1.79 → 0.1.80

package/skills/design-qa/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: design-qa
+description: >-
+  Evaluate Cool Workflow architecture, product design, operator UX,
+  context-pack, workflow-app, MCP/CLI, or release-process proposals. Use when
+  Codex must decide whether a design respects FreeBSD/POLA,
+  mechanism-not-policy, stable JSON surfaces, evidence, and verifier boundaries
+  before implementation.
+---
+
+# Design QA
+
+## Overview
+
+Design QA checks whether a proposed capability belongs in the kernel,
+userland, a manifest, a wrapper, a routine, or an eval before implementation.
+
+## Workflow
+
+1. State the user capability in one sentence.
+2. Identify the contract surface: CLI, MCP, `.cw/` state, file layout, docs,
+   package contents, or external wrapper.
+3. Separate mechanism from policy. Move policy into data, apps, wrappers, env,
+   or docs.
+4. Check POLA: existing outputs, flags, exit codes, and file layouts stay
+   byte-identical unless a new opt-in surface is used.
+5. Define verifier evidence: tests, manifests, screenshots for UI, replay, or
+   logs.
+6. Decide whether the work needs a new eval case or skill update.
+
+## Checks
+
+- Does it preserve stdout-as-data?
+- Does it fail closed instead of guessing?
+- Does it avoid vendor-specific parsing in `src/`?
+- Does it keep generated files verifiable?
+- Does it have a man page or docs contract?
+- Can maker and verifier run in separate worktrees?
+
+## Output Rules
+
+Return:
+
+1. Verdict: acceptable, revise, or reject.
+2. Required contract shape.
+3. Verification plan.
+4. Risks and non-goals.
+
+Do not turn design QA into implementation unless the user asks to proceed.

package/skills/design-qa/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Design QA"
+  short_description: "Check architecture and UX design quality."
+  default_prompt: "Use $design-qa to evaluate this design."

package/skills/pr-review/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: pr-review
+description: >-
+  Review Cool Workflow pull requests or branch diffs. Use when Codex must
+  inspect code changes for bugs, regressions, FreeBSD/POLA violations, missing
+  tests, generated artifact drift, release-contract risk, or CI implications,
+  and return findings first with file/line citations.
+---
+
+# PR Review
+
+## Overview
+
+Review for correctness and release risk before style. Findings lead; summaries
+are secondary. Treat missing tests and POLA drift as real risks.
+
+## Workflow
+
+1. Read the diff and identify touched contracts: CLI, MCP, `.cw/` state, docs,
+   dist, manifests, tests, release flow, or public package files.
+2. Inspect the surrounding code for behavioral expectations.
+3. Check whether tests exercise the changed behavior and fail closed.
+4. Look for stdout chatter, silent fallback, hidden policy in core, untracked
+   generated drift, and accidental public-output changes.
+5. Report findings first, ordered by severity, with file and line references.
+6. Include open questions only when they block confidence.
+
+## Review Rules
+
+- Do not request cosmetic rewrites unless they hide a bug.
+- Do not approve undocumented shipped behavior.
+- Do not accept type-only additions without runtime behavior.
+- Do not accept `dist/` edits without matching `src/` changes.
+- For UI work, require screenshots or browser verification.
+
+## Output Shape
+
+Use this order:
+
+1. Findings
+2. Open questions
+3. Test gaps
+4. Short summary
+
+If there are no findings, say so clearly and name residual risk.

package/skills/pr-review/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "PR Review"
+  short_description: "Review pull requests with cited findings."
+  default_prompt: "Use $pr-review to review this pull request."