{"_id":"@commercetools-demo/commercetools-spec-templates","name":"@commercetools-demo/commercetools-spec-templates","dist-tags":{"latest":"0.1.0"},"versions":{"0.1.0":{"name":"@commercetools-demo/commercetools-spec-templates","version":"0.1.0","description":"Industry vertical spec templates for commercetools, rendered into GitHub Spec Kit or OpenSpec projects.","type":"module","bin":{"cts":"bin/cts.mjs"},"scripts":{"build":"node bin/ctsx.mjs build","lint":"node bin/ctsx.mjs lint --strict","test":"node --test test/*.test.mjs"},"engines":{"node":">=20.19"},"dependencies":{},"devDependencies":{"yaml":"^2.6.0"},"keywords":["commercetools","spec-driven-development","spec-kit","openspec","verticals"],"license":"MIT","author":{"name":"commercetools"},"repository":{"type":"git","url":"git+https://github.com/commercetools-demo/commercetools-spec-templates.git"},"publishConfig":{"access":"public"},"_id":"@commercetools-demo/commercetools-spec-templates@0.1.0","gitHead":"e882e44c942394eb137a46e213cd222d063ff1cd","bugs":{"url":"https://github.com/commercetools-demo/commercetools-spec-templates/issues"},"homepage":"https://github.com/commercetools-demo/commercetools-spec-templates#readme","_nodeVersion":"22.21.1","_npmVersion":"10.9.4","dist":{"integrity":"sha512-PN0RLg8Hl8FD8YgXMG/oiUZc6zU+g6nAmKrfARQgpy6+H2KLtfyViFWkKB50v82IH9VtrW+6+Fvq6j3nxlU6Cg==","shasum":"34fee0d6a6d3b7626c85bf28abb3414e5b4d7554","tarball":"https://registry.npmjs.org/@commercetools-demo/commercetools-spec-templates/-/commercetools-spec-templates-0.1.0.tgz","fileCount":680,"unpackedSize":3163850,"signatures":[{"keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U","sig":"MEUCICK+UjgaEfIHghZbulq/tfEtZQrbuHDn3CLNSOiIwq2eAiEAh3Pg22JtSJw8R1B86jxcspypbF+zJPTAPPFL8tbkGK0="}]},"_npmUser":{"name":"behnam777","email":"behnam777@gmail.com"},"directories":{},"maintainers":[{"name":"lgiavedoni","email":"lgiavedoni@gmail.com"},{"name":"behnam777","email":"behnam777@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages-npm-production","tmp":"tmp/commercetools-spec-templates_0.1.0_1787587218631_0.7203092043647634"},"_hasShrinkwrap":false}},"time":{"created":"2026-08-24T16:00:18.431Z","0.1.0":"2026-08-24T16:00:18.850Z","modified":"2026-08-24T16:00:19.066Z"},"maintainers":[{"name":"lgiavedoni","email":"lgiavedoni@gmail.com"},{"name":"behnam777","email":"behnam777@gmail.com"}],"description":"Industry vertical spec templates for commercetools, rendered into GitHub Spec Kit or OpenSpec projects.","homepage":"https://github.com/commercetools-demo/commercetools-spec-templates#readme","keywords":["commercetools","spec-driven-development","spec-kit","openspec","verticals"],"repository":{"type":"git","url":"git+https://github.com/commercetools-demo/commercetools-spec-templates.git"},"author":{"name":"commercetools"},"bugs":{"url":"https://github.com/commercetools-demo/commercetools-spec-templates/issues"},"license":"MIT","readme":"# commercetools-spec-templates\n\nIndustry vertical specs for commercetools, rendered into your spec-driven development project.\n\n> **This repository is public, and it is the only one.** The engine, the catalog, the taxonomy and\n> the rendered specs all live here under MIT. Collector *answers* do not: they arrive through a\n> Google Form, never touch GitHub, and are ingested into a gitignored `inbox/`. What gets committed\n> is the reviewed capability, never the raw response.\n\n```bash\n# in a project already initialized with `openspec init` (or `specify init`)\nnpx @commercetools-demo/commercetools-spec-templates plan --industry grocery --model B2C\nnpx @commercetools-demo/commercetools-spec-templates apply --industry grocery --model B2C\n```\n\nThat writes the grocery B2C spec set into `openspec/specs/`, runs the\n[commercetools SDD overlay](https://www.npmjs.com/package/@commercetools/commercetools-ai-plugin-sdd)\nso every commercetools-touching task carries its `[SKILL: …]` annotation, and leaves a receipt at\n`.commercetools/spec-templates.lock.json` so `status`, `update` and `remove` all work.\n\nStep-by-step procedures for every task — bringing specs into a project, opening a collection\nround, adding an industry, authoring a vertical — are in **[`docs/runbook.md`](docs/runbook.md)**.\nThis README explains why things are shaped the way they are.\n\n## Three ways to answer the questions\n\nThe questions live in `questions/developer-intake.yaml` and are asked by whichever surface you use.\nThere is one question set, not three.\n\n| Surface | How you answer | Use when |\n| :--- | :--- | :--- |\n| `cts init` | Numbered choices at a terminal | You are a human with a shell |\n| The plugin skill | `AskUserQuestion` buttons in Claude Code, Cursor, Codex or Copilot | You are working with an agent |\n| `cts questions --answers '<json>'` | A JSON request/response loop | You are building your own front end |\n\nThe third is the protocol the other two are built on: pass the answers you have, get back the next\nquestion or the resolved outputs. `cts init` refuses to run without a TTY and names the flag-based\nalternative, so it can never hang a CI job.\n\nA question that has only one real answer is not asked — it is reported. If the project already has\na framework, you see `Using OpenSpec — already set up in this project.` rather than a prompt with\none option. That is `prefill` in the question file, not a special case in the code.\n\n**Prompts are a product surface.** Nothing in a question may show a developer our internal\nvocabulary — no `_base`, no `P1`, no \"capability\", no raw kebab-case ids, no unrendered `{{...}}`.\nA test walks every question the flow can reach and fails the build on any of them.\n\n## What's in the catalog\n\n| Bundle | Capabilities | What it is |\n| :--- | ---: | :--- |\n| `_base` x B2C | 30 | The industry-agnostic storefront: 8 journeys + 22 pages |\n| `_base` x B2B | 48 | Adds the 9 B2B journeys and the 6 B2B-specific pages |\n| `grocery` x B2C | 33 | The base plus 3 grocery capabilities |\n| `grocery` x B2B | 50 | The base plus 2 grocery capabilities that apply to business buyers |\n\nEvery industry inherits `_base`, so a new vertical starts from a complete storefront and adds only\nwhat makes it that industry. An industry with no `vertical.yaml` yet resolves to the base alone —\n`cts coverage` labels those rows `base only` so they cannot be mistaken for industry content.\n\n## How it fits together\n\nOne hand-authored source, compiled into per-framework output:\n\n```\ncatalog/verticals/<industry>/capabilities/*.yaml     authored: framework-agnostic capability YAML\n        │  ctsx build\n        ▼\nrendered/<industry>/<model>/<framework>-<placement>/  committed: the exact bytes cts copies\nregistry.json                                        committed: the single discovery root\n        │  cts apply\n        ▼\nyour project's openspec/specs/ or specs/NNN-<slug>/\n```\n\nAuthoring finished spec files per framework would mean up to `industries × models × frameworks`\ncopies of one requirement. Authoring one neutral source and committing the rendered output gets\nboth: no duplication, and a PR diff that shows the exact bytes a developer will receive.\n\n## Commands\n\n```\ncts detect                                   what framework is here, and is it complete\ncts list [--industry <i>]                    what content exists\ncts questions [--answers '<json>']           drive the intake flow (data-driven)\ncts plan   --industry <i> --model <m> [...]  preview what would be written, and its hash\ncts apply  [--plan <f>] [...]                write it, atomically, and leave a receipt\ncts status | cts remove                      inspect or undo exactly what we wrote\ncts why    --industry <i> --model <m>        explain why a combination resolves as it does\n```\n\nOptions: `--framework openspec|speckit` · `--placement specs|change` · `--scope all|mvp` ·\n`--cwd <dir>` · `--force` · `--dry-run` · `--json` · `--no-overlay`\n\nExit codes: `0` ok · `2` bad args · `4` no or incomplete framework · `5` unsupported combination ·\n`6` blocked by conflicts · `7` renderer not implemented.\n\n## What lands where\n\n| Framework | Placement | Destination |\n| :--- | :--- | :--- |\n| OpenSpec | `specs` (default) | `openspec/specs/<capability>/spec.md` — a browsable baseline catalog |\n| OpenSpec | `change` | `openspec/changes/add-<i>-<m>-<epic>/{proposal,tasks}.md` + delta specs |\n| Spec Kit | — | `specs/<NNN>-<slug>/spec.md`, rebased onto `max(NNN)+n`. **Not implemented in 0.1.0.** |\n\nTwo placement notes that are easy to get wrong, and that this tool gets right:\n\n- **Spec Kit numbering comes from disk, not from git.** `create-new-feature.sh` scans `specs/*` for\n  `^[0-9]{3,}-` and takes max+1, so seeded feature directories are safe and the next\n  `/speckit.specify` continues the sequence.\n- **We never write a `plan.md` or a pre-ticked `checklists/` file.** `setup-plan.sh` skips its\n  template copy when `plan.md` already exists, which would strip the overlay's *Platform Skills\n  Resolution* table out of the feature. A pre-ticked checklist would forge Spec Kit's own\n  content-quality attestations.\n\n## Nothing is written until you have seen it\n\n`cts plan` produces a file list, an action per path, and a `plan_hash`. `cts apply --plan <file>`\nrecomputes that hash and refuses if the project moved on. Files are staged in a temp directory,\nfsync'd, then atomically renamed, and the receipt is written last — so a crash leaves either the\nold state or a complete new one. A path we did not write (`foreign`), or one we wrote and you then\nedited (`ours-edited`), blocks the run until you pass `--force`.\n\n## Coverage, and honesty about gaps\n\n`industry × business model` resolves three ways. A model the vertical explicitly excludes is a\n**hard refusal**, not a guess. A model reached only through inheritance is reported as `derived`,\nand whatever that model structurally needs but no capability covers is rendered as an **open\nquestion** — never as invented content.\n\n```\n$ cts why --industry grocery --model B2B2C\ngrocery|B2B2C: derived match\n  3 capabilit(ies): 3 native to B2B2C, 0 inherited\n  4 model gap(s) with no published content: seller-onboarding, seller-scoped-assortment, …\n  These are rendered as open questions, never as invented content.\n```\n\n## Authoring a vertical\n\n`bin/ctsx.mjs` is the authoring tool; it is not shipped to developers.\n\n```bash\nnode bin/ctsx.mjs build            # regenerate registry.json, dist/, rendered/, collector/forms/\nnode bin/ctsx.mjs lint --strict    # 0 ok · 1 errors · 3 golden drift\nnode bin/ctsx.mjs coverage         # the industry × model matrix\nnode bin/ctsx.mjs collect:render   # regenerate the collector's per-industry forms\nnpm test                           # 25 tests, offline\n```\n\nThe full procedure is `plugin/skills/commercetools-vertical-authoring/SKILL.md`, including how to\nturn a source PDF into capability YAML without ever committing the PDF.\n\n## Licence\n\nMIT throughout — see `LICENSE-MIT`. That covers the engine and the rendered specs the npm package\nships. If the catalog is ever opened up under a separate content licence, that is a decision to\ntake then, with a licence file to match; there is no second licence today.\n","readmeFilename":"README.md","_rev":"1-6b2206e25297c16510ec94343802bf6d"}