summarize
Skill2 starsChanged 52 days agoMITView on GitHub
Use when generating structured session execution summaries, documenting root causes, evidence tables, or transferring context between agent sessions. Don't use for human-facing documentation (use technical-writing) or pull request bodies (use pull-request).
93 other projects use a version of this.
Adopted by
Most recently taken up by
- CloudChef/atlasclaw-providerstheir own version, first seen Nov 8, 2026
- domengabrovsek/agent-configtheir own version, first seen Nov 8, 2026
- domengabrovsek/claudetheir own version, first seen Nov 8, 2026
- sergeiwallace/skillstheir own version, first seen Nov 8, 2026
- mahsumaktas/agent-evolution-kittheir own version, first seen Nov 8, 2026
- insight68/Skillstheir own version, first seen Nov 8, 2026
Used with
Projects with it also use openclaw-performance, plugin-sdk-impact and 10 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.
clawdbotSkillopenclaw-performance
Performance work in OpenClaw: a slow or heavy flow (latency, CPU, memory, SQL, RPC, renders), writing or reviewing a perf PR, or adding a cache. Count the work, delete waste first, cache last.
Also in 7 projects that use this
clawdbotSkillplugin-sdk-impact
Count Plugin SDK consumers across live ClawHub releases and bundled OpenClaw plugins before deprecation, removal, or behavior changes; supports public release-date filters.
Also in 7 projects that use this
AtomicBot-aiSkilltaskflow-inbox-triage
Also in 6 projects that use this
hkyutongSkillnode-connect
Diagnose OpenClaw node connection and pairing failures for Android, iOS, and macOS companion apps. Use when QR/setup code/manual connect fails, local Wi-Fi works but VPS/tailnet does not, or errors mention pairing required, unauthorized, bootstrap token invalid or expired, gateway.bind, gateway.remote.url, Tailscale, or plugins.entries.device-pair.config.publicUrl.
Also in 18 projects that use this
molt-botSkilldiscord-e2e
Test Discord with Convex-leased QA bots: check credentials without a Gateway, exercise owned messages, or prove OpenClaw replies, files, threads, reactions, streaming, and typing. Distinguish API and Gateway evidence from manual user interactions.
Also in 10 projects that use this
molt-botSkillopenclaw-repair-sweep
Run scoped OpenClaw issue/PR repair campaigns: coordinate workers, prove root causes, and land or close verified work under the requested authority.
Also in 10 projects that use this
- +2 more from molt-bot
Other versions93 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 93
- moltbot/clawdbot★ 394ksame name
- steipete/warelay★ 394ksame name
- steipete/clawdis★ 394ksame name
- moltbot/moltbot★ 394ksame name
- clawdbot/clawdbot★ 394ksame name
- openclaw/openclaw★ 394ksame name
- molt-bot/clawdbot★ 391ksame name
- spinabot/brigade★ 11ksame name
- steipete/summarize★ 6.8ksame name
- the-open-agent/openagent★ 5.7ksame name
83 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 repository35 other files it gives its agents.
- agent-planningSkill
- brainstormingSkill
- codebase-designSkill
- code-reviewSkill
- conventional-commitSkill
- copy-web-designSkill
- executing-plansSkill
- frontend-designSkill
- i18nSkill
- laravelSkill
- prototypeSkill
- pull-requestSkill
- reactSkill
- recursive-researchSkill
- reflect-to-skillSkill
- review-a-skillSkill
- s13nSkill
- schema-migrationSkill
- security-auditSkill
- skill-testingSkill
- systematic-debuggingSkill
- t3-operational-guardrailSkill
- technical-writingSkill
- testing-patternsSkill
- ui-motionSkill
- ui-ux-reviewSkill
- unslopSkill
- upsert-codebase-docsSkill
- verification-before-completionSkill
- vibe-wiseSkill
- web-advisor-promptSkill
- wizardSkill
- workspace-onboardingSkill
- writing-for-agentsSkill
- writing-plansSkill
The file
We split this skill into the rules it gives an agent
6 rules. 0 are common, 5 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 81 edited versions we read keep these.
5
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 11
Write-Target Boundary. Summarization operates strictly in a read-only and reporting capacity.
- Distinctive: line 37
If the session produced no code modifications, state this directly.
- Distinctive: line 41
Follow these four steps in sequence:
- Distinctive: line 45
Run status, diff, and log commands to inspect the exact working tree changes and recorded command runs from the session.
- Distinctive: line 63
When operating in Incident and handoff mode, package system state, branch pointers, entry points, and root-cause details into …
- Distinctive: line 85
Document every encounter with bugs or failures:
“Common” is measured: kept by at least 6 in 10 of the 81 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
Summarize
Produce an accurate, structured record of session execution. Write for two consumers: the user who verifies changes and a subsequent agent session that continues the work without rediscovery.
<HARD-GATE>
Write-Target Boundary. Summarization operates strictly in a read-only and reporting capacity. Write only to `.agents/state/summarize/` or user-facing execution reports. Never edit application code, alter configuration files, or execute mutating commands while creating summaries.
</HARD-GATE>Modes
Declare the active operating mode before executing any steps:
- Summary mode (default): Distill session activities, modifications, and findings into structured evidence tables. Run Steps 1 through 3 sequentially and emit
.agents/state/summarize/session-summary.md. - Incident and handoff mode: Package system state, active variables, and failure timelines for incident audits or agent handoffs. Run Steps 1 through 4 sequentially and emit
.agents/state/summarize/incident.jsonalongside the summary document.
Integrity rule
Report exclusively what occurred during the current session:
- Inspect diffs directly; never claim a file changed without inspecting diffs.
- Observe clean terminal output directly; never state a test passed without observing clean terminal output.
- Record verified facts and actual results; never present plans or proposals as completed modifications.
- Record failures, discarded attempts, and dead ends so future sessions do not repeat them.
- Flag unverified paths explicitly instead of assuming success.
Inspect actual repository and working tree state before drafting:
git status --short
git diff --stat
git log --oneline -n 5If the session produced no code modifications, state this directly.
Workflow
Follow these four steps in sequence:
Step 1. State reconnaissance and evidence extraction
Run status, diff, and log commands to inspect the exact working tree changes and recorded command runs from the session.
Completion criterion. .agents/state/summarize/state-inventory.json exists on disk with modified_files, created_files, deleted_files, and executed_commands.
Step 2. Synthesize actions and root causes
Draft overview, chronological actions table, and root-cause breakdowns citing concrete file paths and test outputs.
Completion criterion. Chronological actions and resolved issues drafted with zero unverified claims and zero omitted failures.
Step 3. Tabulate verification and gaps
Construct the verification evidence table and document known gaps, unverified edge cases, and next steps plainly.
Completion criterion. .agents/state/summarize/session-summary.md exists on disk containing the verification evidence table with exact exit codes and unverified items explicitly cataloged.
Step 4. Context handoff assembly
When operating in Incident and handoff mode, package system state, branch pointers, entry points, and root-cause details into machine-readable handoff artifacts.
Completion criterion. .agents/state/summarize/incident.json exists on disk recording incident_trigger, root_cause, preventive_rule, and handoff_block.
Execution summary structure
Render sections in sequence. Omit a section only when empty, stating the omission explicitly:
1. Overview
Two to three sentences stating session purpose, final status, and present state. The first sentence must answer whether the objective was met.
2. Actions taken
List chronological operations with concrete evidence in a table:
| # | Action | Target | Result |
| 1 | Read | src/auth/session.ts | Located token expiration logic |
| 2 | Edit | src/auth/session.ts | Added expiry guard before refresh call |
| 3 | Run | npm test -- auth | 14 passed, 0 failed |
| 4 | Run | npx tsc --noEmit | Clean run with 0 errors |
3. Issues and root causes
Document every encounter with bugs or failures:
- Symptom: Observed error text and stack traces.
- Root cause: Underlying system defect and mechanism.
- Evidence: File path, line number, or command output proving the root cause.
- Fix: Architectural modification addressing the root cause.
- Verification: Command executed to validate the fix.
4. Verification evidence table
Record verification commands with exact output:
| Check | Command | Result |
| Type check | npx tsc --noEmit | Passed. 0 errors |
| Test suite | npm test | Passed. 42 passed, 0 failed |
| Linter | npm run lint | Passed. Clean output |
| Build | npm run build | Passed. Output generated in dist/ |
5. Known gaps and unverified items
State gaps without softening: untested code paths, unverified deployment steps, or open questions requiring decisions.
6. Actionable next steps
Numbered list of concrete next tasks.
7. Agent handoff block
Append this structured block for subsequent agents:
## Context handoff
**State** Completed feature implementation, pending PR creation.
**Branch** `feat/session-refresh`
**Entry point** `src/auth/session.ts`
**Verification command** `npm test && npm run build`
**Open tasks** Caller migration documented in next steps.
**Caution** Do not revert schema migration timestamp constraint.Anti-patterns
| ID | Title | Pattern description | Why it fails | Concrete fix |
| SUM-1 | Ungrounded claims | Asserts tests passed without running the verification command | Subsequent agents inherit broken state | Execute command and record raw exit code |
| SUM-2 | Narrative walls | Packs actions and diffs into continuous narrative paragraphs | Handoff details get lost in conversational text | Tabulate actions and verification in tables |
| SUM-3 | Emotional spin | Phrases outcomes as "We made amazing progress on the bug" | Masks unresolved risks and blocker items | Use objective metrics and explicit gap lists |
| SUM-4 | Unanchored paths | References modified files without line numbers or paths | Readers cannot inspect or verify changes | Format all modified paths as markdown links |
| SUM-5 | Concealed failure | Omits failed attempts or intermediate errors from report | Future agents repeat the identical failing path | Document failed attempts and underlying causes |
| SUM-6 | Hollow handoff | Transfers context without exact verification commands | Incoming agent wastes turns rediscovering state | Include exact entry point and verification commands |
Boundary isolation
Summarization operates strictly in an analytical and reporting capacity. Never edit application code, alter configuration files, or execute mutating commands while creating summaries.
Quick audit checklist
Audit summaries against this table before finalizing:
| Check | Passing condition |
| Verification evidence | Execute verification commands and record exact outputs |
| Failure disclosure | Record failures, discarded paths, and root causes plainly |
| Completion claims | Record verified facts only, never present plans as modifications |
| Status structure | Use structured tables with command, path, and result columns |
| Directness | Present findings directly without filler or introductory fluff |
| Anti-patterns | Anti-pattern table adheres to 5-column schema with stable IDs |
| File anchoring | Cite exact repository file paths and line numbers |
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.

