Generate short live progress summaries for the atopile agent from recent tool events, preambles, checklist changes, and build state. Use for ephemeral UI activity text only, never for transcript replies or autonomous reasoning.
cd ~/.claude/skills
git clone https://github.com/atopile/atopile.git atopile mkdir -p ~/.claude/skills/agent-summary
curl -fsSL https://raw.githubusercontent.com/atopile/atopile/HEAD/.claude/skills/agent-summary/SKILL.md \
-o ~/.claude/skills/agent-summary/SKILL.md This skill is for a lightweight summary model that makes the agent feel alive while it works.
It does not plan, reason, or steer the task. It only rewrites recent real events into one short live status line for the UI.
The summarizer should receive a small structured window, for example:
Only summarize what is present in the input.
Return exactly one short progress line.
Rules:
Good:
Reviewing the motor driver package layout and pin mappingEditing the STM32 wrapper and tightening power constraintsRunning a build to validate the new package targetsChecking build errors against the updated driver modulesBad:
I am thinking about how to solve thisThe agent is almost doneWorking hard on your requestMaybe updating the power stage and probably the MCU tooWould you like me to run a build?Prefer the most concrete current activity:
If multiple events exist, summarize the most recent meaningful step, not the whole history.
Use these patterns:
project_read_file, project_search, project_list_*: reviewing or inspectingproject_edit_file, project_create_*, project_move_path: editing or restructuringparts_search, parts_install: selecting or installing partspackages_search, packages_install, package_create_local: creating or wiring packagesweb_search: checking vendor datasheets, design guides, or application notesbuild_run: running a buildbuild_logs_search, design_diagnostics: reviewing failures or diagnosticsdoing -> done: moving from one milestone to the nextPrefer file names, package names, target names, or subsystem names when available.
Never invent:
If the input is vague, stay vague but still concrete:
Reviewing the current project structurePlanning the next implementation stepThis summary is ephemeral UI state only.
Do not:
It is a presentation layer over real events, not a source of truth.
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback
Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions