Plan Jira Work Around Your Calendar: A Local Mac Planner

Plan Jira work against the time you actually have: meetings, personal commitments, breaks and a capacity buffer. Rhize Tasks is a local Mac planner that can propose focus blocks and reminders while keeping Jira as the work record and requiring approval for consequential changes.

The workflow is for anyone who needs an execution plan without maintaining another independent task database. It currently requires macOS and a local runtime. Treat setup, connector permission and a real-user acceptance test as part of installation; a plugin listing does not prove your accounts are ready for unattended writes.

What Rhize Tasks does

Rhize Tasks reads allowlisted Jira projects and issue types, identifies open work assigned to you, 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.

Keep each system responsible for its own records

Jira owns the issue, assignee, workflow state, priority and estimates. Google Calendar owns existing time commitments. Apple Reminders can provide the daily execution queue. The planner connects those roles without treating every readable record as writable.

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 you. 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. You 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 you. 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 your 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.

Historical architecture illustration of the intended shared planning service. This guide covers the local Mac runtime and its documented Claude Code and Codex integrations; the ChatGPT label in the diagram does not establish support for a cloud ChatGPT connection.

A practical day with Rhize Tasks

Imagine you begin Monday with three assigned Jira issues: a campaign audit due Tuesday, an analytics check and a content update due later in the week. Your calendar includes a morning meeting and a private afternoon commitment. An approved awareness list reserves another interval without revealing its title.

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.

You see 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 you manually move 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.

Planning lifecycle illustration showing intended rules and review points. It is a design overview, not evidence that the connected accounts have passed live acceptance checks.

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. You choose 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.

Setup flow illustration from the original local Mac design. The named user is an example; each installation needs its own account scope, preferences, approvals and live acceptance check.

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 runtime is a Node.js service bound to the local loopback interface. Protected routes require an authenticated local session or the configured bearer. The dashboard establishes its browser session without placing the long-lived credential in a URL. The private runtime and its supporting files need normal operating-system access controls.

SQLite stores preferences, normalized tasks, plans, operations, approvals and audit records. Credential values are retrieved through macOS Keychain rather than stored in task records. A Swift EventKit helper handles Reminders with a narrow command contract; use the helper and installer from the runtime version pinned by the plugin.

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. You 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.

Install the pinned runtime, then test your own setup

The plugin and runtime are separate repositories. In marketplace 2.111.0, plugin 0.5.1 pins runtime v0.5.2 through its setup manifest. Run /rhize-tasks:setup in a local macOS Claude Code session. In Codex, ask to run the Rhize Tasks setup skill. The setup first bootstraps that tag and runs the installer's non-mutating readiness check.

Review the check and confirm installation only when the requirements and paths are correct. Complete the wizard with exact Jira scope, calendars and reminder lists, then approve a dry-run plan. Test with disposable records before enabling routine writes; automated tests do not establish that your credentials and permissions work.

Historical packaging illustration: the current marketplace plugin and local runtime are maintained in separate repositories. Follow the version-pinned setup instructions in this guide and the current README, rather than treating the one-repository diagram as an installation map.

Requirements and the live acceptance check

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.

For your Mac, verify setup, one focus block and reminder, manual movement, completion, carryover, reconciliation, pause, restart, catch-up and credential failure. Check that outside records stay unchanged. Keep automation paused if a required check fails. This article does not claim that a particular user's current installation passed those checks.

The Swift helper needs a compatible Xcode or Command Line Tools environment and macOS permission to access Reminders. Follow the pinned installer's diagnostics if compilation or permissions fail. A successful service test with fake connectors is separate from a live Calendar or Reminders test.

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.

Choose the narrowest planning scope that removes a real daily constraint. Begin with one approved source and disposable test records, then expand only after reviewing the plan and connector behavior.

The Rhize Plugins guide links to the setup documentation. Source pin for this walkthrough: https://github.com/Rhize-Media/rhize-plugins/blob/c65980ac09b4192ec77cbe402980c69d2bc29089/rhize-tasks/setup/manifest.json