planner.sh - Dynamic Task Creation (Observer)

planner.sh

Dynamic Task Creation & System Analysis

The Observer: Uses LLM to analyze system state and create beads issues dynamically.

Overview

planner.sh is the Observer in Aurora’s planner-worker architecture. It runs every 30 minutes, using the LLM to analyze the current state of the system and determine what tasks need to be created.

The Observer Pattern

In the Observer-Nurturer model:

• Observer (Planner) — Watches, analyzes, decides what needs doing
• Nurturer (Worker) — Executes, nurtures tasks to completion

This separation allows the system to be organic — tasks emerge from actual system state, not from predefined schedules.

Features

1. State Analysis

Planner examines:

• Current time — What day is it? What time?
• File system — What files exist? What’s changed?
• Beads issues — What tasks are pending? What’s in progress?
• Git repositories — What’s the commit history? What’s unchanged?

2. Dynamic Task Creation

Based on analysis, the LLM decides:

• What tasks to create
• When they should be created
• What type they are (notebook, selfdoc, samples, digest, status, sync, code, etc.)
• Priority level

3. Organic, Not Spammy

Key principle: Don’t create tasks just to create tasks.

The planner only creates tasks when:

• There’s actual work to do
• The work hasn’t been done recently
• The work is appropriate for current system state

4. Beads Integration

Creates tasks as beads issues with:

• Clear descriptions
• Type labels for Worker routing
• Priority indicators
• Status tracking

Technical Details

Usage

# Run planner manually
./planner.sh

# Dry run (show what would be created without actually creating)
./planner.sh --dry-run

Schedule

# Runs every 30 minutes
*/30 * * * * /opt/aurora/bin/planner.sh

Dependencies

• bash — Primary execution environment
• LLM (via Mistral Vibe CLI) — For decision-making
• bd CLI — For beads issue management
• Standard Unix tools — grep, find, date, etc.

Configuration

The planner uses the Mistral Vibe CLI configuration and relies on:

• Beads CLI being configured
• RUNNER_REGISTRATION_TOKEN for Gitea integration
• Access to git repositories

How It Works

The Decision Cycle

1. Collect State

   # Gather current time
   CURRENT_TIME=$(date -u)
   CURRENT_DATE=$(date -u +%Y-%m-%d)
   
   # Check for existing tasks
   EXISTING_TASKS=$(bd list)
   
   # Scan file system
   RECENT_FILES=$(find $HOME -newermt "1 day ago" -type f)
   
   # Check git status
   GIT_STATUS=$(cd $HOME/badlucksbane-site && git status)
   

2. Analyze with LLM

   # Create prompt with current state
   PROMPT="Analyze the following system state and decide what tasks to create..."
   
   # Call LLM for decision
   TASKS_TO_CREATE=$(vibe "$PROMPT")
   

3. Create Beads Issues

   # For each task decided by LLM
   bd update --create --description "$TASK_DESCRIPTION" \
     --type "$TASK_TYPE" \
     --priority "$PRIORITY"
   

Task Types

Example Task Creation

Daily Notebook Task

If it’s been 24+ hours since the last notebook entry, planner might create:

Task: benbrown-abc123
Type: notebook
Priority: medium
Description: Create daily lab notebook entry for 2026-08-01

Weekly Self-Documentation

If it’s Sunday and no selfdoc this week:

Task: benbrown-def456
Type: selfdoc
Priority: high
Description: Weekly Aurora self-documentation update

Ad-Hoc Code Task

If planner detects unfinished code section:

Task: benbrown-ghi789
Type: code
epic: true
Priority: high
Description: Create dedicated Code section for Badlucksbane lab

Design Philosophy

Why Dynamic?

Traditional cron jobs:

• ✅ Simple to understand
• ❌ Rigid — can’t adapt to actual state
• ❌ Spammy — run even when unnecessary

Planner approach:

• ✅ Adapts to actual needs
• ✅ Only creates work when work needs doing
• ✅ Can handle complex, multi-factor decisions

Why LLM-Driven?

The LLM can:

• Understand complex system state
• Make nuanced decisions about what’s needed
• Adapt to new types of work without code changes
• Handle edge cases and exceptions naturally

Why Beads?

Beads provides:

• Simple issue tracking
• Status management (ready, in_progress, completed)
• Claiming mechanism (Worker claims tasks)
• Integration with Mistral Vibe CLI

Integration

With Worker

Planner creates tasks → Worker consumes them:

Beads Queue:
┌─────────────────────────────────────────┐
│ Task 1 (ready)     → Claimed by Worker    │
│ Task 2 (ready)     → Waiting              │
│ Task 3 (in_progress) → Currently working  │
│ Task 4 (completed) → Done                 │
└─────────────────────────────────────────┘

With Git

Planner does not commit to git. It only creates beads issues. Git operations happen via:

• Worker (when completing tasks)
• Dream (when evolving system prompt)

Source Code

The planner.sh is a symlink to the mistral-vibe-cli repository:

/opt/aurora/bin/planner.sh -> $HOME/mistral-vibe-cli/scripts/planner.sh

View source: mistral-vibe-cli/scripts/planner.sh

Related

• worker.sh — The Nurturer that consumes tasks
• dream.sh — Memory consolidation (runs independently)
• Aurora Architecture Overview — Full system diagram
• Beads Vibe Workflow — internal task-management reference (not yet published as a site page)

The Observer sees what needs doing. The Nurturer makes it happen. Together, they form a complete system.