agentleFS
dafaalzdafaalz/agent-skills/skills/summarize/SKILL.md

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

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.
  • clawdbotSkill

    openclaw-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

  • clawdbotSkill

    plugin-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-aiSkill

    taskflow-inbox-triage

    Also in 6 projects that use this

  • hkyutongSkill

    node-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-botSkill

    discord-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-botSkill

    openclaw-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

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
  1. Very specific:

    Write-Target Boundary. Summarization operates strictly in a read-only and reporting capacity.

    line 11
  2. Distinctive:

    If the session produced no code modifications, state this directly.

    line 37
  3. Distinctive:

    Follow these four steps in sequence:

    line 41
  4. Distinctive:

    Run status, diff, and log commands to inspect the exact working tree changes and recorded command runs from the session.

    line 45
  5. Distinctive:

    When operating in Incident and handoff mode, package system state, branch pointers, entry points, and root-cause details into …

    line 63
  6. Distinctive:

    Document every encounter with bugs or failures:

    line 85

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.json alongside 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 5

If 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:

#ActionTargetResult
1Readsrc/auth/session.tsLocated token expiration logic
2Editsrc/auth/session.tsAdded expiry guard before refresh call
3Runnpm test -- auth14 passed, 0 failed
4Runnpx tsc --noEmitClean 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:

CheckCommandResult
Type checknpx tsc --noEmitPassed. 0 errors
Test suitenpm testPassed. 42 passed, 0 failed
Linternpm run lintPassed. Clean output
Buildnpm run buildPassed. 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

IDTitlePattern descriptionWhy it failsConcrete fix
SUM-1Ungrounded claimsAsserts tests passed without running the verification commandSubsequent agents inherit broken stateExecute command and record raw exit code
SUM-2Narrative wallsPacks actions and diffs into continuous narrative paragraphsHandoff details get lost in conversational textTabulate actions and verification in tables
SUM-3Emotional spinPhrases outcomes as "We made amazing progress on the bug"Masks unresolved risks and blocker itemsUse objective metrics and explicit gap lists
SUM-4Unanchored pathsReferences modified files without line numbers or pathsReaders cannot inspect or verify changesFormat all modified paths as markdown links
SUM-5Concealed failureOmits failed attempts or intermediate errors from reportFuture agents repeat the identical failing pathDocument failed attempts and underlying causes
SUM-6Hollow handoffTransfers context without exact verification commandsIncoming agent wastes turns rediscovering stateInclude 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:

CheckPassing condition
Verification evidenceExecute verification commands and record exact outputs
Failure disclosureRecord failures, discarded paths, and root causes plainly
Completion claimsRecord verified facts only, never present plans as modifications
Status structureUse structured tables with command, path, and result columns
DirectnessPresent findings directly without filler or introductory fluff
Anti-patternsAnti-pattern table adheres to 5-column schema with stable IDs
File anchoringCite exact repository file paths and line numbers

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.