Initial release: 100-file Claude Code toolkit

20 specialized agents, 10 skills, 17 slash commands, 6 plugins,
12 hooks with scripts, 8 rule sets, 3 CLAUDE.md templates,
14 MCP server configs, and interactive setup installer.

rules/agents.md

@@ -0,0 +1,44 @@
+# Agent Rules
+
+## When to Use Subagents
+- Use a subagent for tasks that require focused expertise (security audit, performance analysis, test generation).
+- Use a subagent when the main task would exceed the context window if done inline.
+- Use a subagent for parallel work streams that do not depend on each other.
+- Do not use a subagent for simple, single-step tasks. The overhead is not worth it.
+
+## Subagent Design
+- Give each subagent a clear, single responsibility and a defined scope.
+- Specify the tools the subagent is allowed to use. Restrict to the minimum needed.
+- Provide the subagent with relevant context, not the entire conversation history.
+- Set explicit success criteria: what output is expected and in what format.
+
+## Token Budget Management
+- Track approximate token usage across the session.
+- Use `/compact` when approaching 60% of the context window.
+- Prefer reading specific file sections over entire files.
+- Summarize findings instead of copying large code blocks verbatim.
+- Use glob and grep to find relevant code before reading full files.
+
+## Progressive Disclosure
+- Start with the high-level structure before diving into details.
+- Show the plan before executing it. Get confirmation on the approach.
+- Report progress incrementally: what was done, what is next.
+- Surface important decisions that need human input early in the process.
+
+## Task Decomposition
+- Break complex tasks into 3-7 sequential steps.
+- Each step should produce a verifiable intermediate result.
+- If a step fails, the previous steps should still be valid.
+- Use checklists to track progress on multi-step tasks.
+
+## Safety and Guardrails
+- Never run destructive commands (rm -rf, DROP TABLE, force push) without explicit confirmation.
+- Validate assumptions before acting on them. Read the code before modifying it.
+- Prefer reversible changes. Commit before refactoring so rollback is easy.
+- When uncertain, ask rather than guess. A wrong assumption costs more than a clarifying question.
+
+## Communication Style
+- Be direct and specific. State what you did, what you found, and what you recommend.
+- When presenting options, list tradeoffs for each. Recommend one with reasoning.
+- If something will take multiple steps, outline them upfront with estimated effort.
+- After completing a task, summarize what changed and what to verify.

rules/coding-style.md

@@ -0,0 +1,36 @@
+# Coding Style
+
+## Naming Conventions
+- Variables and functions: camelCase (JS/TS), snake_case (Python/Rust/Go).
+- Classes and types: PascalCase in all languages.
+- Constants: UPPER_SNAKE_CASE for true constants, camelCase for derived values.
+- Booleans: prefix with `is`, `has`, `can`, `should` (e.g., `isActive`, `hasPermission`).
+- Files: kebab-case for most files, PascalCase for React components.
+
+## File Organization
+- One exported concept per file. If a file has multiple unrelated exports, split it.
+- Group files by feature (not by type) in larger projects.
+- Keep files under 300 lines. If longer, extract sub-modules.
+- Index files should only re-export, never contain logic.
+
+## Import Ordering
+1. Standard library / built-in modules.
+2. External packages (node_modules, pip packages).
+3. Internal absolute imports (from project root).
+4. Relative imports (from current directory).
+5. Type-only imports last.
+- Blank line between each group. Alphabetical within each group.
+
+## Code Clarity
+- No magic numbers. Extract named constants with descriptive names.
+- No nested ternaries. Use if/else or extract to a function.
+- Maximum function length: 40 lines. If longer, extract helpers.
+- Maximum function parameters: 3. Use an options object for more.
+- Prefer explicit over implicit. Avoid clever one-liners that sacrifice readability.
+- Remove all dead code. Do not comment out code "for later."
+
+## Formatting
+- Use the project's formatter (Prettier, Black, gofmt, rustfmt). Do not manually format.
+- Consistent indentation: 2 spaces (JS/TS), 4 spaces (Python), tabs (Go).
+- Trailing commas in multi-line structures (JS/TS).
+- No trailing whitespace. Files end with a single newline.

rules/documentation.md

@@ -0,0 +1,43 @@
+# Documentation Rules
+
+## What to Document
+- Public API functions: parameters, return types, error conditions, examples.
+- Architecture decisions: why a particular approach was chosen (ADRs).
+- Setup and installation: prerequisites, steps, common issues.
+- Configuration: all options, defaults, environment variables.
+- Non-obvious behavior: edge cases, gotchas, workarounds.
+
+## What Not to Document
+- Obvious code (getters, setters, simple wrappers).
+- Implementation details that change frequently.
+- Anything the type system already expresses.
+- Temporary workarounds without a tracking issue.
+
+## Keep Docs Current
+- Update documentation in the same PR that changes the code.
+- Review docs in code review. Stale docs are worse than no docs.
+- Use CI to verify that documentation examples compile or run.
+- Keep CLAUDE.md or AGENTS.md updated with current project context.
+
+## Documentation Formats
+- Inline code comments: explain **why**, not what. One line, placed above the code.
+- JSDoc/docstrings: for public APIs. Include parameters, returns, throws, and an example.
+- README: installation, quick start, configuration, contribution guidelines.
+- CLAUDE.md: project context, conventions, build commands, key architecture decisions.
+- ADRs: date, status, context, decision, consequences. Store in `docs/adr/`.
+
+## Style Guidelines
+- Use concrete examples, not abstract descriptions.
+- Write for the reader who will maintain this code in 6 months.
+- Use consistent terminology. Define domain terms in a glossary if needed.
+- Keep sentences short. One idea per paragraph.
+- Use code blocks with language tags for syntax highlighting.
+- Use tables for option lists, comparison matrices, and configuration references.
+
+## README Structure
+1. Project name and one-line description.
+2. Installation / quick start (copy-paste ready).
+3. Usage examples (the most common use case first).
+4. Configuration reference.
+5. Contributing guidelines.
+6. License.

rules/error-handling.md

@@ -0,0 +1,60 @@
+# Error Handling Rules
+
+## Error Types
+- Define specific error types for different failure categories.
+- Use error codes or error classes, not raw strings.
+- Include context in errors: what operation failed, what input caused it, what was expected.
+- Distinguish between client errors (bad input) and server errors (internal failure).
+
+## Error Chains
+- Wrap lower-level errors with context when propagating up the stack.
+- Preserve the original error as a `cause` for debugging.
+- Do not swallow errors silently. If you catch, either handle it or re-throw with context.
+- Log the full error chain at the point where the error is finally handled.
+
+```typescript
+try {
+  await db.query(sql);
+} catch (err) {
+  throw new DatabaseError("Failed to fetch user by email", { cause: err });
+}
+```
+
+## User-Facing Messages
+- Show clear, actionable messages to users. Tell them what happened and what to do next.
+- Never expose stack traces, internal paths, or database details to users.
+- Use error codes that users or support can reference.
+- Provide different detail levels: user message (UI), error code (API), full trace (logs).
+
+## Logging
+- Log errors with structured data: timestamp, error type, message, stack, request context.
+- Use log levels appropriately: ERROR for failures, WARN for degraded behavior, INFO for operations.
+- Include correlation IDs to trace errors across services.
+- Do not log sensitive data (passwords, tokens, PII) even in error messages.
+
+## Recovery Patterns
+- Use retry with exponential backoff for transient failures (network, rate limits).
+- Set maximum retry counts and circuit breakers for external dependencies.
+- Provide fallback values or degraded functionality when non-critical services fail.
+- Use timeouts on all external calls. A hanging request is worse than a failed one.
+
+## API Error Responses
+- Use standard HTTP status codes: 400 (bad input), 401 (unauthenticated), 403 (unauthorized), 404 (not found), 422 (validation), 429 (rate limit), 500 (internal).
+- Return consistent error response shapes across all endpoints.
+- Include a machine-readable error code and a human-readable message.
+
+```json
+{
+  "error": {
+    "code": "VALIDATION_FAILED",
+    "message": "Email format is invalid",
+    "details": [{ "field": "email", "issue": "Must be a valid email address" }]
+  }
+}
+```
+
+## Anti-Patterns
+- Do not use `catch (e) {}` (empty catch blocks).
+- Do not use exceptions for control flow (e.g., using throw to exit a loop).
+- Do not return null/undefined to indicate failure. Use Result types or throw typed errors.
+- Do not log and throw the same error (causes duplicate log entries).

rules/git-workflow.md

@@ -0,0 +1,40 @@
+# Git Workflow
+
+## Commit Messages
+- Follow conventional commits: `type(scope): subject`.
+- Types: feat, fix, refactor, docs, test, chore, perf, style, ci.
+- Subject line: imperative mood, lowercase, no period, max 72 characters.
+- Body: explain why, not what. Wrap at 80 characters.
+- Reference issues: `Closes #123` or `Relates to #456`.
+
+## Branching
+- Create feature branches from main: `feature/short-description`.
+- Use prefixes: `feature/`, `fix/`, `chore/`, `refactor/`, `docs/`.
+- Keep branches short-lived. Merge within 1-3 days.
+- Delete branches after merging.
+
+## Pull Requests
+- One logical change per PR. Do not bundle unrelated changes.
+- Keep PRs under 400 lines of diff when possible.
+- Write a description explaining the motivation, not just the changes.
+- Include a test plan describing how to verify the change.
+- Request review from at least one person.
+- Address all review comments before merging.
+
+## Merge Strategy
+- Squash merge for feature branches (clean history).
+- Merge commit for release branches (preserve history).
+- Never force push to main or shared branches.
+- Rebase feature branches on main before merging to resolve conflicts.
+
+## Safety Rules
+- Never commit secrets, credentials, or API keys.
+- Never commit large binary files. Use Git LFS if needed.
+- Never commit generated files (dist/, build/, node_modules/).
+- Always review `git diff --cached` before committing.
+- Run tests before pushing. If CI fails, fix before merging.
+
+## Tags and Releases
+- Use semantic versioning: MAJOR.MINOR.PATCH.
+- Tag releases on main: `git tag -a v1.2.3 -m "Release 1.2.3"`.
+- Write release notes summarizing changes since last release.

rules/performance.md

@@ -0,0 +1,43 @@
+# Performance Rules
+
+## Loading Strategy
+- Lazy load routes and heavy components. Only load what the user needs right now.
+- Use code splitting at route boundaries.
+- Defer non-critical scripts and stylesheets.
+- Preload critical resources: fonts, above-the-fold images, key API data.
+- Use dynamic imports for features behind user interaction (modals, drawers, editors).
+
+## Caching
+- Cache expensive computations with memoization. Invalidate when inputs change.
+- Set appropriate HTTP cache headers: immutable for hashed assets, short TTL for API responses.
+- Use CDN caching for static assets.
+- Implement application-level caching (Redis, in-memory) for repeated database queries.
+- Always define a cache invalidation strategy before adding a cache.
+
+## Database Performance
+- Add indexes on columns used in WHERE, JOIN, and ORDER BY clauses.
+- Avoid N+1 queries. Use eager loading, joins, or batch queries.
+- Use pagination for list endpoints. Prefer cursor-based over offset-based for large datasets.
+- Profile slow queries with EXPLAIN ANALYZE and optimize them.
+- Use connection pooling. Never open a new connection per request.
+- Keep transactions short. Do not hold locks during I/O operations.
+
+## API Performance
+- Minimize payload size. Return only the fields the client needs.
+- Use compression (gzip/brotli) for API responses.
+- Implement request batching for clients that need multiple resources.
+- Add request timeouts on both client and server sides.
+- Use streaming for large responses instead of buffering everything in memory.
+
+## Frontend Performance
+- Optimize images: use WebP/AVIF, responsive sizes, lazy loading for below-the-fold.
+- Minimize JavaScript bundle size. Track it in CI with bundle analyzer.
+- Avoid layout shifts: set explicit dimensions on images and dynamic content.
+- Debounce user input handlers (search, resize, scroll).
+- Use `requestAnimationFrame` for visual updates, not `setTimeout`.
+
+## Monitoring
+- Measure before optimizing. Use profiling tools, not intuition.
+- Set performance budgets: bundle size, Time to Interactive, API response time.
+- Alert on P95/P99 latency, not just averages.
+- Log slow queries and slow API responses for investigation.

rules/security.md

@@ -0,0 +1,40 @@
+# Security Rules
+
+## Secrets Management
+- Never hardcode secrets, API keys, tokens, or passwords in source code.
+- Use environment variables or a secrets manager (AWS Secrets Manager, Vault, Doppler).
+- Add `.env`, `.env.local`, and credential files to `.gitignore`.
+- Rotate secrets immediately if they are accidentally committed.
+- Use different secrets for development, staging, and production.
+
+## Input Validation
+- Validate all external inputs at the system boundary (API endpoints, CLI args, file uploads).
+- Use schema validation libraries (Zod, Joi, Pydantic) rather than manual checks.
+- Reject invalid input early. Do not try to sanitize and proceed.
+- Enforce length limits, type constraints, and allowed character sets.
+- Validate file uploads: type, size, filename, and content.
+
+## Output Encoding
+- Escape user-provided data before rendering in HTML, SQL, shell, or logs.
+- Use parameterized queries for all database operations. Never string-interpolate SQL.
+- Use template engines with auto-escaping enabled.
+- Sanitize data in log messages to prevent log injection.
+
+## Authentication and Authorization
+- Hash passwords with bcrypt (cost 12+) or argon2. Never use MD5 or SHA1 for passwords.
+- Implement rate limiting on authentication endpoints.
+- Use short-lived tokens (15 minutes for access, 7 days for refresh).
+- Check authorization on every request at the API layer, not just the UI.
+- Use the principle of least privilege for all service accounts and API keys.
+
+## Dependencies
+- Run `npm audit` / `pip audit` / `cargo audit` in CI.
+- Update dependencies with known vulnerabilities within 48 hours for critical, 7 days for high.
+- Pin exact versions in production. Use ranges only in libraries.
+- Review new dependencies before adding them. Check maintenance status and download counts.
+
+## HTTP Security
+- Set security headers: CSP, HSTS, X-Content-Type-Options, X-Frame-Options.
+- Use HTTPS everywhere. Redirect HTTP to HTTPS.
+- Set cookie attributes: HttpOnly, Secure, SameSite=Strict.
+- Implement CORS with explicit allowed origins. Never use wildcard in production.

rules/testing.md

@@ -0,0 +1,43 @@
+# Testing Rules
+
+## Test Before Commit
+- Run the relevant test suite before every commit.
+- All tests must pass before pushing to a shared branch.
+- Never merge a PR with failing tests.
+- If a test is flaky, fix it immediately or quarantine with a tracking issue.
+
+## Coverage Requirements
+- Minimum 80% line coverage on new code.
+- Minimum 75% branch coverage on new code.
+- Coverage should not decrease on any PR.
+- Exclude generated code, type definitions, and config from coverage metrics.
+
+## Test Quality
+- Test behavior, not implementation. Tests should survive refactoring.
+- Each test case tests exactly one thing. One assertion per logical behavior.
+- Tests must be independent. No shared mutable state. No execution order dependency.
+- Use descriptive names: `should_reject_expired_token` over `test_token_3`.
+
+## Test Organization
+- Mirror source directory structure in test directories.
+- Keep test utilities and fixtures in a shared `__tests__/helpers` or `testutils` directory.
+- Mark slow tests (>5s) so they can be excluded from fast feedback loops.
+
+## Mocking Rules
+- Mock at boundaries: HTTP, database, filesystem, clock, randomness.
+- Never mock the unit under test.
+- Prefer fakes (in-memory implementations) over mocks for complex interfaces.
+- Assert on behavior and outputs, not on how many times a mock was called.
+
+## CI Integration
+- No `skip` or `todo` tests in the main branch. Fix or remove them.
+- Run tests in CI on every push and every PR.
+- Fail the build if coverage drops below thresholds.
+- Run tests in parallel where possible to keep CI fast.
+- Set a timeout on test suites to catch infinite loops (10 minutes max).
+
+## Anti-Patterns
+- Do not write tests that pass when the code under test is deleted.
+- Do not test private methods directly. Test through the public interface.
+- Do not ignore test failures by increasing timeouts.
+- Do not copy-paste tests. Parameterize instead.