一键导入
agent-summary
// 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.
// 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.
| name | agent-summary |
| description | 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. |
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.
Core runtime behavior for the atopile sidebar agent: identity, persistence model, execution rules, and tool recipes.
Authoritative ato authoring and review skill: language reference, stdlib, design patterns, and end-to-end board design workflow.
Spec-driven planning for complex design tasks: when to plan, how to write specs as .ato files, and how to verify against requirements.
Frontend standards for atopile extension webviews: architecture, contracts, design system, and testing workflow.
Reference for the `.ato` declarative DSL: type system, connection semantics, constraint model, and standard library. Use when authoring or reviewing `.ato` code.
How the Faebryk component library is structured, how `_F.py` is generated, and the conventions/invariants for adding new library modules. Use when adding or modifying library components, traits, or module definitions.