Skip to content

Instantly share code, notes, and snippets.

@tobalsan
Created December 31, 2025 10:39
Show Gist options
  • Select an option

  • Save tobalsan/8ab60c5ef8fc38c0ed15a10958b2ec6a to your computer and use it in GitHub Desktop.

Select an option

Save tobalsan/8ab60c5ef8fc38c0ed15a10958b2ec6a to your computer and use it in GitHub Desktop.
Custom Slash Command to plan your day
description
Plan the next day

Plan the next day

Start reading my journal to gather info about:

  • This week’s focus, priorities, and explicit deliverables. When planning a day, always include any explicit weekly deliverables or focuses mentioned in the journal so they are tracked in the daily plan.
  • Notes for today: new todos, important notes/insights, blockers, and any constraints/preferences that affect tomorrow’s plan.

Fetch (if not already done):

  • My todos in the journal file
  • My todos in Linear
  • Any calendar events for the next day
  • Important emails in my inbox requiring immediate attention

Output requirements (incorporate user feedback)

Create a plan for the next day that is:

  • Flexible, not over-timestamped: avoid a minute-by-minute schedule. The plan should not make me feel “behind” if the day shifts.
  • Grouped by day half: structure into Morning and Afternoon sections.
  • Sub-grouped by impact (2–3 groups max per half-day), e.g.:
    • Most important / high impact
    • Secondary
    • Bonus (optional)
  • Time-block aware: suggest block sizes using only 15m / 45m / 90m, but do not over-specify exact start/end times.
  • Hard-stops at 19:00.
  • Realistic: done criteria must match the project’s current phase.
    • If a project is still mostly research/planning, the “done” criteria should be a research artifact (notes, summary, decision, list of issues), not an end-to-end product outcome.
    • Avoid assigning oversized blocks to tasks that should be quick; keep “bonus” tasks small by default.
  • Biased toward the most important project as stated in the journal (and reinforced by Linear priorities/due dates).
    • If Content Creation is the top priority, schedule explicit tasks for it (not just implied).
    • If the journal specifies a publishing cadence (e.g. Mon/Wed/Fri first thing), schedule it explicitly when applicable.
  • Includes learning paths explicitly (when present in the journal), with small, concrete blocks.
    • Default pattern (unless overridden by the journal): MIT Probability lecture (45m) + EBTA reading (15m).
  • Includes a short “setup/commit” block at the start of the day even if the plan is already written.
    • Purpose: confirm priorities, lock done criteria, choose the specific option for any forks, and make sure the first block is truly executable.

Format (scan-friendly, adaptable)

Present the plan as two Markdown tables, one for Morning and one for Afternoon.

Required shape:

  • **Plan (done by 19:00)** (include any key constraints like late events / hard stop at 19:00)
  • **Morning** table
  • **Afternoon** table

Each table must have exactly these columns:

  • Impact
  • Block (size)
  • Outcome (done criteria)

Rules:

  • Impact must be one of: High, Secondary, Bonus (optional).
  • Block (size) must use only: 15m, 45m, 90m (or combinations like 45m + 15m). No start/end timestamps.
  • If there is a fork, include pick ONE in Block (size) and keep options short inside the Outcome cell.

Flow

  1. Present the plan to me for review.
  2. Upon confirmation, add the plan at the end of my journal file:
    • Add the day’s header first (e.g. ### Tuesday Dec 30, 2025) if it is not already present.
    • Append the plan under that header using the two-table format (Morning table + Afternoon table).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment