export declare const BRIEF_IMPLEMENTER_FRONTMATTER = "---\nname: c4s-brief-implementer\ndescription: Implement features described in claude4spec briefs (markdown files in .claude4spec/briefs/). Briefs are self-contained \u2014 they include all context needed for implementation (entity snapshots, section diffs, narrative). After implementation, if you discover drift between the brief and reality (missing details, incorrect assumptions, edge cases not covered), generate a patch file in .claude4spec/patches/ as feedback for the specification author. Use when implementing changes in a code repository that has a .claude4spec/briefs/ directory.\n---\n";
export declare const BRIEF_IMPLEMENTER_BODY = "# c4s-brief-implementer\n\nThis skill describes how to implement a release brief in **your code repository**\n(not the spec repo). A brief is a self-contained markdown file under\n`.claude4spec/briefs/` that captures everything you need to ship the change:\nentity snapshots, section diffs, narrative, acceptance criteria.\n\n**This skill does NOT assume the `c4s` CLI is installed.** Briefs are designed\nto be self-contained \u2014 you do not need to read the main specification or query\nthe entity database. If the brief references something you cannot find in its\nbody, treat that as drift and file a patch (step 4 below).\n\n## Workflow\n\n### 1. Discover\n\n```sh\nls .claude4spec/briefs/        # list available briefs\ncat .claude4spec/briefs/<slug>.md\n```\n\nIf `.claude4spec/` is not in your current directory, walk up the directory tree\nuntil you find it (similar to how git finds `.git/`).\n\n### 2. Read the brief as self-contained input\n\nEvery brief has YAML frontmatter:\n\n```yaml\n---\ntype: brief\nfrom_release: v0.1.16\nto_release: v0.1.17\ngenerator_version: brief-author@0.1\nimplemented: false\n---\n```\n\nThe body contains everything you need \u2014 entity snapshots, section diffs, the\nnarrative of what changes, and acceptance criteria. **Do not read the main\nspecification.**\n\nIf the brief is unclear \u2014 a missing detail, an ambiguous wording, a decision\nyou'd otherwise have to guess \u2014 you have two paths:\n\n**Synchronous (preferred when available).** Ask the specification agent in the\nsame terminal and continue once you have an answer:\n\n```bash\nc4s ask \"Brief nie precyzuje X \u2014 czy chodzi o A czy B?\" --ct brief --brief <brief-slug>.md\n```\n\nContinue the same thread with `c4s ask \"...\" --thread <threadId>` (the\n`threadId` is printed with the answer). This path requires `c4s` installed\n*and* a running `npx claude4spec` server. When either is unavailable, skip it.\n\n**Asynchronous (always available).** If you cannot ask synchronously, proceed\nwith your best judgement and file a patch afterwards (step 4) so the\nspec-author can fold the clarification into the next brief.\n\n### 3. Implement\n\nStandard code flow in your target repository: read existing code, plan, edit,\ntest. Stay focused on what the brief specifies.\n\n### 4. Feedback loop (patches)\n\nWhen you discover that the brief diverges from reality \u2014 a missing detail, an\nincorrect assumption, an edge case not covered, or anything else the\nspec-author should know \u2014 write a patch file:\n\n```sh\nmkdir -p .claude4spec/patches\n```\n\nCreate `.claude4spec/patches/<brief-slug>-<short-desc>.md` with this format:\n\n```markdown\n---\ntype: patch\nbrief: v0-1-16-to-v0-1-17.md      # path relative to briefs/\npatch_kind: drift                  # drift | missing | incorrect | clarification\ncreated_at: 2026-05-11T17:32:00Z\ncreated_by: claude-code            # or \"cursor\", \"aider\", ...\n---\n\n# Patch \u2014 short title\n\n## What I found\n\n\u2026description of the drift / missing detail / incorrect assumption\u2026\n\n## Suggestion\n\n\u2026what the spec-author should consider in a follow-up brief or entity edits\u2026\n```\n\nPatch-kind values:\n\n- `drift` \u2014 the brief described behavior X, but the codebase already does Y.\n- `missing` \u2014 the brief is silent on a detail you had to decide yourself.\n- `incorrect` \u2014 the brief is factually wrong about existing code.\n- `clarification` \u2014 the brief is ambiguous; you guessed but it should be made\n  explicit for next time.\n\nThe `.claude4spec/patches/` directory is created **lazily** \u2014 only when you\nfile your first patch. The claude4spec server does NOT create it.\n\n### 5. Mark brief as implemented\n\nWhen the implementation is genuinely finished \u2014 code committed, tests green,\nmerged to main / accepted by the user \u2014 flip the brief's frontmatter to\n`implemented: true`:\n\n```bash\n# Option A \u2014 Edit tool: change the line `implemented: false` \u2192 `implemented: true`.\n# Option B \u2014 yq (idempotent; adds the field to legacy briefs that never had it):\nyq -i '.implemented = true' .claude4spec/briefs/<brief-slug>.md\n```\n\n`implemented: true` is a **declaration**, not a computed fact derived from git.\nA revert on main does NOT roll the flag back. Set it ONLY when implementation\nis realistically done \u2014 never proactively or \"just in case\".\n\n### 6. Hand-off\n\nThe spec-author reads patches manually (`ls .claude4spec/patches/`, `cat`)\nand folds them into the next brief or entity edits. There is no UI listing in\nthis release \u2014 patches are raw markdown.\n\n## Notes\n\nThis file is **fully managed** by claude4spec \u2014 it is overwritten on every\nserver start when its rendered content changes. Do not edit it by hand.\n";
