Briefing source triangulation
Skill Ed3Design/ed3design-skill-bundles/planning-disciplines/skills/briefing-source-triangulation
Claude Code skill bundles for software engineering: 56 skills + 5 Python tools + 6 hooks + 4 sub-agents across 6 thematic plugins (token-savers, code-quality, planning-disciplines, async-forensik, schema-discipline, skill-system-meta). Empirically TDD-validated patterns, MIT licensed.
npx -y skills add Ed3Design/ed3design-skill-bundles --skill briefing-source-triangulationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when building a status briefing (morning standup, weekly review, "where was ", session-start briefing) that reads from multiple persistence sources (Daily Note + `.remember/today-*.md` + `.remember/recent.md` + git-log + file mtimes). Without conscious source-priority, briefings can claim items as "open" that were actually completed (e.g. email sent, meeting held, file shipped) because secondary sources lag or summarise. Trigger on phrases like "morning briefing", "daily standup", "where was ", "what was still open", "session-start briefing", "weekly review", "monthly close", "what's new since yesterday", "day overview", or any skill invocation that consumes `.remember/today-*.md` or `recent.md` as status input. Do NOT load when only consuming a single source (just reading the Daily Note for context), when writing INTO `. remember/` files (those are plugin-owned, not briefing input), or for code-only context-gathering (use git-log directly)
SKILL.md
4.4 KB, as published. Nobody here has run it
briefing-source-triangulation
The source hierarchy
When building any status briefing, sources rank in this priority order:
| Rank | Source | What it is | Trust for "did X happen?" |
|---|---|---|---|
| 1 | Daily Note Daily Notes/YYYY-MM-DD.md | Human/plugin-curated, intent-driven, structured blocks | High for documented activity. Silent on external acts (sends, calls, meetings). |
| 2 | Git log in code-repos | Atomic commits with timestamps | High for code changes. Silent on everything else. |
| 3 | File mtimes on new artifacts | Filesystem ground truth | High for "when was this written". Silent on intent. |
| 4 | User cross-check for external acts | E-mail sent? Meeting held? Phone call done? | Only the user knows. Ask, don't infer. |
| 5 | .remember/today-*.md, recent.md, archive.md | Plugin-LLM-summarised secondary | Plausibility-check only. Do NOT treat as primary. |
Why .remember/ is rank 5 (not rank 1)
The remember-plugin writes via post-tool/save-session hooks:
## HH:MM | branchsection markers are plugin-generated (likely session-start), not user-input times- Content is LLM-summarised (Haiku-cost signature visible in
.remember/logs/memory-YYYY-MM-DD.log) - Sessions with <3 human messages are silently skipped (look for
human msgs < 3, skipin the log) - Cross-day consolidation sessions can legitimately produce yesterday-themed entries under today's HH:MM marker (when the user explicitly asks for a "wrap up the open session" pass)
None of these are bugs. They are design choices that mean .remember/today-*.md cannot be the ground-truth source for "what happened today".
The triangulation procedure
Before writing any briefing:
- Read the Daily Note first. Skim blocks. This is the canonical chronicle.
- Check git log for repos relevant to the briefing scope:
git log --since="midnight" --pretty=format:"%h %ai %s". - For external acts the Daily Note mentions as "ready" / "ready to send" / "pending review" / "prepared" → ask the user whether they completed it. Status verbs like "ready to send" are claims of preparedness, not completion.
- Use
.remember/today-*.mdonly as plausibility check. If something there contradicts the Daily Note, trust the Daily Note. If something appears under an HH:MM marker, don't assume the user typed at that time. - Build the briefing. Carry-Over items inherit the source rank — if the only evidence for "X is open" comes from rank 5, mark it as "appears open, confirm with user".
The lesson (self-correction)
- Daily Note said "ZIP ready to send" (rank 1, but a preparedness verb)
.remember/today-*.mdhad a stale block (rank 5)- No source said "email actually sent"
- The briefing claimed "email send still open" → wrong, the email had been sent hours earlier
- User had to correct it
The miss: the briefing should have asked the user "did the send happen?" instead of inferring "ready to send = still pending". The fix is operational: any Carry-Over claim about an external act gets a user-cross-check before it appears in the briefing.
Future refinements
These are deliberately non-blocking. The pattern works as documented; these would tighten it further:
- A question template for external acts ("Did you send/meet/deploy X? When?")
- A callable triangulation helper that emits a diff between Daily Note claims and
.remember/today-*.mdsummaries - A briefing self-audit checklist (every claim has a source-rank annotation)