Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/a-lottes/aspark/next-stepsnpx skills add a-lottes/aSPARK --skill next-stepsgit clone --depth 1 https://github.com/a-lottes/aSPARKWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/a-lottes/aspark/next-steps)<a href="https://agentmods.dev/skills/a-lottes/aspark/next-steps"><img src="https://agentmods.dev/badge/skills/a-lottes/aspark/next-steps.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00092 | $0.01184 |
| Opus 5 | $0.00046 | $0.00592 |
| Sonnet 5 | $0.00018 | $0.00237 |
| Haiku 4.5 | $0.00009 | $0.00118 |
Grade A, and why
next-steps scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 90 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/next-steps — Propose the Next Feature (Product Owner)
You are running an advisory ceremony, not a gated one. The Product Owner
looks at where the project actually stands and proposes what to build next —
the user picks, tweaks, or discards it. Nothing here gets written to
.spark/ and nothing needs approval; the output is a recommendation to carry
into /story-time or /spark.
Input
None required. Optionally the user may point at a theme or constraint (e.g. "something small", "focus on the API") — pass it through to the agent as a steer, not a fixed answer.
Steps
- Gather the loop state yourself — don't delegate this. The
product-owneragent cannot rungitor walk.spark/. Collect a brief before invoking it:git log --oneline -20(and further back if the project is young) for what actually shipped and when.- Every
.spark/<feature-name>/directory: forspec.md,plan.md,review.md,qa.mdwhere present, read each artifact's Handoff block first — a bounded read, not the whole file. Status, Summary/ Verdict and Open items are enough to classify the feature as shipped (released), shipped-pending-approval (handed-off— closed for this team, never resumed), in-flight (mid-loop, no open blocking findings), or stalled (open review/QA findings, or untouched for a while). - Any unresolved findings sitting in the newest
review.mdorqa.md— these are open points, not just status flags. The block's Open field already names the Blocker/Major IDs; read the specific finding's row in §3 Findings only for the ones you need described in the brief, not the whole report. .spark/constitution.mdif it exists — its Product Principles and Project Profile sections are the standing goals a proposal should serve.- If nothing exists yet in
.spark/and git history is empty or trivial, say so plainly — there is no "state" to read yet, and the honest move is to ask the user for the first idea rather than fabricate one.
- Delegate to the Product Owner. Invoke the
product-owneragent in its propose mode (see its## Proposing the Next Featuresection): give it the brief from step 1 verbatim (shipped list, in-flight/stalled features with their open points, constitution excerpt or "none"), plus any user steer. Point it at.spark/constitution.mdif present. - Relay, don't guess. If the agent asks clarifying questions before it can propose anything sensible (e.g. the constitution is missing and the product's purpose is unclear), put them to the user, then re-invoke with the answers.
- Present the result as a conversation, not a report dump. Show the recommended feature with its one-paragraph rationale (what gap it closes, why now, rough size, what it displaces), plus up to two alternatives the agent considered and rejected. Lead with the recommendation, not the list.
- Let the user decide. They may: accept the recommendation as-is, ask for a different angle (re-invoke the agent with the steer), pick an alternative, or reject all of them and bring their own idea instead.
- Hand off on confirmation. Once the user has settled on an idea
(whichever source), ask whether to continue straight into
/story-time <idea>or the full/spark <idea>loop, and invoke it if they say yes. Do not invoke either automatically — this skill only produces the idea.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 90 lines · 92 tokens per session scan A 16072dcd3911
next-steps is a skill published in the GitHub repository a-lottes/aSPARK (19 stars, last pushed 4d ago), licensed MIT. It adds 92 tokens to every session and 1,184 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
audit-context
Evaluates ambient context artifacts (CLAUDE.md, memory, local skills, settings hooks) for compatibility with swarm governance. Returns a classified report so users can address interference before launching a team.
agentic-workflow-audit
Use when reviewing or auditing an existing agent / LLM-pipeline architecture — e.g. 'is my workflow actually decomposed or secretly a mega-agent?', 'are my task boundaries and success criteria right?' — even without the word 'audit'. | 要檢視/review/稽核既有 agent 或 LLM pipeline 的架構,或問「有沒有拆好」「是不是變成 mega agent」「task…
writing-mode
Writing mode operational spec for the team lead. Returns lead identity, facilitator identity, ownership boundaries, editorial baseline, suggest-members guidance, and phase arc for writing-mode teams.
triage-mode
Triage mode operational spec for the team lead. Returns lead identity, facilitator identity, mode-specific rules, suggest-members guidance, and phase arc for triage teams that diagnose an issue without changing it.
citation-receipts
Systematic per-citation verification protocol for academic writing. MUST be used whenever writing content that cites sources — papers, blog posts, SOTAs, or any document making factual claims about external work. Triggers (FR + EN) on any writing task involving references, citations, or bibliographic claims, or when…
sota-writer
Write structured State-of-the-Art (SOTA) reviews / literature reviews for academic research projects with zero hallucinated citations. Activate this skill whenever the user wants to write, update, or expand a SOTA. Triggers (FR + EN) : "écris un SOTA", "état de l'art sur", "revue de littérature", "mise à jour SOTA"…