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
| Runtime | Invocation | Availability 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"/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"$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
- Gather the strongest evidence from the conversation, accepted decisions, current diff, tests, and relevant issue or plan state.
- Separate implemented and verified work from proposed, inferred, untested, unshipped, or unresolved work.
- Highlight the highest-value outcomes, failures and recovery attempts, important trade-offs, behavior, practical usage, and remaining actions.
- Explain user flow, architecture, database, or UI/UX only when it applies to the work being summarized.
- 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.
- 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:
- Outcome — one short paragraph.
- Highlights — the most important implemented changes.
- Failures and recovery — resolved workarounds first, unresolved failures second.
- Decisions — what was chosen and why.
- How it works — applicable behavior, flow, architecture, database, or UI/UX.
- How to use it — minimal commands or user steps.
- 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
| Symptom | Safe next step |
|---|---|
| Proposed work appears as complete | Relabel it as proposed, inferred, untested, unshipped, or unresolved. |
| A deployment claim lacks proof | Replace it with the verified source or test status and request a current runtime check. |
| Failures are missing | Add each significant attempt, its result, and any remaining blocker. |
| The recap is too long | Keep only evidence that changes understanding, operation, risk, or the next action. |
| A decorative diagram adds no clarity | Remove it and briefly state that no visual was needed. |
| Runtime cannot find the Skill | Follow 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.
Make an outcome-focused priority call with ak:sowat
Review recent implementation and related issues like a product owner, correct weak priorities, and recommend up to three evidence-backed next steps.
Orchestrate a marketing playbook with ak:play
Create and advance a local marketing playbook, review dependency gates, and keep provider and publishing effects separately approved.