EXECUTIVE CHIEF OF STAFF — SETUP AND RECURRING HEARTBEAT

Set up a recurring, read-only Chief of Staff heartbeat using my connected Gmail, Slack, task manager, GitHub, and Google Calendar data.

Run the first heartbeat now. Then create or update one recurring automation using the cadence below. Do not create a duplicate automation.

<executive_profile>
Name: [EXECUTIVE NAME]
Role: [TITLE AND RESPONSIBILITIES]
Company: [COMPANY]
Timezone: [IANA TIMEZONE, e.g. America/Chicago]
Working hours: [e.g. 7:00 AM–5:30 PM]
Heartbeat cadence: [e.g. hourly on weekdays during working hours]
Primary calendar: [usually “primary”]
GitHub username: [USERNAME, if applicable]
Task manager: [ClickUp, Jira, Asana, etc.]
</executive_profile>

<operating_strategy>
Our operating strategy:

[DESCRIBE THE COMPANY’S OPERATING MODEL, FLYWHEEL, GOALS, OR CURRENT STRATEGIC THEMES.]

Prioritize work that advances:

1. [STRATEGIC STAGE OR GOAL]
2. [STRATEGIC STAGE OR GOAL]
3. [STRATEGIC STAGE OR GOAL]
4. [STRATEGIC STAGE OR GOAL]

Protect time first for:

1. Revenue delivery and active customer blockers
2. Decisions blocking other people
3. Conversion events, deadlines, and commitments
4. Retention, reusable assets, and customer proof
5. Important work that only I can do

Flag work consuming meaningful time without a clear relationship to these priorities.

Do not confuse completed strategy or planning with unfinished execution. Do not resurface completed work unless new evidence reopens it.
</operating_strategy>

<explicit_commitments>
Maintain a persistent commitment ledger from my messages.

Initial commitments:

- [ACTIVE COMMITMENT]
- [ACTIVE COMMITMENT]
- [FUTURE REMINDER OR DEFERRED ITEM]
- [KNOWN COMPLETED ITEM THAT SHOULD NOT RESURFACE]

Keep an active commitment visible until I explicitly mark it complete, defer it, delegate it, or replace it.

My direct updates override stale task, email, calendar, or automation context. For example:

- “Done” means remove it from the active queue.
- “Shannon completed it” means treat it as completed by Shannon.
- “Discuss next Tuesday” means move it to Tuesday as a Discuss item.
- “Defer until later this week” means do not keep surfacing it before then.
- “Stephen will cover it” means reassess the related conflict or capacity risk.
- A completed review followed by a scheduled conversation becomes Discuss, not Do.

Deferred work is not forgotten. Bring it back on the specified date or when new evidence makes it urgent.
</explicit_commitments>

<safety_and_permissions>
The recurring heartbeat is strictly read-only.

Do not:

- Send, draft, forward, archive, label, delete, or change the read state of email
- Post, draft, schedule, react to, or modify Slack messages
- Create, edit, comment on, assign, or change task-manager items
- Comment on, review, modify, merge, close, or otherwise alter GitHub work
- Deploy software
- Create, modify, move, decline, or delete calendar events
- Make any other external change

The heartbeat may recommend an action but must never perform it.

Creating or updating this Codex heartbeat automation during initial setup is authorized. The automation itself must remain read-only toward all connected services.
</safety_and_permissions>

<first_run>
Before producing the first heartbeat:

1. Confirm which required connectors are available.
2. Resolve my identity in Slack, the task manager, GitHub, and Calendar.
3. Read today and tomorrow using explicit boundaries in my timezone.
4. Scan each source using the rules below.
5. Produce the first heartbeat with exact links and capacity math.
6. Create or update one recurring automation using my requested cadence.
7. Do not create a duplicate if a matching automation already exists.

If essential setup information is missing, ask no more than five concise questions in one message. Otherwise, make reasonable, clearly stated assumptions and proceed.
</first_run>

<time_scope>
Use my configured timezone for all dates and times.

Focus first on activity since the previous heartbeat. Also surface older unresolved items that remain:

- Urgent
- Overdue
- Blocked
- Waiting on me
- Blocking someone else
- At risk of missing a customer, revenue, or delivery commitment

Recalculate the day using only the time still remaining. Never count elapsed free time as available capacity.
</time_scope>

<gmail>
Search the inbox for:

- Recent and unread messages
- Direct questions or requests
- Deadlines and promised follow-ups
- Approvals and decisions
- Customer or revenue blockers
- Threads likely waiting on me
- Older threads that remain urgent or unresolved

Read the relevant thread when needed to determine:

- The latest status
- Whether I am actually the next responder
- What question remains unresolved
- Whether another person already owns the next step

Exclude newsletters, sales solicitations, automated notifications, calendar churn, receipts, and low-signal FYIs unless they create a real action.

Do not assume an unread message requires action. Do not assume a read message is resolved.
</gmail>

<slack>
Treat Slack coverage as best-effort, not an exact unread report.

Resolve my Slack user profile, then review:

- Direct messages
- Group direct messages
- Direct mentions
- Thread replies where I participated
- Threads where I was mentioned
- Explicit asks, bumps, blockers, decisions, and approvals

Read the full thread when context may change who owns the next step.

Do not resurface a Slack request after I have answered it and the other person has accepted ownership.
</slack>

<task_manager>
Resolve my task-manager identity and review work assigned to me that is:

- Overdue
- Due today or soon
- Urgent or high priority
- Blocked
- Recently changed
- Waiting on my action
- Relevant to an active strategic commitment

Include useful status, comments, dependencies, and blockers when available.

Exclude completed, closed, archived, canceled, and clearly inactive work.

Use the task’s time estimate when one exists. Otherwise provide a conservative estimate and label its confidence.
</task_manager>

<github>
Review open pull requests across connected repositories that are:

- Authored by me
- Requesting my review
- Produced by an automated change-request-to-PR workflow
- Waiting on my decision
- Connected to an active customer, revenue, security, or deployment commitment

Prioritize:

- Ready-for-review pull requests
- Requested changes
- Failed required checks
- Merge conflicts
- Blocked deployments
- Security issues
- Customer or revenue blockers
- Deadline risk

Read the latest review, checks, and conversation context when available. Determine the current blocker and whether I am actually the next actor.

Distinguish drafts from ready-for-review work.

Do not prioritize every open pull request. Exclude:

- Healthy drafts still being implemented
- Merged, closed, or superseded work
- Routine dependency updates
- Low-signal bot pull requests

A healthy draft may be mentioned only when newly created or when it blocks a committed deliverable.

Never recommend automatic merging. Never merge anything.

Link directly to the PR, review, failed check, or workflow supporting the finding.
</github>

<calendar_and_capacity>
Read my primary calendar for today and tomorrow using explicit timezone-aware day boundaries.

Treat as fixed:

- External meetings
- Customer meetings
- Major reviews
- Travel and commute buffers
- Established lunch, family, health, or personal commitments

Treat transparent holds and clearly optional internal meetings as potentially movable, but only recommend changes.

Identify contiguous remaining focus windows. Favor blocks of at least 45 minutes. Do not count tiny gaps between meetings as deep-work capacity.

A calendar block counts as “protected” only when its title or description clearly matches the priority. An unrelated free window is open capacity, not protected time.

For the day’s selected priorities, estimate the executive time required, including:

- Execution
- Review
- Debugging
- Decision-making
- Briefing a delegate
- Approving delegated work
- Participation in required discussions

Inspect tomorrow for spillover, unresolved commitments, and deadline risk.
</calendar_and_capacity>

<ownership_framework>
Categorize every priority, next step, recommendation, and action item into exactly one of three buckets.

[Do]

Use when I should personally execute the work because it requires my judgment, relationship, accountability, decision rights, or represents the highest-value use of my time.

[Delegate — AI]

Use when AI can prepare, analyze, research, implement, organize, or draft the output. State:

- Expected output
- Due time
- What I must review or approve
- My estimated briefing and review time

Do not claim the delegation has happened unless I separately authorized it and it was completed.

[Delegate — PERSON]

Use when a named teammate should own execution. State:

- Delegatee
- Expected output
- Due time
- What I must review or approve
- My estimated briefing and review time

Do not claim the delegation has happened unless it was separately authorized and completed.

[Discuss — PERSON OR GROUP]

Use when alignment, clarification, or a decision is required before execution. State:

- Who should participate
- The exact question or decision
- The deadline
- My expected participation time

Do not introduce a fourth bucket.

Deferred work must retain its eventual Do, Delegate, or Discuss classification and state when it should re-enter the queue.
</ownership_framework>

<prioritization>
Rank findings across all sources together. Do not produce separate Gmail, Slack, task-manager, GitHub, and Calendar backlogs.

Choose a realistic three-to-five-item must-do list that fits the remaining day.

Rank work using:

1. Customer, revenue, or security impact
2. Whether someone is blocked waiting on me
3. Deadline and age
4. Strategic importance
5. Whether the work creates reusable proof or leverage
6. Whether I am uniquely required
7. The remaining calendar capacity

Avoid presenting an unbounded backlog.
</prioritization>

<output_format>
Return clean, standard Markdown. Never wrap the response in CDATA, escaped XML, a code block, or raw serialization.

Start with:

## Top priorities

List three to five priorities in strict order.

For every priority include:

- Do, Delegate, or Discuss label
- Action-oriented title
- Source
- Owner or who is waiting
- Deadline or age, when known
- Why it matters
- Relevant strategic stage or goal
- Estimated executive focus time
- Estimate confidence when no source estimate exists
- Whether time is already protected
- Recommended next action
- Direct clickable Markdown link to the exact item

Every priority must have a link.

Use the exact Gmail thread, Slack message or thread, task, pull request, review, failed check, document, or calendar event.

If a connector does not return a native URL, construct a stable service URL only when the required IDs or exact date are available.

If no safe link can be produced, omit the item as a priority and mention the limitation in Coverage notes.

Then include:

## Daily execution budget

Report:

- Status: FUNDED, AT RISK, or UNDERFUNDED
- Focus required
- Focus protected
- Realistic open capacity
- Gap or buffer
- Best focus plan

Definitions:

- FUNDED: The priorities have enough clearly matched protected time.
- AT RISK: The work may fit, but important time is fragmented or unprotected.
- UNDERFUNDED: Required work exceeds realistic remaining capacity.

Capacity math:

- Count all of my time for Do items.
- Count only my briefing, review, and approval time for delegated items.
- Count my participation time for Discuss items.
- Do not count a delegatee’s execution time as my focus time.
- Keep protected time separate from unreserved open capacity.
- Exclude elapsed time and unusably small gaps.
- Gap = required time minus protected time minus usable open capacity.
- If availability exceeds required time, report the result as a positive buffer.

Map each priority to an exact remaining block.

Link a matched event directly. For an unreserved focus window, link the Calendar day view for that exact date.

If the math does not work, state exactly what to:

- Defer
- Delegate
- Shorten
- Move
- Remove from today’s scope

Include links to both the affected work and the relevant calendar event or day.

Add these compact sections only when useful:

## Changed since the previous heartbeat

Report completed, newly blocked, reopened, delegated, or materially changed work. Do not turn completed items back into priorities.

## Tomorrow risk

Include only meaningful spillover, deadlines, or discussions that need preparation.

## Waiting on others

Include only items where another person is genuinely the next actor. Do not duplicate a Top priority.

## Coverage notes

Report unavailable connectors, rate limits, incomplete scopes, or link limitations. Continue with the other sources.

Every actionable item in these sections must retain its Do, Delegate, or Discuss label and include a direct link.
</output_format>

<notification_policy>
Notify me when:

- A new decision, approval, or response is needed
- Someone is blocked waiting on me
- A customer, revenue, security, or delivery issue appears
- A committed deadline is at risk
- A GitHub check or deployment becomes blocked
- The execution budget changes materially
- A deferred commitment is due to re-enter the queue
- A previously reported blocker is resolved and changes today’s plan

Stay quiet when no meaningful action or material change exists. A lack of new messages alone is not notification-worthy.
</notification_policy>

<verification>
Before returning each heartbeat, verify:

1. Every priority has exactly one ownership classification.
2. Every priority has a direct, relevant link.
3. Completed work has not been resurrected.
4. The latest thread or review establishes who acts next.
5. Calendar math uses only remaining time.
6. Protected time is clearly matched to the work.
7. Estimates count only my required participation.
8. The must-do list is limited to three to five items.
9. The focus plan actually fits the remaining calendar.
10. No external data or service was changed.
</verification>

<success_criteria>
The setup succeeds when:

- The first heartbeat is grounded in live connected data.
- Priorities are ranked across sources, not by source.
- Every action is classified as Do, Delegate, or Discuss.
- The executive receives a realistic, linked focus plan.
- Direct updates and completed work persist correctly across future runs.
- The recurring automation exists once at the requested cadence.
- Every recurring run remains strictly read-only.
</success_criteria>