@applica-software-guru/sdd-core 1.8.1 → 1.8.2

package/dist/scaffold/templates.d.ts

@@ -1,10 +1,6 @@
+export { SKILL_MD_TEMPLATE, SKILL_UI_MD_TEMPLATE, SKILL_REMOTE_MD_TEMPLATE, FILE_FORMAT_REFERENCE, CHANGE_REQUESTS_REFERENCE, BUGS_REFERENCE, } from "./templates.generated.js";
 export interface ProjectInfo {
     description: string;
 }
-export declare const SKILL_MD_TEMPLATE = "---\nname: sdd\ndescription: >\n  Story Driven Development workflow. Use when working in a project\n  with .sdd/config.yaml, or when the user mentions SDD, sdd sync,\n  story driven development, or spec-driven development.\nlicense: MIT\ncompatibility: Requires sdd CLI (npm i -g @applica-software-guru/sdd)\nallowed-tools: Bash(sdd:*) Read Glob Grep\nmetadata:\n  author: applica-software-guru\n  version: \"1.0\"\n---\n\n# SDD \u2014 Story Driven Development\n\n## Detection\n\nThis project uses SDD if `.sdd/config.yaml` exists in the project root.\n\n## Workflow\n\nFollow this loop every time you work on an SDD project:\n\n1. Run `sdd bug open` \u2014 check if there are open bugs to fix first\n2. If there are open bugs, fix the code/docs, then run `sdd mark-bug-resolved`\n3. Run `sdd cr pending` \u2014 check if there are change requests to process\n4. If there are pending CRs, apply them to the docs, then run `sdd mark-cr-applied`\n5. Run `sdd sync` to see what needs to be implemented\n6. Read the documentation files listed in the sync output\n7. Implement what each file describes, writing code inside `code/`\n8. After implementing, mark files as synced:\n\n```\nsdd mark-synced product/features/auth.md\n```\n\nOr mark all pending files at once:\n\n```\nsdd mark-synced\n```\n\n9. **Commit immediately after mark-synced** \u2014 this is mandatory:\n\n```\ngit add -A && git commit -m \"sdd sync: <brief description of what was implemented>\"\n```\n\nDo NOT skip this step. Every mark-synced must be followed by a git commit.\n\n### Removing a feature\n\nIf a documentation file has `status: deleted`, it means that feature should be removed.\nDelete the related code in `code/`, then run `sdd mark-synced <file>` (the doc file will be removed automatically), then commit.\n\n## Available commands\n\n- `sdd status` \u2014 See all documentation files and their state (new/changed/deleted/synced)\n- `sdd diff` \u2014 See what changed since last sync\n- `sdd sync` \u2014 Get the sync prompt for pending files (includes git diff for changed files)\n- `sdd validate` \u2014 Check for broken references and issues\n- `sdd mark-synced [files...]` \u2014 Mark specific files (or all) as synced\n- `sdd cr list` \u2014 List all change requests with their status\n- `sdd cr pending` \u2014 Show draft change requests to process\n- `sdd mark-cr-applied [files...]` \u2014 Mark change requests as applied\n- `sdd bug list` \u2014 List all bugs with their status\n- `sdd bug open` \u2014 Show open bugs to fix\n- `sdd mark-bug-resolved [files...]` \u2014 Mark bugs as resolved\n\n## Rules\n\n1. **Always commit after mark-synced** \u2014 run `git add -A && git commit -m \"sdd sync: ...\"` immediately after `sdd mark-synced`. Never leave synced files uncommitted.\n2. Before running `sdd sync`, check for open bugs with `sdd bug open` and pending change requests with `sdd cr pending`\n3. If there are pending CRs, apply them to the docs first, then mark them with `sdd mark-cr-applied`\n4. Only implement what the sync prompt asks for\n5. All generated code goes inside `code/`\n6. Respect all constraints in `## Agent Notes` sections (if present)\n7. Do not edit files inside `.sdd/` manually\n\n## Project structure\n\n- `product/` \u2014 What to build (vision, users, features)\n- `system/` \u2014 How to build it (entities, architecture, tech stack, interfaces)\n- `code/` \u2014 All generated source code goes here\n- `change-requests/` \u2014 Change requests to the documentation\n- `bugs/` \u2014 Bug reports\n- `.sdd/` \u2014 Project config and sync state (do not edit)\n\n## References\n\nFor detailed information on specific topics, see:\n\n- [File format and status lifecycle](references/file-format.md)\n- [Change Requests workflow](references/change-requests.md)\n- [Bug workflow](references/bugs.md)\n";
-export declare const SKILL_UI_MD_TEMPLATE = "---\nname: sdd-ui\ndescription: >\n  UI Component Editor workflow. Use when the user wants to implement a React component\n  from a screenshot in an SDD project, iterating visually with live preview.\nlicense: MIT\ncompatibility: >\n  Requires sdd CLI (npm i -g @applica-software-guru/sdd).\n  Requires Playwright MCP configured in Claude Code\n  (e.g. @playwright/mcp or @executeautomation/playwright-mcp).\nallowed-tools: Bash(sdd:*) Read Glob Grep Edit Write mcp__playwright__screenshot mcp__playwright__navigate mcp__playwright__click\nmetadata:\n  author: applica-software-guru\n  version: \"1.1\"\n---\n\n# SDD UI \u2014 Visual Component Editor\n\n## Purpose\n\nUse this workflow when implementing a React component from a screenshot reference in an SDD project.\nThe split-panel editor shows the spec screenshot on the left and the live component on the right,\nso you can iterate visually until they match.\n\n## Prerequisites\n\n- `sdd` CLI installed globally\n- Playwright MCP configured in Claude Code settings\n  - e.g. `@playwright/mcp` or `@executeautomation/playwright-mcp`\n  - If not configured, inform the user and stop \u2014 visual feedback won't work without it\n\n## Workflow\n\n### Step 1 \u2014 Read the spec\n\nRead the SDD feature file to understand what the component should look like and do.\nLook for any screenshot paths referenced in the feature doc.\n\n### Step 2 \u2014 Launch the editor\n\n```bash\n# Single screenshot \u2014 detached (recommended when run by an agent)\nsdd ui launch-editor LoginForm \\\n  --screenshot product/features/auth/login.png \\\n  --detach\n\n# Multiple screenshots (e.g. desktop + mobile)\nsdd ui launch-editor LoginForm \\\n  --screenshot product/features/auth/login-desktop.png \\\n  --screenshot product/features/auth/login-mobile.png \\\n  --detach\n```\n\nThe command will:\n- Scaffold `code/components/LoginForm.tsx` if it doesn't exist\n- Print the exact component file path to edit\n- Start the editor at `http://localhost:5174`\n\nWith `--detach` the process runs in background and the terminal is immediately free.\nWithout `--detach` it runs in foreground (use Ctrl+C to stop).\n\nWith multiple screenshots, the left panel shows a tab per screenshot.\nWith a single screenshot, no tab bar is shown.\n\n### Step 3 \u2014 Implement the component\n\nEdit the file printed by `sdd ui launch-editor` (e.g. `code/components/LoginForm.tsx`).\n\nWrite a React component that matches the screenshot. Use standard HTML/CSS or inline styles \u2014\nno external UI library unless the project already uses one.\n\nVite HMR will update the right panel automatically on every save.\n\n### Step 4 \u2014 Visual check with Playwright\n\nAfter each save, screenshot the live preview and compare it with the spec:\n\n```\nmcp__playwright__navigate http://localhost:5174\nmcp__playwright__screenshot\n```\n\nThe left panel already shows the spec screenshot for direct comparison.\nNote differences in layout, spacing, typography, colors, and component structure.\n\n### Step 5 \u2014 Iterate\n\nEdit component \u2192 Playwright screenshot \u2192 compare \u2192 repeat until the preview matches the spec.\n\n### Step 6 \u2014 Finalize\n\n```bash\nsdd ui stop\nsdd mark-synced product/features/auth/login.md\ngit add -A && git commit -m \"sdd sync: implement LoginForm component\"\n```\n\n## Notes\n\n- The component file is permanent \u2014 it lives in `code/components/` and is part of your project\n- Port `5174` by default (not `5173`) to avoid conflicts with the user's app dev server\n- If the component needs props, scaffold it with hardcoded sample data for the preview\n\n## Troubleshooting\n\n**Playwright MCP not configured:**\nStop and ask the user to add it to their Claude Code MCP settings before continuing.\n\n**Component import fails in preview:**\nCheck that the component file has a valid default export and no TypeScript errors.\n\n**Port already in use:**\n`sdd ui launch-editor LoginForm --screenshot login.png --port 5175`\n";
-export declare const FILE_FORMAT_REFERENCE = "# File Format and Status Lifecycle\n\n## YAML Frontmatter\n\nEvery `.md` file in `product/` and `system/` must start with this YAML frontmatter:\n\n```yaml\n---\ntitle: \"File title\"\nstatus: new\nauthor: \"\"\nlast-modified: \"2025-01-01T00:00:00.000Z\"\nversion: \"1.0\"\n---\n```\n\n## Status values\n\n- **`new`** \u2014 new file, needs to be implemented\n- **`changed`** \u2014 modified since last sync, code needs updating\n- **`deleted`** \u2014 feature to be removed, agent should delete related code\n- **`synced`** \u2014 already implemented, up to date\n\n## Version\n\nPatch-bump on each edit: 1.0 \u2192 1.1 \u2192 1.2\n\n## Last-modified\n\nISO 8601 datetime, updated on each edit.\n\n## How sync works\n\n`sdd sync` generates a structured prompt for the agent based on pending files:\n\n- **`new` files**: the agent reads the full documentation and implements it from scratch\n- **`changed` files**: SDD uses `git diff` to compute what changed in the documentation since the last commit, and includes the diff in the sync prompt \u2014 this way the agent sees exactly what was modified and can update only the affected code\n- **`deleted` files**: the agent removes the related code\n\nThis is why **committing after every mark-synced is mandatory** \u2014 the git history is what SDD uses to detect changes.\n\n## UX and screenshots\n\nWhen a feature has UX mockups or screenshots, place them next to the feature doc:\n\n- **Simple feature** (no screenshots): `product/features/auth.md`\n- **Feature with screenshots**: use a folder with `index.md`:\n\n```\nproduct/features/auth/\n  index.md          \u2190 feature doc\n  login.png         \u2190 screenshot\n  register.png      \u2190 screenshot\n```\n\nReference images in the markdown with relative paths:\n\n```markdown\n## UX\n\n![Login screen](login.png)\n![Register screen](register.png)\n```\n\nBoth formats work \u2014 use a folder only when you have screenshots or multiple files for a feature.\n";
-export declare const CHANGE_REQUESTS_REFERENCE = "# Change Requests\n\nChange Requests (CRs) are markdown files in `change-requests/` that describe modifications to the documentation.\n\n## CR format\n\n```yaml\n---\ntitle: \"Add authentication feature\"\nstatus: draft\nauthor: \"user\"\ncreated-at: \"2025-01-01T00:00:00.000Z\"\n---\n```\n\n- **status**: `draft` (pending) or `applied` (already processed)\n\n## CR workflow\n\n1. Check for pending CRs: `sdd cr pending`\n2. Read each pending CR and apply the described changes to the documentation files (marking them as `new`, `changed`, or `deleted`)\n3. After applying a CR to the docs, mark it: `sdd mark-cr-applied change-requests/CR-001.md`\n4. Then run `sdd sync` to implement the code changes\n\n## CR commands\n\n- `sdd cr list` \u2014 See all change requests and their status\n- `sdd cr pending` \u2014 Show only draft CRs to process\n- `sdd mark-cr-applied [files...]` \u2014 Mark CRs as applied after updating the docs\n";
-export declare const BUGS_REFERENCE = "# Bugs\n\nBugs are markdown files in `bugs/` that describe problems found in the codebase.\n\n## Bug format\n\n```yaml\n---\ntitle: \"Login fails with empty password\"\nstatus: open\nauthor: \"user\"\ncreated-at: \"2025-01-01T00:00:00.000Z\"\n---\n```\n\n- **status**: `open` (needs fixing) or `resolved` (already fixed)\n\n## Bug workflow\n\n1. Check for open bugs: `sdd bug open`\n2. Read each open bug and fix the code and/or documentation\n3. After fixing a bug, mark it: `sdd mark-bug-resolved bugs/BUG-001.md`\n4. Commit the fix\n\n## Bug commands\n\n- `sdd bug list` \u2014 See all bugs and their status\n- `sdd bug open` \u2014 Show only open bugs to fix\n- `sdd mark-bug-resolved [files...]` \u2014 Mark bugs as resolved after fixing\n";
 export declare const EMPTY_LOCK_TEMPLATE: () => string;
 //# sourceMappingURL=templates.d.ts.map

package/dist/scaffold/templates.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"templates.d.ts","sourceRoot":"","sources":["../../src/scaffold/templates.ts"],"names":[],"mappings":"AAeA,MAAM,WAAW,WAAW;IAC1B,WAAW,EAAE,MAAM,CAAC;CACrB;AAED,eAAO,MAAM,iBAAiB,ovHAgG7B,CAAC;AAEF,eAAO,MAAM,oBAAoB,q6HAiHhC,CAAC;AAEF,eAAO,MAAM,qBAAqB,47DAiEjC,CAAC;AAEF,eAAO,MAAM,yBAAyB,26BA6BrC,CAAC;AAEF,eAAO,MAAM,cAAc,6uBA6B1B,CAAC;AAEF,eAAO,MAAM,mBAAmB,cAG/B,CAAC"}
+{"version":3,"file":"templates.d.ts","sourceRoot":"","sources":["../../src/scaffold/templates.ts"],"names":[],"mappings":"AAAA,OAAO,EACL,iBAAiB,EACjB,oBAAoB,EACpB,wBAAwB,EACxB,qBAAqB,EACrB,yBAAyB,EACzB,cAAc,GACf,MAAM,0BAA0B,CAAC;AAiBlC,MAAM,WAAW,WAAW;IAC1B,WAAW,EAAE,MAAM,CAAC;CACrB;AAED,eAAO,MAAM,mBAAmB,cAG/B,CAAC"}

package/dist/scaffold/templates.generated.d.ts

@@ -0,0 +1,7 @@
+export declare const SKILL_MD_TEMPLATE = "---\nname: sdd\ndescription: >\n  Story Driven Development workflow. Use when working in a project\n  with .sdd/config.yaml, or when the user mentions SDD, sdd sync,\n  story driven development, or spec-driven development.\nlicense: MIT\ncompatibility: Requires sdd CLI (npm i -g @applica-software-guru/sdd)\nallowed-tools: Bash(sdd:*) Read Glob Grep\nmetadata:\n  author: applica-software-guru\n  version: \"1.0\"\n---\n\n# SDD \u2014 Story Driven Development\n\n## Detection\n\nThis project uses SDD if `.sdd/config.yaml` exists in the project root.\n\n## Workflow\n\nFollow this loop every time you work on an SDD project:\n\n1. Run `sdd bug open` \u2014 check if there are open bugs to fix first\n2. If there are open bugs, fix the code/docs, then run `sdd mark-bug-resolved`\n3. Run `sdd cr pending` \u2014 check if there are change requests to process\n4. If there are pending CRs, apply them to the docs, then run `sdd mark-cr-applied`\n5. Run `sdd sync` to see what needs to be implemented\n6. Read the documentation files listed in the sync output\n7. Implement what each file describes, writing code inside `code/`\n8. After implementing, mark files as synced:\n\n```\nsdd mark-synced product/features/auth.md\n```\n\nOr mark all pending files at once:\n\n```\nsdd mark-synced\n```\n\n9. **Commit immediately after mark-synced** \u2014 this is mandatory:\n\n```\ngit add -A && git commit -m \"sdd sync: <brief description of what was implemented>\"\n```\n\nDo NOT skip this step. Every mark-synced must be followed by a git commit.\n\n10. If remote sync is configured (remote section in `.sdd/config.yaml` and API key available), remind the user they can publish updates with:\n\n```\nsdd push\n```\n\n### Removing a feature\n\nIf a documentation file has `status: deleted`, it means that feature should be removed.\nDelete the related code in `code/`, then run `sdd mark-synced <file>` (the doc file will be removed automatically), then commit.\n\n## Available commands\n\n- `sdd status` \u2014 See all documentation files and their state (new/changed/deleted/synced)\n- `sdd diff` \u2014 See what changed since last sync\n- `sdd sync` \u2014 Get the sync prompt for pending files (includes git diff for changed files)\n- `sdd validate` \u2014 Check for broken references and issues\n- `sdd mark-synced [files...]` \u2014 Mark specific files (or all) as synced\n- `sdd cr list` \u2014 List all change requests with their status\n- `sdd cr pending` \u2014 Show pending change requests to process\n- `sdd mark-cr-applied [files...]` \u2014 Mark change requests as applied\n- `sdd bug list` \u2014 List all bugs with their status\n- `sdd bug open` \u2014 Show open bugs to fix\n- `sdd mark-bug-resolved [files...]` \u2014 Mark bugs as resolved\n\n## Rules\n\n1. **Always commit after mark-synced** \u2014 run `git add -A && git commit -m \"sdd sync: ...\"` immediately after `sdd mark-synced`. Never leave synced files uncommitted.\n2. Before running `sdd sync`, check for open bugs with `sdd bug open` and pending change requests with `sdd cr pending`\n3. If there are pending CRs, apply them to the docs first, then mark them with `sdd mark-cr-applied`\n4. Only implement what the sync prompt asks for\n5. All generated code goes inside `code/`\n6. Respect all constraints in `## Agent Notes` sections (if present)\n7. Do not edit files inside `.sdd/` manually\n8. If remote is configured, suggest `sdd push` after successful local sync + commit\n\n## Project structure\n\n- `product/` \u2014 What to build (vision, users, features)\n- `system/` \u2014 How to build it (entities, architecture, tech stack, interfaces)\n- `code/` \u2014 All generated source code goes here\n- `change-requests/` \u2014 Change requests to the documentation\n- `bugs/` \u2014 Bug reports\n- `.sdd/` \u2014 Project config and sync state (do not edit)\n\n## References\n\nFor detailed information on specific topics, see:\n\n- [File format and status lifecycle](references/file-format.md)\n- [Change Requests workflow](references/change-requests.md)\n- [Bug workflow](references/bugs.md)\n- [Remote pull/enrich/push workflow](../sdd-remote/SKILL.md)\n- [UI Component workflow](../sdd-ui/SKILL.md)\n";
+export declare const SKILL_UI_MD_TEMPLATE = "---\nname: sdd-ui\ndescription: >\n  UI Component Editor workflow. Use when the user wants to implement a React component\n  from a screenshot in an SDD project, iterating visually with live preview.\nlicense: MIT\ncompatibility: >\n  Requires sdd CLI (npm i -g @applica-software-guru/sdd).\n  Requires Playwright MCP configured in Claude Code\n  (e.g. @playwright/mcp or @executeautomation/playwright-mcp).\nallowed-tools: Bash(sdd:*) Read Glob Grep Edit Write mcp__playwright__screenshot mcp__playwright__navigate mcp__playwright__click\nmetadata:\n  author: applica-software-guru\n  version: \"1.1\"\n---\n\n# SDD UI \u2014 Visual Component Editor\n\n## Purpose\n\nUse this workflow when implementing a React component from a screenshot reference in an SDD project.\nThe split-panel editor shows the spec screenshot on the left and the live component on the right,\nso you can iterate visually until they match.\n\n## Prerequisites\n\n- `sdd` CLI installed globally\n- Playwright MCP configured in Claude Code settings\n  - e.g. `@playwright/mcp` or `@executeautomation/playwright-mcp`\n  - If not configured, inform the user and stop \u2014 visual feedback won't work without it\n\n## Workflow\n\n### Step 1 \u2014 Read the spec\n\nRead the SDD feature file to understand what the component should look like and do.\nLook for any screenshot paths referenced in the feature doc.\n\n### Step 2 \u2014 Launch the editor\n\n```bash\n# Single screenshot \u2014 detached (recommended when run by an agent)\nsdd ui launch-editor LoginForm \\\n  --screenshot product/features/auth/login.png \\\n  --detach\n\n# Multiple screenshots (e.g. desktop + mobile)\nsdd ui launch-editor LoginForm \\\n  --screenshot product/features/auth/login-desktop.png \\\n  --screenshot product/features/auth/login-mobile.png \\\n  --detach\n```\n\nThe command will:\n- Scaffold `code/components/LoginForm.tsx` if it doesn't exist\n- Print the exact component file path to edit\n- Start the editor at `http://localhost:5174`\n\nWith `--detach` the process runs in background and the terminal is immediately free.\nWithout `--detach` it runs in foreground (use Ctrl+C to stop).\n\nWith multiple screenshots, the left panel shows a tab per screenshot.\nWith a single screenshot, no tab bar is shown.\n\n### Step 3 \u2014 Implement the component\n\nEdit the file printed by `sdd ui launch-editor` (e.g. `code/components/LoginForm.tsx`).\n\nWrite a React component that matches the screenshot. Use standard HTML/CSS or inline styles \u2014\nno external UI library unless the project already uses one.\n\nVite HMR will update the right panel automatically on every save.\n\n### Step 4 \u2014 Visual check with Playwright\n\nAfter each save, screenshot the live preview and compare it with the spec:\n\n```\nmcp__playwright__navigate http://localhost:5174\nmcp__playwright__screenshot\n```\n\nThe left panel already shows the spec screenshot for direct comparison.\nNote differences in layout, spacing, typography, colors, and component structure.\n\n### Step 5 \u2014 Iterate\n\nEdit component \u2192 Playwright screenshot \u2192 compare \u2192 repeat until the preview matches the spec.\n\n### Step 6 \u2014 Finalize\n\n```bash\nsdd ui stop\nsdd mark-synced product/features/auth/login.md\ngit add -A && git commit -m \"sdd sync: implement LoginForm component\"\n```\n\n## Notes\n\n- The component file is permanent \u2014 it lives in `code/components/` and is part of your project\n- Port `5174` by default (not `5173`) to avoid conflicts with the user's app dev server\n- If the component needs props, scaffold it with hardcoded sample data for the preview\n\n## Troubleshooting\n\n**Playwright MCP not configured:**\nStop and ask the user to add it to their Claude Code MCP settings before continuing.\n\n**Component import fails in preview:**\nCheck that the component file has a valid default export and no TypeScript errors.\n\n**Port already in use:**\n`sdd ui launch-editor LoginForm --screenshot login.png --port 5175`\n";
+export declare const SKILL_REMOTE_MD_TEMPLATE = "---\nname: sdd-remote\ndescription: >\n  Remote sync workflow for Story Driven Development. Use when the user asks\n  to update local state from remote changes, process remote drafts, and push\n  enriched items back.\nlicense: MIT\ncompatibility: Requires sdd CLI (npm i -g @applica-software-guru/sdd)\nallowed-tools: Bash(sdd:*) Read Glob Grep\nmetadata:\n  author: applica-software-guru\n  version: \"1.0\"\n---\n\n# SDD Remote - Pull, Enrich, Push\n\n## Purpose\n\nUse this skill to synchronize local SDD docs with remote updates, enrich draft content,\nand publish the enriched result to remote in active states.\n\n## Detection\n\nThis workflow applies when:\n\n- `.sdd/config.yaml` exists in the project root\n- The user asks to update local state from remote, pull pending CRs/bugs/docs,\n  enrich drafts, or push pending remote updates\n\n## Workflow\n\nFollow this sequence in order:\n\n1. Verify remote configuration\n\n```bash\ntest -f .sdd/config.yaml && sdd remote status\n```\n\nIf remote is not configured or disconnected, run:\n\n```bash\nsdd remote init\n```\n\nThen stop and ask the user for URL/API key if needed.\n\n2. Pull remote updates (docs + CRs + bugs)\n\n```bash\nsdd pull\n```\n\nOptional scoped pulls:\n\n```bash\nsdd pull --docs-only\nsdd pull --crs-only\nsdd pull --bugs-only\n```\n\n3. Generate draft TODO list for your coding agent\n\n```bash\nsdd drafts\n```\n\nThis command lists all local draft docs, CRs, and bugs and prints a minimal TODO-style prompt.\nGive that prompt to your coding agent. If additional context is needed, the agent can fetch it directly from project files.\n\n4. Transition enriched drafts to active states\n\n```bash\nsdd mark-drafts-enriched\n```\n\nThis performs:\n\n- Document: `draft -> new`\n- Change Request: `draft -> pending`\n- Bug: `draft -> open`\n\n5. Push local pending updates to remote\n\n```bash\nsdd push\n```\n\n6. Verify final remote sync state\n\n```bash\nsdd remote status\n```\n\n## Rules\n\n1. Always check remote configuration before pull/push (`sdd remote status`)\n2. Do not use `sdd push --all` unless the user explicitly asks for a full reseed\n3. If pull reports conflicts, do not overwrite local files blindly; report conflicts and ask how to proceed\n4. Do not edit files inside `.sdd/` manually\n5. Keep status transitions explicit: enrich first, then `sdd mark-drafts-enriched`, then push\n\n## Related commands\n\n- `sdd remote init`\n- `sdd remote status`\n- `sdd pull`\n- `sdd drafts`\n- `sdd mark-drafts-enriched`\n- `sdd push`\n";
+export declare const FILE_FORMAT_REFERENCE = "# File Format and Status Lifecycle\n\n## YAML Frontmatter\n\nEvery `.md` file in `product/` and `system/` must start with this YAML frontmatter:\n\n```yaml\n---\ntitle: \"File title\"\nstatus: new\nauthor: \"\"\nlast-modified: \"2025-01-01T00:00:00.000Z\"\nversion: \"1.0\"\n---\n```\n\n## Status values\n\n- **`new`** \u2014 new file, needs to be implemented\n- **`changed`** \u2014 modified since last sync, code needs updating\n- **`deleted`** \u2014 feature to be removed, agent should delete related code\n- **`synced`** \u2014 already implemented, up to date\n\n## Version\n\nPatch-bump on each edit: 1.0 \u2192 1.1 \u2192 1.2\n\n## Last-modified\n\nISO 8601 datetime, updated on each edit.\n\n## How sync works\n\n`sdd sync` generates a structured prompt for the agent based on pending files:\n\n- **`new` files**: the agent reads the full documentation and implements it from scratch\n- **`changed` files**: SDD uses `git diff` to compute what changed in the documentation since the last commit, and includes the diff in the sync prompt \u2014 this way the agent sees exactly what was modified and can update only the affected code\n- **`deleted` files**: the agent removes the related code\n\nThis is why **committing after every mark-synced is mandatory** \u2014 the git history is what SDD uses to detect changes.\n\n## UX and screenshots\n\nWhen a feature has UX mockups or screenshots, place them next to the feature doc:\n\n- **Simple feature** (no screenshots): `product/features/auth.md`\n- **Feature with screenshots**: use a folder with `index.md`:\n\n```\nproduct/features/auth/\n  index.md          \u2190 feature doc\n  login.png         \u2190 screenshot\n  register.png      \u2190 screenshot\n```\n\nReference images in the markdown with relative paths:\n\n```markdown\n## UX\n\n![Login screen](login.png)\n![Register screen](register.png)\n```\n\nBoth formats work \u2014 use a folder only when you have screenshots or multiple files for a feature.\n";
+export declare const CHANGE_REQUESTS_REFERENCE = "# Change Requests\n\nChange Requests (CRs) are markdown files in `change-requests/` that describe modifications to the documentation.\n\n## CR format\n\n```yaml\n---\ntitle: \"Add authentication feature\"\nstatus: draft\nauthor: \"user\"\ncreated-at: \"2025-01-01T00:00:00.000Z\"\n---\n```\n\n- **status**: `draft` (pending) or `applied` (already processed)\n- **status**: `draft` (needs enrichment), `pending` (ready to process), or `applied` (already processed)\n\n## CR workflow\n\n1. Check for pending CRs: `sdd cr pending`\n2. Read each pending CR and apply the described changes to the documentation files (marking them as `new`, `changed`, or `deleted`)\n3. After applying a CR to the docs, mark it: `sdd mark-cr-applied change-requests/CR-001.md`\n4. Then run `sdd sync` to implement the code changes\n\n## CR commands\n\n- `sdd cr list` \u2014 See all change requests and their status\n- `sdd cr pending` \u2014 Show only pending CRs to process\n- `sdd mark-cr-applied [files...]` \u2014 Mark CRs as applied after updating the docs\n";
+export declare const BUGS_REFERENCE = "# Bugs\n\nBugs are markdown files in `bugs/` that describe problems found in the codebase.\n\n## Bug format\n\n```yaml\n---\ntitle: \"Login fails with empty password\"\nstatus: open\nauthor: \"user\"\ncreated-at: \"2025-01-01T00:00:00.000Z\"\n---\n```\n\n- **status**: `draft` (needs enrichment), `open` (needs fixing), or `resolved` (already fixed)\n\n## Bug workflow\n\n1. Check for open bugs: `sdd bug open`\n2. Read each open bug and fix the code and/or documentation\n3. After fixing a bug, mark it: `sdd mark-bug-resolved bugs/BUG-001.md`\n4. Commit the fix\n\n## Bug commands\n\n- `sdd bug list` \u2014 See all bugs and their status\n- `sdd bug open` \u2014 Show only open bugs to fix\n- `sdd mark-bug-resolved [files...]` \u2014 Mark bugs as resolved after fixing\n";
+//# sourceMappingURL=templates.generated.d.ts.map

package/dist/scaffold/templates.generated.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"templates.generated.d.ts","sourceRoot":"","sources":["../../src/scaffold/templates.generated.ts"],"names":[],"mappings":"AAGA,eAAO,MAAM,iBAAiB,+lIAyG7B,CAAC;AAEF,eAAO,MAAM,oBAAoB,q6HAiHhC,CAAC;AAEF,eAAO,MAAM,wBAAwB,m+EA8GpC,CAAC;AAEF,eAAO,MAAM,qBAAqB,47DAiEjC,CAAC;AAEF,eAAO,MAAM,yBAAyB,uhCA8BrC,CAAC;AAEF,eAAO,MAAM,cAAc,0wBA6B1B,CAAC"}

package/dist/scaffold/templates.generated.js

@@ -0,0 +1,464 @@
+"use strict";
+// @generated — DO NOT EDIT. Source of truth: packages/skill/
+// Regenerate with: node packages/core/scripts/generate-templates.mjs
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.BUGS_REFERENCE = exports.CHANGE_REQUESTS_REFERENCE = exports.FILE_FORMAT_REFERENCE = exports.SKILL_REMOTE_MD_TEMPLATE = exports.SKILL_UI_MD_TEMPLATE = exports.SKILL_MD_TEMPLATE = void 0;
+exports.SKILL_MD_TEMPLATE = `---
+name: sdd
+description: >
+  Story Driven Development workflow. Use when working in a project
+  with .sdd/config.yaml, or when the user mentions SDD, sdd sync,
+  story driven development, or spec-driven development.
+license: MIT
+compatibility: Requires sdd CLI (npm i -g @applica-software-guru/sdd)
+allowed-tools: Bash(sdd:*) Read Glob Grep
+metadata:
+  author: applica-software-guru
+  version: "1.0"
+---
+
+# SDD — Story Driven Development
+
+## Detection
+
+This project uses SDD if \`.sdd/config.yaml\` exists in the project root.
+
+## Workflow
+
+Follow this loop every time you work on an SDD project:
+
+1. Run \`sdd bug open\` — check if there are open bugs to fix first
+2. If there are open bugs, fix the code/docs, then run \`sdd mark-bug-resolved\`
+3. Run \`sdd cr pending\` — check if there are change requests to process
+4. If there are pending CRs, apply them to the docs, then run \`sdd mark-cr-applied\`
+5. Run \`sdd sync\` to see what needs to be implemented
+6. Read the documentation files listed in the sync output
+7. Implement what each file describes, writing code inside \`code/\`
+8. After implementing, mark files as synced:
+
+\`\`\`
+sdd mark-synced product/features/auth.md
+\`\`\`
+
+Or mark all pending files at once:
+
+\`\`\`
+sdd mark-synced
+\`\`\`
+
+9. **Commit immediately after mark-synced** — this is mandatory:
+
+\`\`\`
+git add -A && git commit -m "sdd sync: <brief description of what was implemented>"
+\`\`\`
+
+Do NOT skip this step. Every mark-synced must be followed by a git commit.
+
+10. If remote sync is configured (remote section in \`.sdd/config.yaml\` and API key available), remind the user they can publish updates with:
+
+\`\`\`
+sdd push
+\`\`\`
+
+### Removing a feature
+
+If a documentation file has \`status: deleted\`, it means that feature should be removed.
+Delete the related code in \`code/\`, then run \`sdd mark-synced <file>\` (the doc file will be removed automatically), then commit.
+
+## Available commands
+
+- \`sdd status\` — See all documentation files and their state (new/changed/deleted/synced)
+- \`sdd diff\` — See what changed since last sync
+- \`sdd sync\` — Get the sync prompt for pending files (includes git diff for changed files)
+- \`sdd validate\` — Check for broken references and issues
+- \`sdd mark-synced [files...]\` — Mark specific files (or all) as synced
+- \`sdd cr list\` — List all change requests with their status
+- \`sdd cr pending\` — Show pending change requests to process
+- \`sdd mark-cr-applied [files...]\` — Mark change requests as applied
+- \`sdd bug list\` — List all bugs with their status
+- \`sdd bug open\` — Show open bugs to fix
+- \`sdd mark-bug-resolved [files...]\` — Mark bugs as resolved
+
+## Rules
+
+1. **Always commit after mark-synced** — run \`git add -A && git commit -m "sdd sync: ..."\` immediately after \`sdd mark-synced\`. Never leave synced files uncommitted.
+2. Before running \`sdd sync\`, check for open bugs with \`sdd bug open\` and pending change requests with \`sdd cr pending\`
+3. If there are pending CRs, apply them to the docs first, then mark them with \`sdd mark-cr-applied\`
+4. Only implement what the sync prompt asks for
+5. All generated code goes inside \`code/\`
+6. Respect all constraints in \`## Agent Notes\` sections (if present)
+7. Do not edit files inside \`.sdd/\` manually
+8. If remote is configured, suggest \`sdd push\` after successful local sync + commit
+
+## Project structure
+
+- \`product/\` — What to build (vision, users, features)
+- \`system/\` — How to build it (entities, architecture, tech stack, interfaces)
+- \`code/\` — All generated source code goes here
+- \`change-requests/\` — Change requests to the documentation
+- \`bugs/\` — Bug reports
+- \`.sdd/\` — Project config and sync state (do not edit)
+
+## References
+
+For detailed information on specific topics, see:
+
+- [File format and status lifecycle](references/file-format.md)
+- [Change Requests workflow](references/change-requests.md)
+- [Bug workflow](references/bugs.md)
+- [Remote pull/enrich/push workflow](../sdd-remote/SKILL.md)
+- [UI Component workflow](../sdd-ui/SKILL.md)
+`;
+exports.SKILL_UI_MD_TEMPLATE = `---
+name: sdd-ui
+description: >
+  UI Component Editor workflow. Use when the user wants to implement a React component
+  from a screenshot in an SDD project, iterating visually with live preview.
+license: MIT
+compatibility: >
+  Requires sdd CLI (npm i -g @applica-software-guru/sdd).
+  Requires Playwright MCP configured in Claude Code
+  (e.g. @playwright/mcp or @executeautomation/playwright-mcp).
+allowed-tools: Bash(sdd:*) Read Glob Grep Edit Write mcp__playwright__screenshot mcp__playwright__navigate mcp__playwright__click
+metadata:
+  author: applica-software-guru
+  version: "1.1"
+---
+
+# SDD UI — Visual Component Editor
+
+## Purpose
+
+Use this workflow when implementing a React component from a screenshot reference in an SDD project.
+The split-panel editor shows the spec screenshot on the left and the live component on the right,
+so you can iterate visually until they match.
+
+## Prerequisites
+
+- \`sdd\` CLI installed globally
+- Playwright MCP configured in Claude Code settings
+  - e.g. \`@playwright/mcp\` or \`@executeautomation/playwright-mcp\`
+  - If not configured, inform the user and stop — visual feedback won't work without it
+
+## Workflow
+
+### Step 1 — Read the spec
+
+Read the SDD feature file to understand what the component should look like and do.
+Look for any screenshot paths referenced in the feature doc.
+
+### Step 2 — Launch the editor
+
+\`\`\`bash
+# Single screenshot — detached (recommended when run by an agent)
+sdd ui launch-editor LoginForm \\
+  --screenshot product/features/auth/login.png \\
+  --detach
+
+# Multiple screenshots (e.g. desktop + mobile)
+sdd ui launch-editor LoginForm \\
+  --screenshot product/features/auth/login-desktop.png \\
+  --screenshot product/features/auth/login-mobile.png \\
+  --detach
+\`\`\`
+
+The command will:
+- Scaffold \`code/components/LoginForm.tsx\` if it doesn't exist
+- Print the exact component file path to edit
+- Start the editor at \`http://localhost:5174\`
+
+With \`--detach\` the process runs in background and the terminal is immediately free.
+Without \`--detach\` it runs in foreground (use Ctrl+C to stop).
+
+With multiple screenshots, the left panel shows a tab per screenshot.
+With a single screenshot, no tab bar is shown.
+
+### Step 3 — Implement the component
+
+Edit the file printed by \`sdd ui launch-editor\` (e.g. \`code/components/LoginForm.tsx\`).
+
+Write a React component that matches the screenshot. Use standard HTML/CSS or inline styles —
+no external UI library unless the project already uses one.
+
+Vite HMR will update the right panel automatically on every save.
+
+### Step 4 — Visual check with Playwright
+
+After each save, screenshot the live preview and compare it with the spec:
+
+\`\`\`
+mcp__playwright__navigate http://localhost:5174
+mcp__playwright__screenshot
+\`\`\`
+
+The left panel already shows the spec screenshot for direct comparison.
+Note differences in layout, spacing, typography, colors, and component structure.
+
+### Step 5 — Iterate
+
+Edit component → Playwright screenshot → compare → repeat until the preview matches the spec.
+
+### Step 6 — Finalize
+
+\`\`\`bash
+sdd ui stop
+sdd mark-synced product/features/auth/login.md
+git add -A && git commit -m "sdd sync: implement LoginForm component"
+\`\`\`
+
+## Notes
+
+- The component file is permanent — it lives in \`code/components/\` and is part of your project
+- Port \`5174\` by default (not \`5173\`) to avoid conflicts with the user's app dev server
+- If the component needs props, scaffold it with hardcoded sample data for the preview
+
+## Troubleshooting
+
+**Playwright MCP not configured:**
+Stop and ask the user to add it to their Claude Code MCP settings before continuing.
+
+**Component import fails in preview:**
+Check that the component file has a valid default export and no TypeScript errors.
+
+**Port already in use:**
+\`sdd ui launch-editor LoginForm --screenshot login.png --port 5175\`
+`;
+exports.SKILL_REMOTE_MD_TEMPLATE = `---
+name: sdd-remote
+description: >
+  Remote sync workflow for Story Driven Development. Use when the user asks
+  to update local state from remote changes, process remote drafts, and push
+  enriched items back.
+license: MIT
+compatibility: Requires sdd CLI (npm i -g @applica-software-guru/sdd)
+allowed-tools: Bash(sdd:*) Read Glob Grep
+metadata:
+  author: applica-software-guru
+  version: "1.0"
+---
+
+# SDD Remote - Pull, Enrich, Push
+
+## Purpose
+
+Use this skill to synchronize local SDD docs with remote updates, enrich draft content,
+and publish the enriched result to remote in active states.
+
+## Detection
+
+This workflow applies when:
+
+- \`.sdd/config.yaml\` exists in the project root
+- The user asks to update local state from remote, pull pending CRs/bugs/docs,
+  enrich drafts, or push pending remote updates
+
+## Workflow
+
+Follow this sequence in order:
+
+1. Verify remote configuration
+
+\`\`\`bash
+test -f .sdd/config.yaml && sdd remote status
+\`\`\`
+
+If remote is not configured or disconnected, run:
+
+\`\`\`bash
+sdd remote init
+\`\`\`
+
+Then stop and ask the user for URL/API key if needed.
+
+2. Pull remote updates (docs + CRs + bugs)
+
+\`\`\`bash
+sdd pull
+\`\`\`
+
+Optional scoped pulls:
+
+\`\`\`bash
+sdd pull --docs-only
+sdd pull --crs-only
+sdd pull --bugs-only
+\`\`\`
+
+3. Generate draft TODO list for your coding agent
+
+\`\`\`bash
+sdd drafts
+\`\`\`
+
+This command lists all local draft docs, CRs, and bugs and prints a minimal TODO-style prompt.
+Give that prompt to your coding agent. If additional context is needed, the agent can fetch it directly from project files.
+
+4. Transition enriched drafts to active states
+
+\`\`\`bash
+sdd mark-drafts-enriched
+\`\`\`
+
+This performs:
+
+- Document: \`draft -> new\`
+- Change Request: \`draft -> pending\`
+- Bug: \`draft -> open\`
+
+5. Push local pending updates to remote
+
+\`\`\`bash
+sdd push
+\`\`\`
+
+6. Verify final remote sync state
+
+\`\`\`bash
+sdd remote status
+\`\`\`
+
+## Rules
+
+1. Always check remote configuration before pull/push (\`sdd remote status\`)
+2. Do not use \`sdd push --all\` unless the user explicitly asks for a full reseed
+3. If pull reports conflicts, do not overwrite local files blindly; report conflicts and ask how to proceed
+4. Do not edit files inside \`.sdd/\` manually
+5. Keep status transitions explicit: enrich first, then \`sdd mark-drafts-enriched\`, then push
+
+## Related commands
+
+- \`sdd remote init\`
+- \`sdd remote status\`
+- \`sdd pull\`
+- \`sdd drafts\`
+- \`sdd mark-drafts-enriched\`
+- \`sdd push\`
+`;
+exports.FILE_FORMAT_REFERENCE = `# File Format and Status Lifecycle
+
+## YAML Frontmatter
+
+Every \`.md\` file in \`product/\` and \`system/\` must start with this YAML frontmatter:
+
+\`\`\`yaml
+---
+title: "File title"
+status: new
+author: ""
+last-modified: "2025-01-01T00:00:00.000Z"
+version: "1.0"
+---
+\`\`\`
+
+## Status values
+
+- **\`new\`** — new file, needs to be implemented
+- **\`changed\`** — modified since last sync, code needs updating
+- **\`deleted\`** — feature to be removed, agent should delete related code
+- **\`synced\`** — already implemented, up to date
+
+## Version
+
+Patch-bump on each edit: 1.0 → 1.1 → 1.2
+
+## Last-modified
+
+ISO 8601 datetime, updated on each edit.
+
+## How sync works
+
+\`sdd sync\` generates a structured prompt for the agent based on pending files:
+
+- **\`new\` files**: the agent reads the full documentation and implements it from scratch
+- **\`changed\` files**: SDD uses \`git diff\` to compute what changed in the documentation since the last commit, and includes the diff in the sync prompt — this way the agent sees exactly what was modified and can update only the affected code
+- **\`deleted\` files**: the agent removes the related code
+
+This is why **committing after every mark-synced is mandatory** — the git history is what SDD uses to detect changes.
+
+## UX and screenshots
+
+When a feature has UX mockups or screenshots, place them next to the feature doc:
+
+- **Simple feature** (no screenshots): \`product/features/auth.md\`
+- **Feature with screenshots**: use a folder with \`index.md\`:
+
+\`\`\`
+product/features/auth/
+  index.md          ← feature doc
+  login.png         ← screenshot
+  register.png      ← screenshot
+\`\`\`
+
+Reference images in the markdown with relative paths:
+
+\`\`\`markdown
+## UX
+
+![Login screen](login.png)
+![Register screen](register.png)
+\`\`\`
+
+Both formats work — use a folder only when you have screenshots or multiple files for a feature.
+`;
+exports.CHANGE_REQUESTS_REFERENCE = `# Change Requests
+
+Change Requests (CRs) are markdown files in \`change-requests/\` that describe modifications to the documentation.
+
+## CR format
+
+\`\`\`yaml
+---
+title: "Add authentication feature"
+status: draft
+author: "user"
+created-at: "2025-01-01T00:00:00.000Z"
+---
+\`\`\`
+
+- **status**: \`draft\` (pending) or \`applied\` (already processed)
+- **status**: \`draft\` (needs enrichment), \`pending\` (ready to process), or \`applied\` (already processed)
+
+## CR workflow
+
+1. Check for pending CRs: \`sdd cr pending\`
+2. Read each pending CR and apply the described changes to the documentation files (marking them as \`new\`, \`changed\`, or \`deleted\`)
+3. After applying a CR to the docs, mark it: \`sdd mark-cr-applied change-requests/CR-001.md\`
+4. Then run \`sdd sync\` to implement the code changes
+
+## CR commands
+
+- \`sdd cr list\` — See all change requests and their status
+- \`sdd cr pending\` — Show only pending CRs to process
+- \`sdd mark-cr-applied [files...]\` — Mark CRs as applied after updating the docs
+`;
+exports.BUGS_REFERENCE = `# Bugs
+
+Bugs are markdown files in \`bugs/\` that describe problems found in the codebase.
+
+## Bug format
+
+\`\`\`yaml
+---
+title: "Login fails with empty password"
+status: open
+author: "user"
+created-at: "2025-01-01T00:00:00.000Z"
+---
+\`\`\`
+
+- **status**: \`draft\` (needs enrichment), \`open\` (needs fixing), or \`resolved\` (already fixed)
+
+## Bug workflow
+
+1. Check for open bugs: \`sdd bug open\`
+2. Read each open bug and fix the code and/or documentation
+3. After fixing a bug, mark it: \`sdd mark-bug-resolved bugs/BUG-001.md\`
+4. Commit the fix
+
+## Bug commands
+
+- \`sdd bug list\` — See all bugs and their status
+- \`sdd bug open\` — Show only open bugs to fix
+- \`sdd mark-bug-resolved [files...]\` — Mark bugs as resolved after fixing
+`;
+//# sourceMappingURL=templates.generated.js.map

package/dist/scaffold/templates.generated.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"templates.generated.js","sourceRoot":"","sources":["../../src/scaffold/templates.generated.ts"],"names":[],"mappings":";AAAA,6DAA6D;AAC7D,qEAAqE;;;AAExD,QAAA,iBAAiB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAyGhC,CAAC;AAEW,QAAA,oBAAoB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAiHnC,CAAC;AAEW,QAAA,wBAAwB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA8GvC,CAAC;AAEW,QAAA,qBAAqB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAiEpC,CAAC;AAEW,QAAA,yBAAyB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA8BxC,CAAC;AAEW,QAAA,cAAc,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6B7B,CAAC"}