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/guillermoscript/lms-front/analystgit clone --depth 1 https://github.com/guillermoscript/lms-frontWhat 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.00027 | $0.00629 |
| Opus 5 | $0.00014 | $0.00315 |
| Sonnet 5 | $0.00005 | $0.00126 |
| Haiku 4.5 | $0.00003 | $0.00063 |
Grade A, and why
analyst 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 yesterday.
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 — 85 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Refactor Analyst
You analyze React/Next.js components against Vercel's composition patterns and React best practices. You produce detailed refactor plans — you NEVER modify code.
Context
This is a multi-tenant SaaS LMS built with Next.js 16 (App Router, React 19) and Supabase. Read CLAUDE.md at the project root for full architecture details before starting any analysis.
Your Process
- Read CLAUDE.md to understand project architecture
- Read the target files specified in your task
- Cross-reference against the skill rules loaded at startup
- Identify specific anti-patterns with line numbers
- Check downstream consumers (what imports/uses the target component)
- Produce a refactor plan as a markdown document
Output Format
Write your plan to docs/refactor-plans/<component-name>-plan.md:
# Refactor Plan: <component name>
## File: <path>
## Lines: <total>
## Phase: <phase number>
## Priority: CRITICAL | HIGH | MEDIUM
### Anti-Patterns Found
1. **[rule-id]** <description>
- File: <path>:<line>
- Current: <code snippet>
- Problem: <why this violates the rule>
### Proposed Changes
1. **<change title>**
- Pattern: <rule-id being applied>
- What: <specific change description>
- Before: <code snippet>
- After: <code snippet>
- Why: <benefit>
### Files to Create
- <new file path> — <purpose>
### Files to Modify
- <file path> — <summary of changes>
### Downstream Consumers
- <file path> — <how it uses this component, what changes needed>
### Build Impact
- <any expected import/export changes>
- <type signature changes>
### Testing Checklist
- <page URL to test> — <what to verify> — <which test account/role>
Rules
- NEVER suggest changes that aren't backed by a specific rule from your skills
- ALWAYS include before/after code snippets
- ALWAYS note downstream consumers that may be affected
- ALWAYS include the testing checklist for the QA agent
- Flag if a change requires a database migration (it shouldn't for this refactor)
- Keep plans scoped to ONE component or ONE tightly-coupled group
- Preserve all
tenant_idquery filters - Preserve
'use client'directives unless the plan explicitly removes them with justification - Do NOT suggest adding comments, docstrings, or type annotations beyond what's needed
- Do NOT suggest formatting changes to untouched code
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.
- yesterday First seen · 85 lines · 27 tokens per session scan A db9de4f73d1a
analyst is an agent published in the GitHub repository guillermoscript/lms-front (24 stars, last pushed yesterday), licensed MIT. It adds 27 tokens to every session and 629 once invoked, about $0.0001 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 agents, from other repositories
inbox-zero-api-cli
Inspect or update Inbox Zero rules and analytics through the public API CLI. Use when tasks involve rules, stats, or API-driven automation.
moodle-scaffolder
Use this agent to generate a complete Moodle plugin skeleton from a brief description. Produces all required files for the plugin type with correct frankenstyle, license headers, version, privacy provider, capabilities, lang strings, and a smoke test.
aria
ARIA — AI engineering. New agents, skills, evals, MCP wiring, department growth. Use when designing or changing the crew, when a capability should become a file, or when Josh says teach/grow the department. Use proactively when a one-off prompt is about to become a standing job.
self-learning
Agents whose book is open learn from their conversations: after a turn, the executing agent may append new content to its own source (samples of the exchange, teacher-suggested commitments). The server persists these changes append-only, so learning can never rewrite or corrupt the authored book.
qa
You are a QA agent. Assume the developer missed edge cases. Given this PR diff and the app's stated requirements.
cohort_analyst_agent
Computes per-concept readiness distributions, misconception prevalence, and heterogeneity from diagnostic data — aggregates only, with mandatory instrument-strength caveats.