@robosoft/skillhub-cli 0.1.1 → 0.3.2

package/skillhub-registry/skills/testing/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: testing
+description: Comprehensive testing standards covering unit tests, integration tests, edge case coverage, test structure, mocking strategies, and what makes a good vs bad test. Use this skill whenever the user writes new tests, modifies existing tests, debugs failing tests, asks for test coverage suggestions, requests a test for a specific function or component, mentions testing libraries (Jest, Vitest, React Testing Library, Pytest, Mocha, Cypress, Playwright), or asks how to verify code works. Apply when the user mentions tests, specs, assertions, mocks, stubs, fixtures, TDD, BDD, test coverage, or when they ask "how do I test this". Trigger even when testing is implied — for example, when the user asks Claude to verify behavior, prove something works, or write a regression check.
+---
+
+# Testing Skill
+
+This skill applies the org's testing standards. It loads when the task involves writing, reviewing, or debugging tests.
+
+These rules layer on top of `rules/general.md`, `rules/code-standards.md`, and `rules/anti-patterns.md`.
+
+---
+
+## What to Test (Priority Order)
+
+Test things in this order of importance:
+
+1. **Behavior at boundaries** — empty input, null, max/min values, off-by-one
+2. **Failure paths** — what happens when the network fails, the file is missing, the API returns 500
+3. **Business logic** — the rules that make this code valuable to the user
+4. **Integration points** — where your code meets other systems
+5. **Happy path** — the obvious "it works" case
+
+Most teams test in reverse order — happy paths first, edge cases last (or never). Don't.
+
+## What NOT to Test
+
+- **Implementation details** — internal function calls, private state, specific code paths
+- **Third-party libraries** — if you're testing whether `lodash.merge` works, you're testing lodash
+- **Trivial getters/setters** — testing `get name() { return this._name }` adds no value
+- **Framework behavior** — don't write tests that prove React renders or Express routes
+- **The same thing tested elsewhere** — don't duplicate coverage across unit/integration/e2e
+
+> **Why:** Tests that target implementation break on every refactor without catching real bugs. They make code change expensive and discourage cleanup.
+
+## Test Structure
+
+Every test follows **Arrange / Act / Assert** (AAA):
+
+test("describes the behavior in plain English", () => {
+// Arrange — set up the scenario
+const input = makeUser({ age: 17 });// Act — perform the action
+const result = canVote(input);// Assert — check the outcome
+expect(result).toBe(false);
+});
+
+- **Test names describe behavior, not implementation.** ✅ `"rejects users under 18"` ❌ `"calls validateAge with user.age"`
+- **One logical assertion per test.** Multiple `expect()` calls are fine if they verify a single behavior.
+- **No conditional logic in tests.** No `if`, no `try/catch`, no loops over test cases (use parametrized tests instead).
+
+## Edge Cases to Always Consider
+
+For any function or component, run through this checklist:
+
+- [ ] Empty input (`""`, `[]`, `{}`, `null`, `undefined`)
+- [ ] Single-item input (lists/arrays often break here)
+- [ ] Maximum-size input (does it scale? does it crash?)
+- [ ] Boundary values (off-by-one, zero, negative numbers)
+- [ ] Invalid types (string when number expected)
+- [ ] Concurrent calls (race conditions, if applicable)
+- [ ] Network/IO failures (timeout, 5xx, malformed response)
+- [ ] Permission denied / unauthorized
+- [ ] Already-existing entity (duplicate create)
+- [ ] Non-existent entity (read/update/delete on missing)
+
+You don't need to test all of these for every function. You should at least *consider* them and pick the relevant ones.
+
+## Mocking
+
+- **Mock at the boundary**, not internally. Mock the network call, not the function that calls the network.
+- **Don't mock what you own.** If you wrote it, test it for real.
+- **Don't over-mock.** A test where everything is mocked tests nothing.
+- **Reset mocks between tests.** No shared state leaking between tests.
+
+// ❌ Bad — mocking your own function defeats the purpose
+jest.mock('./userService');
+test("creates user", () => {
+userService.create.mockReturnValue({ id: 1 });
+...
+});// ✅ Good — mock the external boundary (HTTP, DB)
+jest.mock('./httpClient');
+test("creates user", () => {
+httpClient.post.mockResolvedValue({ data: { id: 1 } });
+const user = await userService.create({ name: "Alice" });
+expect(user.id).toBe(1);
+});
+
+## Determinism
+
+Tests must produce the same result every time. Sources of flakiness to eliminate:
+
+- **Time** — mock `Date.now()`, freeze the clock; never assert on "now"
+- **Random** — seed random generators, mock `Math.random` if needed
+- **Network** — mock all real HTTP calls in unit/integration tests
+- **File system** — use temp dirs that are cleaned up; never read/write to real paths
+- **Parallel test order** — tests must pass in any order (no test depending on another running first)
+
+A flaky test is worse than no test — teammates start ignoring failures.
+
+## Coverage Targets
+
+- **Unit tests:** target ~80% line coverage as a *floor*, not a goal.
+- **100% coverage is suspicious** — usually means tests are testing implementation, not behavior.
+- **Critical paths** (auth, payment, data integrity) — aim for 100% **branch** coverage.
+- Coverage numbers measure quantity, not quality. A meaningful test of an edge case is worth more than 50 trivial assertions.
+
+## Test Naming
+
+Choose one convention per project and stick with it. Common patterns:
+
+- **`it("does X when Y")`** — `it("returns null when user is not found")`
+- **`describe("function") + it("does X")`** — nested under `describe` blocks
+- **`test("X scenario produces Y outcome")`** — flat, descriptive
+
+Bad names tell you what the code does; good names tell you what the *behavior* is.
+
+## When Tests Should Block a Merge
+
+- ❌ **Test fails** → must fix before merge
+- ❌ **No test for new business logic** → must add before merge
+- ⚠️ **Coverage drops** → discuss; sometimes acceptable, sometimes not
+- ✅ **Test is slow but passes** → merge, optimize later
+- ✅ **Test could be more thorough** → merge, file follow-up
+
+## When You're Unsure
+
+- **Which test framework does the project use?** Check `package.json` / `pyproject.toml` before assuming.
+- **Where do tests live?** `__tests__/`, `*.test.ts` next to source, separate `tests/` folder — confirm before placing.
+- **Does the project mock fetch with MSW, jest.mock, or something else?** Match existing patterns.
+- **Is there a fixtures/factories module?** Use it instead of inventing test data.
+
+If any of the above is unclear, ask one question before writing tests.

package/skillhub-registry/accessibility-review/1.0.0/SKILL.md

@@ -1,22 +0,0 @@
-# Accessibility Review
-
-## Purpose
-
-Use this skill when reviewing UI components, navigation flows, forms, dialogs, carousels, and data-heavy screens.
-
-## Review Rules
-
-1. Every interactive element must be reachable by keyboard.
-2. Focus order must match visual order.
-3. Dialogs must trap focus and restore it on close.
-4. Buttons need meaningful accessible names.
-5. Form inputs need labels, validation messaging, and error association.
-6. Dynamic updates should announce meaningful changes when needed.
-7. Color contrast should pass WCAG AA for normal text.
-
-## Common Failure Points
-
-- Icon-only buttons without labels.
-- Divs pretending to be buttons, the classic costume party of broken UX.
-- Modals that lose focus.
-- Carousels that auto-rotate without pause controls.

package/skillhub-registry/accessibility-review/1.0.0/checklist/ui-review.md

@@ -1,8 +0,0 @@
-# UI Accessibility Checklist
-
-- [ ] Keyboard-only navigation works.
-- [ ] Visible focus indicator is present.
-- [ ] Screen reader labels are meaningful.
-- [ ] Form errors are announced or associated.
-- [ ] Dialog focus is trapped and restored.
-- [ ] Color contrast is acceptable.

package/skillhub-registry/accessibility-review/1.0.0/skill.json

@@ -1,9 +0,0 @@
-{
-  "name": "accessibility-review",
-  "version": "1.0.0",
-  "description": "Accessibility checklist for reviewing UI, keyboard behavior, focus states, and screen-reader output.",
-  "category": "quality",
-  "tags": ["a11y", "accessibility", "ui", "review"],
-  "entry": "SKILL.md",
-  "compatibleWith": ["cursor", "claude", "chatgpt", "github-copilot"]
-}

package/skillhub-registry/nextjs-clean-architecture/1.0.0/SKILL.md

@@ -1,37 +0,0 @@
-# Next.js Clean Architecture
-
-## Purpose
-
-Use this skill when building or reviewing a scalable Next.js App Router project with TypeScript, server components, server actions, and reusable UI components.
-
-## Core Rules
-
-1. Keep business logic out of React components.
-2. Prefer feature-based folders for domain code.
-3. Use server components by default and client components only where browser APIs, state, or events are required.
-4. Keep data access inside services, repositories, or server actions.
-5. Model request and response types clearly.
-6. Every user-facing view needs loading, empty, error, and success states.
-7. Accessibility cannot be treated like decoration added after the building collapses.
-
-## Recommended Folder Pattern
-
-```txt
-src/
-  app/
-  features/
-    users/
-      components/
-      actions/
-      services/
-      schema/
-      types/
-  components/
-    ui/
-  lib/
-  db/
-```
-
-## Output Expectations
-
-When generating code, include the relevant file paths, TypeScript types, validation rules, and integration steps.

package/skillhub-registry/nextjs-clean-architecture/1.0.0/checklist/definition-of-done.md

@@ -1,9 +0,0 @@
-# Definition of Done
-
-- [ ] TypeScript types are explicit where needed.
-- [ ] Loading state is handled.
-- [ ] Empty state is handled.
-- [ ] Error state is handled.
-- [ ] Server/client boundary is intentional.
-- [ ] Accessibility labels and keyboard paths are checked.
-- [ ] Code is easy to delete or refactor later.

package/skillhub-registry/nextjs-clean-architecture/1.0.0/rules/folder-structure.md

@@ -1,7 +0,0 @@
-# Folder Structure Rules
-
-- Use `features/<feature-name>` for domain-specific code.
-- Use `components/ui` only for generic reusable UI primitives.
-- Use `lib` for shared helpers and platform clients.
-- Use `db` for database configuration and schema exports.
-- Avoid dumping everything into `utils`, the drawer of forgotten sins.

package/skillhub-registry/nextjs-clean-architecture/1.0.0/skill.json

@@ -1,9 +0,0 @@
-{
-  "name": "nextjs-clean-architecture",
-  "version": "1.0.0",
-  "description": "Next.js App Router architecture rules, folder patterns, and delivery checklist.",
-  "category": "frontend",
-  "tags": ["nextjs", "react", "typescript", "architecture"],
-  "entry": "SKILL.md",
-  "compatibleWith": ["cursor", "claude", "chatgpt", "github-copilot"]
-}

package/skillhub-registry/shadcn-crud-generator/1.0.0/SKILL.md

@@ -1,25 +0,0 @@
-# Shadcn CRUD Generator
-
-## Purpose
-
-Use this skill when creating admin CRUD modules with Next.js, TypeScript, server actions, Shadcn UI, and a predictable folder structure.
-
-## CRUD Rules
-
-1. Each module must include list, create, edit, delete, and view patterns where applicable.
-2. Use schema validation before mutation.
-3. Keep table column definitions separate from page composition when the table grows.
-4. Add confirmation before destructive actions.
-5. Show toast or visible feedback after mutation.
-6. Never hide errors in `console.log`, because that is not observability, that is denial.
-
-## Generated Files
-
-```txt
-features/<module>/
-  components/
-  actions/
-  schema/
-  types/
-  data/
-```

package/skillhub-registry/shadcn-crud-generator/1.0.0/skill.json

@@ -1,9 +0,0 @@
-{
-  "name": "shadcn-crud-generator",
-  "version": "1.0.0",
-  "description": "CRUD scaffolding guidance and templates for Next.js + Shadcn admin panels.",
-  "category": "generator",
-  "tags": ["shadcn", "crud", "nextjs", "admin"],
-  "entry": "SKILL.md",
-  "compatibleWith": ["cursor", "claude", "chatgpt", "github-copilot"]
-}

package/skillhub-registry/shadcn-crud-generator/1.0.0/templates/feature/actions.ts.hbs

@@ -1,16 +0,0 @@
-"use server";
-
-export async function create{{pascalName}}Action(input: unknown) {
-  // Validate input, persist data, then revalidate affected paths.
-  return { success: true };
-}
-
-export async function update{{pascalName}}Action(id: string, input: unknown) {
-  // Validate id + input, update data, then revalidate affected paths.
-  return { success: true };
-}
-
-export async function delete{{pascalName}}Action(id: string) {
-  // Validate id, delete safely, then revalidate affected paths.
-  return { success: true };
-}

package/skillhub-registry/shadcn-crud-generator/1.0.0/templates/feature/page.tsx.hbs

@@ -1,13 +0,0 @@
-import { {{pascalName}}Table } from "@/features/{{kebabName}}/components/{{kebabName}}-table";
-
-export default async function {{pascalName}}Page() {
-  return (
-    <main className="space-y-6">
-      <div>
-        <h1 className="text-2xl font-semibold">{{title}}</h1>
-        <p className="text-muted-foreground">Manage {{title}} records.</p>
-      </div>
-      <{{pascalName}}Table />
-    </main>
-  );
-}