document360-engine 0.2.10 → 0.2.11

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "document360-engine",
-  "version": "0.2.10",
+  "version": "0.2.11",
   "description": "Headless documentation agent engine for document360-writer / -desktop. Emits a typed event stream; no UI.",
   "type": "module",
   "main": "./dist/index.js",

package/skills/CLAUDE.md

@@ -112,6 +112,7 @@ The "Capabilities" section below lists specialized skills. Pick the right one ba
 - Any "convert/wrap this into a callout/tabs/FAQ/accordion" request, or authoring with rich components → apply `d360-markdown` (always-on syntax reference).
 - "/publish ..." → `publish-to-d360`.
 - "/screenshot ..." or any time you generate a screenshot placeholder → also call `emit-screenshot-spec`.
+- "/capture-setup" / "what data do I need for screenshots" / after authoring screenshot specs in bulk → `capture-setup-checklist`.
 - Pulling extra context from other MCP sources during write-article → `gather-context-from-mcp`.
 
 If the user's intent is ambiguous, ask before invoking a skill that writes files or publishes.

package/skills/capture-setup-checklist/SKILL.md

@@ -0,0 +1,43 @@
+# Skill: capture-setup-checklist
+
+**Activate when** the user asks how to prepare data for screenshots ("what data do I need for captures", "capture setup", `/capture-setup`), OR right after you've emitted screenshot specs in bulk.
+
+**Goal:** one reviewable "stage this data" checklist, so the user dresses the demo context ONCE before running `d360-capture` — the way a technical writer prepares a demo account before a screenshot session. Screenshots can't show data that isn't there; this tells the user exactly what to create.
+
+## How
+
+1. **Collect.** Find every `<!-- SCREENSHOT ... -->` block across `<docsDir>/**/*.md`. From each, read the `id`, the title, and the `prerequisites:` lines.
+2. **Anchor to the scope.** Read the capture `scope` keys from `.d360-capture.json` (e.g. `project`, or `project`+`workspace`, or `org` — whatever THIS product scopes by; do not assume "project"). If no scope is set yet, recommend the keys you saw the product use and tell the user to set them.
+3. **Synthesize — don't dump.** A raw per-spec list is noise. Instead:
+   - **Group by context** (e.g. "In the demo project «`scope.project`»:").
+   - **Dedupe** overlapping needs — if eight shots each need "≥1 suite", say it once.
+   - **Order foundational → specific**: create the context first, then the records, then per-shot specifics.
+   - **Separate the un-stageable**: shots needing a transient state (a toast, a mid-import modal) go under "Set up by hand at capture time", not the standing-data list.
+4. **Write it** to `<captureDir>/CAPTURE-SETUP.md` (versioned + reviewable). Re-running refreshes it.
+5. **Close** by telling the user the path, to set `scope` in `.d360-capture.json` to point at the prepared context, then `d360-capture auth` (once) and `d360-capture capture`.
+
+## Quality bar
+
+- **Concrete:** real record names and counts ("create a suite named *Smoke*", "import one API spec"), not "have some data".
+- **Generic:** use the product's actual scope keys; never hardcode FlowForge's "project".
+- **Honest:** if a spec's `prerequisites:` are missing or vague, list that spec under "Needs a clearer prerequisite" rather than inventing data. Don't pretend a checklist item exists when the source doesn't say so.
+
+## Shape of the output (illustrative)
+
+```markdown
+# Capture data setup
+
+Prepare this once, then run `d360-capture capture`.
+
+## In the demo project "Docs Demo"
+- [ ] At least 1 **suite** (e.g. "Smoke") — needed by: suites-tab-list, suite-run-dashboard, …
+- [ ] At least 3 **schedules** — needed by: schedules-list-populated, schedule-context-menu
+- [ ] 1 **capture** with a click-gallery + a video — needed by: captures-detail-*
+- [ ] 1 imported **API spec** (with a version folder) — needed by: spec-import-*
+
+## Set up by hand at capture time (transient states)
+- flow-generation-timeout-banner — trigger a generation timeout, then capture.
+
+## Needs a clearer prerequisite
+- <spec-id> — its SCREENSHOT block doesn't say what data it needs; refine it.
+```

package/skills/emit-screenshot-spec/SKILL.md

@@ -101,6 +101,7 @@ Don't write a fragile selector. Instead:
 
 - Report the spec's path.
 - List anything that needs the user: the `data-testid`s a dev must add (TODO hatch), and the **data prerequisites** to stage (project/workspace + the records each shot needs).
+- After authoring several specs, run `capture-setup-checklist` to refresh the consolidated `CAPTURE-SETUP.md` staging guide.
 - Remind how to capture (screenshots are a separate tool — not bundled with the writer):
   1. First time only: `npm i -g document360-capture`
   2. Set the capture `scope` for the prepared demo context in `.d360-capture.json`.