Audit workflow YAML for prompt steps that need shell/write (prompt-hard compat)

[5uck1ess]

Problem

PR #64 (#63) extended devkit-guard.sh to enforce a strict allowlist on prompt steps under enforce: hard: only Read, Grep, Glob, NotebookRead, TodoWrite, and devkit MCP tools are allowed. Write, Edit, Bash, Task, WebFetch, and foreign MCP tools are blocked.

Several existing workflow YAMLs still have prompt steps that expect the agent to run shell commands, write files, or dispatch subagents. Under the new policy, those workflows become unusable.

Concrete example: workflows/tri-review.yml step 1 "gather":

- id: gather
  model: fast
  prompt: |
    Collect the code or diff to review: {{input}}
    Output the raw content that will be sent to all three reviewers.

The natural way for an agent to satisfy this prompt is git diff main...HEAD via Bash — which the new guard blocks. There is no read-only alternative.

Proposal

Audit all 18 workflow YAMLs under workflows/ for prompt steps that need shell/write/dispatch access. For each hit, pick one:

1. Reclassify as command — move the shell invocation into the YAML itself so the engine runs it (e.g. command: git diff main...HEAD). This is the deterministic-by-design path and is what PR fix(hooks): enforce workflow progression on prompt steps + orphan recovery #64's architecture assumes.
2. Reclassify as parallel — if the step dispatches multiple subagents, express that in the YAML parallel array.
3. Declare enforce: soft — opt out of hard enforcement for workflows where creativity matters more than strict progression.

Scope

• Every workflow under workflows/ that has a prompt step.
• Document the chosen classification inline with a YAML comment for future auditors.
• Add a lint rule (or CI check) that flags new prompt steps which don't fit the allowlist — prevents future drift.

Acceptance criteria

• All 18 workflows runnable under the new guard policy without hitting a veto on legitimate work.
• Tri-review end-to-end dry run succeeds from a fresh Claude Code session.
• Documented guidance in README.md or a new workflows/CONVENTIONS.md describing when to use prompt vs command vs parallel vs soft enforcement.

Context

Discovered during the PR #64 mega-review. The guard CODE is correct; the workflow DEFINITIONS are pre-strict-policy artifacts. Highest-value follow-up because it closes the gap between the fix and the existing workflow library.

Out of scope

• Changes to the guard policy itself (see PR fix(hooks): enforce workflow progression on prompt steps + orphan recovery #64 / issue PreToolUse hook to enforce devkit workflow step progression #63).
• Python3 elimination (tracked in Replace python3-based hooks with a native devkit-engine guard subcommand #65).

[5uck1ess]

Closing as speculative. This was filed by the assistant during PR #64's mega-review as a theoretical follow-up, not from any real usage breakage. The concern was that 13/18 workflow YAMLs had prompt steps needing Write/Bash that the new guard would block. But (a) the killer feature (tri-review / mega-pr) was already marked SAFE by the audit, and (b) "broken" here meant "degraded output" not "hard error" — workflows still run, they just adapt. If real usage hits the problem we'll relax the guard with a one-line change then, not build a per-step allowlist schema now.