Stack Detection Meta-Skill vs. Stack-Combo Skills

[Jeffallan]

Inspired by #101 (Laravel + Inertia + React + Axios skill request), I want to open a discussion about how we handle technology stack combinations.

The Problem

We're getting requests for specific stack combos:

• Laravel + Inertia + React + Axios
• Next.js + Prisma + tRPC
• Django + HTMX + Alpine
• etc.

If we create individual skills for each combination, we'll end up with an explosion of narrow skills that are hard to maintain and discover.

Possible Approaches

A) Stack-Combo Skills
Create skills like laravel-inertia-react. Pros: precise, curated. Cons: combinatorial explosion, maintenance burden.

B) Meta-Skill: Project Analyzer
A skill that reads package.json, composer.json, pyproject.toml, etc. and outputs recommended skill selections for that project. Could generate a .claude/skills.md or similar.

C) Skill Composition Guides
Reference docs showing which existing skills to combine for common stacks. No new skills, just better discovery.

D) Something else?

Questions for the Community

• How do you currently handle multi-technology projects?
• Would a project analyzer be useful, or overkill?
• Are there stack combos you'd want as dedicated skills regardless?

Curious what approaches would be most valuable to your workflows.

[josuelmm]

Approach to Handling Laravel + Inertia + React + Axios

1) Managing multi-technology projects

This stack is not a single technology but a set of clearly defined layers:

• Laravel: domain logic, validation, policies, auth, jobs, queues, database.
• Inertia: request/response bridge, props, navigation, redirects.
• React: UI, local state, components, UX, accessibility.
• Axios: HTTP transport for actions outside the Inertia cycle (autosave, uploads, polling, quick actions).

The most maintainable approach is task-driven, not stack-driven: each task activates the skills required by the relevant layer.

---

2) Project analyzer: useful as a router, not a mega-skill

An analyzer that reads composer.json, package.json, and project structure can quickly detect:

• Laravel + Inertia + React + Axios
• Key libraries (Inertia, Ziggy, Vite, Axios, etc.)

Its value lies in orchestrating existing skills based on the task (backend, Inertia, UI, HTTP), not in replacing them with a monolithic skill.

---

3) Skill composition guides (recipes)

The highest ROI comes from documenting reusable recipes, without creating new skills:

• Full CRUD

  • Laravel: controllers, FormRequest, policies, resources, pagination
  • Inertia: render, flash, redirects
  • React: tables, filters, modals
  • Axios: deletes and quick background actions

• Forms with validation

  • Laravel: FormRequest
  • Inertia: useForm, error handling
  • React: controlled inputs
  • Axios: live validation (optional)

• Uploads with progress

  • Laravel: storage + validation
  • React: preview / dropzone
  • Axios: onUploadProgress

These recipes improve discoverability and consistency with minimal maintenance cost.

---

4) Dedicated skill: only for wiring and conventions

A dedicated skill makes sense only if it stays thin, focused on:

• Project structure and naming conventions
• Standard Inertia page patterns
• Axios instance setup (CSRF, 401/419 handling, interceptors)
• Unified error handling, toasts, and confirmations

It should not duplicate existing Laravel or React skills.

---

5) Final proposal

For Laravel + Inertia + React + Axios:

1. Project Analyzer meta-skill
   Detects the stack and routes to the right skills per task.

2. Composition guides (recipes)
   For common flows (CRUD, forms, uploads, auth, realtime).

3. Lightweight wiring/conventions skill
   Structure, patterns, and glue between layers.

This approach covers most real-world use cases without causing a combinatorial explosion of skills.

[Jeffallan]

Thanks for the detailed breakdown @josuelmm - the task-driven approach makes a lot of sense.

Building on this, I want to expand the discussion to include a related problem: context bloat from global skill installation.

The Current Problem

Right now, installing claude-skills globally (~/.claude/) means:

• All 65+ skills load into context, even when irrelevant
• Skills for React, Django, Laravel, etc. all activate regardless of project
• The more skills we add, the worse this gets
• Additional content in ~/.claude/ (custom skills, CLAUDE.md instructions, etc.) compounds the problem

This makes the "project analyzer" idea even more important - it's not just about recommending skills, it's about selectively activating them.

Proposed Architecture

1. Plugin Remains a Plugin
The full claude-skills repo stays as-is - a complete collection of skills, recipes, and workflows.

2. Meta-Skill as Lightweight Entry Point
Users install only the analyzer via:

npx add-skill <meta-skill-name>

This installs a single skill globally that handles project setup.

3. Setup Wizard Flow
When invoked, the meta-skill:

• Detects your stack from manifest files (package.json, composer.json, etc.)
• Presents relevant skills for selection
• Optionally includes workflow commands (commit, review-pr, etc.)
• Copies/symlinks selected skills to your project's .claude/skills/

~/my-laravel-app/
  └── .claude/
      └── skills.md              # Generated config
      └── skills/                # Only selected skills
          ├── laravel-specialist/
          ├── react-expert/
          └── inertia-patterns/

4. Loading Strategies

Strategy	How it works	Trade-off
Reference-only	.claude/skills.md lists skills to invoke from plugin repo	Lightest, requires plugin clone
Symlink	Symlinks selected skills to project	Medium - no duplication, requires plugin clone
Copy	Copies skills to project	Heaviest, but fully standalone

5. Recipe Files as Reference Docs
Composition guides (CRUD, forms, uploads) live as reference files. The wiring skill routes to them contextually rather than loading all upfront.

Open Questions for the Community

1. Auto-detect vs explicit? Should the analyzer run automatically on new projects, or require explicit invocation?

2. Preferred loading strategy? Reference-only, symlink, or copy?

3. Skill granularity? Should we split large skills (like laravel-specialist) into smaller composable units, or keep them chunky with better internal routing?

4. Wiring skill scope? For stacks like Laravel+Inertia+React, should the "glue" skill be:

   • A thin conventions-only skill (as @josuelmm suggested)
   • A router that loads recipes on-demand
   • Both?

The goal: 50-80% reduction in context usage for typical projects while maintaining full capability when needed.

Curious what workflows would work best for everyone.

---

@josuelmm - your breakdown was really well thought out. Would you be interested in collaborating on this? Could use help designing the architecture and building out the Laravel+Inertia+React recipes.