mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-03-30 13:43:26 +08:00
merge: PR #529 — feat(skills): add documentation-lookup, bun-runtime, nextjs-turbopack; feat(agents): add rust-reviewer
This commit is contained in:
84
.agents/skills/bun-runtime/SKILL.md
Normal file
84
.agents/skills/bun-runtime/SKILL.md
Normal file
@@ -0,0 +1,84 @@
|
||||
---
|
||||
name: bun-runtime
|
||||
description: Bun as runtime, package manager, bundler, and test runner. When to choose Bun vs Node, migration notes, and Vercel support.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Bun Runtime
|
||||
|
||||
Bun is a fast all-in-one JavaScript runtime and toolkit: runtime, package manager, bundler, and test runner.
|
||||
|
||||
## When to Use
|
||||
|
||||
- **Prefer Bun** for: new JS/TS projects, scripts where install/run speed matters, Vercel deployments with Bun runtime, and when you want a single toolchain (run + install + test + build).
|
||||
- **Prefer Node** for: maximum ecosystem compatibility, legacy tooling that assumes Node, or when a dependency has known Bun issues.
|
||||
|
||||
Use when: adopting Bun, migrating from Node, writing or debugging Bun scripts/tests, or configuring Bun on Vercel or other platforms.
|
||||
|
||||
## How It Works
|
||||
|
||||
- **Runtime**: Drop-in Node-compatible runtime (built on JavaScriptCore, implemented in Zig).
|
||||
- **Package manager**: `bun install` is significantly faster than npm/yarn. Lockfile is `bun.lock` (text) by default in current Bun; older versions used `bun.lockb` (binary).
|
||||
- **Bundler**: Built-in bundler and transpiler for apps and libraries.
|
||||
- **Test runner**: Built-in `bun test` with Jest-like API.
|
||||
|
||||
**Migration from Node**: Replace `node script.js` with `bun run script.js` or `bun script.js`. Run `bun install` in place of `npm install`; most packages work. Use `bun run` for npm scripts; `bun x` for npx-style one-off runs. Node built-ins are supported; prefer Bun APIs where they exist for better performance.
|
||||
|
||||
**Vercel**: Set runtime to Bun in project settings. Build: `bun run build` or `bun build ./src/index.ts --outdir=dist`. Install: `bun install --frozen-lockfile` for reproducible deploys.
|
||||
|
||||
## Examples
|
||||
|
||||
### Run and install
|
||||
|
||||
```bash
|
||||
# Install dependencies (creates/updates bun.lock or bun.lockb)
|
||||
bun install
|
||||
|
||||
# Run a script or file
|
||||
bun run dev
|
||||
bun run src/index.ts
|
||||
bun src/index.ts
|
||||
```
|
||||
|
||||
### Scripts and env
|
||||
|
||||
```bash
|
||||
bun run --env-file=.env dev
|
||||
FOO=bar bun run script.ts
|
||||
```
|
||||
|
||||
### Testing
|
||||
|
||||
```bash
|
||||
bun test
|
||||
bun test --watch
|
||||
```
|
||||
|
||||
```typescript
|
||||
// test/example.test.ts
|
||||
import { expect, test } from "bun:test";
|
||||
|
||||
test("add", () => {
|
||||
expect(1 + 2).toBe(3);
|
||||
});
|
||||
```
|
||||
|
||||
### Runtime API
|
||||
|
||||
```typescript
|
||||
const file = Bun.file("package.json");
|
||||
const json = await file.json();
|
||||
|
||||
Bun.serve({
|
||||
port: 3000,
|
||||
fetch(req) {
|
||||
return new Response("Hello");
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Commit the lockfile (`bun.lock` or `bun.lockb`) for reproducible installs.
|
||||
- Prefer `bun run` for scripts. For TypeScript, Bun runs `.ts` natively.
|
||||
- Keep dependencies up to date; Bun and the ecosystem evolve quickly.
|
||||
7
.agents/skills/bun-runtime/agents/openai.yaml
Normal file
7
.agents/skills/bun-runtime/agents/openai.yaml
Normal file
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Bun Runtime"
|
||||
short_description: "Bun as runtime, package manager, bundler, and test runner"
|
||||
brand_color: "#FBF0DF"
|
||||
default_prompt: "Use Bun for scripts, install, or run"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
90
.agents/skills/documentation-lookup/SKILL.md
Normal file
90
.agents/skills/documentation-lookup/SKILL.md
Normal file
@@ -0,0 +1,90 @@
|
||||
---
|
||||
name: documentation-lookup
|
||||
description: Use up-to-date library and framework docs via Context7 MCP instead of training data. Activates for setup questions, API references, code examples, or when the user names a framework (e.g. React, Next.js, Prisma).
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Documentation Lookup (Context7)
|
||||
|
||||
When the user asks about libraries, frameworks, or APIs, fetch current documentation via the Context7 MCP (tools `resolve-library-id` and `query-docs`) instead of relying on training data.
|
||||
|
||||
## Core Concepts
|
||||
|
||||
- **Context7**: MCP server that exposes live documentation; use it instead of training data for libraries and APIs.
|
||||
- **resolve-library-id**: Returns Context7-compatible library IDs (e.g. `/vercel/next.js`) from a library name and query.
|
||||
- **query-docs**: Fetches documentation and code snippets for a given library ID and question. Always call resolve-library-id first to get a valid library ID.
|
||||
|
||||
## When to use
|
||||
|
||||
Activate when the user:
|
||||
|
||||
- Asks setup or configuration questions (e.g. "How do I configure Next.js middleware?")
|
||||
- Requests code that depends on a library ("Write a Prisma query for...")
|
||||
- Needs API or reference information ("What are the Supabase auth methods?")
|
||||
- Mentions specific frameworks or libraries (React, Vue, Svelte, Express, Tailwind, Prisma, Supabase, etc.)
|
||||
|
||||
Use this skill whenever the request depends on accurate, up-to-date behavior of a library, framework, or API. Applies across harnesses that have the Context7 MCP configured (e.g. Claude Code, Cursor, Codex).
|
||||
|
||||
## How it works
|
||||
|
||||
### Step 1: Resolve the Library ID
|
||||
|
||||
Call the **resolve-library-id** MCP tool with:
|
||||
|
||||
- **libraryName**: The library or product name taken from the user's question (e.g. `Next.js`, `Prisma`, `Supabase`).
|
||||
- **query**: The user's full question. This improves relevance ranking of results.
|
||||
|
||||
You must obtain a Context7-compatible library ID (format `/org/project` or `/org/project/version`) before querying docs. Do not call query-docs without a valid library ID from this step.
|
||||
|
||||
### Step 2: Select the Best Match
|
||||
|
||||
From the resolution results, choose one result using:
|
||||
|
||||
- **Name match**: Prefer exact or closest match to what the user asked for.
|
||||
- **Benchmark score**: Higher scores indicate better documentation quality (100 is highest).
|
||||
- **Source reputation**: Prefer High or Medium reputation when available.
|
||||
- **Version**: If the user specified a version (e.g. "React 19", "Next.js 15"), prefer a version-specific library ID if listed (e.g. `/org/project/v1.2.0`).
|
||||
|
||||
### Step 3: Fetch the Documentation
|
||||
|
||||
Call the **query-docs** MCP tool with:
|
||||
|
||||
- **libraryId**: The selected Context7 library ID from Step 2 (e.g. `/vercel/next.js`).
|
||||
- **query**: The user's specific question or task. Be specific to get relevant snippets.
|
||||
|
||||
Limit: do not call query-docs (or resolve-library-id) more than 3 times per question. If the answer is unclear after 3 calls, state the uncertainty and use the best information you have rather than guessing.
|
||||
|
||||
### Step 4: Use the Documentation
|
||||
|
||||
- Answer the user's question using the fetched, current information.
|
||||
- Include relevant code examples from the docs when helpful.
|
||||
- Cite the library or version when it matters (e.g. "In Next.js 15...").
|
||||
|
||||
## Examples
|
||||
|
||||
### Example: Next.js middleware
|
||||
|
||||
1. Call **resolve-library-id** with `libraryName: "Next.js"`, `query: "How do I set up Next.js middleware?"`.
|
||||
2. From results, pick the best match (e.g. `/vercel/next.js`) by name and benchmark score.
|
||||
3. Call **query-docs** with `libraryId: "/vercel/next.js"`, `query: "How do I set up Next.js middleware?"`.
|
||||
4. Use the returned snippets and text to answer; include a minimal `middleware.ts` example from the docs if relevant.
|
||||
|
||||
### Example: Prisma query
|
||||
|
||||
1. Call **resolve-library-id** with `libraryName: "Prisma"`, `query: "How do I query with relations?"`.
|
||||
2. Select the official Prisma library ID (e.g. `/prisma/prisma`).
|
||||
3. Call **query-docs** with that `libraryId` and the query.
|
||||
4. Return the Prisma Client pattern (e.g. `include` or `select`) with a short code snippet from the docs.
|
||||
|
||||
### Example: Supabase auth methods
|
||||
|
||||
1. Call **resolve-library-id** with `libraryName: "Supabase"`, `query: "What are the auth methods?"`.
|
||||
2. Pick the Supabase docs library ID.
|
||||
3. Call **query-docs**; summarize the auth methods and show minimal examples from the fetched docs.
|
||||
|
||||
## Best Practices
|
||||
|
||||
- **Be specific**: Use the user's full question as the query where possible for better relevance.
|
||||
- **Version awareness**: When users mention versions, use version-specific library IDs from the resolve step when available.
|
||||
- **Prefer official sources**: When multiple matches exist, prefer official or primary packages over community forks.
|
||||
- **No sensitive data**: Redact API keys, passwords, tokens, and other secrets from any query sent to Context7. Treat the user's question as potentially containing secrets before passing it to resolve-library-id or query-docs.
|
||||
7
.agents/skills/documentation-lookup/agents/openai.yaml
Normal file
7
.agents/skills/documentation-lookup/agents/openai.yaml
Normal file
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Documentation Lookup"
|
||||
short_description: "Fetch up-to-date library docs via Context7 MCP"
|
||||
brand_color: "#6366F1"
|
||||
default_prompt: "Look up docs for a library or API"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
44
.agents/skills/nextjs-turbopack/SKILL.md
Normal file
44
.agents/skills/nextjs-turbopack/SKILL.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
name: nextjs-turbopack
|
||||
description: Next.js 16+ and Turbopack — incremental bundling, FS caching, dev speed, and when to use Turbopack vs webpack.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Next.js and Turbopack
|
||||
|
||||
Next.js 16+ uses Turbopack by default for local development: an incremental bundler written in Rust that significantly speeds up dev startup and hot updates.
|
||||
|
||||
## When to Use
|
||||
|
||||
- **Turbopack (default dev)**: Use for day-to-day development. Faster cold start and HMR, especially in large apps.
|
||||
- **Webpack (legacy dev)**: Use only if you hit a Turbopack bug or rely on a webpack-only plugin in dev. Disable with `--webpack` (or `--no-turbopack` depending on your Next.js version; check the docs for your release).
|
||||
- **Production**: Production build behavior (`next build`) may use Turbopack or webpack depending on Next.js version; check the official Next.js docs for your version.
|
||||
|
||||
Use when: developing or debugging Next.js 16+ apps, diagnosing slow dev startup or HMR, or optimizing production bundles.
|
||||
|
||||
## How It Works
|
||||
|
||||
- **Turbopack**: Incremental bundler for Next.js dev. Uses file-system caching so restarts are much faster (e.g. 5–14x on large projects).
|
||||
- **Default in dev**: From Next.js 16, `next dev` runs with Turbopack unless disabled.
|
||||
- **File-system caching**: Restarts reuse previous work; cache is typically under `.next`; no extra config needed for basic use.
|
||||
- **Bundle Analyzer (Next.js 16.1+)**: Experimental Bundle Analyzer to inspect output and find heavy dependencies; enable via config or experimental flag (see Next.js docs for your version).
|
||||
|
||||
## Examples
|
||||
|
||||
### Commands
|
||||
|
||||
```bash
|
||||
next dev
|
||||
next build
|
||||
next start
|
||||
```
|
||||
|
||||
### Usage
|
||||
|
||||
Run `next dev` for local development with Turbopack. Use the Bundle Analyzer (see Next.js docs) to optimize code-splitting and trim large dependencies. Prefer App Router and server components where possible.
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Stay on a recent Next.js 16.x for stable Turbopack and caching behavior.
|
||||
- If dev is slow, ensure you're on Turbopack (default) and that the cache isn't being cleared unnecessarily.
|
||||
- For production bundle size issues, use the official Next.js bundle analysis tooling for your version.
|
||||
7
.agents/skills/nextjs-turbopack/agents/openai.yaml
Normal file
7
.agents/skills/nextjs-turbopack/agents/openai.yaml
Normal file
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Next.js Turbopack"
|
||||
short_description: "Next.js 16+ and Turbopack dev bundler"
|
||||
brand_color: "#000000"
|
||||
default_prompt: "Next.js dev, Turbopack, or bundle optimization"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
84
.cursor/skills/bun-runtime/SKILL.md
Normal file
84
.cursor/skills/bun-runtime/SKILL.md
Normal file
@@ -0,0 +1,84 @@
|
||||
---
|
||||
name: bun-runtime
|
||||
description: Bun as runtime, package manager, bundler, and test runner. When to choose Bun vs Node, migration notes, and Vercel support.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Bun Runtime
|
||||
|
||||
Bun is a fast all-in-one JavaScript runtime and toolkit: runtime, package manager, bundler, and test runner.
|
||||
|
||||
## When to Use
|
||||
|
||||
- **Prefer Bun** for: new JS/TS projects, scripts where install/run speed matters, Vercel deployments with Bun runtime, and when you want a single toolchain (run + install + test + build).
|
||||
- **Prefer Node** for: maximum ecosystem compatibility, legacy tooling that assumes Node, or when a dependency has known Bun issues.
|
||||
|
||||
Use when: adopting Bun, migrating from Node, writing or debugging Bun scripts/tests, or configuring Bun on Vercel or other platforms.
|
||||
|
||||
## How It Works
|
||||
|
||||
- **Runtime**: Drop-in Node-compatible runtime (built on JavaScriptCore, implemented in Zig).
|
||||
- **Package manager**: `bun install` is significantly faster than npm/yarn. Lockfile is `bun.lock` (text) by default in current Bun; older versions used `bun.lockb` (binary).
|
||||
- **Bundler**: Built-in bundler and transpiler for apps and libraries.
|
||||
- **Test runner**: Built-in `bun test` with Jest-like API.
|
||||
|
||||
**Migration from Node**: Replace `node script.js` with `bun run script.js` or `bun script.js`. Run `bun install` in place of `npm install`; most packages work. Use `bun run` for npm scripts; `bun x` for npx-style one-off runs. Node built-ins are supported; prefer Bun APIs where they exist for better performance.
|
||||
|
||||
**Vercel**: Set runtime to Bun in project settings. Build: `bun run build` or `bun build ./src/index.ts --outdir=dist`. Install: `bun install --frozen-lockfile` for reproducible deploys.
|
||||
|
||||
## Examples
|
||||
|
||||
### Run and install
|
||||
|
||||
```bash
|
||||
# Install dependencies (creates/updates bun.lock or bun.lockb)
|
||||
bun install
|
||||
|
||||
# Run a script or file
|
||||
bun run dev
|
||||
bun run src/index.ts
|
||||
bun src/index.ts
|
||||
```
|
||||
|
||||
### Scripts and env
|
||||
|
||||
```bash
|
||||
bun run --env-file=.env dev
|
||||
FOO=bar bun run script.ts
|
||||
```
|
||||
|
||||
### Testing
|
||||
|
||||
```bash
|
||||
bun test
|
||||
bun test --watch
|
||||
```
|
||||
|
||||
```typescript
|
||||
// test/example.test.ts
|
||||
import { expect, test } from "bun:test";
|
||||
|
||||
test("add", () => {
|
||||
expect(1 + 2).toBe(3);
|
||||
});
|
||||
```
|
||||
|
||||
### Runtime API
|
||||
|
||||
```typescript
|
||||
const file = Bun.file("package.json");
|
||||
const json = await file.json();
|
||||
|
||||
Bun.serve({
|
||||
port: 3000,
|
||||
fetch(req) {
|
||||
return new Response("Hello");
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Commit the lockfile (`bun.lock` or `bun.lockb`) for reproducible installs.
|
||||
- Prefer `bun run` for scripts. For TypeScript, Bun runs `.ts` natively.
|
||||
- Keep dependencies up to date; Bun and the ecosystem evolve quickly.
|
||||
90
.cursor/skills/documentation-lookup/SKILL.md
Normal file
90
.cursor/skills/documentation-lookup/SKILL.md
Normal file
@@ -0,0 +1,90 @@
|
||||
---
|
||||
name: documentation-lookup
|
||||
description: Use up-to-date library and framework docs via Context7 MCP instead of training data. Activates for setup questions, API references, code examples, or when the user names a framework (e.g. React, Next.js, Prisma).
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Documentation Lookup (Context7)
|
||||
|
||||
When the user asks about libraries, frameworks, or APIs, fetch current documentation via the Context7 MCP (tools `resolve-library-id` and `query-docs`) instead of relying on training data.
|
||||
|
||||
## Core Concepts
|
||||
|
||||
- **Context7**: MCP server that exposes live documentation; use it instead of training data for libraries and APIs.
|
||||
- **resolve-library-id**: Returns Context7-compatible library IDs (e.g. `/vercel/next.js`) from a library name and query.
|
||||
- **query-docs**: Fetches documentation and code snippets for a given library ID and question. Always call resolve-library-id first to get a valid library ID.
|
||||
|
||||
## When to use
|
||||
|
||||
Activate when the user:
|
||||
|
||||
- Asks setup or configuration questions (e.g. "How do I configure Next.js middleware?")
|
||||
- Requests code that depends on a library ("Write a Prisma query for...")
|
||||
- Needs API or reference information ("What are the Supabase auth methods?")
|
||||
- Mentions specific frameworks or libraries (React, Vue, Svelte, Express, Tailwind, Prisma, Supabase, etc.)
|
||||
|
||||
Use this skill whenever the request depends on accurate, up-to-date behavior of a library, framework, or API. Applies across harnesses that have the Context7 MCP configured (e.g. Claude Code, Cursor, Codex).
|
||||
|
||||
## How it works
|
||||
|
||||
### Step 1: Resolve the Library ID
|
||||
|
||||
Call the **resolve-library-id** MCP tool with:
|
||||
|
||||
- **libraryName**: The library or product name taken from the user's question (e.g. `Next.js`, `Prisma`, `Supabase`).
|
||||
- **query**: The user's full question. This improves relevance ranking of results.
|
||||
|
||||
You must obtain a Context7-compatible library ID (format `/org/project` or `/org/project/version`) before querying docs. Do not call query-docs without a valid library ID from this step.
|
||||
|
||||
### Step 2: Select the Best Match
|
||||
|
||||
From the resolution results, choose one result using:
|
||||
|
||||
- **Name match**: Prefer exact or closest match to what the user asked for.
|
||||
- **Benchmark score**: Higher scores indicate better documentation quality (100 is highest).
|
||||
- **Source reputation**: Prefer High or Medium reputation when available.
|
||||
- **Version**: If the user specified a version (e.g. "React 19", "Next.js 15"), prefer a version-specific library ID if listed (e.g. `/org/project/v1.2.0`).
|
||||
|
||||
### Step 3: Fetch the Documentation
|
||||
|
||||
Call the **query-docs** MCP tool with:
|
||||
|
||||
- **libraryId**: The selected Context7 library ID from Step 2 (e.g. `/vercel/next.js`).
|
||||
- **query**: The user's specific question or task. Be specific to get relevant snippets.
|
||||
|
||||
Limit: do not call query-docs (or resolve-library-id) more than 3 times per question. If the answer is unclear after 3 calls, state the uncertainty and use the best information you have rather than guessing.
|
||||
|
||||
### Step 4: Use the Documentation
|
||||
|
||||
- Answer the user's question using the fetched, current information.
|
||||
- Include relevant code examples from the docs when helpful.
|
||||
- Cite the library or version when it matters (e.g. "In Next.js 15...").
|
||||
|
||||
## Examples
|
||||
|
||||
### Example: Next.js middleware
|
||||
|
||||
1. Call **resolve-library-id** with `libraryName: "Next.js"`, `query: "How do I set up Next.js middleware?"`.
|
||||
2. From results, pick the best match (e.g. `/vercel/next.js`) by name and benchmark score.
|
||||
3. Call **query-docs** with `libraryId: "/vercel/next.js"`, `query: "How do I set up Next.js middleware?"`.
|
||||
4. Use the returned snippets and text to answer; include a minimal `middleware.ts` example from the docs if relevant.
|
||||
|
||||
### Example: Prisma query
|
||||
|
||||
1. Call **resolve-library-id** with `libraryName: "Prisma"`, `query: "How do I query with relations?"`.
|
||||
2. Select the official Prisma library ID (e.g. `/prisma/prisma`).
|
||||
3. Call **query-docs** with that `libraryId` and the query.
|
||||
4. Return the Prisma Client pattern (e.g. `include` or `select`) with a short code snippet from the docs.
|
||||
|
||||
### Example: Supabase auth methods
|
||||
|
||||
1. Call **resolve-library-id** with `libraryName: "Supabase"`, `query: "What are the auth methods?"`.
|
||||
2. Pick the Supabase docs library ID.
|
||||
3. Call **query-docs**; summarize the auth methods and show minimal examples from the fetched docs.
|
||||
|
||||
## Best Practices
|
||||
|
||||
- **Be specific**: Use the user's full question as the query where possible for better relevance.
|
||||
- **Version awareness**: When users mention versions, use version-specific library IDs from the resolve step when available.
|
||||
- **Prefer official sources**: When multiple matches exist, prefer official or primary packages over community forks.
|
||||
- **No sensitive data**: Redact API keys, passwords, tokens, and other secrets from any query sent to Context7. Treat the user's question as potentially containing secrets before passing it to resolve-library-id or query-docs.
|
||||
44
.cursor/skills/nextjs-turbopack/SKILL.md
Normal file
44
.cursor/skills/nextjs-turbopack/SKILL.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
name: nextjs-turbopack
|
||||
description: Next.js 16+ and Turbopack — incremental bundling, FS caching, dev speed, and when to use Turbopack vs webpack.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Next.js and Turbopack
|
||||
|
||||
Next.js 16+ uses Turbopack by default for local development: an incremental bundler written in Rust that significantly speeds up dev startup and hot updates.
|
||||
|
||||
## When to Use
|
||||
|
||||
- **Turbopack (default dev)**: Use for day-to-day development. Faster cold start and HMR, especially in large apps.
|
||||
- **Webpack (legacy dev)**: Use only if you hit a Turbopack bug or rely on a webpack-only plugin in dev. Disable with `--webpack` (or `--no-turbopack` depending on your Next.js version; check the docs for your release).
|
||||
- **Production**: Production build behavior (`next build`) may use Turbopack or webpack depending on Next.js version; check the official Next.js docs for your version.
|
||||
|
||||
Use when: developing or debugging Next.js 16+ apps, diagnosing slow dev startup or HMR, or optimizing production bundles.
|
||||
|
||||
## How It Works
|
||||
|
||||
- **Turbopack**: Incremental bundler for Next.js dev. Uses file-system caching so restarts are much faster (e.g. 5–14x on large projects).
|
||||
- **Default in dev**: From Next.js 16, `next dev` runs with Turbopack unless disabled.
|
||||
- **File-system caching**: Restarts reuse previous work; cache is typically under `.next`; no extra config needed for basic use.
|
||||
- **Bundle Analyzer (Next.js 16.1+)**: Experimental Bundle Analyzer to inspect output and find heavy dependencies; enable via config or experimental flag (see Next.js docs for your version).
|
||||
|
||||
## Examples
|
||||
|
||||
### Commands
|
||||
|
||||
```bash
|
||||
next dev
|
||||
next build
|
||||
next start
|
||||
```
|
||||
|
||||
### Usage
|
||||
|
||||
Run `next dev` for local development with Turbopack. Use the Bundle Analyzer (see Next.js docs) to optimize code-splitting and trim large dependencies. Prefer App Router and server components where possible.
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Stay on a recent Next.js 16.x for stable Turbopack and caching behavior.
|
||||
- If dev is slow, ensure you're on Turbopack (default) and that the cache isn't being cleared unnecessarily.
|
||||
- For production bundle size issues, use the official Next.js bundle analysis tooling for your version.
|
||||
@@ -11,7 +11,8 @@ When invoked:
|
||||
1. Run `cargo check`, `cargo clippy -- -D warnings`, `cargo fmt --check`, and `cargo test` — if any fail, stop and report
|
||||
2. Run `git diff HEAD~1 -- '*.rs'` (or `git diff main...HEAD -- '*.rs'` for PR review) to see recent Rust file changes
|
||||
3. Focus on modified `.rs` files
|
||||
4. Begin review
|
||||
4. If the project has CI or merge requirements, note that review assumes a green CI and resolved merge conflicts where applicable; call out if the diff suggests otherwise.
|
||||
5. Begin review
|
||||
|
||||
## Review Priorities
|
||||
|
||||
|
||||
@@ -15,6 +15,7 @@ Located in `~/.claude/agents/`:
|
||||
| e2e-runner | E2E testing | Critical user flows |
|
||||
| refactor-cleaner | Dead code cleanup | Code maintenance |
|
||||
| doc-updater | Documentation | Updating docs |
|
||||
| rust-reviewer | Rust code review | Rust projects |
|
||||
|
||||
## Immediate Agent Usage
|
||||
|
||||
|
||||
84
skills/bun-runtime/SKILL.md
Normal file
84
skills/bun-runtime/SKILL.md
Normal file
@@ -0,0 +1,84 @@
|
||||
---
|
||||
name: bun-runtime
|
||||
description: Bun as runtime, package manager, bundler, and test runner. When to choose Bun vs Node, migration notes, and Vercel support.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Bun Runtime
|
||||
|
||||
Bun is a fast all-in-one JavaScript runtime and toolkit: runtime, package manager, bundler, and test runner.
|
||||
|
||||
## When to Use
|
||||
|
||||
- **Prefer Bun** for: new JS/TS projects, scripts where install/run speed matters, Vercel deployments with Bun runtime, and when you want a single toolchain (run + install + test + build).
|
||||
- **Prefer Node** for: maximum ecosystem compatibility, legacy tooling that assumes Node, or when a dependency has known Bun issues.
|
||||
|
||||
Use when: adopting Bun, migrating from Node, writing or debugging Bun scripts/tests, or configuring Bun on Vercel or other platforms.
|
||||
|
||||
## How It Works
|
||||
|
||||
- **Runtime**: Drop-in Node-compatible runtime (built on JavaScriptCore, implemented in Zig).
|
||||
- **Package manager**: `bun install` is significantly faster than npm/yarn. Lockfile is `bun.lock` (text) by default in current Bun; older versions used `bun.lockb` (binary).
|
||||
- **Bundler**: Built-in bundler and transpiler for apps and libraries.
|
||||
- **Test runner**: Built-in `bun test` with Jest-like API.
|
||||
|
||||
**Migration from Node**: Replace `node script.js` with `bun run script.js` or `bun script.js`. Run `bun install` in place of `npm install`; most packages work. Use `bun run` for npm scripts; `bun x` for npx-style one-off runs. Node built-ins are supported; prefer Bun APIs where they exist for better performance.
|
||||
|
||||
**Vercel**: Set runtime to Bun in project settings. Build: `bun run build` or `bun build ./src/index.ts --outdir=dist`. Install: `bun install --frozen-lockfile` for reproducible deploys.
|
||||
|
||||
## Examples
|
||||
|
||||
### Run and install
|
||||
|
||||
```bash
|
||||
# Install dependencies (creates/updates bun.lock or bun.lockb)
|
||||
bun install
|
||||
|
||||
# Run a script or file
|
||||
bun run dev
|
||||
bun run src/index.ts
|
||||
bun src/index.ts
|
||||
```
|
||||
|
||||
### Scripts and env
|
||||
|
||||
```bash
|
||||
bun run --env-file=.env dev
|
||||
FOO=bar bun run script.ts
|
||||
```
|
||||
|
||||
### Testing
|
||||
|
||||
```bash
|
||||
bun test
|
||||
bun test --watch
|
||||
```
|
||||
|
||||
```typescript
|
||||
// test/example.test.ts
|
||||
import { expect, test } from "bun:test";
|
||||
|
||||
test("add", () => {
|
||||
expect(1 + 2).toBe(3);
|
||||
});
|
||||
```
|
||||
|
||||
### Runtime API
|
||||
|
||||
```typescript
|
||||
const file = Bun.file("package.json");
|
||||
const json = await file.json();
|
||||
|
||||
Bun.serve({
|
||||
port: 3000,
|
||||
fetch(req) {
|
||||
return new Response("Hello");
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Commit the lockfile (`bun.lock` or `bun.lockb`) for reproducible installs.
|
||||
- Prefer `bun run` for scripts. For TypeScript, Bun runs `.ts` natively.
|
||||
- Keep dependencies up to date; Bun and the ecosystem evolve quickly.
|
||||
90
skills/documentation-lookup/SKILL.md
Normal file
90
skills/documentation-lookup/SKILL.md
Normal file
@@ -0,0 +1,90 @@
|
||||
---
|
||||
name: documentation-lookup
|
||||
description: Use up-to-date library and framework docs via Context7 MCP instead of training data. Activates for setup questions, API references, code examples, or when the user names a framework (e.g. React, Next.js, Prisma).
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Documentation Lookup (Context7)
|
||||
|
||||
When the user asks about libraries, frameworks, or APIs, fetch current documentation via the Context7 MCP (tools `resolve-library-id` and `query-docs`) instead of relying on training data.
|
||||
|
||||
## Core Concepts
|
||||
|
||||
- **Context7**: MCP server that exposes live documentation; use it instead of training data for libraries and APIs.
|
||||
- **resolve-library-id**: Returns Context7-compatible library IDs (e.g. `/vercel/next.js`) from a library name and query.
|
||||
- **query-docs**: Fetches documentation and code snippets for a given library ID and question. Always call resolve-library-id first to get a valid library ID.
|
||||
|
||||
## When to use
|
||||
|
||||
Activate when the user:
|
||||
|
||||
- Asks setup or configuration questions (e.g. "How do I configure Next.js middleware?")
|
||||
- Requests code that depends on a library ("Write a Prisma query for...")
|
||||
- Needs API or reference information ("What are the Supabase auth methods?")
|
||||
- Mentions specific frameworks or libraries (React, Vue, Svelte, Express, Tailwind, Prisma, Supabase, etc.)
|
||||
|
||||
Use this skill whenever the request depends on accurate, up-to-date behavior of a library, framework, or API. Applies across harnesses that have the Context7 MCP configured (e.g. Claude Code, Cursor, Codex).
|
||||
|
||||
## How it works
|
||||
|
||||
### Step 1: Resolve the Library ID
|
||||
|
||||
Call the **resolve-library-id** MCP tool with:
|
||||
|
||||
- **libraryName**: The library or product name taken from the user's question (e.g. `Next.js`, `Prisma`, `Supabase`).
|
||||
- **query**: The user's full question. This improves relevance ranking of results.
|
||||
|
||||
You must obtain a Context7-compatible library ID (format `/org/project` or `/org/project/version`) before querying docs. Do not call query-docs without a valid library ID from this step.
|
||||
|
||||
### Step 2: Select the Best Match
|
||||
|
||||
From the resolution results, choose one result using:
|
||||
|
||||
- **Name match**: Prefer exact or closest match to what the user asked for.
|
||||
- **Benchmark score**: Higher scores indicate better documentation quality (100 is highest).
|
||||
- **Source reputation**: Prefer High or Medium reputation when available.
|
||||
- **Version**: If the user specified a version (e.g. "React 19", "Next.js 15"), prefer a version-specific library ID if listed (e.g. `/org/project/v1.2.0`).
|
||||
|
||||
### Step 3: Fetch the Documentation
|
||||
|
||||
Call the **query-docs** MCP tool with:
|
||||
|
||||
- **libraryId**: The selected Context7 library ID from Step 2 (e.g. `/vercel/next.js`).
|
||||
- **query**: The user's specific question or task. Be specific to get relevant snippets.
|
||||
|
||||
Limit: do not call query-docs (or resolve-library-id) more than 3 times per question. If the answer is unclear after 3 calls, state the uncertainty and use the best information you have rather than guessing.
|
||||
|
||||
### Step 4: Use the Documentation
|
||||
|
||||
- Answer the user's question using the fetched, current information.
|
||||
- Include relevant code examples from the docs when helpful.
|
||||
- Cite the library or version when it matters (e.g. "In Next.js 15...").
|
||||
|
||||
## Examples
|
||||
|
||||
### Example: Next.js middleware
|
||||
|
||||
1. Call **resolve-library-id** with `libraryName: "Next.js"`, `query: "How do I set up Next.js middleware?"`.
|
||||
2. From results, pick the best match (e.g. `/vercel/next.js`) by name and benchmark score.
|
||||
3. Call **query-docs** with `libraryId: "/vercel/next.js"`, `query: "How do I set up Next.js middleware?"`.
|
||||
4. Use the returned snippets and text to answer; include a minimal `middleware.ts` example from the docs if relevant.
|
||||
|
||||
### Example: Prisma query
|
||||
|
||||
1. Call **resolve-library-id** with `libraryName: "Prisma"`, `query: "How do I query with relations?"`.
|
||||
2. Select the official Prisma library ID (e.g. `/prisma/prisma`).
|
||||
3. Call **query-docs** with that `libraryId` and the query.
|
||||
4. Return the Prisma Client pattern (e.g. `include` or `select`) with a short code snippet from the docs.
|
||||
|
||||
### Example: Supabase auth methods
|
||||
|
||||
1. Call **resolve-library-id** with `libraryName: "Supabase"`, `query: "What are the auth methods?"`.
|
||||
2. Pick the Supabase docs library ID.
|
||||
3. Call **query-docs**; summarize the auth methods and show minimal examples from the fetched docs.
|
||||
|
||||
## Best Practices
|
||||
|
||||
- **Be specific**: Use the user's full question as the query where possible for better relevance.
|
||||
- **Version awareness**: When users mention versions, use version-specific library IDs from the resolve step when available.
|
||||
- **Prefer official sources**: When multiple matches exist, prefer official or primary packages over community forks.
|
||||
- **No sensitive data**: Redact API keys, passwords, tokens, and other secrets from any query sent to Context7. Treat the user's question as potentially containing secrets before passing it to resolve-library-id or query-docs.
|
||||
44
skills/nextjs-turbopack/SKILL.md
Normal file
44
skills/nextjs-turbopack/SKILL.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
name: nextjs-turbopack
|
||||
description: Next.js 16+ and Turbopack — incremental bundling, FS caching, dev speed, and when to use Turbopack vs webpack.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Next.js and Turbopack
|
||||
|
||||
Next.js 16+ uses Turbopack by default for local development: an incremental bundler written in Rust that significantly speeds up dev startup and hot updates.
|
||||
|
||||
## When to Use
|
||||
|
||||
- **Turbopack (default dev)**: Use for day-to-day development. Faster cold start and HMR, especially in large apps.
|
||||
- **Webpack (legacy dev)**: Use only if you hit a Turbopack bug or rely on a webpack-only plugin in dev. Disable with `--webpack` (or `--no-turbopack` depending on your Next.js version; check the docs for your release).
|
||||
- **Production**: Production build behavior (`next build`) may use Turbopack or webpack depending on Next.js version; check the official Next.js docs for your version.
|
||||
|
||||
Use when: developing or debugging Next.js 16+ apps, diagnosing slow dev startup or HMR, or optimizing production bundles.
|
||||
|
||||
## How It Works
|
||||
|
||||
- **Turbopack**: Incremental bundler for Next.js dev. Uses file-system caching so restarts are much faster (e.g. 5–14x on large projects).
|
||||
- **Default in dev**: From Next.js 16, `next dev` runs with Turbopack unless disabled.
|
||||
- **File-system caching**: Restarts reuse previous work; cache is typically under `.next`; no extra config needed for basic use.
|
||||
- **Bundle Analyzer (Next.js 16.1+)**: Experimental Bundle Analyzer to inspect output and find heavy dependencies; enable via config or experimental flag (see Next.js docs for your version).
|
||||
|
||||
## Examples
|
||||
|
||||
### Commands
|
||||
|
||||
```bash
|
||||
next dev
|
||||
next build
|
||||
next start
|
||||
```
|
||||
|
||||
### Usage
|
||||
|
||||
Run `next dev` for local development with Turbopack. Use the Bundle Analyzer (see Next.js docs) to optimize code-splitting and trim large dependencies. Prefer App Router and server components where possible.
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Stay on a recent Next.js 16.x for stable Turbopack and caching behavior.
|
||||
- If dev is slow, ensure you're on Turbopack (default) and that the cache isn't being cleared unnecessarily.
|
||||
- For production bundle size issues, use the official Next.js bundle analysis tooling for your version.
|
||||
Reference in New Issue
Block a user