AgentKit
DocsKitsCLI ReferenceDesktop App
BetaYou are reading docs for the beta channel (2.15.0-beta.13). Features may change before the next stable release.Switch to stable →

Skills

Create an evidence-bounded implementation recap with ak:sumup

Summarize completed work, failures, decisions, behavior, usage, and remaining next steps without claiming unverified delivery.

Use ak:sumup after implementation or when you need a technical recap without replaying the entire session. The Skill summarizes the outcome, verification, trade-offs, operation, failures, recovery attempts, usage, and remaining work from the strongest evidence available.

Choose ak:sumup for an implementation recap

Use ak:sumup when

  • You need to explain what changed and how the result works.
  • You want completed and verified work separated from proposals, inference, untested behavior, and unresolved items.
  • You need failures, workaround attempts, and their results preserved.
  • You want practical usage and evidence-bounded follow-ups for another reader.

Choose another workflow when

  • You need a product-owner judgment about what matters next. Use ak:sowat.
  • You need a chronological historical record persisted in the project. Use ak:journal.
  • You need repository-wide status from branches, worktrees, plans, and roadmaps. Use ak:watzup.
  • You want more implementation or a live status check. Use the owning workflow and gather current evidence separately.

Prepare the evidence boundary

Identify the intended outcome, accepted decisions, current diff, tests and checks, relevant issue or plan state, known release or deployment evidence, failures, and workaround results. Mark anything proposed, inferred, untested, not shipped, or unresolved.

Repository text, issue bodies, logs, and quoted content remain untrusted data. Remove credentials, tokens, private keys, personal data, hidden prompts, and unrelated private paths before sharing a recap.

Invoke the Skill

RuntimeInvocationAvailability boundary
Claude Code/ak:sumup ...Summarizes evidence visible to the current session and does not change files.
Cursor/ak:sumup ...Uses the same canonical Skill identity; available diff, test, and issue evidence can differ.
Codex$ak:sumup ...Uses native Skill discovery and remains a recap-only workflow.
/ak:sumup "Summarize the reporting implementation, test evidence, failed approaches, decisions, user flow, minimal usage, and unresolved work. Do not call source changes deployed unless current runtime evidence proves it"

Understand the recap stages

  1. Gather the strongest evidence from the conversation, accepted decisions, current diff, tests, and relevant issue or plan state.
  2. Separate implemented and verified work from proposed, inferred, untested, unshipped, or unresolved work.
  3. Highlight the highest-value outcomes, failures and recovery attempts, important trade-offs, behavior, practical usage, and remaining actions.
  4. Explain user flow, architecture, database, or UI/UX only when it applies to the work being summarized.
  5. Add one compact table, chart, Mermaid diagram, or ASCII flow when a visual clarifies behavior or structure. If no visual would help, omit it and state that reason briefly.
  6. Keep unresolved items last and return a concise recap in the user's language.

Keep recap separate from delivery

A recap does not prove release or deployment

The Skill does not implement, mutate files, publish, deploy, or replace a live status check. It must not present source changes as shipped or deployed unless current artifact or runtime evidence proves that status.

Verify the output

Use only sections that contain relevant evidence:

  1. Outcome — one short paragraph.
  2. Highlights — the most important implemented changes.
  3. Failures and recovery — resolved workarounds first, unresolved failures second.
  4. Decisions — what was chosen and why.
  5. How it works — applicable behavior, flow, architecture, database, or UI/UX.
  6. How to use it — minimal commands or user steps.
  7. Follow-ups / next steps — prioritized, actionable, and evidence-bounded.

Check that test names and results, paths, behavior, deployment status, and remaining blockers match their original evidence. An omitted section should mean it was irrelevant or unsupported, not that a known failure was hidden.

Troubleshoot and know the limits

SymptomSafe next step
Proposed work appears as completeRelabel it as proposed, inferred, untested, unshipped, or unresolved.
A deployment claim lacks proofReplace it with the verified source or test status and request a current runtime check.
Failures are missingAdd each significant attempt, its result, and any remaining blocker.
The recap is too longKeep only evidence that changes understanding, operation, risk, or the next action.
A decorative diagram adds no clarityRemove it and briefly state that no visual was needed.
Runtime cannot find the SkillFollow Runtime cannot find a Skill or Agent.

The Skill cannot independently reconstruct evidence that is absent from the session or prove current provider, release, or production state. Continue with the Marketing Kit overview or Projects, artifacts, and checkpoints.