@execuro-sw-ecosystem/sw-ecosystem-agentic-harness 0.1.0 → 0.1.3

package/lib/{companions.mjs → extra-components.mjs}

@@ -1,13 +1,13 @@
-// The two optional companion packages, probed rather than installed by us.
+// The two optional extra components, probed rather than installed by us.
 //
 // Read-then-copy, not `install-skill --target`: the engine's whole safety
 // story is "hash what we intend to write, compare, record". A foreign binary
 // that writes on its own cannot be previewed, so `plan` would lie and
 // `uninstall` would have to guess. Reading the body with `--print` and
-// copying it ourselves through `writeAtomic` keeps every companion skill on
-// the same adopt/conflict/drift/update ladder as everything else this CLI
-// writes, and makes `uninstall` exact even after the user has removed the
-// companion package — the common case, since it is optional.
+// copying it ourselves through `writeAtomic` keeps every extra-component
+// skill on the same adopt/conflict/drift/update ladder as everything else
+// this CLI writes, and makes `uninstall` exact even after the user has
+// removed the extra component — the common case, since it is optional.
 //
 // `--no-install` plus `npm_config_yes=false` are two independent guards that
 // this can never reach the network: the first tells npx not to fetch a
@@ -17,7 +17,7 @@ import { spawnSync } from 'node:child_process';
 import { sha256 } from './fsx.mjs';
 import { wrapCommand } from './content.mjs';
 
-export const COMPANIONS = [
+export const EXTRA_COMPONENTS = [
   {
     id: 'sw-specs-editor', pkg: '@execuro-sw-ecosystem/sw-specs-editor', version: '0.1.0',
     label: 'Specs Editor',
@@ -29,8 +29,8 @@ export const COMPANIONS = [
 ];
 
 /** The argv `probe` would spawn, without spawning it — for tests. */
-export function probeArgs(companion, platform) {
-  const spec = `${companion.pkg}@${companion.version}`;
+export function probeArgs(component, platform) {
+  const spec = `${component.pkg}@${component.version}`;
   const wrapped = wrapCommand(
     { command: 'npx', args: ['--no-install', spec, 'install-skill', '--print'] },
     platform,
@@ -51,9 +51,9 @@ function lastLine(text) {
   return lines.length ? lines[lines.length - 1] : '';
 }
 
-function doProbe(companion, platform) {
-  const spec = `${companion.pkg}@${companion.version}`;
-  const base = { id: companion.id, pkg: companion.pkg, version: companion.version, spec, label: companion.label };
+function doProbe(component, platform) {
+  const spec = `${component.pkg}@${component.version}`;
+  const base = { id: component.id, pkg: component.pkg, version: component.version, spec, label: component.label };
   const wrapped = wrapCommand(
     { command: 'npx', args: ['--no-install', spec, 'install-skill', '--print'] },
     platform,
@@ -103,15 +103,15 @@ function doProbe(companion, platform) {
   return { ...base, available: true, state: 'available', body: stdout, hash: sha256(stdout), bytes: stdout.length };
 }
 
-/** Probe one companion. Never throws. */
-export function probe(companion, { platform = process.platform } = {}) {
-  const key = `${companion.pkg}@${companion.version}`;
+/** Probe one extra component. Never throws. */
+export function probe(component, { platform = process.platform } = {}) {
+  const key = `${component.pkg}@${component.version}`;
   if (cache.has(key)) return cache.get(key);
-  const result = doProbe(companion, platform);
+  const result = doProbe(component, platform);
   cache.set(key, result);
   return result;
 }
 
 export function probeAll(opts) {
-  return COMPANIONS.map((c) => probe(c, opts));
+  return EXTRA_COMPONENTS.map((c) => probe(c, opts));
 }

package/lib/guide.mjs

@@ -6,31 +6,39 @@
 
 import * as out from './out.mjs';
 import { PKG_NAME, PKG_VERSION } from './content.mjs';
+import { EXTRA_COMPONENTS } from './extra-components.mjs';
 
 const RUN = `npx -y ${PKG_NAME}@${PKG_VERSION}`;
+const EXTRA_COMPONENT_INSTALLS = EXTRA_COMPONENTS.map((c) => `npm i -D ${c.pkg}@${c.version}`).join('\n');
 
 export const GUIDE = `# ${PKG_NAME} — install protocol
 
-This CLI installs the Shopware agentic harness — 11 \`sw-*\` skills and 7
+This CLI installs the Shopware agentic harness — 10 \`sw-*\` skills and 7
 \`sw-*\` sub-agents — into whichever coding agents this repository uses, and
 registers the MCP servers and permission rules they depend on.
 
 ## The loop
 
-1. \`${RUN} status\`
-   Read-only. Reports which hosts are present, what is already installed, and
-   anything that has drifted since it was installed. Always safe.
+1. \`${RUN} install\`
+   The whole install in one command. It refuses to prompt — Codex's question
+   tool does not block outside Plan mode, and CI has no terminal — so the verb
+   itself is the consent. Same as \`apply --yes\`.
 
-2. \`${RUN} plan\`
+2. \`${RUN} status\`
+   Read-only, optional. Reports which hosts are present, what is already
+   installed, and anything that has drifted since it was installed. Always safe.
+
+3. \`${RUN} plan\`
    Prints the exact set of changes and writes nothing. Every entry says what it
    would do and why. Show this to the user before applying.
 
-3. \`${RUN} apply --yes\`
-   Performs the changes. It refuses without \`--yes\`; there is no prompt,
-   because Codex's question tool does not block outside Plan mode and CI has no
+4. \`${RUN} apply --yes\`
+   The scriptable name for the same write \`install\` performs — use it for
+   re-runs and repairs. It refuses without \`--yes\`; there is no prompt, because
+   Codex's question tool does not block outside Plan mode and CI has no
    terminal.
 
-4. \`${RUN} uninstall --yes\`
+5. \`${RUN} uninstall --yes\`
    Removes what the lock file records and reverts the managed config blocks.
 
 ## Flags
@@ -38,17 +46,22 @@ registers the MCP servers and permission rules they depend on.
   --host claude-code|codex|copilot|cursor   restrict to one host, repeatable
   --scope project|user                      default: project
   --root <path>                             default: the current directory
-  --no-companions                           skip the optional companion-package skills
+  --no-extra-components                     skip the optional extra-component skills
 
-## Optional companion packages
+## Optional extra components
 
 Two skills — Specs Editor and Tender Discovery Tool — ship inside their own
 npm packages, not this one. \`plan\`/\`apply\` detect them offline
-(\`npx --no-install\`) and never fetch them. A \`skipped\` action means the
-package is not on this machine yet: install it with
-\`npm i -D <package>@<version>\` (the exact command is in the action's
-\`remedy\`, and in \`status\`'s \`companions\` array), then re-run
-\`${RUN} apply --yes\`.
+(\`npx --no-install\`) and never fetch them, probing for the exact version
+this release pins — any other version, including \`@latest\`, is treated as
+absent and the skill is skipped:
+
+\`\`\`bash
+${EXTRA_COMPONENT_INSTALLS}
+\`\`\`
+
+The exact command is also in a \`skipped\` action's \`remedy\`, and in
+\`status\`'s \`extra_components\` array. Install it, then re-run \`${RUN} apply --yes\`.
 
 ## What you can rely on
 
@@ -82,6 +95,14 @@ Every host reads its configuration at startup. The result's \`help\` array
 names the restart or reload each one needs — pass it on to the user rather
 than assuming the change is already live.
 
+## Keeping it current
+
+This guide is version ${PKG_VERSION}. To install or upgrade to the newest
+published version, run \`npx -y ${PKG_NAME}@latest install\`. Omitting
+\`@latest\` can reuse a copy already in the \`npx\` cache or this project's
+\`node_modules\`, so you would silently stay on whatever version you first
+installed.
+
 ## If you are a skill
 
 Call this CLI. Do not re-implement any of it, and do not copy this text into a
@@ -91,8 +112,8 @@ skill file — run \`${RUN} guide\` and follow what it says now.
 export async function main() {
   return out.ok('guide', {
     version: PKG_VERSION,
-    next_step: `${RUN} status`,
-    help: [`${RUN} status`, `${RUN} plan`, `${RUN} apply --yes`],
+    next_step: `${RUN} install`,
+    help: [`${RUN} install`, `${RUN} status`, `${RUN} plan`, `${RUN} apply --yes`],
     guide: GUIDE,
   });
 }

package/lib/hosts.mjs

@@ -14,12 +14,12 @@ import {
 import { abs, isDir, isWritable, walk } from './fsx.mjs';
 import { renderTomlTable, tomlTableExists, findFence } from './merge.mjs';
 import { readTextMaybe } from './fsx.mjs';
-import { COMPANIONS } from './companions.mjs';
+import { EXTRA_COMPONENTS } from './extra-components.mjs';
 
 export const HOSTS = ['claude-code', 'codex', 'copilot', 'cursor'];
 
 /** Where each host reads its skills from — the base every skill-copy and
- * companion skill-copy action is rooted at. */
+ * extra-component skill-copy action is rooted at. */
 export const SKILL_DIR = {
   'claude-code': '.claude/skills',
   codex: '.agents/skills',
@@ -103,16 +103,16 @@ function skillActions(host, targetBase) {
 }
 
 /**
- * One `skill-copy` action per optional companion package. The `skill:`
+ * One `skill-copy` action per optional extra component. The `skill:`
  * segment (not `file:`) keeps these ids from colliding, or deduping,
  * against a shipped `file-copy` action at the same path.
  */
-function companionActions(host, targetBase) {
-  return COMPANIONS.map((c) => {
+function extraComponentActions(host, targetBase) {
+  return EXTRA_COMPONENTS.map((c) => {
     const target = `${targetBase}/${c.id}/SKILL.md`;
     return {
       id: `${host}:skill:${target}`, host, kind: 'skill-copy',
-      companion: c.id, package: `${c.pkg}@${c.version}`, target,
+      component: c.id, package: `${c.pkg}@${c.version}`, target,
     };
   });
 }
@@ -158,7 +158,7 @@ function planClaude(ctx) {
   const host = 'claude-code';
   const out = [
     ...skillActions(host, SKILL_DIR[host]),
-    ...(ctx.companions === false ? [] : companionActions(host, SKILL_DIR[host])),
+    ...(ctx.extraComponents === false ? [] : extraComponentActions(host, SKILL_DIR[host])),
     ...agentActions(host, '.claude/agents', 'claude', '.md'),
     ...mcpJsonActions(host, '.mcp.json', 'mcpServers', ctx),
   ];
@@ -184,7 +184,7 @@ function planCodex(ctx) {
   const out = [
     // Codex discovers skills from `.agents/skills`, never `.claude/skills`.
     ...skillActions(host, SKILL_DIR[host]),
-    ...(ctx.companions === false ? [] : companionActions(host, SKILL_DIR[host])),
+    ...(ctx.extraComponents === false ? [] : extraComponentActions(host, SKILL_DIR[host])),
     ...agentActions(host, '.codex/agents', 'codex', '.toml'),
   ];
 
@@ -229,7 +229,7 @@ function planCopilot(ctx) {
   const host = 'copilot';
   const out = [
     ...skillActions(host, SKILL_DIR[host]),
-    ...(ctx.companions === false ? [] : companionActions(host, SKILL_DIR[host])),
+    ...(ctx.extraComponents === false ? [] : extraComponentActions(host, SKILL_DIR[host])),
     ...agentActions(host, '.github/agents', 'copilot', '.agent.md'),
     // Copilot CLI reads `.mcp.json`; VS Code reads `.vscode/mcp.json` under the
     // incompatible `servers` key. Both, or the two surfaces disagree.
@@ -256,7 +256,7 @@ function planCursor(ctx) {
     || (isDir(abs(ctx.root, '.claude/skills')) && isDir(abs(ctx.root, '.claude/agents')));
   if (!claudeTrees) {
     out.push(...skillActions(host, SKILL_DIR[host]));
-    if (ctx.companions !== false) out.push(...companionActions(host, SKILL_DIR[host]));
+    if (ctx.extraComponents !== false) out.push(...extraComponentActions(host, SKILL_DIR[host]));
     out.push(...agentActions(host, '.cursor/agents', 'claude', '.md'));
   }
   out.push(...mcpJsonActions(host, '.cursor/mcp.json', 'mcpServers', ctx));

package/lib/merge.mjs

@@ -17,6 +17,16 @@
 
 export const FENCE_ID = 'sw-ecosystem-agentic-harness';
 
+/**
+ * Collapse CRLF (and stray CR) to LF. A fence's identity is what sits between
+ * its markers, not the line-ending style the target file happens to use —
+ * `writeAtomic` writes back whatever EOL the file already had, so hashing raw
+ * bytes would make the same content look edited on a CRLF checkout.
+ */
+export function normalizeEol(text) {
+  return text.replace(/\r\n/g, '\n').replace(/\r/g, '');
+}
+
 // ---------------------------------------------------------------- JSON
 
 /**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@execuro-sw-ecosystem/sw-ecosystem-agentic-harness",
-  "version": "0.1.0",
+  "version": "0.1.3",
   "description": "Shopware 6 agentic harness: sw-* skills and sub-agents, plus an installer that writes them into Claude Code, Codex, GitHub Copilot and Cursor.",
   "license": "MIT",
   "author": "Execuro UG (haftungsbeschränkt)",
@@ -49,7 +49,7 @@
   "scripts": {
     "gen": "node scripts/gen-codex-agents.mjs && node scripts/gen-copilot-agents.mjs && node scripts/gen-agents-md.mjs",
     "gen:check": "node scripts/gen-codex-agents.mjs --check && node scripts/gen-copilot-agents.mjs --check && node scripts/gen-agents-md.mjs --check",
-    "test": "node --test test/*.test.mjs scripts/*.test.mjs",
+    "test": "node -e \"const{spawnSync}=require('node:child_process');const{readdirSync}=require('node:fs');const list=(dir)=>readdirSync(dir).filter((f)=>f.endsWith('.test.mjs')).map((f)=>dir+'/'+f);const files=[...list('test'),...list('scripts')];const r=spawnSync(process.execPath,['--test',...files],{stdio:'inherit'});process.exit(r.status??1);\"",
     "check:mcp": "node scripts/check-mcp.mjs"
   },
   "publishConfig": {

package/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "sw-ecosystem-agentic-harness",
-  "version": "0.1.0",
+  "version": "0.1.3",
   "description": "Shopware 6 agentic harness: sw-* skills and sub-agents for requirements, specs, implementation, verification and documentation, with an installer CLI that writes them into Claude Code, Codex, GitHub Copilot and Cursor. The knowledge-base MCP and the editor tools are separate npm packages.",
   "author": {
     "name": "Execuro UG (haftungsbeschränkt)",

package/skills/sw-design-requirements/SKILL.md

@@ -2,7 +2,7 @@
 name: sw-design-requirements
 description: Turn a briefing — chat text or a file, covering one or more features — into a lean, business-only PRD stored as specs/NNNN-slug.md. Runs an interactive clarification loop for the requirement gaps and inconsistencies that actually change the requirements, then scores a weighted confidence %. Use when asked to write, draft, refine, continue, or score a PRD / requirements doc / feature brief for this Shopware project. Never writes a tech spec or answers architecture questions — that's sw-design-solution.
 when_to_use: Trigger phrases — "write a PRD", "draft requirements", "turn this brief into a PRD", "continue PRD 0003", "is this PRD ready for specification", "raise the confidence on this PRD", "requirements for <feature>".
-argument-hint: [file-path | briefing text | specs/NNNN-slug.md to continue] [--editor]
+argument-hint: '[file-path | briefing text | specs/NNNN-slug.md to continue] [--editor]'
 allowed-tools: Read Write Edit Glob Grep AskUserQuestion Agent Skill Bash(ls *) Bash(mkdir -p specs) Bash(npx -y @execuro-sw-ecosystem/sw-specs-editor@0.1.0 *) mcp__ShopwareDevKnowledgeBase__list_docs mcp__ShopwareDevKnowledgeBase__grep_docs mcp__ShopwareDevKnowledgeBase__read_doc mcp__ShopwareDevKnowledgeBase__kb_status
 
 ---

package/skills/sw-design-solution/SKILL.md

@@ -2,7 +2,7 @@
 name: sw-design-solution
 description: Turn a PRD (specs/NNNN-slug.md) into a technical spec at specs/NNNN-slug-spec.md. Applies TDD — every acceptance criterion gets an implementation plan and e2e coverage, with Shopware toolchain (shopware-cli/PHPStan/ESLint/Stylelint) conventions baked into decisions up front. Runs a clarification loop for the gaps that change the implementation plan, and on the user's say-so extracts project-wide architecture/stack decisions into ADR files (specs/NNNN-slug-adr-<topic>.md) that gate readiness while proposed. Pre-checks vendor/ and the KB before it starts. Use when asked to write, draft, refine, or continue a tech spec / implementation plan. Never edits the source PRD or answers business/requirements questions — that's sw-design-requirements.
 when_to_use: Trigger phrases — "write the tech spec for PRD 0007", "create an implementation plan for this PRD", "draft the spec", "continue spec 0007", "is this spec ready for implementation".
-argument-hint: [specs/NNNN-slug.md | specs/NNNN-slug-spec.md] [--editor]
+argument-hint: '[specs/NNNN-slug.md | specs/NNNN-slug-spec.md] [--editor]'
 allowed-tools: Read Write Edit Glob Grep AskUserQuestion Agent Skill Bash(ls *) Bash(npx -y @execuro-sw-ecosystem/sw-specs-editor@0.1.0 *) WebSearch WebFetch mcp__ShopwareDevKnowledgeBase__list_docs mcp__ShopwareDevKnowledgeBase__grep_docs mcp__ShopwareDevKnowledgeBase__read_doc mcp__ShopwareDevKnowledgeBase__kb_status
 ---
 

package/skills/sw-discover-tender/SKILL.md

@@ -2,7 +2,7 @@
 name: sw-discover-tender
 description: Analyse a client tender (RFP, RFI or RFQ) for a Shopware 6 project into one markdown sidecar, <source basename>-analysis.md. Every requirement row gets a class against the installed Shopware version (stock / config / plugin / custom), a three-point person-day estimate, one line of mechanism and proposed scope-lock assumptions the partner accepts by ticking checkboxes — in the file or on the Tender Discovery Tool page (`--editor`); the next run reconciles the ticks, dissolves answered questions and re-estimates. At Ready to submit it exports one CSV per client table with compliance, comment and effort filled in the client's columns. Scope and PD only — never costs, prices, licence fees or budgets. Never designs the solution — that's sw-design-solution.
 when_to_use: Trigger phrases — "scope this RFP", "analyse the tender", "answer the RFI", "discover RFP 0001", "continue RFP 0001", "reconcile RFP 0001", "export the response for RFP 0001", "is RFP 0001 ready to submit", "open RFP 0001 in the browser", "open the tender tool", "sw-discover-tender specs/rfp-0001-x-analysis.md --editor".
-argument-hint: [tender file or folder of exports (.xlsx|.md|.txt|.csv|.pdf) | specs/rfp-NNNN-slug-analysis.md to continue] [--editor] [--batch <n|all>] [--export]
+argument-hint: '[tender file or folder of exports (.xlsx|.md|.txt|.csv|.pdf) | specs/rfp-NNNN-slug-analysis.md to continue] [--editor] [--batch <n|all>] [--export]'
 allowed-tools: Read Write Edit Glob Grep Agent AskUserQuestion Bash(ls *) Bash(mkdir -p specs) Bash(mkdir -p specs/.rfp *) Bash(shasum -a 256 *) Bash(npx -y @execuro-sw-ecosystem/sw-tender-discovery-tool@0.1.0 *) Bash(open *) Bash(xdg-open *) Bash(tail *) Bash(grep *) Bash(printf *) mcp__ShopwareDevKnowledgeBase__list_docs mcp__ShopwareDevKnowledgeBase__grep_docs mcp__ShopwareDevKnowledgeBase__read_doc mcp__ShopwareDevKnowledgeBase__kb_status
 ---
 

package/skills/sw-document-feature/SKILL.md

@@ -2,7 +2,7 @@
 name: sw-document-feature
 description: Document one Shopware project feature into the LLM-wiki under docs/project-wiki/ — one feature page per surface (administration/ and/or storefront/), the "why" row in the domain index, ADR pages only promoted from the WIP ADR files sw-design-solution extracted into specs/ once they are accepted and built (with an organised table of contents) or provided by the user (never invented). Sources are a PRD (specs/NNNN-slug.md), its tech spec (specs/NNNN-slug-spec.md), or the current chat. Runs a mandatory built-check gate first — pages for functionality that does not exist in custom/ or vendor/ are written only after the user explicitly enforces it, and then carry the ⚠️ NOT BUILT block. Never restates code; references paths, extension points, decisions, config. Not for writing PRDs or specs — that's sw-design-requirements / sw-design-solution.
 when_to_use: Trigger phrases — "document this feature", "write the wiki page for spec 0007", "document PRD specs/0003-…", "add docs for <feature>", "update the wiki for <feature>", "put this in the project wiki", "record this as a project coding rule", "override/waive this guideline for our project".
-argument-hint: [path to PRD or spec | empty = use chat] [--setup]
+argument-hint: '[path to PRD or spec | empty = use chat] [--setup]'
 allowed-tools: Read Glob Grep Bash Write Edit Agent AskUserQuestion mcp__ShopwareDevKnowledgeBase__list_docs mcp__ShopwareDevKnowledgeBase__grep_docs mcp__ShopwareDevKnowledgeBase__read_doc mcp__ShopwareDevKnowledgeBase__kb_status
 ---
 

package/skills/sw-document-feature/reference/setup-wiki.md

@@ -27,7 +27,12 @@ On repair the flavor is never asked — derive it: `docs/project-wiki/_config.ym
 
 ## 2. Questions (init only)
 
-One call to a structured question tool if you have one (Claude Code: `AskUserQuestion`; Codex: `request_user_input`), asked once ever per wiki. Question 2 is included only when the answer to question 1 is Jekyll — if the tool cannot express that dependency, ask question 1 alone first, then 2–3 in a second call.
+Asked once ever per wiki with a structured question tool if you have one (Claude Code: `AskUserQuestion`; Codex: `request_user_input`), in **two calls, never one**:
+
+- **Call 1 — question 1 on its own.** Wait for the answer.
+- **Call 2 — questions 2 and 3 together, and only when the answer to question 1 was Jekyll.** On Vanilla there is no second call at all: the flavor is the only answer needed.
+
+Questions 2 and 3 exist solely to fill `_config.yml`, which the Vanilla flavor does not have. Never put them in the same call as question 1 — no structured question tool can make an option list conditional on another answer in the same call, so a single call asks every user to pick a GitHub Pages deployment style, `baseurl` and all, before anyone has established that the wiki is a Jekyll site.
 
 - **Question 1 — "docs/project-wiki/ does not exist yet — set it up as a Jekyll/GitHub Pages site or a plain Markdown wiki?"**
   - Option 1, label "Jekyll / GitHub Pages (Recommended)": adds `_config.yml`, so pages render as a themed site with left sidebar navigation and search (Just the Docs, via `remote_theme:`), plus a Liquid-generated ADR table on top of the hand-maintained ADR index; ready to publish via GitHub Pages or `jekyll serve`.
@@ -136,7 +141,7 @@ On Jekyll, always name the resolved `baseurl` in that row, and when it was left
 ## Dry-run examples
 
 - **Empty project, no flag** (`composer.json` name `acme/webshop`, lock `6.7.13.0`, origin `git@github.com:acme/webshop-docs.git`): detect → no directory → ask §2 → Jekyll + own repository + default title → resolve `acme/webshop`, `6.7.13`, today, `baseurl: "/webshop-docs"` → announce → sub-agent writes 16 files → table: 16 created, `flavor | Jekyll / GitHub Pages · baseurl "/webshop-docs"`, no drift check (`guidelines/documentation-guidelines.md` was just created) → continue at step 1.
-- **Empty project, user picks Vanilla**: questions 2–3 are skipped (no `_config.yml` to configure) → 15 writes, overlay files from `reference/scaffold/vanilla/` → table: 15 created, `flavor | Vanilla / plain Markdown` → continue at step 1.
+- **Empty project, user picks Vanilla**: the second call never happens — questions 2–3 are never shown (no `_config.yml` to configure) → 15 writes, overlay files from `reference/scaffold/vanilla/` → table: 15 created, `flavor | Vanilla / plain Markdown` → continue at step 1.
 - **`--setup`, existing wiki with `domains/platform/logging.md` deleted**: repair → flavor derived from `_config.yml` → 1 write → drift check → table: 1 created, kept count, no `flavor` row → stop. Business domains, feature pages and the hand-edited `_config.yml` untouched.
 - **`--setup`, complete wiki**: nothing missing → drift check only → table: N kept → stop.
 - **No flag, complete wiki**: this file is never opened.

package/skills/sw-implement-feature/SKILL.md

@@ -2,7 +2,7 @@
 name: sw-implement-feature
 description: Implement a feature from its technical spec (specs/NNNN-slug-spec.md, written by sw-design-solution) following TDD — tests first per acceptance criterion, then the implementation, fixing until every relevant test passes (including that AC's own acceptance/e2e test, run immediately, not deferred), running Shopware's own shopware-cli fixers/static-analysis per AC to conform to Shopware's coding standards as code is written rather than after the fact. Builds ACs group by group per the spec's Parallel groups/Depends on data, fanning out independent ACs to concurrent agent spawns instead of one at a time. Runs sw-verify-feature as its final step to produce a full verification report. Use when asked to implement, build, or code a feature/epic from an existing tech spec.
 when_to_use: Trigger phrases — "implement spec 0007", "build this feature", "code the epic-1 spec", "implement the tech spec".
-argument-hint: [specs/NNNN-slug-spec.md]
+argument-hint: '[specs/NNNN-slug-spec.md]'
 allowed-tools: Read Write Edit Glob Grep Bash Agent mcp__ShopwareDevKnowledgeBase__list_docs mcp__ShopwareDevKnowledgeBase__grep_docs mcp__ShopwareDevKnowledgeBase__read_doc mcp__ShopwareDevKnowledgeBase__kb_status
 ---
 

package/skills/sw-setup/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: sw-setup
-description: Print one environment-readiness table for the project's development/test setup — containers, vendor/, Node, the editor CLIs, shopware-cli, the KB MCP, the acceptance-test project, Playwright browsers, its .env, per-plugin test scaffolding, the project wiki and `.gitignore`, plus the installer CLI's own configuration/drift status. Stops when every row is ticked. When rows are missing, asks one yes/no question and delegates the fix to the installer CLI. Use when asked to set up the project, check if the environment is ready, or bootstrap the tests. Never designs, implements or verifies a feature itself — that's sw-design-solution, sw-implement-feature and sw-verify-feature, which call this skill first. Never writes a host configuration file itself — that's the installer CLI.
+description: Print one environment-readiness table for the project's development/test setup — vendor/, Node, the editor CLIs, shopware-cli, the KB MCP, the acceptance-test project, Playwright browsers, its .env, per-plugin test scaffolding, the project wiki and `.gitignore`, plus the installer CLI's own configuration/drift status. Stops when every row is ticked. When rows are missing, asks one yes/no question and delegates the fix to the installer CLI. Use when asked to set up the project, check if the environment is ready, or bootstrap the tests. Never designs, implements or verifies a feature itself — that's sw-design-solution, sw-implement-feature and sw-verify-feature, which call this skill first. Never writes a host configuration file itself — that's the installer CLI.
 when_to_use: Trigger phrases — "set up the project", "is the environment ready", "bootstrap the tests", "sw-setup".
-allowed-tools: Read Glob Grep AskUserQuestion Skill Bash mcp__ShopwareDevKnowledgeBase__kb_status Bash(npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@0.1.0 *)
+allowed-tools: Read Glob Grep AskUserQuestion Skill Bash mcp__ShopwareDevKnowledgeBase__kb_status Bash(npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@latest *)
 ---
 
 # sw-setup
@@ -20,7 +20,7 @@ copy of this skill can go stale while the CLI does not. For the current
 source of truth, run:
 
 ```
-npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@0.1.0 guide
+npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@latest guide
 ```
 
 This skill only renders the CLI's output as a table and relays its one
@@ -40,22 +40,22 @@ table from this run's output — it does not re-run `sw-setup`'s checks.
 Run:
 
 ```
-npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@0.1.0 status
+npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@latest status
 ```
 
 It prints one JSON object (`ok`, `next_step`, `help`, and its own
 `hosts[]`/`drift[]` configuration state). Alongside it, run every
 environment row's check from `reference/rows.md` in this skill's directory —
-read-only, seconds each: file/directory existence, one `docker compose ps`,
-one version command, one `kb_status` call. Never write, never install, never
-ask a question in this step.
+read-only, seconds each: file/directory existence, one version command, one
+`kb_status` call. Never write, never install, never ask a question in this
+step.
 
 Print one checkbox list, one line per row — the environment rows first, then
 one line per configuration item the CLI's `hosts[]`/`drift[]` reports:
 
 ```
-- [x] Containers — web running
 - [x] vendor/ — shopware/core 6.7.13.0
+- [ ] vendor/ — vendor/bin/phpunit missing (tree built --no-dev)
 - [ ] Node — 18.x (need >= 20)
 - [-] Visual editors (optional) — Specs Editor not installed, Tender tool not installed
 - [x] shopware-cli — 0.16.10
@@ -86,11 +86,11 @@ For a missing/drifted configuration row, do not research or plan the fix
 yourself — the CLI's `plan` command already has it:
 
 ```
-npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@0.1.0 plan
+npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@latest plan
 ```
 
 List the concrete steps in plain words: environment-row fixes in order
-(Containers → vendor/ → Visual editors → KB MCP → Acceptance-test project →
+(vendor/ → Visual editors → KB MCP → Acceptance-test project →
 Playwright browsers → ATS env → Plugin tests → Project wiki), then the CLI's
 planned configuration changes last. Skip any row already ticked.
 
@@ -100,7 +100,7 @@ if you have one (Claude Code: `AskUserQuestion`; Codex: `request_user_input`,
 which is non-blocking outside Plan mode — so end the turn after asking).
 Options:
 - **Yes, run it** — run the environment-row fixes in order, then
-  `npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@0.1.0 apply --yes`
+  `npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@latest apply --yes`
   for the configuration changes, then re-run step 1 and print the final table.
 - **No, stop** — stop; the table from step 1 is already on screen.
 
@@ -112,8 +112,9 @@ Options:
   itself) are reported with install advice only, never installed.
 - Credentials (ATS env values) are prompted for as part of the single
   question in step 3, never invented, never printed back once entered.
-- A fix that needs a running container states so in the step list and stops
-  before running if the Containers row is still unticked at execution time.
+- A fix that runs inside a container says so in the step list; if the
+  container is not running at execution time it stops and reports that —
+  sw-setup never starts the developer's stack itself.
 - The Project wiki fix invokes `sw-document-feature --setup` with the Skill
   tool; the KB MCP row only reports whether the platform layer is built —
   the corpus ships already built inside the
@@ -137,7 +138,7 @@ line:
 
 ## Reference files
 
-`reference/rows.md` in this skill's directory — the twelve environment rows:
+`reference/rows.md` in this skill's directory — the eleven environment rows:
 check command(s), what "ticked" means, the fix steps verbatim from the
 guideline, and which skills the row blocks. Host configuration state (what
 gets installed into `.mcp.json`, permissions, `.gitignore`) is not in this