claude-code-pilot 3.0.0 → 3.1.1

package/src/skills/laravel-plugin-discovery/SKILL.md

@@ -0,0 +1,229 @@
+---
+name: laravel-plugin-discovery
+description: Discover and evaluate Laravel packages via LaraPlugins.io MCP. Use when the user wants to find plugins, check package health, or assess Laravel/PHP compatibility.
+origin: ECC
+---
+
+# Laravel Plugin Discovery
+
+Find, evaluate, and choose healthy Laravel packages using the LaraPlugins.io MCP server.
+
+## When to Use
+
+- User wants to find Laravel packages for a specific feature (e.g. "auth", "permissions", "admin panel")
+- User asks "what package should I use for..." or "is there a Laravel package for..."
+- User wants to check if a package is actively maintained
+- User needs to verify Laravel version compatibility
+- User wants to assess package health before adding to a project
+
+## MCP Requirement
+
+LaraPlugins MCP server must be configured. Add to your `~/.claude.json` mcpServers:
+
+```json
+"laraplugins": {
+  "type": "http",
+  "url": "https://laraplugins.io/mcp/plugins"
+}
+```
+
+No API key required — the server is free for the Laravel community.
+
+## MCP Tools
+
+The LaraPlugins MCP provides two primary tools:
+
+### SearchPluginTool
+
+Search packages by keyword, health score, vendor, and version compatibility.
+
+**Parameters:**
+- `text_search` (string, optional): Keyword to search (e.g. "permission", "admin", "api")
+- `health_score` (string, optional): Filter by health band — `Healthy`, `Medium`, `Unhealthy`, or `Unrated`
+- `laravel_compatibility` (string, optional): Filter by Laravel version — `"5"`, `"6"`, `"7"`, `"8"`, `"9"`, `"10"`, `"11"`, `"12"`, `"13"`
+- `php_compatibility` (string, optional): Filter by PHP version — `"7.4"`, `"8.0"`, `"8.1"`, `"8.2"`, `"8.3"`, `"8.4"`, `"8.5"`
+- `vendor_filter` (string, optional): Filter by vendor name (e.g. "spatie", "laravel")
+- `page` (number, optional): Page number for pagination
+
+### GetPluginDetailsTool
+
+Fetch detailed metrics, readme content, and version history for a specific package.
+
+**Parameters:**
+- `package` (string, required): Full Composer package name (e.g. "spatie/laravel-permission")
+- `include_versions` (boolean, optional): Include version history in response
+
+---
+
+## How It Works
+
+### Finding Packages
+
+When the user wants to discover packages for a feature:
+
+1. Use `SearchPluginTool` with relevant keywords
+2. Apply filters for health score, Laravel version, or PHP version
+3. Review the results with package names, descriptions, and health indicators
+
+### Evaluating Packages
+
+When the user wants to assess a specific package:
+
+1. Use `GetPluginDetailsTool` with the package name
+2. Review health score, last updated date, Laravel version support
+3. Check vendor reputation and risk indicators
+
+### Checking Compatibility
+
+When the user needs Laravel or PHP version compatibility:
+
+1. Search with `laravel_compatibility` filter set to their version
+2. Or get details on a specific package to see its supported versions
+
+---
+
+## Examples
+
+### Example: Find Authentication Packages
+
+```
+SearchPluginTool({
+  text_search: "authentication",
+  health_score: "Healthy"
+})
+```
+
+Returns packages matching "authentication" with healthy status:
+- spatie/laravel-permission
+- laravel/breeze
+- laravel/passport
+- etc.
+
+### Example: Find Laravel 12 Compatible Packages
+
+```
+SearchPluginTool({
+  text_search: "admin panel",
+  laravel_compatibility: "12"
+})
+```
+
+Returns packages compatible with Laravel 12.
+
+### Example: Get Package Details
+
+```
+GetPluginDetailsTool({
+  package: "spatie/laravel-permission",
+  include_versions: true
+})
+```
+
+Returns:
+- Health score and last activity
+- Laravel/PHP version support
+- Vendor reputation (risk score)
+- Version history
+- Brief description
+
+### Example: Find Packages by Vendor
+
+```
+SearchPluginTool({
+  vendor_filter: "spatie",
+  health_score: "Healthy"
+})
+```
+
+Returns all healthy packages from vendor "spatie".
+
+---
+
+## Filtering Best Practices
+
+### By Health Score
+
+| Health Band | Meaning |
+|-------------|---------|
+| `Healthy` | Active maintenance, recent updates |
+| `Medium` | Occasional updates, may need attention |
+| `Unhealthy` | Abandoned or infrequently maintained |
+| `Unrated` | Not yet assessed |
+
+**Recommendation**: Prefer `Healthy` packages for production applications.
+
+### By Laravel Version
+
+| Version | Notes |
+|---------|-------|
+| `13` | Latest Laravel |
+| `12` | Current stable |
+| `11` | Still widely used |
+| `10` | Legacy but common |
+| `5`-`9` | Deprecated |
+
+**Recommendation**: Match the target project's Laravel version.
+
+### Combining Filters
+
+```typescript
+// Find healthy, Laravel 12 compatible packages for permissions
+SearchPluginTool({
+  text_search: "permission",
+  health_score: "Healthy",
+  laravel_compatibility: "12"
+})
+```
+
+---
+
+## Response Interpretation
+
+### Search Results
+
+Each result includes:
+- Package name (e.g. `spatie/laravel-permission`)
+- Brief description
+- Health status indicator
+- Laravel version support badges
+
+### Package Details
+
+The detailed response includes:
+- **Health Score**: Numeric or band indicator
+- **Last Activity**: When the package was last updated
+- **Laravel Support**: Version compatibility matrix
+- **PHP Support**: PHP version compatibility
+- **Risk Score**: Vendor trust indicators
+- **Version History**: Recent release timeline
+
+---
+
+## Common Use Cases
+
+| Scenario | Recommended Approach |
+|----------|---------------------|
+| "What package for auth?" | Search "auth" with healthy filter |
+| "Is spatie/package still maintained?" | Get details, check health score |
+| "Need Laravel 12 packages" | Search with laravel_compatibility: "12" |
+| "Find admin panel packages" | Search "admin panel", review results |
+| "Check vendor reputation" | Search by vendor, check details |
+
+---
+
+## Best Practices
+
+1. **Always filter by health** — Use `health_score: "Healthy"` for production projects
+2. **Match Laravel version** — Always check `laravel_compatibility` matches the target project
+3. **Check vendor reputation** — Prefer packages from known vendors (spatie, laravel, etc.)
+4. **Review before recommending** — Use GetPluginDetailsTool for a comprehensive assessment
+5. **No API key needed** — The MCP is free, no authentication required
+
+---
+
+## Related Skills
+
+- `laravel-patterns` — Laravel architecture and patterns
+- `laravel-tdd` — Test-driven development for Laravel
+- `laravel-security` — Laravel security best practices
+- `documentation-lookup` — General library documentation lookup (Context7)

package/src/skills/nextjs-turbopack/SKILL.md

@@ -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.

package/src/skills/nuxt4-patterns/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: nuxt4-patterns
+description: Nuxt 4 app patterns for hydration safety, performance, route rules, lazy loading, and SSR-safe data fetching with useFetch and useAsyncData.
+origin: ECC
+---
+
+# Nuxt 4 Patterns
+
+Use when building or debugging Nuxt 4 apps with SSR, hybrid rendering, route rules, or page-level data fetching.
+
+## When to Activate
+
+- Hydration mismatches between server HTML and client state
+- Route-level rendering decisions such as prerender, SWR, ISR, or client-only sections
+- Performance work around lazy loading, lazy hydration, or payload size
+- Page or component data fetching with `useFetch`, `useAsyncData`, or `$fetch`
+- Nuxt routing issues tied to route params, middleware, or SSR/client differences
+
+## Hydration Safety
+
+- Keep the first render deterministic. Do not put `Date.now()`, `Math.random()`, browser-only APIs, or storage reads directly into SSR-rendered template state.
+- Move browser-only logic behind `onMounted()`, `import.meta.client`, `ClientOnly`, or a `.client.vue` component when the server cannot produce the same markup.
+- Use Nuxt's `useRoute()` composable, not the one from `vue-router`.
+- Do not use `route.fullPath` to drive SSR-rendered markup. URL fragments are client-only, which can create hydration mismatches.
+- Treat `ssr: false` as an escape hatch for truly browser-only areas, not a default fix for mismatches.
+
+## Data Fetching
+
+- Prefer `await useFetch()` for SSR-safe API reads in pages and components. It forwards server-fetched data into the Nuxt payload and avoids a second fetch on hydration.
+- Use `useAsyncData()` when the fetcher is not a simple `$fetch()` call, when you need a custom key, or when you are composing multiple async sources.
+- Give `useAsyncData()` a stable key for cache reuse and predictable refresh behavior.
+- Keep `useAsyncData()` handlers side-effect free. They can run during SSR and hydration.
+- Use `$fetch()` for user-triggered writes or client-only actions, not top-level page data that should be hydrated from SSR.
+- Use `lazy: true`, `useLazyFetch()`, or `useLazyAsyncData()` for non-critical data that should not block navigation. Handle `status === 'pending'` in the UI.
+- Use `server: false` only for data that is not needed for SEO or the first paint.
+- Trim payload size with `pick` and prefer shallower payloads when deep reactivity is unnecessary.
+
+```ts
+const route = useRoute()
+
+const { data: article, status, error, refresh } = await useAsyncData(
+  () => `article:${route.params.slug}`,
+  () => $fetch(`/api/articles/${route.params.slug}`),
+)
+
+const { data: comments } = await useFetch(`/api/articles/${route.params.slug}/comments`, {
+  lazy: true,
+  server: false,
+})
+```
+
+## Route Rules
+
+Prefer `routeRules` in `nuxt.config.ts` for rendering and caching strategy:
+
+```ts
+export default defineNuxtConfig({
+  routeRules: {
+    '/': { prerender: true },
+    '/products/**': { swr: 3600 },
+    '/blog/**': { isr: true },
+    '/admin/**': { ssr: false },
+    '/api/**': { cache: { maxAge: 60 * 60 } },
+  },
+})
+```
+
+- `prerender`: static HTML at build time
+- `swr`: serve cached content and revalidate in the background
+- `isr`: incremental static regeneration on supported platforms
+- `ssr: false`: client-rendered route
+- `cache` or `redirect`: Nitro-level response behavior
+
+Pick route rules per route group, not globally. Marketing pages, catalogs, dashboards, and APIs usually need different strategies.
+
+## Lazy Loading and Performance
+
+- Nuxt already code-splits pages by route. Keep route boundaries meaningful before micro-optimizing component splits.
+- Use the `Lazy` prefix to dynamically import non-critical components.
+- Conditionally render lazy components with `v-if` so the chunk is not loaded until the UI actually needs it.
+- Use lazy hydration for below-the-fold or non-critical interactive UI.
+
+```vue
+<template>
+  <LazyRecommendations v-if="showRecommendations" />
+  <LazyProductGallery hydrate-on-visible />
+</template>
+```
+
+- For custom strategies, use `defineLazyHydrationComponent()` with a visibility or idle strategy.
+- Nuxt lazy hydration works on single-file components. Passing new props to a lazily hydrated component will trigger hydration immediately.
+- Use `NuxtLink` for internal navigation so Nuxt can prefetch route components and generated payloads.
+
+## Review Checklist
+
+- First SSR render and hydrated client render produce the same markup
+- Page data uses `useFetch` or `useAsyncData`, not top-level `$fetch`
+- Non-critical data is lazy and has explicit loading UI
+- Route rules match the page's SEO and freshness requirements
+- Heavy interactive islands are lazy-loaded or lazily hydrated

package/src/skills/opensource-pipeline/SKILL.md

@@ -0,0 +1,255 @@
+---
+name: opensource-pipeline
+description: "Open-source pipeline: fork, sanitize, and package private projects for safe public release. Chains 3 agents (forker, sanitizer, packager). Triggers: '/opensource', 'open source this', 'make this public', 'prepare for open source'."
+origin: ECC
+---
+
+# Open-Source Pipeline Skill
+
+Safely open-source any project through a 3-stage pipeline: **Fork** (strip secrets) → **Sanitize** (verify clean) → **Package** (CLAUDE.md + setup.sh + README).
+
+## When to Activate
+
+- User says "open source this project" or "make this public"
+- User wants to prepare a private repo for public release
+- User needs to strip secrets before pushing to GitHub
+- User invokes `/opensource fork`, `/opensource verify`, or `/opensource package`
+
+## Commands
+
+| Command | Action |
+|---------|--------|
+| `/opensource fork PROJECT` | Full pipeline: fork + sanitize + package |
+| `/opensource verify PROJECT` | Run sanitizer on existing repo |
+| `/opensource package PROJECT` | Generate CLAUDE.md + setup.sh + README |
+| `/opensource list` | Show all staged projects |
+| `/opensource status PROJECT` | Show reports for a staged project |
+
+## Protocol
+
+### /opensource fork PROJECT
+
+**Full pipeline — the main workflow.**
+
+#### Step 1: Gather Parameters
+
+Resolve the project path. If PROJECT contains `/`, treat as a path (absolute or relative). Otherwise check: current working directory, `$HOME/PROJECT`, then ask the user.
+
+```
+SOURCE_PATH="<resolved absolute path>"
+STAGING_PATH="$HOME/opensource-staging/${PROJECT_NAME}"
+```
+
+Ask the user:
+1. "Which project?" (if not found)
+2. "License? (MIT / Apache-2.0 / GPL-3.0 / BSD-3-Clause)"
+3. "GitHub org or username?" (default: detect via `gh api user -q .login`)
+4. "GitHub repo name?" (default: project name)
+5. "Description for README?" (analyze project for suggestion)
+
+#### Step 2: Create Staging Directory
+
+```bash
+mkdir -p $HOME/opensource-staging/
+```
+
+#### Step 3: Run Forker Agent
+
+Spawn the `opensource-forker` agent:
+
+```
+Agent(
+  description="Fork {PROJECT} for open-source",
+  subagent_type="opensource-forker",
+  prompt="""
+Fork project for open-source release.
+
+Source: {SOURCE_PATH}
+Target: {STAGING_PATH}
+License: {chosen_license}
+
+Follow the full forking protocol:
+1. Copy files (exclude .git, node_modules, __pycache__, .venv)
+2. Strip all secrets and credentials
+3. Replace internal references with placeholders
+4. Generate .env.example
+5. Clean git history
+6. Generate FORK_REPORT.md in {STAGING_PATH}/FORK_REPORT.md
+"""
+)
+```
+
+Wait for completion. Read `{STAGING_PATH}/FORK_REPORT.md`.
+
+#### Step 4: Run Sanitizer Agent
+
+Spawn the `opensource-sanitizer` agent:
+
+```
+Agent(
+  description="Verify {PROJECT} sanitization",
+  subagent_type="opensource-sanitizer",
+  prompt="""
+Verify sanitization of open-source fork.
+
+Project: {STAGING_PATH}
+Source (for reference): {SOURCE_PATH}
+
+Run ALL scan categories:
+1. Secrets scan (CRITICAL)
+2. PII scan (CRITICAL)
+3. Internal references scan (CRITICAL)
+4. Dangerous files check (CRITICAL)
+5. Configuration completeness (WARNING)
+6. Git history audit
+
+Generate SANITIZATION_REPORT.md inside {STAGING_PATH}/ with PASS/FAIL verdict.
+"""
+)
+```
+
+Wait for completion. Read `{STAGING_PATH}/SANITIZATION_REPORT.md`.
+
+**If FAIL:** Show findings to user. Ask: "Fix these and re-scan, or abort?"
+- If fix: Apply fixes, re-run sanitizer (maximum 3 retry attempts — after 3 FAILs, present all findings and ask user to fix manually)
+- If abort: Clean up staging directory
+
+**If PASS or PASS WITH WARNINGS:** Continue to Step 5.
+
+#### Step 5: Run Packager Agent
+
+Spawn the `opensource-packager` agent:
+
+```
+Agent(
+  description="Package {PROJECT} for open-source",
+  subagent_type="opensource-packager",
+  prompt="""
+Generate open-source packaging for project.
+
+Project: {STAGING_PATH}
+License: {chosen_license}
+Project name: {PROJECT_NAME}
+Description: {description}
+GitHub repo: {github_repo}
+
+Generate:
+1. CLAUDE.md (commands, architecture, key files)
+2. setup.sh (one-command bootstrap, make executable)
+3. README.md (or enhance existing)
+4. LICENSE
+5. CONTRIBUTING.md
+6. .github/ISSUE_TEMPLATE/ (bug_report.md, feature_request.md)
+"""
+)
+```
+
+#### Step 6: Final Review
+
+Present to user:
+```
+Open-Source Fork Ready: {PROJECT_NAME}
+
+Location: {STAGING_PATH}
+License: {license}
+Files generated:
+  - CLAUDE.md
+  - setup.sh (executable)
+  - README.md
+  - LICENSE
+  - CONTRIBUTING.md
+  - .env.example ({N} variables)
+
+Sanitization: {sanitization_verdict}
+
+Next steps:
+  1. Review: cd {STAGING_PATH}
+  2. Create repo: gh repo create {github_org}/{github_repo} --public
+  3. Push: git remote add origin ... && git push -u origin main
+
+Proceed with GitHub creation? (yes/no/review first)
+```
+
+#### Step 7: GitHub Publish (on user approval)
+
+```bash
+cd "{STAGING_PATH}"
+gh repo create "{github_org}/{github_repo}" --public --source=. --push --description "{description}"
+```
+
+---
+
+### /opensource verify PROJECT
+
+Run sanitizer independently. Resolve path: if PROJECT contains `/`, treat as a path. Otherwise check `$HOME/opensource-staging/PROJECT`, then `$HOME/PROJECT`, then current directory.
+
+```
+Agent(
+  subagent_type="opensource-sanitizer",
+  prompt="Verify sanitization of: {resolved_path}. Run all 6 scan categories and generate SANITIZATION_REPORT.md."
+)
+```
+
+---
+
+### /opensource package PROJECT
+
+Run packager independently. Ask for "License?" and "Description?", then:
+
+```
+Agent(
+  subagent_type="opensource-packager",
+  prompt="Package: {resolved_path} ..."
+)
+```
+
+---
+
+### /opensource list
+
+```bash
+ls -d $HOME/opensource-staging/*/
+```
+
+Show each project with pipeline progress (FORK_REPORT.md, SANITIZATION_REPORT.md, CLAUDE.md presence).
+
+---
+
+### /opensource status PROJECT
+
+```bash
+cat $HOME/opensource-staging/${PROJECT}/SANITIZATION_REPORT.md
+cat $HOME/opensource-staging/${PROJECT}/FORK_REPORT.md
+```
+
+## Staging Layout
+
+```
+$HOME/opensource-staging/
+  my-project/
+    FORK_REPORT.md           # From forker agent
+    SANITIZATION_REPORT.md   # From sanitizer agent
+    CLAUDE.md                # From packager agent
+    setup.sh                 # From packager agent
+    README.md                # From packager agent
+    .env.example             # From forker agent
+    ...                      # Sanitized project files
+```
+
+## Anti-Patterns
+
+- **Never** push to GitHub without user approval
+- **Never** skip the sanitizer — it is the safety gate
+- **Never** proceed after a sanitizer FAIL without fixing all critical findings
+- **Never** leave `.env`, `*.pem`, or `credentials.json` in the staging directory
+
+## Best Practices
+
+- Always run the full pipeline (fork → sanitize → package) for new releases
+- The staging directory persists until explicitly cleaned up — use it for review
+- Re-run the sanitizer after any manual fixes before publishing
+- Parameterize secrets rather than deleting them — preserve project functionality
+
+## Related Skills
+
+See `security-review` for secret detection patterns used by the sanitizer.