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 agents/jumppad-labs/spektacular/knowledge-triggergit clone --depth 1 https://github.com/jumppad-labs/spektacularWhat 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.00000 | $0.00436 |
| Opus 5 | $0.00000 | $0.00218 |
| Sonnet 5 | $0.00000 | $0.00087 |
| Haiku 4.5 | $0.00000 | $0.00044 |
Grade A, and why
knowledge-trigger 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 3d 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.
What it actually says
Knowledge-Worthy Discovery Recognition
Managed by
{{command}} init— edittemplates/agents/knowledge-trigger.mdin the Spektacular source, not this section in place. Hand edits will not survive the next init.
While working — debugging, reading code to understand how something works, making a non-obvious choice — watch for the moment you surface something durable and non-obvious: a convention inferred from code that isn't written down anywhere, a gotcha hit while debugging, the reasoning behind a choice that wasn't the obvious one, a term whose meaning had to be worked out from context. Recognizing this moment is your job, not the user's — don't wait to be asked.
When you recognize the moment, offer — never write to the knowledge base
unprompted. Something like: "this looks like an undocumented convention —
want me to save it via spek-knowledge?" Say briefly what you'd capture and
why it's worth keeping. Wait for the user's decision before doing anything
else.
The user's response falls into one of three outcomes:
- Accept — invoke the
spek-knowledgeskill to write the entry. The skill's own propose-then-confirm flow handles scope selection and the actual write from there. - Defer ("not now", "later", "remind me at the end") — do not invoke the skill. Continue the task normally, and treat this as temporary: if the work keeps surfacing related material, you may raise the offer again later in the same conversation.
- Decline ("no", "not worth saving") — do not invoke the skill, and do not raise the offer again for this discovery for the remainder of the conversation. A decline is final for that discovery, not a "not now."
This is the recognition trigger only; it does not change how a knowledge
entry gets written once you decide to write one — that is still entirely the
spek-knowledge skill's job, per the Memory & Context section above.
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.
- 3d ago First seen · 37 lines · 0 tokens per session scan A 2c4762d4a8bc
knowledge-trigger is an agent published in the GitHub repository jumppad-labs/spektacular (20 stars, last pushed 12d ago), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 436 tokens. 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 agents, from other repositories
gsd-phase-researcher
Researches how to implement a phase before planning. Produces RESEARCH.md consumed by gsd-planner. Spawned by /gsd:plan-phase orchestrator.
gsd-project-researcher
Researches domain ecosystem before roadmap creation. Produces files in .planning/research/ consumed during roadmap creation. Spawned by /gsd:new-project or /gsd:new-milestone orchestrators.
propagate
Generate tests from Allium specifications. Use when the user wants to propagate tests, generate test files from a spec, write tests for a specification, create property-based tests, produce state machine tests, check test coverage against spec obligations, or understand what tests a specification requires.
weed
Weed the Allium garden. Find where Allium specifications and implementation code have diverged, and help resolve the divergences. Use when the user wants to check spec-code alignment, compare specs against implementation, audit for spec drift or violations, sync specs with code or code with specs, or verify whether…
issue-tracker
Issues and PRDs for this repo live as GitHub issues on open-gsd/gsd-pi (the upstream remote). Use the gh CLI for all operations.
gsd-verifier
Verifies phase goal achievement through goal-backward analysis. Checks codebase delivers what phase promised, not just that tasks completed. Creates VERIFICATION.md report.