In the first part of this post, I wrote about my system for gathering and organizing information. You can find it here.
Information gathering is one of the fundamental activities of a manager. Whether you work in tech or another industry, if you lead people and are responsible for an outcome, you need a system for remembering what matters, managing your tasks, and quickly finding the context you need to make decisions.
Before AI, this largely meant synthesizing information yourself. You might sift through information, decide what was worth keeping, and capture it in your knowledge repository so you could find and reference it later.
LLMs make it much easier to digest large amounts of information, summarise, or extract what is relevant without requiring you to manually curate everything.
My workflow for doing this is built around three main skills. They help my AI agent understand what matters to me, what information it should pay attention to, and how to turn that information into a list I read before starting my day.
projects.md
people.md
daily.md
Projects.md
Projects.md contains all the information and context an agent needs to understand the key projects I’m involved in and what actually concerns me.
AI agent combs through Slack, Google Drive, GitHub, experimentation tools, email, and other sources to gather information about the projects listed or conversations related to them.
The important part is that I’m not asking the agent to look through everything and tell me what happened but instead providing it context about what I care about, so it has a way to distinguish signal from noise.
People.md
people.md contains the context an agent needs to understand about the people I primarily work with, support their career growth, or regularly have touch points with.
These can be people who are working on something I care about or whose work impacts what I care about. We would often have meetings, and the notes from those meetings become input for AI. Often, there might be an action item, follow-up, or something I need to remember from the meeting notes that the agent brings back to my attention.
This skill is particularly useful for giving the agent context about previous discussions and unchecked action items. Instead of relying on my memory of what I discussed with someone weeks ago, the agent can consult the history and bring back to mind relevant points or any unchecked follow-up items.
Daily.md
Daily.md serves as your central daily briefing, consolidating context from projects.md and people.md to map out what matters to me. The AI agent scans GitHub, Slack, Google Docs, meeting transcripts, and experiment logs for significant updates, links them to the relevant projects and people, and generates a clear, digestible summary.
Daily.md looks like this:
---
name: daily-manager-review
description: Prepare [Manager Name]'s daily manager review by identifying meaningful changes, risks, decisions, and support needs that require attention.
---
# Purpose
Prepare a concise, action-oriented daily review for [Manager Name].
Don't summarize everything that happened but identify:
- What changed
- Why it is important
- What requires [Manager Name]'s attention
- What [Manager Name] may need to do next
# Time window
Search only the requested time window.
If no date is specified for a daily review:
- Use yesterday and today.
- If yesterday was not a workday, use the most recent workday and today.
- Do not search older material unless required to understand a newly discovered item.
When older context is required, clearly distinguish historical context from new information.
# Sources
Use:
- Slack
- Google Drive
- Email
- 1:1 documents
- Project documents
- Experimentation and metrics sources
- Other connected work systems when relevant
Use `direct.md` to identify relevant people and use `projects.md` to identify projects and workstreams in scope.
Do not use activity in Slack, GitHub, email, or documents to infer reporting relationships or project ownership.
# Core principle
Optimize for signal, not coverage. Do not report something merely because it happened. A candidate item should generally satisfy at least one of:
- Requires a decision
- Requires approval
- Is blocking important work
- Represents a meaningful risk
- Indicates a regression or incident
- Requires cross-team intervention
- Requires support for a direct report
- Represents meaningful experiment or metric movement
- Creates an important staffing or delivery concern
- Contains an explicit request for [Manager Name]
Routine progress should normally be omitted.
# Signal evaluation
For every candidate signal, determine:
1. Is it new?
2. Is it within [Manager Name]'s scope?
3. Why does it matter?
4. Does it require attention?
5. What evidence supports it?
6. What action, if any, is required?
Discard low-value or purely informational items.
# Priority
Classify important signals as:
- `P0` — immediate attention required
- `P1` — important action or decision required
- `P2` — meaningful development or emerging risk
- `P3` — informational only
The daily review should primarily contain P0 and P1 items.
Include P2 when it provides useful context.
Normally omit P3 items.
# Evidence
Every substantive finding must have a source.
Prefer direct evidence over inference.
When reporting a risk, identify the evidence that supports it.
Do not convert uncertainty into fact.
For experiments specifically:
Do not claim a regression unless there is evidence such as:
- Negative metric movement
- Negative trend
- Red or yellow status
- Sample Mismatch Ratio
- Rollout pause
- Reversion
- Incident-related anomaly
- Explicit concern from a relevant owner
If a source mentions a concerning experiment readout but the underlying metrics are unavailable, report the concern as a reported concern rather than as an established regression.
# Search workflow
## 1. Load scope
Read:
- Direct.md
- Project.md
Identify relevant names, aliases, and projects.
## 2. Search for high-value signals
Search the requested time window for:
- blockers
- incidents
- regressions
- launches
- rollouts
- approvals
- escalations
- decisions
- staffing
- performance concerns
- experiment readouts
- metric changes
- tracking problems
- cross-team requests
- explicit asks for [Manager Name]
Use project and direct-report context to narrow searches where possible.
## 3. Search communication sources
Search Slack and email for relevant signals.
Before first use of `email_search_v2`, run `help(email_search_v2)`.
Do not search broadly without a relevant signal or scope anchor.
## 4. Verify
Read only the documents, threads, or messages necessary to verify important findings.
Prefer primary sources.
Do not rely on search-result snippets when the underlying source can be inspected.
## 5. Deduplicate
The same event may appear in:
- Slack
- email
- Drive
- project documents
- experiment tools
Combine these into one finding.
Prefer the strongest or most recent source.
Do not report the same event multiple times.
## 6. Identify actions
For each important finding, determine whether [Manager Name] needs to:
- Decide
- Approve
- Unblock
- Investigate
- Follow up
- Escalate
- Support a direct report
- Monitor
If no action is required, consider whether the information belongs in the review at all.
# Direct-report review
Prepare a 1:1 section only when there is meaningful new context.
Look for:
- Current project or experiment work
- Wins or shipped progress
- Blockers
- Risks
- Decisions
- Explicit asks
- Follow-ups
- Support needs
- Staffing or performance concerns
Do not produce a detailed activity report for each person.
If there is no meaningful new context for a direct report, omit them rather than filling the section with routine information.
# Experiments and metrics
Look specifically for meaningful signals related to:
- [Manager Name]'s experiments
- Direct-report experiments
- Projects in scope
- Internal experimentation tools
- Topline metrics
- Funnel metrics
- Installs
- DAU
- CTR
- Retention
- Experiment health
- Tracking integrity
Flag:
- Meaningful negative movement
- Rollout pauses
- Reversions
- Experiment exposure issues
- Missing or suspect tracking
- Incident-related anomalies
- Explicit requests for review
Do not report normal metric movement unless it materially changes a decision or project outcome.
# Output
Produce a concise Logseq-ready Markdown note.
If a writable Logseq repository or file path is available, write the note there.
Otherwise, output Markdown ready to paste into Logseq.
Use:
- `[[YYYY-MM-DD]]`
- `[[Project Name]]`
- `[[Person Name]]`
- Plain Logseq `TODO` markers
- Links to source material
# Output structure
# [[YYYY-MM-DD]]
## Important TODOs
- TODO [P0/P1 action] — [[Project]] — reason — [source]
## Experiments / Metrics Watch
- [[Experiment]] — signal, evidence, impact — [source]
## Project Updates
- [[Project]] — meaningful change and why it matters — [source]
## 1:1 Prep
### [[Report Name]]
- Current context
- Blockers / risks
- Support or decision needed
- Follow-up
# Quality bar
Before producing the final review:
- Remove routine updates.
- Remove duplicate findings.
- Remove unsupported claims.
- Remove information that does not affect [Manager Name].
- Prefer actions over descriptions.
- Prefer evidence over interpretation.
- Prefer concise summaries over exhaustive reporting.
The final review should answer:
> **"What changed since I last looked, what matters, and what do I need to do about it?"**Setup
I created a scheduled task in Codex that runs at 8:00 AM every workday to generate a briefing.
I hope this helps you setup yours.