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/probelabs/visor/visor-agent-devnpx skills add probelabs/visor --skill visor-agent-devgit clone --depth 1 https://github.com/probelabs/visorWhat 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.00049 | $0.04572 |
| Opus 5 | $0.00024 | $0.02286 |
| Sonnet 5 | $0.00010 | $0.00914 |
| Haiku 4.5 | $0.00005 | $0.00457 |
Grade A, and why
visor-agent-dev 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 2d 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 — 499 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Visor Agent Development Skill
You are helping the user build or extend a visor-based AI assistant. Follow this structured workflow to ensure correctness, safety, and iterability.
SAFETY RULES — READ FIRST
- NEVER run with real providers (
--no-mocks) without user confirmation. Real runs consume API credits and may trigger external side effects. - NEVER modify or delete existing production configs (e.g., the main
.visor.yamlortyk-assistant.yaml) without explicit user approval. Work on copies or new files. - NEVER commit API keys, tokens, or secrets into YAML files. Use
${ENV_VAR}references. - NEVER add
allowed_commandspatterns likerm:*,sudo:*,chmod:*, or other destructive shell patterns to skills. - NEVER run
visorwith--slack,--telegram,--a2a, or other runner flags unless the user explicitly asks — these connect to live services. - Ask before running any command that hits external APIs (MCP servers, HTTP clients, etc.).
- When writing
disallowed_commandsfor skills, always include:rm:*,sudo:*,shutdown:*,reboot:*,mkfs:*,dd:*.
RUNNING VISOR
All commands in this skill use npx -y @probelabs/visor@latest (aliased as visor below for brevity). When executing commands, always use the full npx form so it works out of the box without a global install:
npx -y @probelabs/visor@latest <command> [flags]
If the user has visor installed globally or as a project dependency, they may tell you to use visor directly — follow their preference.
DEVELOPMENT WORKFLOW
Follow these steps in order. The goal is: write tests first → validate config → iterate with mocks → graduate to real providers → debug with traces.
Step 1: Understand the Goal
Ask the user what they want to build:
- A new skill (knowledge + tools bundle for the assistant)?
- A new workflow (reusable multi-step pipeline)?
- A new check (standalone analysis step)?
- A modification to an existing assistant?
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.
- 2d ago First seen · 499 lines · 49 tokens per session scan A f50c6fcc0185
visor-agent-dev is a skill published in the GitHub repository probelabs/visor (23 stars, last pushed 2d ago), licensed MIT. It adds 49 tokens to every session and 4,572 once invoked, about $0.0002 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
otter-rules-engine
This skill should be used when the user asks to "add a rule", "create a ruleset", "add a fact", "create a custom operator", "add a rules-engine action", "make behavior conditional at runtime", or when authoring or debugging anything in an Otter @o3r/rules-engine workspace. Guides the fact/operator/action/ruleset…
use-sdk
Install, configure, and use a TypeScript SDK generated with @ama-sdk. Use when user wants to call APIs, set up a client (fetch, Angular, beacon), or understand how to use an existing SDK package.
logic-component-shape
Decision tree for single component versus container/presenter, which componentStructure to generate, and which componentType to declare. Invoked by logic-placement and logic-review, not directly.
logic-placement
Decide where new logic belongs — component shape, logic layer, and store variant — when designing a component, service, or store in an Angular/Otter workspace. Use logic-review to assess existing code.
logic-review
Review existing components, services, or stores for misplaced logic — presenter leaks, componentType mismatches, wrong store variants. Use logic-placement when designing something new.
logic-state-layer
Decision tree for whether logic belongs in the component class, a service, or an NgRx store, including service scope and where API calls go. Invoked by logic-placement and logic-review, not directly.