@robosoft/skillhub-cli 0.1.2 → 0.3.2

package/skillhub-registry/rules/code-standards.md

@@ -0,0 +1,182 @@
+# Code Standards
+
+Status: **Universal — applies to all coding tasks regardless of language**
+Last updated: 2026-05-06
+Owner: [Raj Shah]
+
+Concrete, measurable standards for code structure. These apply across all languages. Language-specific rules belong in `skills/` (e.g., `skills/react/SKILL.md`, `skills/python/SKILL.md`).
+
+## Function Size
+
+- **Maximum ~40 lines per function.**
+- If a function exceeds this, extract logical chunks into named helpers.
+- Exception: declarative configuration objects, route tables, and similar data structures.
+
+> **Why:** Functions over 40 lines almost always mix multiple responsibilities. Breaking them up forces clearer naming and makes diffs reviewable.
+
+## Nesting Depth
+
+- **Maximum 3 levels of nesting** (conditionals, loops, error handling blocks).
+- Use early returns or guard clauses to flatten control flow.
+- Reject the "arrow anti-pattern" — code that drifts rightward across the page.
+
+**Pseudocode example:**
+
+    // ❌ Bad — deeply nested
+    function process(user):
+        if user exists:
+            if user is active:
+                if user has permission:
+                    do_action(user)
+
+    // ✅ Good — flat with early returns
+    function process(user):
+        if user does not exist: return
+        if user is not active: return
+        if user lacks permission: return
+        do_action(user)
+
+> **Why:** Deep nesting is the strongest predictor of bugs. Early returns are easier to read and easier to modify.
+
+## Naming
+
+- **Variables and functions:** descriptive, no single letters except short-scope loop counters.
+- **Allowed abbreviations:** universally-understood ones only (`id`, `url`, `db`, `api`, `ctx`).
+- **Booleans:** prefix with `is`, `has`, `should`, `can` (e.g., `isReady`, `hasError`).
+- **Functions:** verb-first (e.g., `getUser`, `validateInput`).
+- **Constants:** language convention — typically `SCREAMING_SNAKE_CASE` for true constants.
+- Match casing conventions of the language (`snake_case` for Python, `camelCase` for JS, etc.).
+
+## Magic Values
+
+- **No magic numbers or strings.** Extract to named constants.
+- The constant's name must explain *what the value represents*, not just *that it's a value*.
+
+**Pseudocode example:**
+
+    // ❌ Bad
+    if user.age > 17: allow_access()
+    sleep(5000)
+
+    // ✅ Good
+    MIN_ADULT_AGE = 18
+    RETRY_DELAY_MS = 5000
+    if user.age >= MIN_ADULT_AGE: allow_access()
+    sleep(RETRY_DELAY_MS)
+
+> **Why:** Magic values force readers to guess intent. Named constants document the *why*, not just the *what*.
+
+## Error Handling
+
+- **Handle errors explicitly.** No silent failures, no empty catch blocks.
+- If you catch an error, do exactly one of: log it, transform it, retry, or propagate it. Never swallow it.
+- Errors must carry enough context to debug from logs alone.
+
+**Pseudocode example:**
+
+    // ❌ Bad — silent failure
+    try: risky_operation()
+    catch: pass
+
+    // ✅ Good — explicit handling
+    try:
+        risky_operation()
+    catch err:
+        logger.error("risky_operation failed", err)
+        throw new OperationFailedError("Could not complete X", cause: err)
+
+## Environment Variables and Secrets
+
+- **Never hardcode** API URLs, base URLs, service endpoints, or environment-dependent values in business logic.
+- **Never commit secrets** (API keys, tokens, passwords, connection strings) to version control — use environment variables, secret managers, or platform-native secret storage.
+- **Centralize config access:**
+  - Read environment variables in one place (e.g., a `config` module that exposes typed values).
+  - Business logic, components, and services consume from the config module — not from `process.env` / `os.environ` / equivalent directly.
+  - This makes the set of expected variables auditable in one place.
+
+**Pseudocode example:**
+
+    // ❌ Bad — env access scattered, no validation
+    function fetchUsers() {
+        return fetch(process.env.API_URL + "/users")
+    }
+
+    // ✅ Good — centralized, validated config
+    // config.js
+    export const config = {
+        apiUrl: requireEnv("API_URL"),
+        // ... other typed values
+    }
+
+    // userService.js
+    import { config } from "./config"
+    function fetchUsers() {
+        return fetch(`${config.apiUrl}/users`)
+    }
+
+> **Why:** Centralized config makes deployments safer (one place to audit required env vars), tests easier (mock the config module), and rotation simpler (change in one place). Scattered env access creates silent failures when a variable is missing in some environments but not others.
+
+## Side Effects
+
+- **Default to pure functions** — input in, output out, no external state changes.
+- When side effects are necessary (network, file system, database, UI mutation), **isolate them in clearly named functions** (`saveUser`, `fetchOrders`).
+- Avoid mixing pure logic and side effects in the same function.
+
+> **Why:** Pure functions are trivially testable. Side-effecting code requires mocks, fixtures, and integration setup.
+
+## Duplication
+
+- **Rule of three:** extract shared logic on the *third* repetition, not the second.
+- Two similar pieces of code might diverge over time — premature deduplication creates the wrong abstraction.
+- When extracting, the abstraction must capture *shared intent*, not just *shared syntax*.
+
+> **Why:** The wrong abstraction costs more than duplication. Wait until the pattern is real.
+
+## Comments
+
+- **Explain *why*, not *what*.** Code already shows what it does.
+- Delete commented-out code. Use version control history instead.
+- `TODO` / `FIXME` comments must include context: who wrote it, when, and why.
+
+**Pseudocode example:**
+
+    // ❌ Bad — restates the code
+    // Increment counter
+    counter += 1
+
+    // ✅ Good — explains a non-obvious decision
+    // Counter resets at midnight UTC to align with billing cycle.
+    counter += 1
+
+## Logging
+
+- **No debug prints in production paths.** `console.log`, `print()`, `dump()`, equivalents — these are debugging artifacts, not production logging.
+- **Use a real logging library** with levels (debug, info, warn, error). What gets logged where, and at what verbosity, becomes configurable per environment.
+- **Log structured data, not concatenated strings.** Logs that include data as fields (`{ user_id: 123, action: "login" }`) are searchable; logs as concatenated text (`"user 123 did login"`) are not.
+- **Don't log secrets.** Never log passwords, tokens, full credit card numbers, or other sensitive fields. Mask or omit them.
+- **Don't log noise.** Successful happy-path operations rarely need INFO logs in production — they fill log storage and obscure real issues.
+
+**Pseudocode example:**
+
+    // ❌ Bad — debug print, unstructured, leaks data
+    console.log("user logged in: " + user.email + " token: " + token)
+
+    // ✅ Good — structured, intentional level, no secret leakage
+    logger.info("user_login_succeeded", {
+        user_id: user.id,
+        // email and token deliberately omitted
+    })
+
+> **Why:** Production logs are a debugging tool, a security surface, and a cost line item. Debug prints fail all three: they're inconsistent, can leak secrets, and pile up storage costs. Structured logging with discipline makes incidents debuggable without making them expensive or risky.
+
+## Imports / Dependencies
+
+- Group imports logically: external libraries → internal modules → local files.
+- Remove unused imports before finishing.
+- Don't add a dependency without confirming it's necessary and not already available.
+
+## File Organization
+
+- One primary export per file when the language supports it.
+- File name should match the primary export.
+- Co-locate tightly coupled code (tests next to source, types next to implementation) when conventional for the language.

package/skillhub-registry/rules/frontend/antipattern.md

@@ -0,0 +1,21 @@
+# Frontend Anti-Patterns
+
+## Purpose
+
+Use this rule file when reviewing or generating frontend application code.
+
+## Avoid
+
+- Putting API calls directly inside presentational components.
+- Mixing business logic, validation, and JSX in one large component.
+- Creating untyped `any` data contracts for API responses.
+- Using client components by default in Next.js App Router.
+- Ignoring loading, empty, error, and permission states.
+- Creating duplicated form logic instead of reusable hooks or schema helpers.
+- Mutating shared state directly.
+- Adding UI libraries without checking project conventions.
+- Shipping inaccessible controls without labels, focus states, or keyboard support.
+
+## Required Review
+
+Before final output, check whether the implementation follows existing project structure, naming rules, TypeScript typing, accessibility basics, and error handling.

package/skillhub-registry/rules/frontend/component-standards.md

@@ -0,0 +1,10 @@
+# Frontend Component Standards
+
+## Rules
+
+- Keep UI components small, typed, and composable.
+- Prefer server components unless interactivity is needed.
+- Keep feature-specific components inside the feature folder.
+- Keep reusable primitives under shared components.
+- Use clear prop names and avoid boolean-prop explosions.
+- Handle loading, empty, and error states close to the UI boundary.

package/skillhub-registry/rules/frontend-app.md

@@ -0,0 +1,24 @@
+# Frontend App Rules
+
+## Purpose
+
+Use these always-on rules when building frontend features.
+
+## Rules
+
+- Match the existing frontend architecture before adding new structure.
+- Use feature folders for medium and large applications.
+- Keep API clients, validation schemas, and UI components separate.
+- Every user-facing async state must handle loading, empty, error, and success.
+- Accessibility is not optional decoration. Buttons need names, forms need labels, focus must be visible.
+- Do not add a new package when the project already has an equivalent solution.
+- Do not invent APIs or assume backend payloads. Confirm with types, schema, docs, or existing calls.
+
+## Review Checklist
+
+- [ ] Types are explicit
+- [ ] Component names are clear
+- [ ] No business logic buried in JSX
+- [ ] No hardcoded secrets or environment-specific URLs
+- [ ] UI works on mobile and desktop
+- [ ] Error messages are human-readable

package/skillhub-registry/rules/general.md

@@ -0,0 +1,51 @@
+# General Coding Rules
+
+Status: **Universal — applies to all coding tasks**
+Last updated: 2026-05-06
+Owner: [Raj Shah]
+
+These are the non-negotiable foundations. They apply to every language, every project, every developer using Claude with this template. Exceptions require a documented case via the [exception process](../docs/exception-process.md).
+
+## The Four Foundations
+
+### 1. Match the existing codebase before applying these rules
+When editing existing code, follow the conventions of that codebase — even if they conflict with rules below. Consistency within a project is more valuable than consistency with this template.
+
+> **Why:** Mixing styles within a single file is harder to read than either style alone. The cost of converting a whole codebase is rarely worth the benefit.
+
+### 2. Never invent APIs, library functions, or syntax
+If you are not certain a function/method/library exists, say so explicitly. Do not produce plausible-looking code that might not work. Better to ask "does your project use lodash?" than to call `_.cloneDeepWith()` and hope.
+
+> **Why:** Hallucinated code is the #1 cause of wasted time when using AI assistants. Saying "I don't know" is faster than debugging fake APIs.
+
+### 3. Ask one clarifying question when the request is ambiguous
+If the requirement could reasonably be interpreted two ways, ask before coding. One short question now saves a full rewrite later. Limit yourself to **one** question — don't interrogate.
+
+> **Why:** Silent assumptions are the most expensive mistakes. They look right until they aren't.
+
+### 4. Prefer the simplest solution that fully solves the problem
+Default to the most boring, obvious approach. Add complexity only when a *current* requirement forces it — never for imagined future needs.
+
+> **Why:** Speculative complexity ages badly. The "flexibility" you build today usually doesn't match what you actually need tomorrow.
+
+## When You're Uncertain
+
+State uncertainty explicitly:
+- ✅ "I'm not sure if your project uses TypeScript strict mode — can you confirm?"
+- ❌ Producing code that assumes one way and silently fails the other
+
+State limitations explicitly:
+- ✅ "I can't run the tests, but here's what I'd expect to pass."
+- ❌ "All tests pass." (when you didn't run them)
+
+## Scope Discipline
+
+Do exactly what was asked. Do not:
+- Refactor unrelated code "while you're there"
+- Add features that weren't requested
+- Rename things that work
+- Reformat files beyond your changes
+
+If you spot something that *should* be fixed, mention it briefly at the end. Don't fix it unsolicited.
+
+> **Why:** Scope creep in AI-assisted edits creates massive review burden and merges get rejected. Stay in your lane.

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

@@ -0,0 +1,167 @@
+---
+name: api
+description: Universal API design and implementation standards covering naming, input validation, error responses, versioning, pagination, idempotency, authentication, rate limiting, and contract design for REST, GraphQL, RPC, and internal service APIs. Use this skill whenever the user works on API endpoints, designs API contracts, modifies API responses, debugs API issues, writes API handlers, defines API schemas, mentions REST, GraphQL, gRPC, RPC, OpenAPI, Swagger, JSON Schema, status codes, HTTP methods, request/response shapes, API versioning, or backend services. Apply when reviewing API code, building new endpoints, refactoring API surfaces, integrating external APIs, designing webhooks, or discussing API architecture. Trigger when the user mentions endpoints, routes, handlers, controllers, or any HTTP-related work. Also load `domain/api.md` for org-specific conventions when working in this codebase.
+---
+
+# API Skill
+
+This skill applies universal API design standards. It loads whenever the user works on API design or implementation.
+
+These rules layer on top of `rules/general.md`, `rules/code-standards.md`, and `rules/anti-patterns.md`.
+
+**Important:** This skill covers universal best practices. Org-specific conventions (your envelope shape, your auth header, your pagination style) live in `domain/api.md` — read both when working in this codebase.
+
+---
+
+## Naming
+
+- **Resources are nouns, not verbs.** ✅ `/users` ❌ `/getUsers`
+- **Plural for collections, singular for single resources.** ✅ `/users/123` ❌ `/user/123`
+- **Lowercase with hyphens for path segments.** ✅ `/user-profiles` ❌ `/userProfiles` or `/user_profiles`
+- **camelCase or snake_case for JSON fields** — pick one and stay consistent across the entire API
+- **Verbs only for actions that don't fit CRUD** — ✅ `POST /orders/123/cancel` when "cancel" isn't a normal update
+
+## HTTP Methods (REST)
+
+| Method | Use for | Idempotent? | Body? |
+|---|---|---|---|
+| `GET` | Read | Yes | No |
+| `POST` | Create, or actions that don't fit CRUD | No | Yes |
+| `PUT` | Replace entire resource | Yes | Yes |
+| `PATCH` | Partial update | Usually | Yes |
+| `DELETE` | Remove | Yes | No |
+
+- **Don't use `GET` for state changes.** Browsers, caches, and crawlers replay GETs freely.
+- **`PUT` requires the full resource.** If the client sends a partial, use `PATCH`.
+
+## Status Codes
+
+Use the standard ones; don't invent meaning:
+
+| Code | When |
+|---|---|
+| `200` | Success with body |
+| `201` | Created (return the resource or its location) |
+| `204` | Success, no body |
+| `400` | Client sent malformed/invalid data |
+| `401` | Not authenticated |
+| `403` | Authenticated but not authorized |
+| `404` | Resource doesn't exist |
+| `409` | Conflict (e.g., duplicate, version mismatch) |
+| `422` | Semantically invalid (validation failed) |
+| `429` | Rate limited |
+| `500` | Server error (your bug) |
+| `502/503/504` | Upstream / availability issues |
+
+- **Don't return `200 OK` with an error in the body.** That breaks every HTTP-aware tool.
+- **Don't use `404` to hide authorization failures.** Use `403`. (Exception: when leaking existence is itself a security risk — but document that decision.)
+
+## Request Validation
+
+- **Validate at the boundary.** Reject invalid requests *before* business logic runs.
+- **Use a schema validator** (Zod, Yup, JSON Schema, Pydantic, etc.) — not hand-rolled `if` checks.
+- **Reject early, reject specifically.** Tell the client what was wrong, not just that it was wrong.
+- **Whitelist allowed fields.** Don't accept arbitrary fields and let the database sort it out.
+- **Validate types AND constraints.** A string is not enough — is it a non-empty string? A valid email? A length-bounded string?
+
+## Error Response Shape
+
+Pick **one** error envelope and use it everywhere. A common shape:
+
+```json
+
+{
+"error": {
+"code": "VALIDATION_FAILED",
+"message": "Human-readable summary",
+"details": [
+{ "field": "email", "issue": "must be a valid email address" }
+],
+"request_id": "req_abc123"
+}
+}
+
+Rules:
+
+- **`code` is a stable machine-readable identifier.** Clients pattern-match on this. Never change it without versioning.
+- **`message` is for humans.** Can be localized, can be reworded freely.
+- **`details` for field-level issues.** Lets clients display per-field errors.
+- **`request_id` for support.** Lets users report errors and engineers trace them in logs.
+- **Don't leak internals.** No stack traces, no SQL fragments, no internal service names.
+
+## Pagination
+
+For any list endpoint that could return >100 items:
+
+- **Cursor-based** is preferred for stable, scalable pagination. Returns `next_cursor` to continue.
+- **Offset-based** is acceptable for small, stable data sets but breaks with concurrent inserts.
+- **Always paginate.** Never return unbounded result sets, even if "currently it's small."
+- **Document the default and max page size.** Clients shouldn't have to guess.
+
+## Versioning
+
+- **Version the API from day one.** ✅ `/v1/users` — even if v2 doesn't exist yet.
+- **Pick one strategy:** URI path (`/v1/`), header (`API-Version: 1`), or accept header (`application/vnd.org.v1+json`). Don't mix.
+- **Breaking changes require a new version.** Adding a field is not breaking. Removing or changing one is.
+- **Maintain old versions for a stated deprecation window** — communicate the timeline.
+
+## Idempotency
+
+- **`GET`, `PUT`, `DELETE` are naturally idempotent.** Same request, same effect.
+- **`POST` is naturally not idempotent.** For payment-like or critical operations, accept an `Idempotency-Key` header so retries don't double-charge.
+- **Document idempotency expectations** for every mutating endpoint. Clients need to know what's safe to retry.
+
+## Authentication & Authorization
+
+- **Authentication answers "who are you?"** — handled by middleware, before the handler runs.
+- **Authorization answers "are you allowed?"** — handled inside the handler, with awareness of the specific resource.
+- **Never trust the client's assertion of identity.** Validate tokens server-side every time.
+- **Authorize on the data, not just the route.** A user passing route-level auth might still not own *this specific* resource.
+- **Don't include sensitive data in URLs.** URLs end up in logs, browser history, referrer headers.
+- **Use HTTPS only.** No exceptions for "internal" services that might leak.
+
+## Rate Limiting
+
+- **Rate-limit every public endpoint.** Even reads. Even authenticated.
+- **Return `429 Too Many Requests`** with a `Retry-After` header.
+- **Different limits for different endpoints** — login attempts should be stricter than reads.
+- **Per-user, per-IP, per-key.** Layered limits catch different abuse patterns.
+
+## Caching
+
+- **Cache `GET` aggressively** with `Cache-Control` headers — `public`, `private`, `max-age`, `no-store` mean specific things; use them deliberately.
+- **`ETag` and `If-None-Match`** to enable conditional requests.
+- **Never cache responses that contain user-specific data** in a shared cache.
+- **Invalidate on writes** — a `PUT` to `/users/123` should bust the cache for that resource.
+
+## Avoiding Over- and Under-Fetching
+
+- **Don't return what the client doesn't need** — extra fields cost bandwidth and leak info.
+- **Don't force the client to make N follow-up calls** — design endpoints around the client's actual needs.
+- **GraphQL solves this natively.** REST APIs use sparse fieldsets (`?fields=id,name`) or expansion params (`?expand=author`).
+
+## Webhooks (If Applicable)
+
+- **Sign every webhook payload.** HMAC with a shared secret. The receiver must verify.
+- **Make webhooks idempotent.** Retries will happen.
+- **Include event ID and timestamp** in every payload for dedup and ordering.
+- **Document retry policy** — receivers need to know what `2xx` means and what triggers a retry.
+
+## Documentation
+
+- **Spec-first or code-first** — pick one (OpenAPI, GraphQL Schema, Protobuf) and keep it in sync with reality.
+- **Examples for every endpoint.** Real request/response samples. Not just type definitions.
+- **Document error cases.** What `code` values can this endpoint return, under what conditions.
+
+## When You're Unsure
+
+- **Check `domain/api.md`** for org-specific conventions before applying universal defaults.
+- **Match existing endpoints in the codebase.** Consistency within an API beats theoretical purity.
+- **Ask before introducing a new pattern.** If your suggested error shape differs from the codebase's, surface that.
+
+## What This Skill Does NOT Cover
+
+- **Database design** — that's a separate concern
+- **Frontend integration with APIs** — see `skills/react` for client-side patterns
+- **Deployment and infrastructure** — separate domain
+- **Org-specific decisions** (envelope shape, header names, auth flow) → see `domain/api.md`

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

@@ -0,0 +1,114 @@
+---
+name: build
+description: Structured implementation workflow for building new features, components, functions, modules, or any net-new code. Use this skill whenever the user invokes /build, asks to "build", "implement", "create", "add", "write", or "make" something — a feature, function, component, endpoint, module, page, hook, utility, service, or class. Apply when the user is starting fresh code rather than modifying existing code (use /refactor for that) or evaluating existing code (use /review for that). Trigger when the user says things like "build me a X", "implement Y", "I need a function that does Z", "add a feature for W", or "create a component for V".
+---
+
+# Build Skill
+
+This skill applies the org's standard implementation workflow. It loads when the user is creating new code.
+
+These rules layer on top of `rules/general.md`, `rules/code-standards.md`, and `rules/anti-patterns.md`. If a domain skill (`react`, `testing`, `performance`) also triggers, apply both.
+
+---
+
+## The Build Workflow
+
+Follow these steps in order. Don't skip steps unless a step is genuinely irrelevant to the task.
+
+### Step 1: Understand the Task
+
+Restate the requirement in your own words. Specifically clarify:
+
+- **What is the user-visible behavior?** (the *what*)
+- **What inputs does it accept?**
+- **What outputs does it produce?**
+- **What does success look like?**
+- **What's explicitly out of scope?**
+
+If any of these are unclear, ask **one** clarifying question before continuing. Don't write code based on assumptions.
+
+### Step 2: Identify Edge Cases
+
+Before writing code, list the edge cases that matter:
+
+- Empty input (`""`, `[]`, `{}`, `null`, `undefined`)
+- Boundary values (zero, negative, max-size)
+- Invalid types
+- Network / IO failures (if applicable)
+- Concurrent access (if applicable)
+- Permission / authorization edge cases
+- Already-existing entity / non-existent entity
+
+State which ones you're handling and which ones you're explicitly *not* handling (and why).
+
+### Step 3: Plan Briefly
+
+State the approach in 2-4 bullets. For non-trivial tasks, also note:
+
+- One alternative you considered
+- Why you rejected it
+
+This is not architecture documentation — it's a sanity check that you've thought about it. Keep it short.
+
+### Step 4: Write the Code
+
+Apply all loaded rules and skills:
+
+- Match the existing codebase style first
+- Apply `rules/code-standards.md` (function size, nesting, naming, errors)
+- Avoid every anti-pattern in `rules/anti-patterns.md`
+- If a domain skill is active, apply its rules too
+
+### Step 5: Refactor for Clarity
+
+Before declaring done, re-read the code as if you were a reviewer:
+
+- Are all variables / functions named meaningfully?
+- Is anything nested deeper than 3 levels?
+- Are there any magic values?
+- Are there any silent error swallows?
+- Does the code do anything beyond the stated scope? (Remove if so.)
+
+### Step 6: Validate Against Requirements
+
+Walk through the original requirements one more time:
+
+- Does the code actually do what was asked?
+- Are the edge cases from Step 2 actually handled?
+- Are there any obvious test cases that would currently fail?
+
+## Output Format
+
+For build tasks, structure the response as:
+
+[Optional: 1-2 sentence summary of the approach taken — only if non-obvious]
+[The code]
+[Optional: notes on edge cases not handled, follow-up TODOs, or assumptions made — only if relevant]
+
+Skip empty sections. Don't include "Here's the code:" preambles or closing summaries that just restate what the code does.
+
+## Tests
+
+If a domain demands tests (covered by `rules/general.md` and `skills/testing`), include them. If you're skipping tests deliberately (Fast Mode, prototype, user said no tests), state that briefly.
+
+## When to Ask Before Building
+
+Ask one clarifying question, then build, when:
+
+- The requirement could reasonably be interpreted two ways
+- The task implies design decisions (where does this file go? what's the API shape?)
+- The task touches an unfamiliar part of the codebase
+
+Don't ask, just build, when:
+
+- The requirement is concrete and unambiguous
+- The codebase pattern is clear from context
+- It's a trivial, isolated piece of code
+
+## What This Skill Does NOT Cover
+
+- **Modifying existing code** → use `/refactor`
+- **Reviewing existing code** → use `/review`
+- **Multi-step features that span multiple files** → use `/feature-dev` workflow
+
+If the user asks for something that spans skills, apply all relevant ones together.

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

@@ -0,0 +1,56 @@
+---
+name: fast
+description: Activates Fast Mode for quick prototyping and rapid iteration. Use this skill whenever the user invokes /fast, says "fast mode", "quick and dirty", "just hack it together", "I need this fast", "rough version", "MVP version", "throwaway code", "prototype this", or otherwise signals they want speed over polish. Apply when the user explicitly prioritizes shipping over quality, when iterating on an idea that may be discarded, or when exploring a solution before committing to one. Do NOT trigger this for production code, code marked for review, or when the user requests "clean", "production-ready", "robust", or "thorough".
+---
+
+# Fast Mode
+
+This skill switches Claude into rapid-iteration mode. It explicitly relaxes some `rules/` constraints in exchange for speed.
+
+This is a deliberate trade-off — Fast Mode is for prototyping, not production.
+
+---
+
+## What Changes in Fast Mode
+
+### Relaxed
+- ✅ Skip exhaustive edge case analysis
+- ✅ Skip over-engineering (no abstractions, no flexibility hooks)
+- ✅ Minimal explanation in output
+- ✅ "Good enough" beats "perfect"
+- ✅ Inline ad-hoc constants instead of extracting them
+- ✅ Skip writing tests unless explicitly requested
+- ✅ Don't refactor existing code while adding features
+
+### Still Enforced
+- 🔒 No hallucinated APIs or libraries (`rules/general.md` — non-negotiable)
+- 🔒 No silent error swallowing (failures must surface)
+- 🔒 Match existing codebase style (don't introduce inconsistency)
+- 🔒 No security shortcuts (auth, secrets, input validation stay strict)
+- 🔒 No deletion or destructive operations without confirmation
+
+## Behavior
+
+- **Lead with the code.** Skip preamble, skip recap.
+- **Pick obvious solutions.** Don't deliberate between approaches.
+- **Don't optimize anything.** Premature optimization wastes the point of Fast Mode.
+- **Flag debt explicitly.** End with one short line: `// FIXME(fast-mode): explain X edge case if this becomes real code`.
+- **Don't apologize for not testing / not handling all cases.** The user knows.
+
+## When the User Might Misuse This Mode
+
+If the user invokes `/fast` for something that looks like:
+- Production code
+- Security-sensitive code (auth, payment, PII)
+- Code that will be merged to main
+- Database migrations or destructive operations
+
+→ **Briefly confirm:** "Fast mode for production code is risky — confirm you want speed over correctness here?" Then proceed if confirmed.
+
+## Output Format in Fast Mode
+
+- Code first, talking later
+- No "Here's the code:" preamble
+- No closing summary
+- One-line FIXME comments only where critical
+- Skip the "I considered alternatives" reasoning