agentleFS
Sign inStart free
MicrosoftKnown publishermicrosoft/PilotSwarm/.github/skills/pilotswarm-perf/SKILL.md

pilotswarm-perf

Skill14 starsChanged 8 months agoMITView on GitHub

Run and analyze PilotSwarm performance workflows, starting with SDK sub-agent spawn perf. Use when collecting fresh perf baselines, comparing runs, generating stable perf reports, or updating perf memory and next steps.

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 7 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when the user wants performance numbers or follow-up analysis for this repository.

    line 8
  2. Distinctive:

    Keep the workflow deterministic.

    line 10
  3. Very specific:

    If the user wants fresh numbers, run npm run perf:spawn from repo root.

    line 26
  4. Very specific:

    Treat npm run perf:spawn as the source of truth: it must generate latest.*, append history, and update perf/memory/perf-agent-memory.md …

    line 27
  5. Very specific:

    If you add deeper interpretation beyond the generated memory, refine perf/memory/perf-agent-memory.md so the next run starts from the …

    line 30
  6. Distinctive:

    Prefer repo scripts over ad hoc shell pipelines.

    line 35
  7. Distinctive:

    Do not change perf assertions just to make results look better.

    line 36
  8. Very specific:

    Treat latest.* files as generated outputs.

    line 37
  9. Distinctive:

    Keep memory concise and cumulative.

    line 38
  10. Distinctive:

    If worktree changes may affect perf validity, call that out explicitly in both the response and the memory file.

    line 39
  11. Distinctive:

    If you add another perf surface later, give it all of the following:

    line 43

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “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

PilotSwarm Perf

Use this skill when the user wants performance numbers or follow-up analysis for this repository.

Keep the workflow deterministic. Fresh numbers should come from repo-owned runners, and conclusions should be written back into repo memory.

Canonical Files

  • Perf agent memory: perf/memory/perf-agent-memory.md
  • Spawn perf runner: scripts/perf/run-sdk-spawn-perf.mjs
  • Spawn perf command: npm run perf:spawn
  • Raw spawn perf test: packages/sdk/test/perf/spawn.perf.test.js
  • Perf Vitest config: packages/sdk/vitest.perf.config.js
  • Latest generated report: perf/reports/spawn/latest.md
  • Latest generated metrics: perf/reports/spawn/latest.json
  • Historical run index: perf/reports/spawn/history/index.json

Workflow

  1. Read perf/memory/perf-agent-memory.md.
  2. If the user wants fresh numbers, run npm run perf:spawn from repo root.
  3. Treat npm run perf:spawn as the source of truth: it must generate latest.*, append history, and update perf/memory/perf-agent-memory.md automatically.
  4. Base the analysis on perf/reports/spawn/latest.json and perf/reports/spawn/latest.md, not on terminal snippets alone.
  5. Compare the latest run against the prior latest run if the generated report includes a comparison section.
  6. If you add deeper interpretation beyond the generated memory, refine perf/memory/perf-agent-memory.md so the next run starts from the updated hypotheses and next steps.
  7. In the user-facing summary, include exact measurements, notable comparisons, and the next recommended experiment or optimization.

Rules

  • Prefer repo scripts over ad hoc shell pipelines.
  • Do not change perf assertions just to make results look better.
  • Treat latest.* files as generated outputs.
  • Keep memory concise and cumulative. Replace stale hypotheses with confirmed findings when possible.
  • If worktree changes may affect perf validity, call that out explicitly in both the response and the memory file.

Extending Perf Coverage

If you add another perf surface later, give it all of the following:

  • a dedicated perf test under packages/*/test/perf/
  • a deterministic runner under scripts/perf/
  • generated outputs under perf/reports/<surface>/
  • a memory update in perf/memory/perf-agent-memory.md

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.

Check your setup, free