debrief
Skill0 starsChanged 13 days agoApache-2.0View on GitHub
Capture a structured session summary and publish it to the OACP org-memory debrief store as an immutable record. Run at the end of any session.
30 other projects use a version of this.
Adopted by
Most recently taken up by
- srizzon/skillstheir own version, first seen Nov 8, 2026
- Works-HQ/ai-brain-starter-packtheir own version, first seen Nov 1, 2026
- piotrmechlinski/executive-braintheir own version, first seen Nov 1, 2026
- pedroromeroluna/peter-braintheir own version, first seen Nov 1, 2026
- bks-lab/open-bridgetheir own version, first seen Oct 30, 2026
- adamlinscott/claude-skillstheir own version, first seen Oct 30, 2026
Used with
Projects with it also use brief, review and 1 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
AnthropicSkillbrief
Generate contextual briefings for legal work — daily summary, topic research, or incident response. Use when starting your day and need a scan of legal-relevant items across email, calendar, and contracts, when researching a specific legal question across internal sources, or when a developing situation (data breach, litigation threat, regulatory inquiry) needs rapid context.
Also in 3 projects that use this
SentrySkillreview
Fixture review skill.
Also in 3 projects that use this
MicrosoftSkillhandoff
Compact the current conversation into a handoff document for another agent to pick up.
Also in 3 projects that use this
Other versions30 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 30
- suboss87/FDEOps★ 940same name
- spacedock-dev/spacedock★ 85same name
- bks-lab/open-bridge★ 13same name
- pedroromeroluna/peter-brain★ 9same name
- trydebrief/debrief-skills★ 4same name
- uttambharadwaj/kb-graph★ 4same name
- adamlinscott/claude-skills★ 3same name
- Works-HQ/ai-brain-starter-pack★ 3same name
- armenr/modelmux★ 2same name
- siemendev/release-process★ 2same name
20 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository17 other files it gives its agents.
- check-inboxSkill
- check-inboxSkill
- debriefSkill
- doctorSkill
- doctorSkill
- oacpSkill
- oacpSkill
- org-memory-synthesisSkill
- org-memory-synthesisSkill
- review-loop-authorSkill
- review-loop-authorSkill
- review-loop-reviewerSkill
- review-loop-reviewerSkill
- self-improveSkill
- self-improveSkill
- wrap-upSkill
- wrap-upSkill
The file
We split this skill into the rules it gives an agent
5 rules. 0 are common, 2 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 27 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 55
If the main repository has an .agent-memory.json binding, resolve its project and home before publication.
- Very specific: line 116
Write the body to a scratch file, then hand that file to the writer.
- Very specific: line 151
Leave {{DURATION}} literal.
- Distinctive: line 188
Stop here if the writer cannot be resolved.
- Distinctive: line 273
Keep each section to the facts a later reader needs.
“Common” is measured: kept by at least 6 in 10 of the 27 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/debrief — Codex Session Debrief
Publish a structured summary of this session to the central org-memory debrief store:
$MEMORY_HOME/org-memory/debriefs/<project>/<YYYY>/<MM>/<YYYYMMDD>-<agent>-<session>.mdMEMORY_HOME is the memory home resolved in step 1.
One session produces exactly one file, written once at session end and never
rewritten. The store is the full-fidelity session record; curated outcomes
reach other agents through agent-memory event write instead (see "Curation guard"
below).
Arguments
/debrief— generate the summary and publish it/debrief --dry-run— generate and display the summary without writing anything
The shared writer needs Python 3.9+ and the standard library. Binding status,
curated events, and store diagnostics use agent-memory-cli (0.1.1+ for
event write); report a missing capability before that operation. The writer
itself has no OACP CLI dependency.
Instructions
1. Identify the project
Resolve the project name with this fallback chain:
The
project_namefield in the workspace marker. The marker is gitignored and lives only at the repository's main root, so resolve that root first:ROOT=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)") python3 -c "import json,sys; print(json.load(open(sys.argv[1]))['project_name'])" "$ROOT/.oacp"basename "$ROOT"— notgit rev-parse --show-toplevel, which returns the linked-worktree directory when the session is running inside one- The working directory basename, when not in a git repo
The name must match the workspace directory under $OACP_HOME/projects/
byte-for-byte — the store path segment is case-sensitive. The writer checks
segment syntax, not workspace existence: confirm a missing workspace mapping
before publishing unless a repository memory binding establishes the project.
If the main repository has an .agent-memory.json binding, resolve its project
and home before publication. An ambient AGENT_MEMORY_HOME or OACP_HOME can
override that binding in the CLI; inspect it with
env -u AGENT_MEMORY_HOME -u OACP_HOME agent-memory status, or read the exact
binding file and resolve its home. The binding supplies the project without a
new confirmation. Do not infer this project from the task worktree's name.
Set MEMORY_HOME once to the binding's resolved home, otherwise to
${OACP_HOME:-$HOME/oacp}. Use this same value for ruling lookup, publication,
event curation, optional initialization, and doctor. The bound home must be
writable before publication; retain the draft if it is unavailable.
2. Collect the session identity
The writer needs five identity values. Gather them before composing the body:
--project— from step 1--agent codex— this runtime's registered project-agent name--runtime codex— the runtime family writing the record--session— a short stable session id: 1-32 lowercase letters and digits, never hyphens. Use the first 8 characters of the harness session UUID with hyphens stripped when Codex exposes it. Otherwise generate one 8-character lowercase hexadecimal id once for this run and retain it for every retry. This is what distinguishes multiple sessions by the same agent on the same day. If the session keeps working after a debrief has already landed, use the derived continuation id described in step 8 instead.--started-utc/--ended-utc— session bounds as ISO 8601 UTC with whole seconds, e.g.2026-08-25T20:04:11Z. Take these from the clock, never from an estimate;ended_utcmust not precedestarted_utc, and the date ofstarted_utcdetermines the filename and directory segments.
UTC, not local time. The store path and the
<YYYYMMDD>filename prefix are derived fromstarted_utcin UTC. On a machine whose OS timezone is ahead of or behind UTC, a locally-stamped date lands the record in the wrong month directory. Generate both stamps withdate -u +%Y-%m-%dT%H:%M:%SZ.
3. Review the session
Gather what actually happened:
- Accomplishments — what was built, fixed, reviewed, or decided
- Decisions — key choices and their rationale
- Issues — tickets created, closed, or updated. If other agents
collaborated (parallel runs, review loops), include their closures and PR
activity; local
git logalone misses them. - Files changed —
git log --name-only --format= --since="<started_utc>"plusgit status --short - Git activity —
git log --oneline --since="<started_utc>", in each repo touched for cross-project sessions - Next actions — carry-forward items, open threads, and blockers that
remain live. Before restating a plan, check today's entries in
$MEMORY_HOME/org-memory/events/and$MEMORY_HOME/org-memory/decisions.mdfor a ruling that already supersedes it; the published record is immutable.
Your conversation context is the primary source. Git activity supplements it; it does not replace what you remember of the session.
4. Compose the body
Write the body to a scratch file, then hand that file to the writer. The body
is everything after the frontmatter — the writer generates the frontmatter
itself, so do not write a --- block at the top.
# Session Summary: <project> — YYYY-MM-DD
**Runtime**: codex
**Duration**: ~{{DURATION}} minutes
## What Changed
- bullet points of accomplishments
## Decisions Made
- key decisions with rationale
## Tickets / Issues
- created/closed/updated references (or "None")
## Files Modified
- key files changed
## Next Actions
- [ ] carry-forward items
## Notes
- anything notable (omit the section if nothing)Leave {{DURATION}} literal. The shared writer fills it from the start/end
stamps, rounding partial minutes up before hashing. Other placeholders remain
unchanged.
Use a file-writing tool, never a shell heredoc. Shell expansion corrupts debrief bodies — backticks in a double-quoted heredoc execute as command substitution, and the mangling is silent. Write the body with your runtime's file-writing tool and pass the path.
5. Resolve the shared writer
The catalog has one writer at skills/debrief/scripts/write_debrief.py; the
Codex wrapper does not carry a fork. Resolve the writer from the loaded skill
directory, never from the current project's working directory.
# Prefer an installed package, where SKILL.md and scripts/ share one directory.
SKILL_DIR="<directory containing the loaded debrief SKILL.md>"
# In a catalog checkout, codex/SKILL.md sits one level below the shared writer.
if [ ! -f "$SKILL_DIR/scripts/write_debrief.py" ] && \
[ -f "$SKILL_DIR/../scripts/write_debrief.py" ]; then
SKILL_DIR="$(cd "$SKILL_DIR/.." && pwd)"
fi
# Try the common project and global Codex install locations.
if [ ! -f "$SKILL_DIR/scripts/write_debrief.py" ]; then
for d in "$PWD/.agents/skills/debrief" \
"${CODEX_HOME:-$HOME/.codex}/skills/debrief"; do
[ -f "$d/scripts/write_debrief.py" ] && SKILL_DIR="$d" && break
done
fi
test -f "$SKILL_DIR/scripts/write_debrief.py" \
|| { echo "debrief writer not found; re-install the skill" >&2; exit 1; }Stop here if the writer cannot be resolved. Do not hand-compose a record into the store — the frontmatter, the content hash, and the publication primitive are the writer's contract, and a hand-written file satisfies none of them.
6. Dry run
/debrief --dry-run stops here. Run the step 7 command with --dry-run
appended: the writer validates the identity and body, composes the exact
record it would publish, prints it, and touches nothing — no directories
created, no files written. Status is reported as dry-run.
Show the composed record and the target path, then stop. Do not continue to step 7, and do not report the session as debriefed.
7. Publish
python3 "$SKILL_DIR/scripts/write_debrief.py" \
--project "<project>" \
--agent codex \
--runtime codex \
--session "<session>" \
--started-utc "<started>" \
--ended-utc "<ended>" \
--body-file "<path-to-body>" \
--oacp-dir "${MEMORY_HOME:?resolve it in step 1}" \
--jsonThe writer validates the schema, fills {{DURATION}}, computes the content
hash, stages privately, publishes with an atomic no-replace link, and reads back to
confirm. Exit codes: 0 published (or an idempotent re-publish of a
byte-identical record), 1 validation error, 2 publication failure.
Publication is failure-atomic — the canonical path only ever holds a complete,
verified record. On any failure the path stays absent; at worst a private
.stage.* file remains, and a later successful publication of the same record
sweeps it. The writer only ever publishes an inode it created itself, so a
.stage.* file that appears from anywhere else is never adopted —
agent-memory doctor --home "${MEMORY_HOME:?resolve it in step 1}" reports it
and it is safe to delete by hand.
8. Handle a collision
--session collisions are the one failure that needs a judgment call:
- Byte-identical record already published → reported as
idempotent. Nothing to do; the run already landed. - Different record at the same path → hard failure. A published debrief is never replaced. Re-publish under a new session identifier; the existing record stays as it is.
Corrections and follow-ups are new artifacts too — a later debrief, or an event referencing the original — never an edit to a landed file.
A session that keeps working after its own debrief. Publish a continuation segment under the same project, agent, and runtime: suffix the session id with the segment number (
b31ffdea→b31ffdea2, thenb31ffdea3), setstarted_utcto the previous record'sended_utc, and setended_utcto now. The suffixed form stays inside the 1-32 lowercase alphanumeric grammar. Open the body by naming the parent record and the span it covers; never backfill the landed record or skip the continuation.
9. Confirm
Print the canonical path, the status, and the content hash from the writer's JSON output.
Curation guard
Raw debriefs never enter recent.md or events/. Only curated folds do. If
the session produced an outcome other agents or projects need, write it as a
separate event:
agent-memory event write --home "${MEMORY_HOME:?resolve it in step 1}" \
--type decision --project "<project>" --agent codex --slug "<slug>" \
--source-ref "<YYYYMMDD>-codex-<session>" --body-file "<path-to-event-body>"Set the event's source_ref to the debrief filename stem
(<YYYYMMDD>-<agent>-<session>) so the two can be reconciled later.
Notes
- Keep each section to the facts a later reader needs. If the session was trivial, say so rather than padding.
- Facts over narrative: the store is read by curation tooling, not for prose.
- Debrief files are never auto-loaded at session start; they are permanent history, not context.
- The store does not have to exist first — the writer provisions its own
tree.
agent-memory org init --home "${MEMORY_HOME:?resolve it in step 1}"is optional setup. agent-memory doctor --home "${MEMORY_HOME:?resolve it in step 1}"validates store setup — layout, staging artifacts, symlinks. It never opens debrief files; schema and hash correctness are the writer's contract, verified at publication.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

