Add sp-stack composer skill

plugins/document-navigator/skills/sp-stack/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: sp-stack
+description: Describe a whole website, service, or app and get the complete @suaveplan/* library set, host wiring, and starter code — selected to minimise the code you write.
+---
+
+# Stack Composer for Suaveplan
+
+Turn a natural-language description of an entire website, service, or app into the full
+set of `@suaveplan/*` packages needed across all layers, plus the wiring and starter
+code to compose them. Selection always prefers the highest-level turnkey package so the
+user writes as little code as possible.
+
+This skill is the whole-app counterpart to `sp` (which finds a library for a single
+stated need). Use `sp-stack` when the input describes a product; use `sp` for "which
+library does X" or "how do I use Y".
+
+## Inputs
+
+A product description, e.g. *"a multi-tenant SaaS with email campaigns, Stripe billing,
+and a booking calendar"*.
+
+## Sources
+
+| Source | Path |
+|--------|------|
+| Capability manifest | `${CLAUDE_PLUGIN_ROOT}/skills/sp-stack/capabilities.md` |
+| Docs tree (fallback + examples) | `${CLAUDE_PLUGIN_ROOT}/docs/` |
+
+## Flow
+
+1. **Decompose.** Parse the description into a list of capabilities and infer the
+   app-type (service / website / app / game). Map each capability to the manifest
+   vocabulary (auth, multi-tenancy, payments, email-campaigns, file-upload, search,
+   realtime-sse, rate-limiting, notifications, webhooks, booking, validation, pwa,
+   client-data-hooks, cli, testing, …).
+
+2. **Resolve each capability.**
+   - **Manifest hit** → take `primary` + `supporting`; open its `example_doc` under
+     `${CLAUDE_PLUGIN_ROOT}/docs/` and read the quick-start block verbatim.
+   - **Manifest miss** → fall back to the `sp` docs-traversal: root README →
+     `<category>/README.md` → `<subcategory>/README.md` → package README, ranking
+     turnkey `api-plugin-*` / engine packages above low-level primitives.
+
+3. **Assemble.** Dedupe packages, order by dependency (turnkey plugins first), group by
+   `layer` (backend / frontend / foundation / devtools).
+
+4. **Read examples.** Pull the quick-start code verbatim from each chosen package's
+   docs. Never fabricate import paths.
+
+5. **Emit** the output below.
+
+## Output
+
+- **Bill of materials** — grouped by layer, one-line reason per package.
+- **Install** — a single `bun add @suaveplan/… …`.
+- **Wiring** — the `createHost({ plugins: [...] })` composition (see
+  `docs/api-stack/api/api/README.md` for the host entry point).
+- **Starter code** — stitched from the verbatim docs examples.
+- **Gaps & prerequisites** — capabilities with no `@suaveplan` package (the user writes
+  custom code or brings a third-party lib) and required external services (API keys,
+  datastores) drawn from each manifest row's `external` column.
+
+## Constraints
+
+- Only reference packages that exist under `${CLAUDE_PLUGIN_ROOT}/docs/`. Never invent
+  package names.
+- Use exact `@suaveplan/<name>` identifiers.
+- Extract code examples verbatim from `.md` files; do not fabricate import paths.
+- Prefer the turnkey package for a capability (the manifest's `primary`) over
+  hand-assembling low-level primitives.
+- Be honest about gaps — do not imply coverage that the catalog does not provide.
+
+## Checklist
+
+1. Description decomposed into capabilities + app-type.
+2. Each capability resolved via manifest, or via docs-traversal fallback when absent.
+3. Packages deduped, dependency-ordered, grouped by layer.
+4. Code examples pulled verbatim from the docs tree, not invented.
+5. Gaps and external prerequisites stated explicitly.