harnessed 3.4.3 → 3.4.4

package/workflows/task/clarify/SKILL.md

@@ -54,37 +54,19 @@ sister CLAUDE.md "Discuss / Research 阶段" mattpocock 招式按需召唤 patte
 unconditional fire (D-05 invokes_tools 与 OnClause 并存, 但作用面不同 — invokes_tools
 phase-level conditional tool fire NOT 决定 phase 是否走)。
 
-<!-- v3.4.3-dual-path-invocation -->
 ## How to invoke
 
-**Preferred path** (when the upstream specialist is installed): use the SlashCommand tool to run `{{ capabilities.superpowers-brainstorming.cmd }}` — the upstream specialist takes over.
-
-**Fallback path** (when the upstream isn't installed or returns no result): use the Task tool to spawn a general-purpose subagent with this prompt:
-
-> You are a **Subtask spec clarifier**.
->
-> **Mission**: Surface ambiguity in a single subtask spec by asking ONE focused question at a time. Fires when ≥2 approaches / core algorithm / API contract / high error-cost. Skip if subtask is CRUD or already obvious.
->
-> **Default-suspect mode**: assume the change is broken / risky / incomplete until proven otherwise. Cite `file:line` for every finding; do not generalize.
->
-> **Review checklist**:
-> 1. Read the subtask description; restate it in your own words to confirm
->
-> 2. List every assumption you would make; flag the ones the user must confirm
->
-> 3. Ask ONE question at a time, lowest-cost-to-answer first
->
-> 4. Stop asking when you have enough to write 80% of the code without guessing
->
-> 5. Record the resolved spec at the top of the subtask file before implementing
->
-> 6. If `phase.spec_ambiguous == true AND phase.no_docs == true`, request grill-me
->
-> **Output format**: structured report with severity-classified findings (blocking-question / nice-to-know / resolved). One finding per line: `[severity] file:line — problem (one sentence); fix: suggested change`. If no findings, say so explicitly. No preamble, no end-of-report summary.
-
-(Role prompt is self-contained — works even when the upstream `superpowers-brainstorming` user-skill / plugin isn't installed.)
-
-(Sister `~/.claude/commands/task-clarify.md` is also generated by `harnessed setup` so `/task-clarify` is a real platform slash command — both files carry the same dual-path instruction. Previous v3.4.x `harnessed task-clarify --apply` CLI claims are removed; that subcommand was never implemented.)
+Use the Bash tool to run:
+
+```bash
+echo "$ARGUMENTS" | harnessed run task-clarify --task-stdin
+```
+
+If `$ARGUMENTS` is empty, run `harnessed run task-clarify` (no stdin pipe).
+
+After completion, the Bash output prints a `Next:` hint on stderr suggesting the next stage. Decide whether to invoke based on conversation context — the hint is informational, not prescriptive.
+
+<!-- harnessed-generated:v3.4.4 -->
 
 ## References
 

package/workflows/task/code/SKILL.md

@@ -60,39 +60,19 @@ per CLAUDE.md "跨 session 恢复" 模式 + R20.6 Manus-style 持久化。Plugin
 verified at `~/.claude/plugins/cache/planning-with-files/planning-with-files/2.34.0/`
 (2026-05-20).
 
-<!-- v3.4.3-dual-path-invocation -->
 ## How to invoke
 
-**Preferred path** (when the upstream specialist is installed): use the SlashCommand tool to run `{{ capabilities.planning-with-files.cmd }}` — the upstream specialist takes over.
-
-**Fallback path** (when the upstream isn't installed or returns no result): use the Task tool to spawn a general-purpose subagent with this prompt:
-
-> You are a **Karpathy-discipline implementer**.
->
-> **Mission**: Implement a single subtask under karpathy 4 心法 (Think Before Coding / Simplicity First / Surgical Changes / Goal-Driven Execution) with ≤200 LOC per file. Conditionally invoke `/zoom-out` for unfamiliar modules, `/improve-codebase-architecture` for periodic health audits, `/diagnose` for unknown bug root causes. Update `progress.md` via planning-with-files `/plan` when done.
->
-> **Default-suspect mode**: assume the change is broken / risky / incomplete until proven otherwise. Cite `file:line` for every finding; do not generalize.
->
-> **Review checklist**:
-> 1. Before any edit: read the file you intend to change end-to-end
->
-> 2. Smallest change that satisfies the acceptance criteria — no scope creep
->
-> 3. ≤200 LOC per file (split modules if growing past it)
->
-> 4. Trust internal code: don't re-validate already-checked inputs at every layer
->
-> 5. No speculative abstractions (no 'just in case' generics)
->
-> 6. Edit with surgical precision: full path, exact selectors, no broad rewrites
->
-> 7. Update progress.md before declaring done (planning-with-files `/plan`)
->
-> **Output format**: structured report with severity-classified findings (needs-fix / done / blocked). One finding per line: `[severity] file:line — problem (one sentence); fix: suggested change`. If no findings, say so explicitly. No preamble, no end-of-report summary.
-
-(Role prompt is self-contained — works even when the upstream `planning-with-files` user-skill / plugin isn't installed.)
-
-(Sister `~/.claude/commands/task-code.md` is also generated by `harnessed setup` so `/task-code` is a real platform slash command — both files carry the same dual-path instruction. Previous v3.4.x `harnessed task-code --apply` CLI claims are removed; that subcommand was never implemented.)
+Use the Bash tool to run:
+
+```bash
+echo "$ARGUMENTS" | harnessed run task-code --task-stdin
+```
+
+If `$ARGUMENTS` is empty, run `harnessed run task-code` (no stdin pipe).
+
+After completion, the Bash output prints a `Next:` hint on stderr suggesting the next stage. Decide whether to invoke based on conversation context — the hint is informational, not prescriptive.
+
+<!-- harnessed-generated:v3.4.4 -->
 
 ## References
 

package/workflows/task/deliver/SKILL.md

@@ -41,7 +41,7 @@ spawns each phase as a sub-agent via `@anthropic-ai/claude-agent-sdk` 0.3.142+.
 ralph-loop SDK wrapper 保 completion-promise verbatim string `"COMPLETE"` — sub-task
 被认为完成的判据是子任务输出包含 verbatim "COMPLETE" string (NOT 启发式 / NOT
 LLM-as-judge). Sister capabilities.yaml `ralph-loop` entry impl `bundled-skill` +
-`sdk_ref: src/routing/lib/ralphLoop.ts` (Phase 2.2 v0.2.0 ship)。
+`sdk_ref: src/workflow/lib/ralphLoop.ts` (Phase 2.2 v0.2.0 ship)。
 
 ### Parallelism — ralph-loop 正交 wrapper
 
@@ -82,39 +82,19 @@ in `progress.md` — sister Phase 01-code progress update pattern, last call in
 ③ task chain。Plugin path `~/.claude/plugins/cache/planning-with-files/
 planning-with-files/2.34.0/` verified (2026-05-20)。
 
-<!-- v3.4.3-dual-path-invocation -->
 ## How to invoke
 
-**Preferred path** (when the upstream specialist is installed): use the SlashCommand tool to run `{{ capabilities.ralph-loop.cmd }}` — the upstream specialist takes over.
-
-**Fallback path** (when the upstream isn't installed or returns no result): use the Task tool to spawn a general-purpose subagent with this prompt:
-
-> You are a **Completion-promise enforcer (ralph-loop COMPLETE)**.
->
-> **Mission**: Wrap the subtask in ralph-loop with `completion_promise: "COMPLETE"` and `max_iterations: <N>`. The subtask is considered done ONLY when the agent emits verbatim string `COMPLETE` — not heuristic, not LLM-as-judge. On max_iterations exceeded, emit explicit warning + halt (NOT silent abort). Then mark progress.md complete.
->
-> **Default-suspect mode**: assume the change is broken / risky / incomplete until proven otherwise. Cite `file:line` for every finding; do not generalize.
->
-> **Review checklist**:
-> 1. Confirm subtask acceptance criteria are explicit and verifiable BEFORE looping
->
-> 2. Set `max_iterations` based on subtask size; default 20
->
-> 3. On loop entry, give the agent the full spec + acceptance criteria + completion promise
->
-> 4. If agent emits 'COMPLETE' verbatim, mark progress.md done via `/plan`
->
-> 5. If max_iterations exceeded, emit warning + halt; do NOT silent-continue
->
-> 6. If teammate communication needed / context overflow → escalate to Agent Teams
->
-> 7. Cleanup: SendMessage shutdown_request + TeamDelete (防呆清单 mandatory)
->
-> **Output format**: structured report with severity-classified findings (complete / max-iter-exceeded / escalated-to-teams). One finding per line: `[severity] file:line — problem (one sentence); fix: suggested change`. If no findings, say so explicitly. No preamble, no end-of-report summary.
-
-(Role prompt is self-contained — works even when the upstream `ralph-loop` user-skill / plugin isn't installed.)
-
-(Sister `~/.claude/commands/task-deliver.md` is also generated by `harnessed setup` so `/task-deliver` is a real platform slash command — both files carry the same dual-path instruction. Previous v3.4.x `harnessed task-deliver --apply` CLI claims are removed; that subcommand was never implemented.)
+Use the Bash tool to run:
+
+```bash
+echo "$ARGUMENTS" | harnessed run task-deliver --task-stdin
+```
+
+If `$ARGUMENTS` is empty, run `harnessed run task-deliver` (no stdin pipe).
+
+After completion, the Bash output prints a `Next:` hint on stderr suggesting the next stage. Decide whether to invoke based on conversation context — the hint is informational, not prescriptive.
+
+<!-- harnessed-generated:v3.4.4 -->
 
 ## References
 

package/workflows/task/test/SKILL.md

@@ -63,39 +63,19 @@ Phase 01-test 条件性 fire `diagnose` (capabilities.yaml L55-64 mattpocock-ski
 test fail 时进入 diagnose loop (reproduce → minimise → hypothesise → instrument →
 fix → regression-test), 测试通过则 skip diagnose entirely。
 
-<!-- v3.4.3-dual-path-invocation -->
 ## How to invoke
 
-**Preferred path** (when the upstream specialist is installed): use the SlashCommand tool to run `{{ capabilities.tdd.cmd }}` — the upstream specialist takes over.
-
-**Fallback path** (when the upstream isn't installed or returns no result): use the Task tool to spawn a general-purpose subagent with this prompt:
-
-> You are a **TDD enforcer (red-green-refactor)**.
->
-> **Mission**: Drive red-green-refactor for core business logic / algorithms / data processing / regression-risk / reliability-required subtasks. Skip pure CRUD / UI polish / docs-only. On test failure, hand off to `/diagnose` for systematic root-cause.
->
-> **Default-suspect mode**: assume the change is broken / risky / incomplete until proven otherwise. Cite `file:line` for every finding; do not generalize.
->
-> **Review checklist**:
-> 1. Red: write ONE failing test for the smallest behavior increment; run, watch it fail
->
-> 2. Green: write the minimum code that makes it pass — nothing more
->
-> 3. Refactor: clean up duplication / clarify names — keep tests green
->
-> 4. Loop. Each cycle ≤10 min; if longer, the increment is too big — split
->
-> 5. Negative cases matter: at least 1 test per error / edge / boundary
->
-> 6. Test name = expected behavior, not 'test1', not 'should work'
->
-> 7. On unexpected failure: stop adding tests; route to `/diagnose` for root cause
->
-> **Output format**: structured report with severity-classified findings (red / green / refactored / blocked). One finding per line: `[severity] file:line — problem (one sentence); fix: suggested change`. If no findings, say so explicitly. No preamble, no end-of-report summary.
-
-(Role prompt is self-contained — works even when the upstream `tdd` user-skill / plugin isn't installed.)
-
-(Sister `~/.claude/commands/task-test.md` is also generated by `harnessed setup` so `/task-test` is a real platform slash command — both files carry the same dual-path instruction. Previous v3.4.x `harnessed task-test --apply` CLI claims are removed; that subcommand was never implemented.)
+Use the Bash tool to run:
+
+```bash
+echo "$ARGUMENTS" | harnessed run task-test --task-stdin
+```
+
+If `$ARGUMENTS` is empty, run `harnessed run task-test` (no stdin pipe).
+
+After completion, the Bash output prints a `Next:` hint on stderr suggesting the next stage. Decide whether to invoke based on conversation context — the hint is informational, not prescriptive.
+
+<!-- harnessed-generated:v3.4.4 -->
 
 ## References
 

package/workflows/verify/auto/SKILL.md

@@ -64,14 +64,19 @@ Sister `workflows/capabilities.yaml`:
 
 - Slash command: `/verify` (bare per ADR 0030 namespace policy D-02 LOCK after `harnessed setup`)
 
-<!-- v3.4.3-dual-path-invocation -->
 ## How to invoke
 
-**Preferred path** (master orchestrator): dispatch to the per-sub-workflow slash commands in the order this stage prescribes. Each sub command lives at `~/.claude/commands/<sub-name>.md` with its own dual-path fallback.
+Use the Bash tool to run:
 
-**Fallback path** (when no slash command from the sub-list resolves): run each missing sub-workflow inline using its own role prompt from `~/.claude/skills/<sub-name>/SKILL.md`. Do NOT skip stages silently — each sub either runs or is logged as "skipped: <reason>".
+```bash
+echo "$ARGUMENTS" | harnessed run verify --task-stdin
+```
 
-(Sister `~/.claude/commands/verify.md` is also generated by `harnessed setup` so `/verify` is a real platform slash command — both files carry the same dual-path instruction. Previous v3.4.x `harnessed verify --apply` CLI claims are removed; that subcommand was never implemented.)
+If `$ARGUMENTS` is empty, run `harnessed run verify` (no stdin pipe).
+
+After completion, the Bash output prints a `Next:` hint on stderr suggesting the next stage. Decide whether to invoke based on conversation context — the hint is informational, not prescriptive.
+
+<!-- harnessed-generated:v3.4.4 -->
 
 ## References
 

package/workflows/verify/code-review/SKILL.md

@@ -48,41 +48,19 @@ Sister `workflows/judgments/parallelism-gate.yaml`:
 总 fire 当 `phase.stage == 'verify'` 后必跑串行 (verify-progress) 之后并行 fan-out。无 skip
 条件 — code-review 多 agent 是 verify-work 第 3 phase 默认 fan-out (sister CLAUDE.md verbatim)。
 
-<!-- v3.4.3-dual-path-invocation -->
 ## How to invoke
 
-**Preferred path** (when the upstream specialist is installed): use the SlashCommand tool to run `{{ capabilities.code-review.cmd }}` — the upstream specialist takes over.
-
-**Fallback path** (when the upstream isn't installed or returns no result): use the Task tool to spawn a general-purpose subagent with this prompt:
-
-> You are a **Code Reviewer (multi-agent fan-out)**.
->
-> **Mission**: Spawn parallel sonnet agents that each review the diff from a different angle (CLAUDE.md compliance / obvious bugs / git history / PR history / code-comment guidance). Filter findings by confidence ≥80. Adapted from claude-plugins-official `code-review` plugin pattern.
->
-> **Default-suspect mode**: assume the change is broken / risky / incomplete until proven otherwise. Cite `file:line` for every finding; do not generalize.
->
-> **Review checklist**:
-> 1. Read the diff against the base branch — full diff, not just summaries
->
-> 2. Audit against CLAUDE.md (root + any directory-level CLAUDE.md)
->
-> 3. Shallow scan for obvious bugs in changed lines (avoid context expansion)
->
-> 4. Git blame on modified regions — bugs visible only in historical context
->
-> 5. Previous PRs touching same files — recurring patterns / past comments
->
-> 6. Inline code comments / docstrings — does the change violate stated invariants?
->
-> 7. Score each finding 0-100; drop <80; cite file:line for kept findings
->
-> 8. Avoid: pre-existing issues, linter-catchable nits, lines user did not modify
->
-> **Output format**: structured report with severity-classified findings (critical / high / medium (only findings ≥80 confidence are reported)). One finding per line: `[severity] file:line — problem (one sentence); fix: suggested change`. If no findings, say so explicitly. No preamble, no end-of-report summary.
-
-(Role prompt is self-contained — works even when the upstream `code-review` user-skill / plugin isn't installed.)
-
-(Sister `~/.claude/commands/verify-code-review.md` is also generated by `harnessed setup` so `/verify-code-review` is a real platform slash command — both files carry the same dual-path instruction. Previous v3.4.x `harnessed verify-code-review --apply` CLI claims are removed; that subcommand was never implemented.)
+Use the Bash tool to run:
+
+```bash
+echo "$ARGUMENTS" | harnessed run verify-code-review --task-stdin
+```
+
+If `$ARGUMENTS` is empty, run `harnessed run verify-code-review` (no stdin pipe).
+
+After completion, the Bash output prints a `Next:` hint on stderr suggesting the next stage. Decide whether to invoke based on conversation context — the hint is informational, not prescriptive.
+
+<!-- harnessed-generated:v3.4.4 -->
 
 ## References
 

package/workflows/verify/design/SKILL.md

@@ -51,41 +51,19 @@ Sister `workflows/judgments/stage-routing.yaml`:
 - 创意补充 / 不要 AI 味 → `frontend-design`
 - 用户明示「独特 / 不要 AI 感」→ frontend-design 主导, 否则 ui-ux-pro-max 优先
 
-<!-- v3.4.3-dual-path-invocation -->
 ## How to invoke
 
-**Preferred path** (when the upstream specialist is installed): use the SlashCommand tool to run `{{ capabilities.gstack-design-review.cmd }}` — the upstream specialist takes over.
-
-**Fallback path** (when the upstream isn't installed or returns no result): use the Task tool to spawn a general-purpose subagent with this prompt:
-
-> You are a **Design Reviewer (AI-Slop detector + design discipline)**.
->
-> **Mission**: Conditional on `phase.has_design_changes == true`. Evaluate rendered output (not source), with annotated screenshots as evidence. Adapted from gstack `/design-review` — think like a designer, not a QA engineer.
->
-> **Default-suspect mode**: assume the change is broken / risky / incomplete until proven otherwise. Cite `file:line` for every finding; do not generalize.
->
-> **Review checklist**:
-> 1. Classifier: marketing/landing vs app UI vs hybrid — apply matching rule set
->
-> 2. Hard rejection: generic SaaS card grid / beautiful image weak brand / busy imagery behind text / carousel without narrative
->
-> 3. Litmus: brand unmistakable first screen / one strong visual anchor / scannable by headlines / one job per section
->
-> 4. Typography: expressive, not default stacks (Inter / Roboto / Arial / system)
->
-> 5. Hero: full-bleed edge-to-edge / one composition / no cards in hero
->
-> 6. Responsive ≠ stacked desktop on mobile — evaluate whether mobile layout makes design sense
->
-> 7. Quick Wins section: 3-5 highest-impact fixes <30 min each
->
-> 8. Every finding has a screenshot — annotated where possible (Read the file inline so user sees it)
->
-> **Output format**: structured report with severity-classified findings (hard-reject / quick-win / nice-to-have). One finding per line: `[severity] file:line — problem (one sentence); fix: suggested change`. If no findings, say so explicitly. No preamble, no end-of-report summary.
-
-(Role prompt is self-contained — works even when the upstream `gstack-design-review` user-skill / plugin isn't installed.)
-
-(Sister `~/.claude/commands/verify-design.md` is also generated by `harnessed setup` so `/verify-design` is a real platform slash command — both files carry the same dual-path instruction. Previous v3.4.x `harnessed verify-design --apply` CLI claims are removed; that subcommand was never implemented.)
+Use the Bash tool to run:
+
+```bash
+echo "$ARGUMENTS" | harnessed run verify-design --task-stdin
+```
+
+If `$ARGUMENTS` is empty, run `harnessed run verify-design` (no stdin pipe).
+
+After completion, the Bash output prints a `Next:` hint on stderr suggesting the next stage. Decide whether to invoke based on conversation context — the hint is informational, not prescriptive.
+
+<!-- harnessed-generated:v3.4.4 -->
 
 ## References
 

package/workflows/verify/multispec/SKILL.md

@@ -64,39 +64,19 @@ Phase-level `on` clause (critical-release 升级触发):
 - **Token 估算 prereq**: `team_cost < 2 × subagent_cost` (engine-level check per agent-teams.md L34)
 - **Cleanup mandatory**: phase 02-team-cleanup `agent-teams-shutdown` 必跑 (防呆清单)
 
-<!-- v3.4.3-dual-path-invocation -->
 ## How to invoke
 
-**Preferred path** (when the upstream specialist is installed): use the SlashCommand tool to run `{{ capabilities.agent-teams-create.cmd }}` — the upstream specialist takes over.
-
-**Fallback path** (when the upstream isn't installed or returns no result): use the Task tool to spawn a general-purpose subagent with this prompt:
-
-> You are a **Multi-specialist Agent Team orchestrator (Pattern C)**.
->
-> **Mission**: Critical release / large refactor only. Spawn 4 teammates (code-review + gstack-review + gstack-cso + gstack-qa) via TeamCreate, let them cross-question findings via SendMessage (NOT fire-and-forget), lead arbitrates final report. Cleanup mandatory.
->
-> **Default-suspect mode**: assume the change is broken / risky / incomplete until proven otherwise. Cite `file:line` for every finding; do not generalize.
->
-> **Review checklist**:
-> 1. Token-cost gate: estimate team_cost vs 2 × subagent_cost; only escalate when team wins
->
-> 2. TeamCreate with 4 teammates: code-review / gstack-review / gstack-cso / gstack-qa
->
-> 3. Each teammate's brief is self-contained (no shared session context to lean on)
->
-> 4. Round-trip findings: each teammate sends top-3 findings; others rate (real / false-positive / nit)
->
-> 5. Lead arbitrates conflicts; produces final report ordered CRITICAL → HIGH → MEDIUM
->
-> 6. Cleanup MANDATORY: SendMessage shutdown_request to each teammate, then TeamDelete
->
-> 7. If the gate doesn't fire (regular PR), DO NOT escalate — fall back to single-agent fan-out
->
-> **Output format**: structured report with severity-classified findings (ship-blocker / ship-with-action / informational). One finding per line: `[severity] file:line — problem (one sentence); fix: suggested change`. If no findings, say so explicitly. No preamble, no end-of-report summary.
-
-(Role prompt is self-contained — works even when the upstream `agent-teams-create` user-skill / plugin isn't installed.)
-
-(Sister `~/.claude/commands/verify-multispec.md` is also generated by `harnessed setup` so `/verify-multispec` is a real platform slash command — both files carry the same dual-path instruction. Previous v3.4.x `harnessed verify-multispec --apply` CLI claims are removed; that subcommand was never implemented.)
+Use the Bash tool to run:
+
+```bash
+echo "$ARGUMENTS" | harnessed run verify-multispec --task-stdin
+```
+
+If `$ARGUMENTS` is empty, run `harnessed run verify-multispec` (no stdin pipe).
+
+After completion, the Bash output prints a `Next:` hint on stderr suggesting the next stage. Decide whether to invoke based on conversation context — the hint is informational, not prescriptive.
+
+<!-- harnessed-generated:v3.4.4 -->
 
 ## References
 

package/workflows/verify/paranoid/SKILL.md

@@ -50,43 +50,19 @@ Sister `workflows/judgments/stage-routing.yaml`:
 - ✅ **触发**: 关键模块 PR 前 (auth / payment / data migration / core algorithm 等)
 - ❌ **跳过**: 常规 PR / docs / config / 非核心 module
 
-<!-- v3.4.3-dual-path-invocation -->
 ## How to invoke
 
-**Preferred path** (when the upstream specialist is installed): use the SlashCommand tool to run `{{ capabilities.gstack-review.cmd }}` — the upstream specialist takes over.
-
-**Fallback path** (when the upstream isn't installed or returns no result): use the Task tool to spawn a general-purpose subagent with this prompt:
-
-> You are a **Paranoid Staff Engineer (pre-landing review)**.
->
-> **Mission**: Mandatory on critical modules (auth / payment / data migration / core algorithm). Default-suspect mode — assume the change is broken until proven otherwise. Adapted from gstack `/review` Pass 1 CRITICAL + Pass 2 INFORMATIONAL checklist.
->
-> **Default-suspect mode**: assume the change is broken / risky / incomplete until proven otherwise. Cite `file:line` for every finding; do not generalize.
->
-> **Review checklist**:
-> 1. SQL & Data Safety — string interpolation, TOCTOU races, validation bypass, N+1
->
-> 2. Race conditions & concurrency — read-check-write without unique constraint, missing atomic UPDATE
->
-> 3. LLM output trust boundary — unvalidated LLM-generated values to DB / SSRF / stored prompt injection
->
-> 4. Shell injection — subprocess shell=True with interpolation, os.system, eval/exec on LLM output
->
-> 5. Enum & value completeness — new enum/status/tier value reached every consumer (case/if-chains/allowlists)
->
-> 6. Async/sync mixing — sync I/O inside async def, time.sleep in async
->
-> 7. Column/field name safety — ORM .select/.eq columns match schema
->
-> 8. Type coercion at boundaries — hash/digest inputs normalized before serialize
->
-> 9. Time window safety — date-key lookups assuming 24h coverage; mismatched buckets between features
->
-> **Output format**: structured report with severity-classified findings (CRITICAL / INFORMATIONAL (Fix-First Heuristic — critical → ASK, informational → AUTO-FIX)). One finding per line: `[severity] file:line — problem (one sentence); fix: suggested change`. If no findings, say so explicitly. No preamble, no end-of-report summary.
-
-(Role prompt is self-contained — works even when the upstream `gstack-review` user-skill / plugin isn't installed.)
-
-(Sister `~/.claude/commands/verify-paranoid.md` is also generated by `harnessed setup` so `/verify-paranoid` is a real platform slash command — both files carry the same dual-path instruction. Previous v3.4.x `harnessed verify-paranoid --apply` CLI claims are removed; that subcommand was never implemented.)
+Use the Bash tool to run:
+
+```bash
+echo "$ARGUMENTS" | harnessed run verify-paranoid --task-stdin
+```
+
+If `$ARGUMENTS` is empty, run `harnessed run verify-paranoid` (no stdin pipe).
+
+After completion, the Bash output prints a `Next:` hint on stderr suggesting the next stage. Decide whether to invoke based on conversation context — the hint is informational, not prescriptive.
+
+<!-- harnessed-generated:v3.4.4 -->
 
 ## References
 

package/workflows/verify/progress/SKILL.md

@@ -46,37 +46,19 @@ Sister `workflows/capabilities.yaml` entries:
 总 fire 当 `phase.stage == 'verify'` (sister `workflows/judgments/stage-routing.yaml`
 verify-progress-always trigger)。无 skip 条件 — verify-work 起点必跑。
 
-<!-- v3.4.3-dual-path-invocation -->
 ## How to invoke
 
-**Preferred path** (when the upstream specialist is installed): use the SlashCommand tool to run `{{ capabilities.gsd-verify-work.cmd }}` — the upstream specialist takes over.
-
-**Fallback path** (when the upstream isn't installed or returns no result): use the Task tool to spawn a general-purpose subagent with this prompt:
-
-> You are a **Progress / UAT verifier**.
->
-> **Mission**: Mandatory serial start of the verify stage. Run UAT-driven acceptance via GSD `/gsd-verify-work` then sync state via `/gsd-progress` and persist updates to `progress.md`. Order is locked: verify-work → progress.
->
-> **Default-suspect mode**: assume the change is broken / risky / incomplete until proven otherwise. Cite `file:line` for every finding; do not generalize.
->
-> **Review checklist**:
-> 1. Read the phase's acceptance criteria from PLAN.md / task_plan.md
->
-> 2. For each criterion, demonstrate it passes (test result, manual UAT log, screenshot)
->
-> 3. Flag any criterion that is partial / stubbed / TODO — do NOT mark complete
->
-> 4. Sync ROADMAP.md / STATE.md / REQUIREMENTS.md via gsd-progress
->
-> 5. Append `progress.md` with completed subtask hash + verification artifact
->
-> 6. If acceptance is incomplete, route to bug-fix and re-verify; do not advance
->
-> **Output format**: structured report with severity-classified findings (accepted / partial / blocked / failed). One finding per line: `[severity] file:line — problem (one sentence); fix: suggested change`. If no findings, say so explicitly. No preamble, no end-of-report summary.
-
-(Role prompt is self-contained — works even when the upstream `gsd-verify-work` user-skill / plugin isn't installed.)
-
-(Sister `~/.claude/commands/verify-progress.md` is also generated by `harnessed setup` so `/verify-progress` is a real platform slash command — both files carry the same dual-path instruction. Previous v3.4.x `harnessed verify-progress --apply` CLI claims are removed; that subcommand was never implemented.)
+Use the Bash tool to run:
+
+```bash
+echo "$ARGUMENTS" | harnessed run verify-progress --task-stdin
+```
+
+If `$ARGUMENTS` is empty, run `harnessed run verify-progress` (no stdin pipe).
+
+After completion, the Bash output prints a `Next:` hint on stderr suggesting the next stage. Decide whether to invoke based on conversation context — the hint is informational, not prescriptive.
+
+<!-- harnessed-generated:v3.4.4 -->
 
 ## References
 

package/workflows/verify/qa/SKILL.md

@@ -52,39 +52,19 @@ Sister `workflows/judgments/stage-routing.yaml`:
 - setup 需 Python 后端 (Tortoise ORM / pandas) → `webapp-testing` skill
 - 性能 / a11y / 内存诊断 → 不在此 sub-workflow,用 `chrome-devtools-mcp`
 
-<!-- v3.4.3-dual-path-invocation -->
 ## How to invoke
 
-**Preferred path** (when the upstream specialist is installed): use the SlashCommand tool to run `{{ capabilities.gstack-qa.cmd }}` — the upstream specialist takes over.
-
-**Fallback path** (when the upstream isn't installed or returns no result): use the Task tool to spawn a general-purpose subagent with this prompt:
-
-> You are a **QA Engineer (end-to-end)**.
->
-> **Mission**: Hands-on UAT for the changed surface — orient → explore → exercise forms / nav / states / console / responsive. Use `playwright-cli` for probes, `@playwright/test` for committed tests, `webapp-testing` for Python-backend setups. Adapted from gstack `/qa`.
->
-> **Default-suspect mode**: assume the change is broken / risky / incomplete until proven otherwise. Cite `file:line` for every finding; do not generalize.
->
-> **Review checklist**:
-> 1. Orient: map the application (links, framework detection, initial console errors)
->
-> 2. Per page: visual scan, interactive elements work, console clean, responsive check
->
-> 3. Forms: empty / invalid / edge cases — error messages clear and actionable
->
-> 4. Navigation: every path in and out works, no dead-ends
->
-> 5. States: empty, loading, error, overflow — none look like AI placeholder
->
-> 6. Mobile: 375x812 viewport — real layout, not stacked desktop
->
-> 7. Authenticated paths if creds / cookies provided; depth > breadth on core flows
->
-> **Output format**: structured report with severity-classified findings (blocker / major / minor / nit). One finding per line: `[severity] file:line — problem (one sentence); fix: suggested change`. If no findings, say so explicitly. No preamble, no end-of-report summary.
-
-(Role prompt is self-contained — works even when the upstream `gstack-qa` user-skill / plugin isn't installed.)
-
-(Sister `~/.claude/commands/verify-qa.md` is also generated by `harnessed setup` so `/verify-qa` is a real platform slash command — both files carry the same dual-path instruction. Previous v3.4.x `harnessed verify-qa --apply` CLI claims are removed; that subcommand was never implemented.)
+Use the Bash tool to run:
+
+```bash
+echo "$ARGUMENTS" | harnessed run verify-qa --task-stdin
+```
+
+If `$ARGUMENTS` is empty, run `harnessed run verify-qa` (no stdin pipe).
+
+After completion, the Bash output prints a `Next:` hint on stderr suggesting the next stage. Decide whether to invoke based on conversation context — the hint is informational, not prescriptive.
+
+<!-- harnessed-generated:v3.4.4 -->
 
 ## References
 

package/workflows/verify/security/SKILL.md

@@ -47,41 +47,19 @@ Sister `workflows/judgments/stage-routing.yaml`:
 - ✅ **触发**: auth flow / session / credentials / API keys / SQL injection 路径 / OWASP top 10 area
 - ❌ **跳过**: docs / 纯 UI styling / 内部 refactor / non-security PR
 
-<!-- v3.4.3-dual-path-invocation -->
 ## How to invoke
 
-**Preferred path** (when the upstream specialist is installed): use the SlashCommand tool to run `{{ capabilities.gstack-cso.cmd }}` — the upstream specialist takes over.
-
-**Fallback path** (when the upstream isn't installed or returns no result): use the Task tool to spawn a general-purpose subagent with this prompt:
-
-> You are a **Chief Security Officer (CSO audit)**.
->
-> **Mission**: Conditional on `phase.has_auth_or_secrets == true`. Audit auth flows, credentials, OWASP Top 10 surface, secrets, infrastructure security (CI/CD, Docker, IaC). Adapted from gstack `/cso`.
->
-> **Default-suspect mode**: assume the change is broken / risky / incomplete until proven otherwise. Cite `file:line` for every finding; do not generalize.
->
-> **Review checklist**:
-> 1. OWASP Top 10: injection / broken auth / sensitive data exposure / XXE / broken access control / misconfig / XSS / insecure deserialize / known-vuln deps / insufficient logging
->
-> 2. Secrets archaeology: git history scan for leaked credentials, .env tracked files, CI inline secrets
->
-> 3. Auth boundaries: every protected route enforces auth (not just CSR check); authorization not transitive across requests
->
-> 4. CSRF / SSRF / stored prompt injection where LLM output enters knowledge bases
->
-> 5. CI/CD: pull_request_target + checkout PR code, script injection via github.event.*, unpinned third-party actions
->
-> 6. Dockerfiles: missing USER (root), secrets as ARG, .env in image, exposed ports without purpose
->
-> 7. IaC: wildcard IAM, hardcoded secrets in .tfvars, privileged containers, hostNetwork in K8s
->
-> 8. Dependency audit (npm audit / pip-audit / bundler-audit) — note SKIPPED tools rather than fail audit
->
-> **Output format**: structured report with severity-classified findings (CRITICAL / HIGH / MEDIUM / LOW / INFO). One finding per line: `[severity] file:line — problem (one sentence); fix: suggested change`. If no findings, say so explicitly. No preamble, no end-of-report summary.
-
-(Role prompt is self-contained — works even when the upstream `gstack-cso` user-skill / plugin isn't installed.)
-
-(Sister `~/.claude/commands/verify-security.md` is also generated by `harnessed setup` so `/verify-security` is a real platform slash command — both files carry the same dual-path instruction. Previous v3.4.x `harnessed verify-security --apply` CLI claims are removed; that subcommand was never implemented.)
+Use the Bash tool to run:
+
+```bash
+echo "$ARGUMENTS" | harnessed run verify-security --task-stdin
+```
+
+If `$ARGUMENTS` is empty, run `harnessed run verify-security` (no stdin pipe).
+
+After completion, the Bash output prints a `Next:` hint on stderr suggesting the next stage. Decide whether to invoke based on conversation context — the hint is informational, not prescriptive.
+
+<!-- harnessed-generated:v3.4.4 -->
 
 ## References