Delegation & skill expansion

How Furoshiki queues agentic work (delegation_jobs), runs isolated CLI sessions, drafts new capabilities under ~/.furoshiki/proposals/, and surfaces outcomes through mind_queue and Telegram. Canonical markdown: docs/DELEGATION-AND-SKILLS.md in the repo.

Unified extension queue

extension_work_items is the single SQLite table for operator-facing “extension” work across all three tracks: delegations (research, code changes, system checks via delegation_jobs), skill creation (self-modification proposals — task_type='self_modification' in delegation_jobs), and repairs (doctor-initiated fixes via repair_jobs). The web dashboard Extensions page shows the unified queue, all proposal files (~/.furoshiki/proposals/), and installed plugins. CLI: furoshiki extensions list | view | jobs … | skills … | plugins … | purge. Details: docs/EXTENSIONS-UNIFIED-PIPELINE.md.

Each delegation run gets a single delegation_jobs.id at creation—the lifecycle spine. Proposal files under ~/.furoshiki/proposals/ include job<NN> in the filename. The worker reads bundled docs from the shipped SRC_DIR and writes only under the instance (FUROSHIKI_DATA).

Why it matters

Delegation moves multi-step coding and research out of a single chat turn into a tracked job with proposals and apply workflow (no upstream git merge on a typical install). The self-modification path adds plugins and slash commands without editing the core repo during the draft phase.

Delegation job states (DB vs dashboard)

delegation_jobs.status is stored in SQLite (pending → dispatched → proposed / fixed / failed, etc.). The dashboard adds display phase and track: for research and system_check, when status is proposed, the Extensions queue shows phase complete (the report file is the deliverable). Track idle means no dispatcher is running — normal after success (not an error). Canonical reference: docs/DELEGATION-AND-SKILLS.md.

stateDiagram-v2
  [*] --> pending: create job
  pending --> dispatched: spawn dispatcher
  dispatched --> proposed: wrote md under proposals
  dispatched --> fixed: auto_fix path
  dispatched --> failed: error
  proposed --> pending: apply continues\n(new job id)
  failed --> pending: redispatch
    

Telegram to delegation

Messages hit telegram_listener.py. A bounded recent transcript (build_delegation_transcript in micro_brain.py) feeds classify_delegation_intent / resolve_delegation_intent in classify_intent.py so short replies stay tied to the thread. Borderline confidence may trigger a clarifying question and _pending_delegation; clarify and immediate-dispatch turns are written to conversation_turns. On dispatch, prepare_delegation_task_for_job runs a MICRO task_brief pass, then create_delegation_job (with context_json) + spawn_delegation_dispatcher. The worker is delegation_dispatcher.py (or self_modification_dispatcher.py for skills).

flowchart TD
  subgraph harness [TelegramHarness]
    TL[telegram_listener]
  end
  subgraph intentLayer [Intent]
    CD[classify_delegation_intent]
    RV[resolve_delegation_intent]
    PD[pending_delegation_state]
  end
  subgraph queueLayer [Queue]
    CJ[create_delegation_job]
    SD[spawn_delegation_dispatcher]
    DJ[(delegation_jobs)]
  end
  subgraph workers [Workers]
    DD[delegation_dispatcher]
    SM[self_modification_dispatcher]
    WT[CLI_worker_SRC_and_DATA]
  end
  subgraph surface [Surface]
    MQ[(mind_queue)]
    VP[voice_and_Telegram]
  end
  TL --> CD
  MB[prepare_delegation_task_for_job]
  CD -->|borderline| PD
  PD --> RV
  CD -->|dispatch| MB
  RV -->|confirmed| MB
  MB --> CJ
  CJ --> DJ
  SD --> DD
  DD -->|self_modification| SM
  DD -->|other_types| WT
  SM --> DJ
  WT --> DJ
  DJ --> MQ
  MQ --> VP
    

Telegram when a job finishes

Finalized runs enqueue mind_queue as delegation_proposed, delegation_fixed, delegation_failed, skill_build_invite, or skill_draft_ready (delegation outcomes use high priority). outreach_pulse.py (cron, about every five minutes) invokes voice_dispatcher.py, which composes one short in-character DM from the top row — not synchronous with the worker. Quiet hours and cooldowns apply; extension outcomes get relaxed gates after a few minutes. An orphaned dispatched row (worker died without finalizing) never hits mind_queue; use furoshiki extensions jobs redispatch. Canonical write-up: docs/DELEGATION-AND-SKILLS.md.

Callable skills (runtime)

Separate from the job queue: installed plugins can expose type: callable hooks with a unique tool name. skill_orchestrator.py asks a fast model which tools to run (or micro-contemplation may list skill_calls in JSON), plugin_loader.run_callable_skill runs each subprocess, and raw results are injected into the same reply or reflection LLM that already has SOUL and emotional state — so answers stay in-character. high / urgent results enqueue mind_queue rows for voice_dispatcher to phrase proactively. List tools: furoshiki skills callable. Spec: docs/PLUGIN-SPEC.md § callable.

Skill creation sequence

furoshiki skills create inserts a self_modification row. After backup, creation and review passes run; Python writes the proposal markdown and updates the database. On the Furoshiki web dashboard, the Skills page (Bearer: an admin API key from API Keys or furoshiki api-keys create) lists the same files: you can open full markdown, delete, or run Apply (equivalent to furoshiki plugins apply when the document contains APPROVED).

sequenceDiagram
  participant User
  participant CLI as furoshiki_CLI
  participant DB as delegation_jobs
  participant DD as delegation_dispatcher
  participant SM as self_modification_dispatcher
  participant Drafts as furoshiki_drafts
  participant Prop as furoshiki_proposals
  participant MQ as mind_queue
  User->>CLI: skills create description
  CLI->>DB: insert self_modification job
  CLI->>DD: spawn job_id
  DD->>SM: subprocess
  SM->>Drafts: creation pass
  SM->>SM: review pass
  SM->>Prop: proposal markdown
  SM->>DB: status and proposal_path
  SM->>MQ: skill_draft_ready
  User->>CLI: plugins apply or delegate apply
    

The operator dashboard Delegations view shows the same queue: open a job to read the proposal file, run apply, or delete — parallel to furoshiki delegate view / apply / delete (API token required).

CLI quick reference