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/aps08/fullstack-clean-architecture/react_testingnpx skills add aps08/fullstack-clean-architecture --skill react_testinggit clone --depth 1 https://github.com/aps08/fullstack-clean-architectureWhat 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.00024 | $0.00921 |
| Opus 5 | $0.00012 | $0.00461 |
| Sonnet 5 | $0.00005 | $0.00184 |
| Haiku 4.5 | $0.00002 | $0.00092 |
Grade A, and why
react-testing 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 — 100 lines — stays where its author put it; the contents beside it link to each section on GitHub.
React Testing Skill
Testing Tools
- Use
Vitestas the primary test runner. - Use
@testing-library/reactfor component behavior testing. - Use
Playwrightfor all End-to-End (E2E) testing.
Directory Structure
All test files are located under web/tests/ and are organized as follows:
tests/unit/: Contains unit tests testing components, hooks, features, and utils in isolation using Vitest and React Testing Library.tests/e2e/: Contains end-to-end integration tests that run in a browser using Playwright.tests/mocks/: Contains mocks for external integrations or APIs.tests/fixtures/: Contains reusable test fixtures or data.tests/test_utils.tsx: Contains common testing utilities, such as a customrenderwrapper.
Standards & Best Practices
- Test user interactions rather than implementation details.
- Ensure all tests are isolated and don't depend on global state.
- No Comments Needed: No need to add comments inside any of the test code (like
// Arrange,// Act,// Assert). Thetestoritdescription strings are enough to explain the test logic. - Code Coverage: Ensure test coverage is strictly more than 80% of the lines.
- Mocking: Use
vi.fn()for mock functions andvi.mock()for module mocks in Vitest.
Example: Unit Test (Vitest + Testing Library)
import { fireEvent, render, screen } from "@testing-library/react";
import { describe, expect, it, vi } from "vitest";
import { ArchiveCard } from "@/components/ArchiveCard";
const todo = {
id: "todo-1",
title: "Old Project Notes",
isCompleted: false,
createdAt: "2024-01-01T00:00:00Z",
updatedAt: "2024-03-01T00:00:00Z",
};
describe("ArchiveCard", () => {
it("renders the todo title", () => {
render(<ArchiveCard todo={todo} onRestore={vi.fn()} onDelete={vi.fn()} />);
expect(screen.getByText("Old Project Notes")).toBeInTheDocument();
});
it("calls onRestore with the todo id when Restore is clicked", () => {
const onRestore = vi.fn();
render(
<ArchiveCard todo={todo} onRestore={onRestore} onDelete={vi.fn()} />,
);
fireEvent.click(screen.getByRole("button"));
fireEvent.click(screen.getByText("Restore"));
expect(onRestore).toHaveBeenCalledWith("todo-1");
});
});
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 · 100 lines · 24 tokens per session scan A 8745d07e10c7
react-testing is a skill published in the GitHub repository aps08/fullstack-clean-architecture (2 stars, last pushed 3mo ago), licensed Apache-2.0. It adds 24 tokens to every session and 921 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-31.
Other skills, from other repositories
backend-conventions
Backend convention reference (.NET 10 / C# 13). Auto-injected into backend-aware agents - not user-invocable.
frontend-conventions
Frontend convention reference (SvelteKit / Svelte 5). Auto-injected into frontend-aware agents - not user-invocable.
add-test
Add tests following project test patterns.
polish-ui
Design-quality workflow that combines design taste, aesthetic direction, image-to-code, a Web Interface Guidelines audit, and real-browser verification. Use when building or polishing a UI surface, implementing a mockup/screenshot, or when asked to make a page "look great".
review-dependabot
Reviews a Dependabot PR and evaluates whether the dependency update is safe to merge. Use when a Dependabot PR is opened, when evaluating dependency updates, or when asked to check if a version bump is safe.
add-background-job
Add a Hangfire background job (recurring or one-time).