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 lynxlangya/techne --skill anchor-vizgit clone --depth 1 https://github.com/lynxlangya/techneWrote 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/lynxlangya/techne/anchor-viz)<a href="https://agentmods.dev/skills/lynxlangya/techne/anchor-viz"><img src="https://agentmods.dev/badge/skills/lynxlangya/techne/anchor-viz/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/lynxlangya/techne/anchor-viz"><img src="https://agentmods.dev/badge/skills/lynxlangya/techne/anchor-viz.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00058 | $0.01317 |
| Opus 5 | $0.00029 | $0.00659 |
| Sonnet 5 | $0.00012 | $0.00263 |
| Haiku 4.5 | $0.00006 | $0.00132 |
Grade A, and why
anchor-viz 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 9d 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 — 99 lines — stays where its author put it; the contents beside it link to each section on GitHub.
anchor-viz
Investigate by diagramming. The diagram is the byproduct; the value is forcing real investigation before drawing.
Forced Procedure
- Route the request. Choose one
diagramKindfrom the table below. If the user's intent fits multiple kinds, ask one short clarification instead of guessing. - Find evidence for that kind. For
architecture, enumerate roots, manifests, workspace/build/native/container/edge/infra/source-only signals. For other kinds, find the bounded entrypoint, schema, state enum, workflow, or module/type namespace before drawing. - Classify shape or scope. For
architecture, state one project shape and cite evidence:single-frontend,single-backend,coupled-fullstack,monorepo,library,native,native+edge,source-only code, ornon-code. For other kinds, state the bounded scope and the files that prove it. - Apply the non-code decision. Never declare non-code only because manifests are absent. First scan roots; then run a bounded source-extension/code-signal scan. If both are absent, or docs/vault signals clearly dominate, do not fabricate a code diagram. Draw the real top-level structure or ask what the user wants.
- Match the user's language. Human-facing diagram text follows the user's primary language: titles, display labels, edge/message labels, shape notes, and short explanations. Keep code-facing identifiers source-native: Mermaid IDs, file paths, symbols, package names, class/function/module names, and established technical terms such as API, SDK, CLI, HTTP, SwiftUI, AppKit, or React.
- Draw only evidenced relationships. Use the evidence contract for the selected kind. Every node, participant, entity, state, type, and edge/message must come from a file read.
- Enforce complexity gates. Keep
architectureat 12-15 top-level nodes by default. For other kinds, use the validator's participant/message, entity/relationship, state/transition, or type/member limits. Split into drill-down diagrams when needed. - Mark provenance. Add render-neutral comments for every element before
storing:
%% techne:source <elementRef> <path>[#<symbol>]or, for relationship-like elements only,%% techne:inferred <relationshipRef> <reason>. Entity-like elements always need verifiedtechne:source; relationship-like elements need file+symbol proof unless explicitly inferred with sourced endpoints. Useactorfor human sequence participants so the actor path-only allowance is mechanically scoped. Solid relationships mean read-from-code. Dashed or labeled relationships mean inference only where the selected Mermaid type supports it. - Emit, validate, store, build viewer, open when interactive. Write Mermaid
source first, validate it, store it with
scripts/store_viz.py, always build the self-contained viewer, and only open it when the session is interactive.
What ships with it
13 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
- eval.md 6.2 KB
- README-CN.md 6.7 KB
- README.md 7.3 KB
- reference.md 10.0 KB
- scripts/build_viewer.py 5.3 KB runs code
- scripts/package.json 115 B
- scripts/store_viz.py 6.5 KB runs code
- scripts/validate-mermaid.mjs 31 KB runs code
- scripts/viewer/.gitattributes 49 B
- scripts/viewer/mermaid.min.js 3235 KB runs code
- scripts/viewer/svg-pan-zoom.min.js 29 KB runs code
- scripts/viewer/template.html 35 KB
- scripts/viewer/VENDOR-LICENSES.txt 2.7 KB
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.
- 9d ago First seen · 99 lines · 58 tokens per session scan A 39caf1e454ce
anchor-viz is a skill published in the GitHub repository lynxlangya/techne (105 stars, last pushed 2mo ago), licensed MIT. It adds 58 tokens to every session and 1,317 once invoked, about $0.0003 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
ijfw-ui-spec
Use when the user says: 'ui spec', 'design contract', 'ui audit setup', 'lock the design', 'visual contract', 'ui review setup', or '/ijfw-ui-spec'. Produces UI-SPEC.md as the visual design contract before any frontend or visual-artifact build, and dispatches ijfw-ui-auditor as the final 6-pillar gate.
ijfw-design
Use when the user says: 'design', 'redesign', 'UI', 'UX', 'dashboard', 'page', 'component', 'make it look better', 'polish', 'pretty', 'professional', 'user experience', 'layout', 'visual', 'accessibility', 'colors', 'typography', 'brand'.
Add Claude design-system and accessibility workflows with UX/UI Agent Skills
Use UX/UI Agent Skills when Claude should generate tokens, component specs, accessibility audits, and framework-specific UI code from a repeatable design workflow.
design-maker
name: design-maker description: Used when the Design Brief is complete and the user needs to generate mockups. Reads Product-Spec.md and Design-Brief.md, then generates a complete set of design deliverables through a design tool MCP, including all pages, state variants, component specifications, design tokens…
design-brief-builder
name: design-brief-builder description: Used when the user wants to define a design style or visual direction, or says something vague like 'I want a premium/sleek/modern look'. Guides the user through a design interview to clarify visual preferences and outputs Design-Brief.md. After Brief is saved, MUST run Next…
ui-designer
Designs and builds interface work on top of the design system the repo already has: layout, spacing, hierarchy, interaction states, and accessible defaults, with creativity calibrated to the surface instead of an unrequested redesign. Use when asked for a new screen, a redesign, empty, loading, and error states, or to…