Skip to content

fix skill broker chatId + add per-skill auto_allow#22

Merged
cjus merged 1 commit into
mainfrom
carlos/solrac-skill-permissioning
May 15, 2026
Merged

fix skill broker chatId + add per-skill auto_allow#22
cjus merged 1 commit into
mainfrom
carlos/solrac-skill-permissioning

Conversation

@cjus
Copy link
Copy Markdown
Owner

@cjus cjus commented May 15, 2026

Summary

  • Bug fix: ollama-tier skills routed broker confirmation prompts to chatId: 0 (hardcoded in runSkillBareWithTools with a stale "log correlation only" comment). Every confirm-tier tool call (e.g. /lognotion_create_page) fail-closed to deny without the operator ever seeing a prompt. Now reads the real chatId/auditId from skillToolCtx (the AsyncLocalStorage both production callers already wrap us in).
  • New auto_allow: true SKILL.md frontmatter (default false) suppresses the interactive Telegram-confirm prompt for every tool the skill body calls. Loop detector, hard-deny classifier, and cost cap all still gate — only the prompt is bypassed. Wired into both engines:
    • Claude tiers (runSkill): canUseTool swapped for skillDefaultAllowAll; PreToolUse hook unchanged.
    • Ollama tier (executeToolCall): confirm branch falls through to invoke; per-round confirm cap skipped (no prompts to stack).

Why

Without the bug fix, no skill with default tier ollama could write to a confirm-tier integration through Telegram — notion_create_page, gmail_send_draft, etc. all denied silently. The fix is mandatory to ship /log.

The auto_allow flag is a UX win for skills whose entire purpose IS the operation. Re-prompting on every notion_create_page inside /log is friction without a safety benefit (the cost cap + loop detector still backstop). Opt-in, per-skill — no global toggle, no env var.

Impact

  • Skills that previously appeared to silently fail (no prompt + no result) now correctly prompt the operator.
  • Existing skills are unaffected — auto_allow defaults to false.
  • Anti-goal reversal? No — Solrac's three-tier policy stays intact; auto_allow is a per-skill opt-in surfaced through SKILL.md, not a removal of the gate.

Test plan

  • npm run typecheck passes
  • bun test — 753 pass (6 new: 4 auto_allow parse cases, 2 executor bypass cases)
  • Manual: deploy, add auto_allow: true to /log SKILL.md, invoke /log foo in Telegram; verify Notion entry appears with no prompt
  • Manual: remove auto_allow, re-invoke /log foo; verify confirm prompt now appears (regression check for the bug fix)

ollama-tier skills routed broker confirmation prompts to chatId=0 (a
hardcoded stub with a stale "log correlation only" comment), so every
confirm-tier tool call silently fail-closed to deny without the operator
ever seeing a prompt. read the real chatId/auditId from skillToolCtx
inside runSkillBareWithTools; both production callers already wrap us
in the ALS.

new auto_allow: bool frontmatter (default false) suppresses the
interactive confirm prompt for every tool the skill body calls.
appropriate for skills whose entire purpose IS a known write (e.g.
/log -> notion). loop detector, hard-deny classifier, and cost cap all
still gate. wired into both engines:
- claude tiers: canUseTool swapped for skillDefaultAllowAll; PreToolUse
  hook unchanged.
- ollama tier: executeToolCall confirm branch falls through to invoke;
  per-round confirm cap skipped (no prompts to stack).

docs/USAGE.md updated.
@cjus cjus merged commit d8fc63b into main May 15, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant