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 skills add qarium/goga --skill goga-define-usersgit clone --depth 1 https://github.com/qarium/gogaWrote 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/qarium/goga/goga-define-users)<a href="https://agentmods.dev/skills/qarium/goga/goga-define-users"><img src="https://agentmods.dev/badge/skills/qarium/goga/goga-define-users/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/qarium/goga/goga-define-users"><img src="https://agentmods.dev/badge/skills/qarium/goga/goga-define-users.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
SkillSpector: 1 finding, up to low
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- low Excessive Agency · line 112 Skill's behavior or capabilities extend beyond its stated purpose. Scope creep allows an agent to perform actions unrelated to its documented functionality, increasing the attack surface.Fix: Limit the skill's scope to its documented purpose. Remove instructions that enable the agent to perform actions outside its stated functionality.
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.1 | $0.00005 | $0.01275 |
| Opus 5 | $0.00003 | $0.00638 |
| Sonnet 5 | $0.00001 | $0.00255 |
| Haiku 4.5 | $0.00001 | $0.00128 |
Grade A, and why
goga-define-users 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 7d 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 — 281 lines — stays where its author put it; the contents beside it link to each section on GitHub.
goga-define-users
Purpose
Define the users and usage contexts that are relevant to the identified product problem.
Transform the problem into a clear understanding of:
- who encounters the problem;
- what they are trying to accomplish;
- in what context the problem occurs;
- what matters to them in that situation;
- which other actors may participate in the same product flow.
The result must provide enough understanding of the relevant users to design an appropriate product experience.
Contract
consume:
- product
- problem
produce:
- users
Core Principle
Focus on users relevant to the problem, not on generic personas.
Do not create personas simply because they are a common product-management artifact.
A user is relevant when understanding their goals, context, or behaviour can materially affect the product decision.
Product Interview
Do not infer the user model solely from the project structure or the wording of the request.
Interview the user when multiple actors may be involved and their roles would materially change the product solution.
Clarify when necessary:
- who experiences the problem;
- who initiates the relevant action;
- who receives the outcome;
- who may be affected by the action;
- whether different user groups have materially different needs;
- which user is the primary focus of the current change.
Do not create personas or user groups merely because they are technically present in the product.
The user model must reflect the product decision being made, not the structure of the system.
Process
1. Identify the primary user
Determine who directly experiences the problem.
Describe the user in terms of their role in the product and the situation in which they encounter the problem.
Avoid demographic or fictional persona details unless they materially affect the product experience.
2. Understand the user's context
Determine:
- what the user is trying to accomplish;
- why they are doing it;
- when the problem occurs;
- what triggers the interaction;
- what the user already knows or expects;
- what constraints exist in their situation;
- what happens if they cannot accomplish the task.
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.
- 7d ago First seen · 281 lines · 5 tokens per session scan A 5cee96ae48d2
goga-define-users is a skill published in the GitHub repository qarium/goga (29 stars, last pushed 3d ago), licensed BSD-3-Clause. It adds 5 tokens to every session and 1,275 once invoked, about $0.0000 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-09-03.
Other skills, from other repositories
doubt-driven-review
In-flight adversarial check on a non-trivial decision BEFORE it stands — distinct from post-hoc review of a finished diff. Use on "stress-test this decision", "are we sure about this", "verify before commit", "poke holes in this", when working in unfamiliar code, or before an irreversible step (migration, prod deploy…
release-cut
Cut a new pi-agent-dashboard release: promote ## [Unreleased] in CHANGELOG.md, bump every workspace package.json per SemVer, commit, tag v , and push — triggering the Release workflow that publishes every non-private workspace, builds the Electron artifacts, and creates a GitHub Release. Use on "cut a release"…
spec-coherence-check
Sweep all active OpenSpec proposals for staleness, conflicts, and obsolescence against the current codebase and archived changes. Use when proposals may be outdated, when checking cross-proposal conflicts, or before starting a batch of implementations. Produces a gap-analysis report, updates a priority queue file, and…
ship-it
Worktree-side implementation orchestrator for an OpenSpec change. Idempotent: gates automated scenarios on filesystem reality, owns the red-test fix loop, runs the docker harness with always-teardown, then drives ship-change inline. Escape hatch writes SHIPITBLOCKED.md. Runnable headless. Triggers: "ship it", "build…
faq-mine
Mine docs/faq.md from README.md, docs/.md, and the pi-hermes memory stores. Dispatches @fast subagents per source, dedupes against the existing FAQ, and merges entries in caveman style. Use when asked to "build / regenerate / extend the FAQ", "mine docs into FAQ", "mine hermes memory into FAQ", "surface runtime…
session-to-guideline
Turn a pi session into a Markdown "how-we-did-it" collaboration guideline: reads the session's JSONL transcript and synthesizes a reusable playbook of which prompts worked, what had to be steered, and how to reproduce the result faster. Use when: "document this session", "write up how we did X with the AI", "make a…