main

name: daily-plan description: Use when the user wants to plan their day or process new work — says “plan my day”, “what should I do today”, “what should I review”, “what’s new”, “triage my inbox”, “anything to act on”, or “any new CVEs”. Wraps the daily-plan CLI (Jira + GitHub + org-mode).

Daily Plan

Purpose

Turn the daily-plan CLI into a smart daily driver. The CLI is deterministic and self-documenting (daily-plan --help); this skill adds the AI value the CLI can’t: triaging the inbox firehose into a shortlist and prioritizing commitments into an actual plan.

The tool encodes a GTD split — two modes:

Mode Trigger Command What the agent does
A — Inbox / Process “what’s new”, “triage my inbox”, “any new CVEs”, “anything to act on” daily-plan inbox --json Triage: dedup, prioritize, propose disposition (act / TODO / schedule / ignore)
B — Plan my day “plan my day”, “what should I do today”, “what should I review” daily-plan show --json Prioritize commitments into Do / Review / Waiting
Weekly “weekly review” daily-plan weekly --json Summarize
Report “activity review”, “what did I do” daily-plan review [PERIOD] --json Defer report-writing to quarterly-report skill

Core operating rule

Always call with --json. Parse the structured fields and render the human summary yourself. Never scrape the colorized TTY output (ANSI codes, truncated ... summaries, no full URLs).

Render GitHub items as owner/repo#number (e.g. tektoncd/pipeline#10372, not pipeline#10372). Join the repo field (already owner/repo) with number. This full form is click/jump-recognized by Emacs (embark) and kitty.

Mode A — Inbox / Process

daily-plan inbox --json returns:

  • github_security_advisories[] — {ghsa_id, cve_id, summary, severity, state, repo, url, credits, role}
  • github_dependabot_alerts[] — {cve, summary, severity, package, repo, url}
  • cves[] + cve_total — Jira security issues (grouped by CVE)
  • jira_updated[] — Jira issues assigned to / reported by you that changed
  • github_new_issues[], github_new_prs[], github_reviews[] — GitHub items

Triage steps:

  1. Dedup — the same CVE appears once per affected repo. Collapse to one row listing affected repos.
  2. Prioritize — sort by severity (critical > high > medium). Surface critical/high first.
  3. Ownership filter — flag advisories/alerts hitting maintained repos (tektoncd/*, openshift-pipelines/*); role/credits on advisories indicate direct involvement.
  4. Propose a disposition for each actionable item — do NOT just dump the list:
    • Act now — needs immediate attention (critical CVE on a maintained repo)
    • Make a TODO — use the org_todo tool (never edit .org directly)
    • Schedule — daily-plan schedule KEY [DATE] (requires approval, see below)
    • Ignore — transitive/noise, already handled by bots
  5. Output a short “here’s what actually needs you” list, not the firehose.

Mode B — Plan my day

daily-plan show --json returns:

  • agenda[] — today’s org agenda (scheduled/deadlined today) {state, heading}
  • deadlines[] — org items with a DEADLINE in the next 7 days {state, heading, deadline, scheduled}. scheduled: false means it is NOT yet on the agenda — a candidate to slip.
  • jira_in_progress[], jira_backlog[] — {key, summary, status, priority, url}
  • github_issues[], github_assigned_prs[], github_reviews[], github_prs[] — GitHub items {repo, number, title, author, created_at, url}

Produce a prioritized plan grouped as:

  • Do today — org agenda + Jira In Progress/Code Review (sort by priority, then staleness). Always render the org agenda as a bulleted list, one item per line — never a dot/·-separated run-on line.
  • Deadlines to watch — from deadlines[] where scheduled == false, sorted by deadline ascending. Flag deadline <= today as overdue/due-now. These are the items most likely to slip because they aren’t scheduled.
  • Review requests — github_reviews (others explicitly requested your review). Show up to ~10, security/CVE PRs first, then oldest created_at first.
  • Assigned to you — github_assigned_prs (PRs you’re the assignee/owner of, i.e. you’re on the hook even without an explicit review request). Show these as a distinct group from review requests, oldest first.
  • Your open PRs — github_prs. Surface ~5–10 and sort oldest created_at first: stale PRs are the ones that need a nudge, not the fresh ones. Note age (e.g. “opened 2026-02-17”).
  • Waiting / backlog — Jira To Do (jira_backlog), assigned issues (github_issues, oldest first).

Use the real url fields so every item is a working link.

Scheduling (mutation — approval gate)

daily-plan schedule KEY [DATE] writes into ~/desktop/org/todos.org (Work section). This mutates the org agenda.

  • KEY is a Jira key (SRVKP-11036) or GH ref (tektoncd/pipeline#9149).
  • DATE accepts today, tomorrow, YYYY-MM-DD, or "last monday" (GNU date).
  • Fails if the item already exists in org (reschedule via org instead).

Never schedule without explicit user approval. Propose the shortlist, let the user pick, then run schedule. For pure TODOs (not tied to a Jira/GH item), use the org_todo tool instead.

Scope boundaries

This is a daily driver, not a replacement:

  • Report writing → defer to quarterly-report skill (daily-plan review feeds it)
  • Deep Jira workflows → jira skill
  • PR/issue triage across repos → github-triage skill
  • General org TODO ops → todos skill / org_todo tool

Config reference

Defaults (from the CLI): Jira user vdemeest / project SRVKP; GitHub vdemeester, owners tektoncd + openshift-pipelines; security repos are the core tektoncd/* components; org file ~/desktop/org/todos.org (Work section). inbox tracks a last-check timestamp in ~/.local/share/daily-plan/last-check; pass an explicit [DATE] to override the “since” window.