CtrlK
BlogDocsLog inGet started
Tessl Logo

arbiter

Push decisions to Arbiter Zebu for async human review. Use when you need human input on plans, architectural choices, or approval before proceeding.

79

Quality

76%

Does it follow best practices?

Impact

Pending

No eval scenarios have been run

SecuritybySnyk

Advisory

Suggest reviewing before use

Optimize this skill with Tessl

npx tessl skill review --optimize ./public/skills/5hanth/arbiter/SKILL.md
SKILL.md
Quality
Evals
Security

Arbiter Skill

Push decisions to Arbiter Zebu for async human review. Use when you need human input on plans, architectural choices, or approval before proceeding.

Installation

Quick install via ClawHub:

clawhub install arbiter

Or via bun (makes CLI commands available globally):

bun add -g arbiter-skill

Or manual:

git clone https://github.com/5hanth/arbiter-skill.git
cd arbiter-skill && npm install && npm run build
ln -s $(pwd) ~/.clawdbot/skills/arbiter

Prerequisites

  • Arbiter Zebu bot running (or just bunx arbiter-zebu)
  • ~/.arbiter/queue/ directory (created automatically by the bot)

Environment Variables

Set these in your agent's environment for automatic agent/session detection:

VariableDescriptionExample
CLAWDBOT_AGENTAgent IDceo, swe1
CLAWDBOT_SESSIONSession keyagent:ceo:main

When to Use

  • Plan review before implementation
  • Architectural decisions with tradeoffs
  • Anything blocking that needs human judgment
  • Multiple related decisions as a batch

Do NOT use for:

  • Simple yes/no that doesn't need explanation
  • Urgent real-time decisions (use direct message instead)
  • Technical questions you can research yourself

Tools

arbiter_push

Create a decision plan for human review.

CLI: arbiter-push '<json>' — takes a single JSON argument containing all fields.

arbiter-push '{
  "title": "API Design Decisions",
  "tag": "nft-marketplace",
  "context": "SWE2 needs these decided before API work",
  "priority": "normal",
  "notify": "agent:swe2:main",
  "decisions": [
    {
      "id": "auth-strategy",
      "title": "Auth Strategy", 
      "context": "How to authenticate admin users",
      "options": [
        {"key": "jwt", "label": "JWT tokens", "note": "Stateless"},
        {"key": "session", "label": "Sessions", "note": "More control"},
        {"key": "oauth", "label": "OAuth", "note": "External provider"}
      ]
    },
    {
      "id": "database",
      "title": "Database Choice",
      "context": "Primary datastore",
      "options": [
        {"key": "postgresql", "label": "PostgreSQL + JSONB"},
        {"key": "mongodb", "label": "MongoDB"}
      ],
      "allowCustom": true
    }
  ]
}'

JSON Fields:

FieldRequiredDescription
titleYesPlan title
tagNoTag for filtering (e.g., project name)
contextNoBackground for reviewer
priorityNolow, normal, high, urgent (default: normal)
notifyNoSession to notify when complete
agentNoAgent ID (auto-detected from CLAWDBOT_AGENT env)
sessionNoSession key (auto-detected from CLAWDBOT_SESSION env)
decisionsYesArray of decisions

Decision object:

FieldRequiredDescription
idYesUnique ID within plan
titleYesDecision title
contextNoExplanation for reviewer
optionsYesArray of {key, label, note?}
allowCustomNoAllow free-text answer (default: false)
defaultNoSuggested option key

Returns:

{
  "planId": "abc123",
  "file": "~/.arbiter/queue/pending/ceo-api-design-abc123.md",
  "total": 2,
  "status": "pending"
}

arbiter_status

Check the status of a decision plan.

CLI: arbiter-status <plan-id> or arbiter-status --tag <tag>

arbiter-status abc12345
# or
arbiter-status --tag nft-marketplace

Returns:

{
  "planId": "abc123",
  "title": "API Design Decisions",
  "status": "in_progress",
  "total": 3,
  "answered": 1,
  "remaining": 2,
  "decisions": {
    "auth-strategy": {"status": "answered", "answer": "jwt"},
    "database": {"status": "pending", "answer": null},
    "caching": {"status": "pending", "answer": null}
  }
}

arbiter_get

Get answers from a completed plan.

CLI: arbiter-get <plan-id> or arbiter-get --tag <tag>

arbiter-get abc12345
# or
arbiter-get --tag nft-marketplace

Returns:

{
  "planId": "abc123",
  "status": "completed",
  "completedAt": "2026-01-30T01:45:00Z",
  "answers": {
    "auth-strategy": "jwt",
    "database": "postgresql",
    "caching": "redis"
  }
}

Error if not complete:

{
  "error": "Plan not complete",
  "status": "in_progress",
  "remaining": 2
}

arbiter_await

Block until plan is complete (with timeout).

arbiter-await abc12345 --timeout 3600

Polls every 30 seconds until complete or timeout.

Returns: Same as arbiter_get on completion.

Usage Examples

Example 1: Plan Review

# Push plan decisions (single JSON argument)
RESULT=$(arbiter-push '{"title":"Clean IT i18n Plan","tag":"clean-it","priority":"high","notify":"agent:swe3:main","decisions":[{"id":"library","title":"i18n Library","options":[{"key":"i18next","label":"i18next"},{"key":"formatjs","label":"FormatJS"}]},{"id":"keys","title":"Key Structure","options":[{"key":"flat","label":"Flat (login.button)"},{"key":"nested","label":"Nested ({login:{button}})"}]}]}')

PLAN_ID=$(echo $RESULT | jq -r '.planId')
echo "Pushed plan $PLAN_ID — waiting for human review"

Example 2: Check and Proceed

# Check if decisions are ready
STATUS=$(arbiter-status --tag nft-marketplace)

if [ "$(echo $STATUS | jq -r '.status')" == "completed" ]; then
  ANSWERS=$(arbiter-get --tag nft-marketplace)
  AUTH=$(echo $ANSWERS | jq -r '.answers["auth-strategy"]')
  echo "Using auth strategy: $AUTH"
  # Proceed with implementation
else
  echo "Still waiting for $(echo $STATUS | jq -r '.remaining') decisions"
fi

Example 3: Blocking Wait

# Wait up to 1 hour for decisions
ANSWERS=$(arbiter-await abc12345 --timeout 3600)

if [ $? -eq 0 ]; then
  # Got answers, proceed
  echo "Decisions ready: $ANSWERS"
else
  echo "Timeout waiting for decisions"
fi

Best Practices

  1. Batch related decisions — Don't push one at a time
  2. Provide context — Human needs to understand tradeoffs
  3. Use tags — Makes filtering easy (--tag project-name)
  4. Set notify — So blocked agents get woken up
  5. Use priority sparingly — Reserve urgent for true blockers

File Locations

PathPurpose
~/.arbiter/queue/pending/Plans awaiting review
~/.arbiter/queue/completed/Answered plans (archive)
~/.arbiter/queue/notify/Agent notifications

Checking Notifications (Agent Heartbeat)

In your HEARTBEAT.md, add:

## Check Arbiter Notifications

1. Check if `~/.arbiter/queue/notify/` has files for my session
2. If yes, read answers and proceed with blocked work
3. Delete notification file after processing

Troubleshooting

IssueSolution
Plan not showing in ArbiterCheck file is valid YAML frontmatter
Answers not appearingCheck arbiter_status, may be incomplete
Notification not receivedEnsure --notify was set correctly

See Also

Repository
Demerzels-lab/elsamultiskillagent
Last updated
Created

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.