Workflow tool over-triggers on any mention of the word 'workflow' in prompt text

[john-savepoint]

Problem

The keyword trigger for the workflow tool is so loose that merely talking about workflows, the repo, or a file named workflow.ts rewrites the user's message and forces a workflow invocation. This is hostile to natural language: questions about the tool are converted into executions of the tool without the user asking for it.

Repro Steps

1. Ensure default settings (no /workflows-trigger off) on QuintinShaw/pi-dynamic-workflows v2.13.2.
2. Send any of these messages:
   • github.com/QuintinShaw/pi-dynamic-workflows
   • workflowRunner function
   • my-workflow-helper
   • Look at workflow.ts
   • the workflow tool engages any time
3. Observe that the message is rewritten with a forcing directive (You MUST handle this request by calling the tool named exactly workflow) and the workflow tool is invoked.

Expected vs Actual

Expected: The workflow tool should only run when the user explicitly asks for it, e.g. via /workflows run <prompt> or an explicit keyword like workflow: / run a workflow / backticks-wrapped workflow.

Actual: Any substring match for workflow (with only a / lookbehind exclusion) arms the trigger. URLs, camelCase identifiers, hyphenated identifiers, filenames, and plain English sentences all fire it.

Proposed Fix

1. Slash-command-only by default: Make /workflows run <prompt> the primary invocation path and change keywordTriggerEnabled default from true to false in src/workflow-editor.ts:563. Users who want keyword triggering can opt in with /workflows-trigger on.
2. Narrow the default regex: If keyword triggering stays on by default, make the default 'workflow' regex use the same boundary matching as custom words ((?<![/A-Za-z0-9_-])workflow(?![A-Za-z0-9_-])) instead of the legacy substring (?<!\/)workflows?. Require the trigger word to be a standalone token, or only match workflow:, run a workflow, workflow_id, or backticks-wrapped workflow.
3. Reduce self-priming in the tool description: Remove the 22 repetitions of For workflow, in src/workflow-tool.ts:162-185 and replace them with neutral phrasing so the LLM is not primed to call the tool whenever it sees the word.

Environment

• Repository: QuintinShaw/pi-dynamic-workflows
• Version: v2.13.2 (local clone commit 2f28a74)
• Runtime: OMP (Oh My Pi)
• Settings: model-tiers.json absent at session start (created later); keywordTriggerEnabled defaults to true

Related

• PR fix: bound workflow keyword matching #79 fixes URL/camelCase/hyphen false positives but still fires on natural English and filename references.
• Reduce always-on workflow prompt size (model catalogue adds ~5k tokens) #65 "Reduce always-on workflow prompt size" is adjacent — the always-on prompt primes the LLM to call the tool whenever the word appears.

[QuintinShaw]

Thanks @john-savepoint — a genuinely useful, well-analyzed report, and I agree with the thrust of it.

On your three points:

• Regex boundaries (2): fixed in fix: bound workflow keyword matching #79, shipped in 2.14.1 — the default workflow word now matches at identifier boundaries, so URLs, workflowRunner, my-workflow-helper, and workflow.ts no longer trigger. Worth re-testing on 2.14.1+.
• Tool-description self-priming (3): being addressed — @Whamp is reworking the tool definition/contract to be much more concise (Reduce always-on workflow prompt size (model catalogue adds ~5k tokens) #65), which directly cuts the For workflow, repetition you flagged.
• Default-on (1): this is the real one. You're right that default-on keyword triggering is hostile to talking about the tool — and Pi behavior is weird when workflow execution is triggered via the editor component keyword. #89 reports a related edge (editor-triggered runs go background/idle instead of inline). A third independent report converging on the same rough edge means the trigger's default + behavior deserve a rethink, not a /workflows-trigger off workaround. I'm treating this — together with Pi behavior is weird when workflow execution is triggered via the editor component keyword. #89 and the prompt-size work — as a design track to reshape keyword triggering, likely toward a less aggressive default and a trigger that enables rather than forces a background workflow.

Really appreciate the depth here.

[Whamp]

Why not just change your trigger word in the config? I changed mine to "pi-workflow" because I often use the word workflow in my day-to-day language and so was accidentally triggering it as well, which is why I shipped a PR allowing you to change the trigger word in your config file.

[QuintinShaw]

Update — the redesign is on main for 3.0.0. On your three points:

• Forcing (the core issue): feat: authorize keyword triggering instead of forcing it (addresses #88, #89) #93 flips the trigger from force to authorize — it no longer rewrites your message into "You MUST call workflow / the ONLY acceptable action", it arms the tool and the model decides, so talking about workflows is answered in prose. The hostile rewrite you reported is gone.
• Boundaries (2): shipped in fix: bound workflow keyword matching #79 / 2.14.1.
• Self-priming (3): the always-on prompt is now a single gate line and the how-to moved into the tool's static (cacheable) description. Honest caveat: the For workflow, text was relocated, not yet shortened — @Whamp's Reduce always-on workflow prompt size (model catalogue adds ~5k tokens) #65 contract-concision work is what actually trims it.
• Default-on (1): I kept it on, deliberately — under authorize semantics its worst case is one benign armed-turn directive rather than a forced wrong run, so default-off isn't needed to defuse the hostility. (And per @Whamp you can already set a custom trigger word.) If you still see over-triggering once 3.0.0 ships, reopen and I'll revisit.

Lands in 3.0.0 — I'll close this when it releases.

[QuintinShaw]

Shipped in 3.0.0 (just released). The trigger now authorizes rather than forces — talking about workflows is answered in prose instead of being rewritten into a forced run — and the identifier-boundary matching from #79 is in as well. Default-on stayed (under authorize semantics its worst case is a benign armed-turn directive, not a forced wrong run), and a custom trigger word is available. Thanks again for the sharp, well-analyzed report — closing as resolved; please reopen if you still see over-triggering on 3.0.0.