Problem
The logic to open a file in the user's default app exists in two places that will drift apart:
- Tested code — the
manage_flow_nodes render handler in src/tools/handlers.ts (~L3784-3805) works out the per-OS opener (open / xdg-open / start), including the non-obvious Windows empty-title quirk (start "" so a path with spaces isn't swallowed as the window title), wrapped in try/catch.
- Prose — the
agent-red-team skill's "Delivering the report" step (plugin/skills/agent-red-team/SKILL.md) restates the same per-OS commands in English for the LLM to reconstruct and run itself.
A fix to the opener in the handler (WSL edge case, PowerShell fallback, etc.) never reaches the prose copy, and vice versa. The start "" quoting fix already landed in both independently in #33 — a live example of the drift risk.
Suggested fix
Per the repo's "extend an existing tool" convention, extract the opener into a shared helper (or a small tool operation) with the single source of truth, and have the skill call it instead of describing the commands.
Notes / open question
Low severity — both copies are small and stable. The catch: a generic "open a local file" operation doesn't map onto any of the 16 Cognigy-API tools, so exposing it as a tool op adds a new surface just for the skill, which cuts against the "few tools" principle. A shared internal helper reused by the render handler (without a new LLM-facing tool) may be the better shape. Worth deciding before implementing.
Context: PR #33 review finding 4 (Arsalan Harouni K (@cu4nt0m)).
Problem
The logic to open a file in the user's default app exists in two places that will drift apart:
manage_flow_nodesrender handler insrc/tools/handlers.ts(~L3784-3805) works out the per-OS opener (open/xdg-open/start), including the non-obvious Windows empty-title quirk (start ""so a path with spaces isn't swallowed as the window title), wrapped in try/catch.agent-red-teamskill's "Delivering the report" step (plugin/skills/agent-red-team/SKILL.md) restates the same per-OS commands in English for the LLM to reconstruct and run itself.A fix to the opener in the handler (WSL edge case, PowerShell fallback, etc.) never reaches the prose copy, and vice versa. The
start ""quoting fix already landed in both independently in #33 — a live example of the drift risk.Suggested fix
Per the repo's "extend an existing tool" convention, extract the opener into a shared helper (or a small tool operation) with the single source of truth, and have the skill call it instead of describing the commands.
Notes / open question
Low severity — both copies are small and stable. The catch: a generic "open a local file" operation doesn't map onto any of the 16 Cognigy-API tools, so exposing it as a tool op adds a new surface just for the skill, which cuts against the "few tools" principle. A shared internal helper reused by the render handler (without a new LLM-facing tool) may be the better shape. Worth deciding before implementing.
Context: PR #33 review finding 4 (Arsalan Harouni K (@cu4nt0m)).