export declare const SKILL_MD_TEMPLATE = "---\nname: sdd\ndescription: >\n  Story Driven Development workflow. Use this skill whenever working in a\n  project that has `.sdd/config.yaml`, or when the user mentions SDD, sdd sync,\n  story driven development, spec-driven development, change requests, bugs, or\n  asks to implement a feature described in `product/` or `system/`. Also trigger\n  on phrases like \"sync the docs\", \"mark synced\", \"apply this CR\", \"fix this bug\"\n  when an SDD project is detected.\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.1\"\n---\n\n# SDD \u2014 Story Driven Development\n\n## What this is\n\nSDD keeps documentation (`product/`, `system/`) and code (`code/`) in sync.\nSpecs change \u2192 `sdd sync` surfaces what's pending \u2192 agent implements \u2192 `sdd mark-synced` commits the state \u2192 repeat.\n\nThe engine behind it is git: SDD uses `git diff` on the doc files to know what changed since the last sync. That's why committing immediately after every `mark-synced` is non-negotiable \u2014 skip a commit and the next sync will see phantom changes.\n\n## Detection\n\nThis project uses SDD if `.sdd/config.yaml` exists in the project root.\n\n## The core loop\n\nEvery session on an SDD project starts the same way \u2014 clear the backlog from highest priority down, then move new work forward:\n\n1. **Bugs first.** Run `sdd bug open`. If there are open bugs, fix the code/docs and run `sdd mark-bug-resolved`. Bugs block everything else.\n\n2. **Then Change Requests.** Run `sdd cr pending`. If there are pending CRs, apply them to the docs in `product/`/`system/` (this flips docs to `new`/`changed`/`deleted`), then run `sdd mark-cr-applied`. CRs are the intended way to modify specs \u2014 never edit docs arbitrarily to reflect user requests; turn them into CRs first if scope justifies it.\n\n3. **Then sync.** Run `sdd sync`. It returns a structured prompt listing every pending file and (for `changed` files) the exact git diff of what changed in the spec. Read only what the prompt tells you to read.\n\n4. **Implement.** Write code inside `code/` matching what each doc describes. For `deleted` files, remove the corresponding code \u2014 the doc itself gets deleted automatically on mark-synced.\n\n5. **Mark synced + commit.** This is one atomic step:\n\n```bash\nsdd mark-synced                     # or sdd mark-synced <specific files>\ngit add -A && git commit -m \"sdd sync: <what you implemented>\"\n```\n\nEvery mark-synced MUST be followed by a commit in the same turn. No exceptions. See \"Why the commit is mandatory\" below.\n\n6. **Publish (if remote configured).** If `.sdd/config.yaml` has a `remote:` section and an API key is set, remind the user they can push with `sdd push`.\n\n## Why the commit is mandatory\n\n`sdd mark-synced` records a snapshot of the doc files as the new sync baseline. On the next `sdd sync`, SDD runs `git diff` between HEAD and the working tree for each doc \u2014 that's how it detects what changed. If you mark-sync without committing, the diff machinery breaks: either the next sync sees nothing (false \"all synced\") or it re-surfaces already-implemented changes. The commit is what makes the sync loop durable.\n\n## Available commands\n\n- `sdd status` \u2014 All doc files and their state (new/changed/deleted/synced)\n- `sdd diff` \u2014 Spec changes since last sync\n- `sdd sync` \u2014 Structured prompt for pending files (with git diff for `changed`)\n- `sdd validate` \u2014 Check for broken references and issues\n- `sdd mark-synced [files...]` \u2014 Mark files (or all) as synced\n- `sdd cr list` / `sdd cr pending` / `sdd mark-cr-applied [files...]`\n- `sdd bug list` / `sdd bug open` / `sdd mark-bug-resolved [files...]`\n- `sdd compact [--purge] [--dry-run]` \u2014 Archive (default) or delete (`--purge`) applied CRs and resolved bugs\n- `sdd preflight [--no-validate]` \u2014 Pre-flight check: validation + transient docs + drafts + pending CRs + open bugs. Exits non-zero if anything is pending.\n\n## Rules\n\n1. **Always commit after mark-synced, in the same turn.** This is the one rule you cannot break \u2014 see rationale above.\n2. Always check bugs + CRs before sync; they take priority over new work.\n3. Only implement what the sync prompt asks for. Don't wander into unrelated code.\n4. All generated code goes inside `code/`. Nothing in `code/` should exist that isn't described by a doc.\n5. Respect constraints in `## Agent Notes` sections of doc files when present.\n6. Never edit files inside `.sdd/` manually \u2014 it's SDD's internal state.\n7. If remote is configured, suggest `sdd push` after a 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\n- `change-requests/` \u2014 Proposed modifications to the docs\n- `bugs/` \u2014 Bug reports\n- `.sdd/` \u2014 Config and sync state (do not edit by hand)\n\n## References\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";
export declare const SKILL_REMOTE_MD_TEMPLATE = "---\nname: sdd-remote\ndescription: >\n  Remote sync workflow for Story Driven Development. Use this skill whenever\n  the user asks to pull from remote, push changes to SDD Flow, enrich drafts,\n  update local state from remote, publish local updates, process remote drafts,\n  or run a remote worker job (enrich or sync). Also trigger on phrases like\n  \"sdd pull\", \"sdd push\", \"sync with SDD Flow\", \"enrich this CR\",\n  \"push the remote updates\", \"pull the latest specs\".\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.2\"\n---\n\n# SDD Remote \u2014 Pull, Enrich, Push\n\n## Purpose\n\nSynchronize local SDD docs with remote updates (from the SDD Flow server), enrich draft content,\nand publish the enriched result to remote in active states.\n\nThis skill also applies when a **remote worker job** is dispatched from SDD Flow \u2014 the worker\nruns these same workflows on behalf of the user.\n\n## Detection\n\nThis workflow applies when:\n\n- `.sdd/config.yaml` exists in the project root with a `remote:` section configured\n- The user asks to update local state from remote, pull pending CRs/bugs/docs,\n  enrich drafts, or push pending remote updates\n- A remote worker job prompt instructs you to follow this workflow\n\nBefore any pull/push operation, check remote configuration with `sdd remote status`.\n\n## Workflows\n\n### Enrich workflow \u2014 Change Request\n\nFollow this sequence to enrich a draft CR:\n\n1. Pull remote drafts:\n\n```bash\nsdd pull --crs-only\n```\n\n2. Generate the draft TODO list:\n\n```bash\nsdd drafts\n```\n\n3. Enrich the draft with technical details, acceptance criteria, edge cases, and any\n   relevant information from the project documentation and comments.\n\n4. Transition the enriched CR from `draft` to `pending`:\n\n```bash\nsdd mark-drafts-enriched\n```\n\n5. Push the enriched content:\n\n```bash\nsdd push\n```\n\n### Enrich workflow \u2014 Document\n\nFollow this sequence to enrich a document (e.g. a feature spec):\n\n1. Pull remote drafts:\n\n```bash\nsdd pull --docs-only\n```\n\n2. Locate the document file in `product/` or `system/` and update its content with the\n   enriched version.\n\n3. Push the enriched content:\n\n```bash\nsdd push\n```\n\nIf the document was in `draft` status, it transitions to `new` on the server.\n\n### Sync workflow \u2014 Project-level\n\nFull project sync when the user asks for \"the latest\" or \"pull everything and implement\":\n\n1. Pull the latest specs:\n\n```bash\nsdd pull\n```\n\n2. Run the `sdd` skill \u2014 it handles the full loop: open bugs, pending CRs, documentation\n   sync, code implementation, mark-synced, and commit.\n\n3. Push the local updates:\n\n```bash\nsdd push\n```\n\n## Rules\n\n1. Always check remote configuration before pull/push (`sdd remote status`). Fail gracefully if not configured.\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 the 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.\n6. **Always commit before pushing** when the sync workflow makes code changes. Push should never carry uncommitted work.\n\n## Related commands\n\n- `sdd remote init` \u2014 Configure remote for this project\n- `sdd remote status` \u2014 Show remote config + connectivity\n- `sdd pull` / `sdd pull --crs-only` / `sdd pull --docs-only`\n- `sdd drafts` \u2014 List draft items to enrich\n- `sdd mark-drafts-enriched` \u2014 Transition enriched drafts to pending\n- `sdd sync` / `sdd mark-synced` \u2014 Local sync loop (see `sdd` skill)\n- `sdd push` \u2014 Publish local updates to remote\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`sdd pull` keeps this status in sync with the remote (sdd-flow): remote `draft` maps to local `draft`; remote `pending` and `approved` both map to local `pending` (ready to process). Local `applied` is written only by `sdd mark-cr-applied`; if a CR is reopened on remote, the local file goes back to `pending`. Status transitions are shown in the pull output (e.g. `\u21BB change-requests/001-x.md (status: draft \u2192 pending)`).\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- `sdd compact [--purge] [--dry-run]` \u2014 Archive (or delete with `--purge`) applied CRs to keep the project lean. Only touches `applied` CRs.\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- `sdd compact [--purge] [--dry-run]` \u2014 Archive (or delete with `--purge`) resolved bugs to keep the project lean. Only touches `resolved` bugs.\n";
//# sourceMappingURL=templates.generated.d.ts.map