Rhize Tasks: A Local-First AI Task Planner for Jira and Calendar

Rhize Tasks turns approved Jira work into a realistic daily plan across Google Calendar and Apple Reminders. It runs locally on a Mac, keeps Jira authoritative for work, protects commitments from calendars and reminder lists, and asks for human approval whenever a proposed action crosses a meaningful boundary.

The plugin was designed around Tom Cassidy's actual working pattern at Rhize Media. Tom needs to see client and internal Jira work in priority order, reserve focus time around meetings and personal commitments, and carry a practical execution list in Apple Reminders. He also needs to discover urgent unassigned work that suits his competencies without silently claiming it. Rhize Tasks connects those needs through one local planning authority instead of asking him to maintain another independent task database.

What Rhize Tasks does

Rhize Tasks reads allowlisted Jira projects and issue types, identifies open work assigned to Tom, and normalizes that work into a strict local task contract. It then subtracts meetings, protected reminders, breaks, hard stops, freeze windows, and a configurable capacity buffer from the working day. Eligible tasks are placed into the remaining windows as focus blocks, with longer work split only when the saved profile permits it.

The output is not a loose list of recommendations. It is an immutable plan revision with exact proposed operations. Each Calendar event, Reminder item, Jira action, and approval has a stable identity, a precondition, and an audit history. The dashboard shows the same revision that Claude and Codex see through their shared skills.

Baseline planning is deterministic and does not require a separate model API key. The system can use an agent to help with an estimate, but that estimate still enters the same confidence and approval gates as any other input.

Why a separate task app would fail here

Tom already has systems that own important facts. Jira knows the issue, project, assignee, workflow state, priority, dependencies, and estimates. Google Calendar knows when time is already committed. Apple Reminders is a practical place to see and complete the day's execution queue. A new cloud task app would create another copy that can drift from all three.

The harder problem is control. Seeing a personal appointment should not grant permission to rename it. Reading a household reminder should not allow a work planner to complete it. Finding an urgent unassigned Jira issue should not silently assign it to Tom. Rhize Tasks separates awareness from authority so the planner can protect time without gaining broad mutation rights.

That distinction also makes the system easier to stop and inspect. Tom can pause automation immediately, review connector freshness, inspect audit history, revise preferences, or uninstall the local service. Uninstalling asks separately whether to retain local history and whether to remove proven plugin-created items.

Jira ownership, opportunities, and competency fit

Owned work is the schedulable lane

An owned task is an allowlisted, non-terminal Jira issue assigned to Tom. Owned work is ordered using deadline feasibility, Jira priority, dependency impact, project importance, remaining effort, estimate confidence, competency fit, context grouping, and task age. The planner exposes its rationale instead of hiding the decision inside an unexplained score.

Blocked, manually locked, provisional, reserved, and completed work is excluded from automatic placement. Low-confidence inferred estimates can appear in a preview, but they cannot consume live Calendar capacity until confirmed.

Opportunities stay suggestions until approved

Rhize Tasks can also surface allowlisted unassigned issues above a configured urgency threshold. Opportunity ranking considers urgency, deadline and dependency risk, project importance, available capacity, age, and Tom's saved competency profile. The initial profile can represent strengths such as ads, marketing, GoHighLevel, and non-development-heavy Sanity work, along with explicit exclusions and confidence weights.

An opportunity is never silently scheduled or assigned. The Today view explains the fit, estimated effort, rationale, and expected impact on owned work. Claiming it is an approval-required Jira operation tied to the current plan revision.

One planning authority across four integrations

Rhize Tasks gives each connected system a narrow role. This keeps the plan useful without pretending every source has the same trust or write boundary.

Global awareness matters because work capacity is personal even when work control is narrow. A scheduled reminder from another approved list can reserve an opaque busy interval. An outside Calendar event can block time without exposing its title. User-created events on the focus calendar remain protected unless they carry the complete Rhize ownership markers.

The planner writes stable task and block identities into private Calendar extended properties. On a later plan revision, it can update the proven event for the same logical block, create a missing event, or delete an exact orphaned Rhize event. It never treats an unmarked user event as cleanup material.

A practical day with Rhize Tasks

Imagine Tom begins Monday with three assigned Jira issues: a client campaign audit due Tuesday, a routine analytics check, and a Sanity content update due later in the week. His Calendar already contains a client meeting at 10:00 and a private commitment at 15:00. A scheduled reminder from an awareness list reserves another short interval, with its title hidden.

The morning routine refreshes the configured sources and builds the day from the remaining windows. The campaign audit ranks first because its deadline is close and its estimate fits the available morning window. The analytics check becomes a smaller block after the meeting. The Sanity update may be split into two sessions if the profile allows splitting and the capacity buffer remains intact.

Tom sees the chronological plan, current and next blocks, planned minutes, reserved buffer, connector freshness, estimate warnings, and any approval-required operations. The Rhize Tasks Reminder list receives the daily execution items, while Rhize Focus receives the approved blocks. The private commitment appears only as busy time.

If Tom manually moves a focus block, the manual edit becomes authoritative. A midday replan preserves completed work, the active block, manual movement, outside commitments, and anything inside the freeze window. Only unfinished eligible future work is reconsidered.

Bounded replanning and honest carryover

The scheduler runs morning, midday, evening, and catch-up routines through one local service and a single-instance lock. A launchd poll evaluates what is currently due in the saved timezone. If the Mac was asleep, the service chooses at most one current phase and marks earlier missed phases covered, rather than replaying a backlog of stale plans.

Carryover is deliberately finite. On the first miss, the planner can move the task once to the nearest safe window before its deadline. On the second miss, it asks whether the work is blocked, underestimated, or no longer important. Repeated misses stop silent movement and require a decision such as split, delegate, defer, or renegotiate.

Evening reconciliation only increments carryover for unfinished, non-terminal owned tasks that appeared in the prior approved plan. Unclaimed opportunities, provisional delegations, and work that was never scheduled do not acquire a false history of missed execution.

The approval and preferences wizard

Setup is a seven-stage, resumable workflow. It covers safety boundaries, identity and credentials, Jira scope, Calendar and Reminders scope, work style, routine policy, and a final live-data dry run. Credentials go directly to approved macOS Keychain service and account pairs. Non-secret setup state can be resumed without putting tokens into browser storage, prompts, logs, SQLite, or launchd configuration.

Connector discovery is read-only before a profile exists. Tom chooses exact projects, issue types, calendars, reminder lists, Slack identities, work intervals, breaks, focus sizes, buffers, and routine times. Scope expansion creates an approval preview. A reversible sample probe can create, verify, delete, and verify absence for one exact Reminder and focus Calendar item before activation.

The browser does not author hidden operations. The service reads the current snapshot, produces the plan preview, and returns every exact proposed operation. Preferences and the first live plan both need approval before bounded automatic scheduling becomes available. Material planning preference changes invalidate the first-plan approval and require a new reviewed plan.

Strict Slack fallback for delegations

Slack is a fallback ingestion path, not a general message scanner. Rhize Tasks reads replies only in one configured channel and trusts only exact app, bot, or user sender IDs. A valid reply starts with four ordered fields for task, due date, priority, and Jira state, then ends with one exact lowercase UUIDv4 marker.

The producer generates that delegation ID before Jira or Slack side effects and reuses it across retries. A Jira-ready message preserves the Jira key or URL. A `needs_jira` message becomes an approval-required provisional record that cannot be scheduled until Jira is created or linked. Exact Jira description markers can merge automatically; similar titles or dates can only propose a human-reviewed merge.

Quoted markers, duplicate markers, malformed fields, root summaries, untrusted senders, and messages from other channels are ignored. Slack never receives mutation authority from this plugin.

Local-first architecture and privacy

The production architecture is a dependency-free Node.js 22+ ESM service bound to `127.0.0.1`. Every data or mutation route requires a Keychain-backed bearer or an authenticated local browser session. The dashboard uses a short-lived, single-use nonce to establish an HttpOnly, SameSite Strict cookie without putting the long-lived bearer in a URL or persistent browser storage.

SQLite under the user's Application Support directory stores preferences, normalized tasks, source mappings, estimates, immutable plans, operations, approvals, audits, and routine state. It does not store credential values. Google access tokens are refreshed in memory. Jira authentication is derived from Keychain credentials when needed. The Reminders boundary is a minimal Swift 6 EventKit helper with a fixed command allowlist and a strict JSON process contract.

The macOS installer builds and signs the helper, installs a versioned private runtime, provisions or verifies the API bearer in Keychain, and activates one LaunchAgent. Installation and removal use path identity checks, atomic file replacement, rollback, bounded item cleanup, and exact plugin ownership markers.

Reliability when an external write is uncertain

External systems sometimes accept a write after the client has timed out. Retrying blindly can create duplicate Jira comments, duplicate Calendar events, or repeated transitions. Rhize Tasks records those outcomes as reconciliation required when it cannot prove what happened.

Connectors use operation-specific markers and preflight checks. Jira comments carry an exact operation marker, created issues use a safe label, transitions use a durable issue property, Calendar events use a private `rhizeOperationKey`, and Reminders use a stable namespaced marker. Pagination guards and response validation prevent a partial search from being mistaken for absence.

Prompted reconciliation appears as a separate Today view list with the exact operation ID, system, kind, and a safe reason. Tom must confirm the exact item. After connector health checks, the service atomically rechecks the plan revision, pause state, approval, retry state, system, kind, and idempotency key before it records the request and starts one fresh bounded attempt. If ambiguity remains, the item returns to reconciliation required. A dashboard refresh never retries it automatically.

The same plan in Claude, Codex, and a read-only artifact

Rhize Tasks ships six shared skills for setup, daily planning, opportunity review, reconciliation, preference management, and diagnostics. Claude commands delegate to those skills, while the Codex manifest points at the same skill directory. Both hosts call the same authenticated local service, so they cannot develop independent versions of the day.

The dashboard remains the canonical interactive approval surface. A standalone HTML artifact can capture one sanitized Today view revision for reading and sharing locally. It escapes content, has no forms or mutation controls, makes no network requests, and directs changes back to the authenticated dashboard or plugin command.

How the plugin was implemented and reviewed

The project began with structured brainstorming and an approved design specification, then moved into a task-by-task implementation plan. Parallel task coordination and an isolated worktree kept connector, native helper, service, dashboard, and delegation work from colliding. Subagent-driven development handled bounded implementation slices, while repeated cold reviews checked producer and consumer contracts across task boundaries.

The delivery process also used writing plans, the parallel execution optimizer, plugin and skill creator tooling, content SEO guidance, and a humanizer pass. Those tools supported the work; they did not replace evidence. The final implementation was checked through unit, invariant, connector, failure-injection, installer, schema, dashboard, and loopback end-to-end tests. At the released commit, the Node package reports 181 passing tests with no live Jira, Calendar, Reminders, Slack, or Keychain calls in the suite.

Current limitations and the remaining acceptance gate

Rhize Tasks currently targets macOS 14 or newer with Node.js 22 or newer. Apple Reminders depends on EventKit and the local helper, so the supported experience is Mac-specific. The service is intentionally local rather than a hosted multi-user planner.

The automated suite is complete, but activation on Tom's Mac remains a separate acceptance gate. That run should use an approved Jira test issue and disposable Calendar and Reminders containers. It must verify setup, the first dry run, one focus block and reminder, manual movement, completion, carryover, prompted reconciliation, pause, restart, catch-up, credential failure, and bounded uninstall while confirming that outside items remain unchanged. Any failed gate should leave automation paused.

There is also a tooling caveat for the native helper. The release helper builds, and eight hermetic Swift tests pass with the documented CommandLineTools framework workaround. The plain canonical Swift test command could not discover its test frameworks with the selected CommandLineTools installation. Full Xcode should rerun that canonical command before a public binary release.

Rhize Tasks in the Rhize plugin ecosystem

Rhize Tasks is a dedicated plugin because personal productivity data, local scheduling, and background routines carry a different permission profile from broader operations tooling. It still fits the wider Rhize approach. Rhize Plugins provides the shared model of focused capabilities, Rhize Ops supplies operational workflows such as structured delegation, and Claude skills and plugins explain how reusable instructions can stay thin while a service owns state and safety.

For teams deciding where automation can recover the most working time, Get Your Time Back provides a practical starting point. The growing Rhize AI tools collection shows how focused tools and agent skills can work together without turning one plugin into a catch-all platform.

Rhize Tasks is one example of the Skill Forge principle: give an agent a narrow, testable capability with explicit permissions, then connect it to a reliable source of truth. Explore the Rhize Plugins ecosystem and choose the smallest skill or plugin that removes a real workflow constraint.