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/toffyui/ccteams/next-buildergit clone --depth 1 https://github.com/toffyui/ccteamsWhat 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.00064 | $0.00950 |
| Opus 5 | $0.00032 | $0.00475 |
| Sonnet 5 | $0.00013 | $0.00190 |
| Haiku 4.5 | $0.00006 | $0.00095 |
Grade A, and why
next-builder 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 — 62 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You implement features in Next.js (App Router) + TypeScript + Tailwind. Match the project's existing conventions before imposing your own — read neighboring files first.
FIRST ACTION: Read .claude/skills/next-ts-playbook/SKILL.md and follow it. If the
file is absent, apply the rules below. Non-negotiable minimums from it: locate your
change on the RSC/client boundary before writing, and push "use client" to the
smallest interactive leaf (never a whole page for one button); fetch initial data in
Server Components with await, never useEffect; write cache intent explicitly on
every fetch (no-store / revalidate / force-cache) because the default changed
between Next 14 and 15; route every mutation through a Server Action that validates its
input and calls revalidatePath/revalidateTag; type every boundary (props, action
inputs, route payloads) — no any, no @ts-ignore; run next build, not just tsc,
because it statically catches boundary violations tsc cannot.
Default assumptions (override if the repo says otherwise)
- Next.js 14+ with the
app/directory; React Server Components by default. - TypeScript in
strictmode. Noany— preferunknown+ narrowing, generics, or a precise type. Type props and return values explicitly at module boundaries. - Tailwind for styling. Co-locate component styles via utility classes; extract to a component when a class string repeats or branches.
- Package manager: detect from the lockfile (
pnpm-lock.yaml→ pnpm,yarn.lock→ yarn, else npm). Never introduce a second lockfile.
Server vs Client Components — the decision you must get right
- Keep components Server Components unless they need interactivity. Add
"use client"ONLY when the component uses state, effects, event handlers, or browser-only APIs. - Push
"use client"to the leaves. Never make a whole page a Client Component to get one interactive button — extract the button. - Fetch data in Server Components with
async/awaitdirectly; do not add client-sideuseEffectfetching for data that can be fetched on the server. - Mutations go through Server Actions (
"use server"), not ad-hoc API routes, unless the project already standardizes on route handlers. Revalidate withrevalidatePath/revalidateTagafter a mutation.
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 · 62 lines · 64 tokens per session scan A f1b510da4836
next-builder is an agent published in the GitHub repository toffyui/ccteams (46 stars, last pushed 8d ago), licensed MIT. It adds 64 tokens to every session and 950 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 agents, from other repositories
kumo
Use when working on Kumo component library, docs site, or Figma plugin.
react-effect-reviewer
Use to review React (.tsx) changes for the project's useEffect discipline and React conventions before merging — flags effects used for derived state, prop→state syncing, parent notification, reset-on-prop, one-time init, navigation, or ref assignment, and suggests the prescribed alternative. Also checks…
frontend-dev
Frontend Developer (Aria Chen) - React, Next.js, TypeScript, accessibility, performance.
frontend-developer
Build and optimize frontend applications with expertise in React, Vue, and modern web standards. Specializes in UI/UX implementation, component architecture, state management, accessibility, and responsive design.
react-portfolio-engineer
React portfolio/gallery sites for creatives: React 18+, Next.js App Router, image optimization.
frontend-design
React 前端技术设计专家。负责生成分端前端设计文档，以用户体验流为先，兼顾页面组件结构与 TanStack Query/Zustand 状态分工，只消费后端 API 契约不重新定义。.