@seanmars/tospec 0.4.2

package/dist/core/templates/workflows/apply.js

@@ -0,0 +1,81 @@
+import { VERIFY_METHODOLOGY } from './verify.js';
+const APPLY_BODY = `**Steps**
+
+1. **Confirm planning is done**
+   \`\`\`bash
+   tospec status --change "<name>" --json
+   \`\`\`
+   Every artifact in \`applyRequires\` must be \`done\` before you write any code. If one isn't, stop and send the user back to \`tospec-propose\` or \`tospec-issue\`. Note \`schemaName\` — it decides which branch below applies.
+
+2. **Work the tracks file one item at a time**
+
+   The tracks file is \`tasks.md\` (sdd) or \`task.md\` (issue). Take the next unchecked item, implement it, check it off (\`- [ ]\` → \`- [x]\`) only once its test is green, then move to the next. Never batch multiple items into one pass.
+
+### sdd branch — TDD per slice
+
+For each tracer-bullet slice in \`tasks.md\`:
+1. Write the failing test first (red) — **only at the seam \`design.md\` named**. Don't test internals, don't add implementation-coupled assertions (mocking internal collaborators, reaching into private state, checking the database instead of the interface).
+2. Implement the minimum to pass (green). Don't anticipate future slices or add speculative flexibility.
+3. Verify the result matches the behavior the slice's specs describe.
+4. Check off the slice, then move to the next one — one slice per cycle. Refactoring is not part of this loop; it belongs to the verify step at the end of this workflow.
+
+### issue branch — three-way test split
+
+Read \`task.md\`'s feedback loop. Then:
+- **Existing test, failing** → the regression test from diagnosis already goes red. Find out why it fails and fix root cause (grep every caller of the function you're touching — the bug may hit more than the one path the ticket names).
+- **Existing test, passing** → the bug is an edge case the existing test doesn't cover. Add a new failing test for that edge case first, then fix.
+- **No existing test** → write the red regression test from \`task.md\`'s feedback loop first, then fix.
+
+Fix root cause, not symptom — if the same defect is reachable through multiple callers of a shared function, the fix belongs in the shared function, not patched into just the caller the ticket named.
+
+3. **Re-validate artifacts**
+   \`\`\`bash
+   tospec validate "<name>" --json
+   \`\`\`
+   Implementation sometimes touches tasks.md/specs directly (adding a discovered edge case, correcting an estimate) — confirm the change's artifacts are still structurally valid before handing off. Fix and re-run until it passes.
+
+## Verify (automatic — apply's final step)
+
+Once every task is checked off and \`tospec validate\` passes, run the two-axis review **automatically**. This is not a separate command the user has to invoke — verify is folded into apply and runs here as its last step, before the change is handed to \`tospec-archive\`.
+
+${VERIFY_METHODOLOGY}
+
+**Output**
+
+Report which tasks/checkboxes completed this pass, current progress (\`tospec status --change "<name>"\`), and whether all required artifacts are checked off. When everything is done, the verify review above has already run — if it came back clean, tell the user the change is ready for \`tospec-archive\`; if it surfaced blocking findings, keep working here to resolve them.
+
+**Guardrails**
+- Red before green, always — never write the implementation before its failing test
+- One slice/task at a time — no batching
+- Test only at the pre-agreed seam (design.md for sdd; the existing/new seam identified for issue) — never against internals
+- Fix root cause: check every caller of a shared function before declaring a fix complete
+- Don't hand off to archive until the automatic verify step is clean and the full test suite is green`;
+export function getTospecApplySkillTemplate() {
+    return {
+        name: 'tospec-apply',
+        description: 'Implement a change test-first, one tracer-bullet slice or task at a time, checking off tasks.md/task.md as you go, then automatically run the two-axis verify review. Use when planning artifacts are complete (sdd: ticket/specs/design/tasks; issue: ticket/task) and the user wants to start or continue implementation.',
+        instructions: `Implement a change's tasks test-first (red → green), one slice at a time, branching by schema, then automatically run the two-axis verify review — ready for \`tospec-archive\` when done.
+
+**Input**: The user's request should name the change to implement (or continue implementing).
+
+${APPLY_BODY}`,
+        license: 'MIT',
+        compatibility: 'Requires tospec CLI.',
+        metadata: { author: 'tospec', version: '1.0' },
+        allowedTools: ['Bash(tospec:*)', 'Bash', 'Read', 'Write', 'Edit', 'Grep', 'Glob', 'Agent'],
+    };
+}
+export function getTospecApplyCommandTemplate() {
+    return {
+        name: 'TOSPEC: Apply',
+        description: 'Implement a change test-first, one slice at a time, then auto-run the two-axis verify review',
+        category: 'Workflow',
+        tags: ['workflow', 'tdd', 'implementation'],
+        content: `Implement a change's tasks test-first (red → green), one slice at a time, branching by schema, then automatically run the two-axis verify review — ready for \`tospec-archive\` when done.
+
+**Input**: The argument after \`tospec-apply\` is the change name to implement (or continue implementing).
+
+${APPLY_BODY}`,
+    };
+}
+//# sourceMappingURL=apply.js.map

package/dist/core/templates/workflows/apply.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"apply.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/apply.ts"],"names":[],"mappings":"AAOA,OAAO,EAAE,kBAAkB,EAAE,MAAM,aAAa,CAAC;AAEjD,MAAM,UAAU,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAuCjB,kBAAkB;;;;;;;;;;;sGAWkF,CAAC;AAEvG,MAAM,UAAU,2BAA2B;IACzC,OAAO;QACL,IAAI,EAAE,cAAc;QACpB,WAAW,EAAE,6TAA6T;QAC1U,YAAY,EAAE;;;;EAIhB,UAAU,EAAE;QACV,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,CAAC;KAC3F,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,6BAA6B;IAC3C,OAAO;QACL,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,8FAA8F;QAC3G,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,KAAK,EAAE,gBAAgB,CAAC;QAC3C,OAAO,EAAE;;;;EAIX,UAAU,EAAE;KACX,CAAC;AACJ,CAAC"}

package/dist/core/templates/workflows/archive.d.ts

@@ -0,0 +1,10 @@
+/**
+ * Skill Template Workflow Modules
+ *
+ * This file is generated by splitting the legacy monolithic
+ * templates file into workflow-focused modules.
+ */
+import type { SkillTemplate, CommandTemplate } from '../types.js';
+export declare function getTospecArchiveSkillTemplate(): SkillTemplate;
+export declare function getTospecArchiveCommandTemplate(): CommandTemplate;
+//# sourceMappingURL=archive.d.ts.map

package/dist/core/templates/workflows/archive.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"archive.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/archive.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AAiDlE,wBAAgB,6BAA6B,IAAI,aAAa,CAc7D;AAED,wBAAgB,+BAA+B,IAAI,eAAe,CAYjE"}

package/dist/core/templates/workflows/archive.js

@@ -0,0 +1,75 @@
+const ARCHIVE_BODY = `**Finishing a change: confirm verify, decide about sync, then archive — in that order.** Do not run \`tospec archive\` speculatively "to see what happens"; each step below must actually hold first.
+
+**Step 0 — verify already happened in apply**
+
+verify is not a separate command anymore — it runs automatically at the end of \`tospec-apply\`. Before archiving, confirm apply's verify step came back clean (both Standards and Spec axes clear of blocking findings, full test suite green). If apply's verify surfaced blocking issues, **stop** and go back to \`tospec-apply\` to fix them — do not archive over them.
+
+**Step 1 — judge whether a sync is needed, and only ask if it is**
+
+Archive merges the change's delta specs into \`tospec/specs/\`, so if those specs have drifted from what the code actually does, archiving would lock in a spec that no longer matches reality. Decide **proactively** whether that risk applies here:
+
+- **Sync is warranted** when the change produced delta specs (a non-empty \`specs/<capability>/spec.md\` under the change dir) — i.e. behavior was added or changed, so spec-vs-code drift is possible.
+- **Sync is not needed** when there are no delta specs at all (e.g. a purely cosmetic issue fix with no behavior change). In that case skip straight to Step 2 and archive directly — don't ask a pointless question.
+
+If a sync is warranted, **ask the user one question** (make clear both answers are fine):
+
+> "This change has spec deltas. Run \`tospec-sync\` to reconcile the specs against the code before archiving? (recommended, but you can archive without it.)"
+
+- **User says yes** → run the \`tospec-sync\` workflow now. It reconciles each Requirement against the code (code wins) and writes \`sync-report.md\` with \`結論: PASS\`. If it ends in \`結論: FAIL\` (a real CODE-BUG), **stop** and return to \`tospec-apply\` to fix the code — do not archive. On PASS, archive **with** \`--require-sync\` (Step 2, synced branch).
+- **User says no** → that's allowed. Skip the sync and archive **without** \`--require-sync\` (Step 2, not-synced branch). Declining does not block archiving.
+
+**Step 2 — archive**
+
+Synced branch (user chose to sync and \`sync-report.md\` says \`結論: PASS\`):
+\`\`\`bash
+tospec archive "<name>" --require-sync
+\`\`\`
+\`--require-sync\` is the CLI's own machine-checkable half of the sync gate: it refuses unless \`sync-report.md\` exists with a \`結論: PASS\` line (\`SYNC_REPORT_MISSING\` / \`SYNC_REPORT_FAILED\`). If \`tospec-sync\` actually ran and passed, this succeeds for free — a CLI-enforced backstop behind the instruction-level order above. Only pass \`--require-sync\` when a sync actually ran; otherwise the CLI will (correctly) refuse.
+
+Not-synced branch (sync wasn't needed, or the user declined):
+\`\`\`bash
+tospec archive "<name>"
+\`\`\`
+
+Either way, the CLI then: re-validates the delta specs (blocking), checks tasks/task completion (asks for confirmation if incomplete), does a two-phase atomic merge into \`tospec/specs/\` (dry-run + re-validate every target first, writes only if all pass), and moves the change directory — including \`sync-report.md\` when present — into \`tospec/changes/archive/\` under a \`yyyyMMdd_HHmmss-<name>\` timestamp the CLI generates itself.
+
+**Guardrails — explicit and non-negotiable**
+- Judge whether a sync is warranted before archiving; only ask the user when the change has spec deltas — and honor a "no" (archive still proceeds, just without \`--require-sync\`)
+- Only pass \`--require-sync\` when \`tospec-sync\` actually produced a passing \`sync-report.md\` this run
+- **Never** construct an archive directory name yourself (the \`yyyyMMdd_HHmmss-<name>\` timestamp is generated by \`tospec archive\`'s internals — you have no way to reproduce it correctly, and guessing risks a collision or a wrong sort order)
+- **Never** create the archive directory yourself
+- **Never** manually move, copy, or rename the change directory
+- If \`tospec archive\` reports a validation failure or asks for confirmation on incomplete tasks, resolve the underlying issue (or explicitly confirm with the user) — do not route around it with manual file operations
+
+**Output**
+
+Report the archived name and path from \`tospec archive\`'s output, whether a sync ran, and confirm \`tospec/specs/\` now reflects the merged change.`;
+export function getTospecArchiveSkillTemplate() {
+    return {
+        name: 'tospec-archive',
+        description: 'Finish and archive a completed change: confirm apply\'s verify was clean, judge whether a spec/code sync is needed (asking the user first when it is), then run the one true tospec archive command. Use when the user wants to finalize an implemented change — never to manually move change directories or invent archive folder names.',
+        instructions: `Finish a completed change: confirm verify (done in apply), decide about sync (run \`tospec-sync\` if warranted and the user agrees), then \`tospec archive\` — the only path to a merged, archived change.
+
+**Input**: The user's request should name the change to archive.
+
+${ARCHIVE_BODY}`,
+        license: 'MIT',
+        compatibility: 'Requires tospec CLI.',
+        metadata: { author: 'tospec', version: '1.0' },
+        allowedTools: ['Bash(tospec:*)', 'Read', 'Write', 'Edit', 'Grep', 'Glob', 'AskUserQuestion'],
+    };
+}
+export function getTospecArchiveCommandTemplate() {
+    return {
+        name: 'TOSPEC: Archive',
+        description: 'Judge whether a spec/code sync is needed (ask if so), then finalize and archive a completed change',
+        category: 'Workflow',
+        tags: ['workflow', 'archive'],
+        content: `Finish a completed change: confirm verify (done in apply), decide about sync (run \`tospec-sync\` if warranted and the user agrees), then \`tospec archive\` — the only path to a merged, archived change.
+
+**Input**: The argument after \`tospec-archive\` is the change name to archive.
+
+${ARCHIVE_BODY}`,
+    };
+}
+//# sourceMappingURL=archive.js.map

package/dist/core/templates/workflows/archive.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"archive.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/archive.ts"],"names":[],"mappings":"AAQA,MAAM,YAAY,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;sJA6CiI,CAAC;AAEvJ,MAAM,UAAU,6BAA6B;IAC3C,OAAO;QACL,IAAI,EAAE,gBAAgB;QACtB,WAAW,EAAE,4UAA4U;QACzV,YAAY,EAAE;;;;EAIhB,YAAY,EAAE;QACZ,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,iBAAiB,CAAC;KAC7F,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,+BAA+B;IAC7C,OAAO;QACL,IAAI,EAAE,iBAAiB;QACvB,WAAW,EAAE,oGAAoG;QACjH,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,SAAS,CAAC;QAC7B,OAAO,EAAE;;;;EAIX,YAAY,EAAE;KACb,CAAC;AACJ,CAAC"}

package/dist/core/templates/workflows/explore.d.ts

@@ -0,0 +1,10 @@
+/**
+ * Skill Template Workflow Modules
+ *
+ * This file is generated by splitting the legacy monolithic
+ * templates file into workflow-focused modules.
+ */
+import type { SkillTemplate, CommandTemplate } from '../types.js';
+export declare function getExploreSkillTemplate(): SkillTemplate;
+export declare function getTospecExploreCommandTemplate(): CommandTemplate;
+//# sourceMappingURL=explore.d.ts.map

package/dist/core/templates/workflows/explore.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"explore.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/explore.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AAiDlE,wBAAgB,uBAAuB,IAAI,aAAa,CAcvD;AAED,wBAAgB,+BAA+B,IAAI,eAAe,CAYjE"}

package/dist/core/templates/workflows/explore.js

@@ -0,0 +1,75 @@
+const EXPLORE_BODY = `**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and run \`tospec\` read-only commands, but you must NEVER write code or create artifact files during explore. When the requirement converges, hand off to \`tospec-propose\` or \`tospec-issue\` — those write the files.
+
+This is a grilling interview, not a freeform chat. Interview the user relentlessly about the idea or problem until you both share the same understanding, walking every branch of the decision tree — batching questions that stand on their own, but following dependent threads one question at a time.
+
+**Steps**
+
+1. **Build known boundaries first**
+   \`\`\`bash
+   tospec list --json
+   \`\`\`
+   Read \`tospec/specs/\` for the capabilities this touches and \`tospec/config.yaml\` for project context. Do this BEFORE asking anything — questions you can answer yourself by reading the codebase are questions you should never ask the user.
+
+2. **Batch independent questions; sequence dependent ones**
+
+   Ask unrelated questions together in a single turn (use \`AskUserQuestion\` — up to 4 at once) so the user answers in one pass instead of a slow drip. Only when one question's answer changes what you'd ask next — A decides B — drop back to one at a time and wait for the answer before continuing. Each question carries your suggested answer and the reasoning, so the user can just say "yes" instead of writing an essay.
+
+   Work through this priority order, skipping anything already answered by the conversation or the codebase:
+   1. Goal and success condition — what does "done" look like?
+   2. Who the user/actor is
+   3. Boundaries — what's explicitly out of scope
+   4. Exceptions and error paths
+   5. Data and state — what persists, what's transient
+   6. Unstated assumptions — the things nobody said out loud
+
+3. **Probe every answer for hidden premises**
+
+   After each answer, ask what it implies that hasn't been said yet. This is the core of the interview — surface-level answers hide the decisions that actually matter. Keep pulling on a thread until it stops giving you new information, then move to the next branch.
+
+4. **Route by question type**
+   - **Factual** ("does X already exist", "what does Y currently do") → look it up in the codebase yourself, never ask the user
+   - **Decision** (behavior, scope, tradeoffs) → always ask, and wait for the answer before proceeding
+
+5. **Converge**
+
+   You're done when you can fully restate the requirement back to the user in your own words and they confirm it's correct — not when you run out of questions. If they correct your restatement, that's a sign there's still a hidden branch; keep grilling.
+
+6. **Restate and hand off**
+
+   Deliver the converged understanding back in the conversation — the problem, the decisions made (with reasoning), and anything explicitly ruled out — so \`tospec-propose\`/\`tospec-issue\` can synthesize it straight from context (that's exactly the input they expect). Explore persists nothing itself; the decisions get written into \`proposal.md\`/\`task.md\` by whichever skill you hand off to. Then ask whether to proceed to \`tospec-propose\` (new requirement) or \`tospec-issue\` (something is broken) — or keep exploring if the user isn't ready.
+
+**Guardrails**
+- **Don't implement** — never write application code or edit source files during explore
+- **Batch what's independent, sequence what's dependent** — ask unrelated questions together in one turn; split to one at a time only when A's answer decides B
+- **Don't ask what you can look up** — codebase facts are yours to find, not the user's to recite
+- **Don't stop at the first plausible answer** — dig for the implied premise behind it
+- **Don't force convergence** — if the user wants to keep exploring after you've restated where things stand, keep going`;
+export function getExploreSkillTemplate() {
+    return {
+        name: 'tospec-explore',
+        description: 'Grill the user through a focused interview to converge on a requirement or a problem before it becomes a change. Use when the idea is still fuzzy, before creating a proposal or issue, or whenever the user wants to think something through rather than build it yet.',
+        instructions: `Grill the user about their idea or problem — batching independent questions, sequencing dependent ones — until it converges into something concrete enough to become a \`tospec-propose\` or \`tospec-issue\`.
+
+**Input**: The user's request is whatever they want to think through — a vague idea, a specific problem, or a change name to explore in context of.
+
+${EXPLORE_BODY}`,
+        license: 'MIT',
+        compatibility: 'Requires tospec CLI.',
+        metadata: { author: 'tospec', version: '1.0' },
+        allowedTools: ['Bash(tospec:*)', 'Read', 'Grep', 'Glob', 'AskUserQuestion'],
+    };
+}
+export function getTospecExploreCommandTemplate() {
+    return {
+        name: 'TOSPEC: Explore',
+        description: 'Grill the user through a focused interview to converge on a requirement or a problem',
+        category: 'Workflow',
+        tags: ['workflow', 'explore'],
+        content: `Grill the user about their idea or problem — batching independent questions, sequencing dependent ones — until it converges into something concrete enough to become a \`tospec-propose\` or \`tospec-issue\`.
+
+**Input**: The argument after \`tospec-explore\` is whatever the user wants to think through — a vague idea, a specific problem, or a change name to explore in context of. May be empty.
+
+${EXPLORE_BODY}`,
+    };
+}
+//# sourceMappingURL=explore.js.map

package/dist/core/templates/workflows/explore.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"explore.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/explore.ts"],"names":[],"mappings":"AAQA,MAAM,YAAY,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;yHA6CoG,CAAC;AAE1H,MAAM,UAAU,uBAAuB;IACrC,OAAO;QACL,IAAI,EAAE,gBAAgB;QACtB,WAAW,EAAE,yQAAyQ;QACtR,YAAY,EAAE;;;;EAIhB,YAAY,EAAE;QACZ,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,iBAAiB,CAAC;KAC5E,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,+BAA+B;IAC7C,OAAO;QACL,IAAI,EAAE,iBAAiB;QACvB,WAAW,EAAE,sFAAsF;QACnG,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,SAAS,CAAC;QAC7B,OAAO,EAAE;;;;EAIX,YAAY,EAAE;KACb,CAAC;AACJ,CAAC"}

package/dist/core/templates/workflows/issue.d.ts

@@ -0,0 +1,10 @@
+/**
+ * Skill Template Workflow Modules
+ *
+ * This file is generated by splitting the legacy monolithic
+ * templates file into workflow-focused modules.
+ */
+import type { SkillTemplate, CommandTemplate } from '../types.js';
+export declare function getTospecIssueSkillTemplate(): SkillTemplate;
+export declare function getTospecIssueCommandTemplate(): CommandTemplate;
+//# sourceMappingURL=issue.d.ts.map

package/dist/core/templates/workflows/issue.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"issue.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/issue.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AA+DlE,wBAAgB,2BAA2B,IAAI,aAAa,CAc3D;AAED,wBAAgB,6BAA6B,IAAI,eAAe,CAY/D"}

package/dist/core/templates/workflows/issue.js

@@ -0,0 +1,89 @@
+const ISSUE_BODY = `Diagnose before you propose a fix. Jumping to a hypothesis before you can reproduce the bug on command is the exact failure this workflow prevents.
+
+**Steps**
+
+1. **Create the change**
+   \`\`\`bash
+   tospec new change "<name>" --schema issue
+   \`\`\`
+   Derive a kebab-case name from the symptom if none was given. This also **auto-generates the ticket stub** in the global index at \`tospec/tickets/<yyyyMMdd_HHmmss>-<name>.md\` (yaml header + a short Summary, \`ref\` pointing at \`task.md\`) — the CLI owns that timestamped filename, so **never create or rename ticket files yourself**.
+
+2. **Refine the ticket summary**
+   \`\`\`bash
+   tospec status --change "<name>" --json
+   \`\`\`
+   The ticket stub already exists in \`tospec/tickets/\` (CLI-written; not a \`status\` artifact). Edit its one-line \`## Summary\` to name the symptom in a sentence. Keep it thin — the full symptom/reproduction/expected-vs-actual and the whole diagnosis go into \`task.md\` (step 6), not the ticket.
+
+3. **Build a tight feedback loop before hypothesizing**
+
+   This is the core of the workflow. Find or build **one command** that reliably goes red on this exact bug: a failing test at the right seam, a CLI invocation diffed against expected output, a curl against a running dev server — whatever's fastest. It must be:
+   - **Red-capable** — actually drives the bug's code path and catches the user's exact symptom, not "runs without erroring"
+   - **Deterministic** — same verdict every run (flaky bugs: raise the reproduction rate until it's debuggable)
+   - **Fast** — seconds, not minutes
+   - **Already run at least once** — you have pasted its invocation and output before moving on
+
+   Do not skip this to go read code and form a theory. No red-capable command, no hypotheses.
+
+4. **Rank 3-5 falsifiable hypotheses**
+
+   Each hypothesis must predict something checkable: "if X is the cause, changing Y makes the bug disappear." A hypothesis you can't falsify is a vibe — sharpen it or drop it. Show the ranked list to the user before testing; they often have context that instantly re-ranks it ("we just touched that module").
+
+5. **Verify hypotheses one at a time**
+
+   Change one variable per probe. Prefer a debugger/REPL breakpoint over logs; if you must log, tag every debug line with a unique prefix (\`[DEBUG-xxxx]\`) so cleanup is one grep. Stop at the first hypothesis the loop from step 3 confirms.
+
+6. **Write the diagnosis into task.md**
+   \`\`\`bash
+   tospec instructions task --change "<name>" --json
+   \`\`\`
+   Include: the symptom and how to reproduce it, the verified root cause (not a guess — how you verified it), why existing tests didn't already catch this, the fix plan, the test plan, and a checkbox task list for \`tospec-apply\`. This is where the issue's detail lives (the ticket only summarizes).
+
+7. **Delta specs — only if behavior changes**
+
+   \`specs\` is optional in the issue schema. Only produce it if the fix changes externally observable behavior (skip it and \`status\` will show \`skipped\`, not \`blocked\`). If the bug is the spec itself being wrong, use MODIFIED to correct the Requirement instead of writing new tests against a wrong spec.
+
+8. **Validate and auto-fix**
+   \`\`\`bash
+   tospec validate "<name>" --json
+   \`\`\`
+   Fix whatever the report points at and re-run until it passes.
+
+**Output**
+
+Summarize the confirmed root cause, the fix plan, and prompt: "Run \`tospec-apply\` to fix it."
+
+**Guardrails**
+- The ticket file and its timestamp are CLI-generated — never create, rename, or move ticket files; only edit the Summary in the existing stub
+- No hypotheses before a red-capable feedback loop exists
+- 3-5 ranked, falsifiable hypotheses — never a single guess
+- Root cause must be verified, not assumed — state how you confirmed it
+- Don't write \`specs\` unless the fix actually changes external behavior`;
+export function getTospecIssueSkillTemplate() {
+    return {
+        name: 'tospec-issue',
+        description: 'Diagnose a reported bug down to a verified root cause and turn it into an issue change (ticket stub + task). Use when the user reports something broken, throwing, or behaving unexpectedly and wants it tracked and fixed.',
+        instructions: `Diagnose a bug to a verified root cause and produce an issue change (ticket stub + task) — ready for \`tospec-apply\`.
+
+**Input**: The user's request should describe the symptom (what's broken) and, ideally, how to reproduce it.
+
+${ISSUE_BODY}`,
+        license: 'MIT',
+        compatibility: 'Requires tospec CLI.',
+        metadata: { author: 'tospec', version: '1.0' },
+        allowedTools: ['Bash(tospec:*)', 'Bash', 'Read', 'Write', 'Edit', 'Grep', 'Glob', 'AskUserQuestion'],
+    };
+}
+export function getTospecIssueCommandTemplate() {
+    return {
+        name: 'TOSPEC: Issue',
+        description: 'Diagnose a reported bug to a verified root cause and produce an issue change',
+        category: 'Workflow',
+        tags: ['workflow', 'issue', 'debugging'],
+        content: `Diagnose a bug to a verified root cause and produce an issue change (ticket stub + task) — ready for \`tospec-apply\`.
+
+**Input**: The argument after \`tospec-issue\` describes the symptom (what's broken) and, ideally, how to reproduce it.
+
+${ISSUE_BODY}`,
+    };
+}
+//# sourceMappingURL=issue.js.map

package/dist/core/templates/workflows/issue.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"issue.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/issue.ts"],"names":[],"mappings":"AAQA,MAAM,UAAU,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;0EA2DuD,CAAC;AAE3E,MAAM,UAAU,2BAA2B;IACzC,OAAO;QACL,IAAI,EAAE,cAAc;QACpB,WAAW,EAAE,6NAA6N;QAC1O,YAAY,EAAE;;;;EAIhB,UAAU,EAAE;QACV,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,iBAAiB,CAAC;KACrG,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,6BAA6B;IAC3C,OAAO;QACL,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,8EAA8E;QAC3F,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,OAAO,EAAE,WAAW,CAAC;QACxC,OAAO,EAAE;;;;EAIX,UAAU,EAAE;KACX,CAAC;AACJ,CAAC"}

package/dist/core/templates/workflows/propose.d.ts

@@ -0,0 +1,10 @@
+/**
+ * Skill Template Workflow Modules
+ *
+ * This file is generated by splitting the legacy monolithic
+ * templates file into workflow-focused modules.
+ */
+import type { SkillTemplate, CommandTemplate } from '../types.js';
+export declare function getTospecProposeSkillTemplate(): SkillTemplate;
+export declare function getTospecProposeCommandTemplate(): CommandTemplate;
+//# sourceMappingURL=propose.d.ts.map

package/dist/core/templates/workflows/propose.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"propose.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/propose.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AAmDlE,wBAAgB,6BAA6B,IAAI,aAAa,CAc7D;AAED,wBAAgB,+BAA+B,IAAI,eAAe,CAYjE"}

package/dist/core/templates/workflows/propose.js

@@ -0,0 +1,77 @@
+const PROPOSE_BODY = `Do NOT re-interview the user — synthesize what's already in the conversation (or from a prior \`tospec-explore\`). If the requirement is still fuzzy, send them to \`tospec-explore\` first instead of guessing.
+
+**Steps**
+
+1. **Create the change**
+   \`\`\`bash
+   tospec new change "<name>" --schema sdd
+   \`\`\`
+   Derive a kebab-case name from the request if none was given. This also **auto-generates the ticket stub** in the global index at \`tospec/tickets/<yyyyMMdd_HHmmss>-<name>.md\` (yaml header + a short Summary) — the CLI owns that timestamped filename, so **never create or rename ticket files yourself**.
+
+2. **Get the artifact build order**
+   \`\`\`bash
+   tospec status --change "<name>" --json
+   \`\`\`
+   Use \`applyRequires\`, \`artifacts\`, and \`actionContext\` to drive the loop below — never assume paths. The ticket stub already exists in \`tospec/tickets/\` (the CLI wrote it; it's not a \`status\` artifact), so \`proposal\` is the first artifact to build.
+
+3. **Produce each ready artifact in dependency order** (\`proposal\` -> \`specs\`/\`design\` -> \`tasks\`)
+
+   For each artifact whose status is \`ready\`:
+   \`\`\`bash
+   tospec instructions <artifact-id> --change "<name>" --json
+   \`\`\`
+   Read \`template\` and \`instruction\` from the response, write \`resolvedOutputPath\`, then re-run \`status --json\` and continue until every \`applyRequires\` artifact is \`done\`.
+
+   Artifact-specific rules on top of what \`instructions\` returns:
+   - **ticket** (already created): keep it thin — just refine the one-line \`## Summary\` so it names what this change does. All the detail (why, what, scope, decisions) lives in \`proposal.md\`, not here. Don't duplicate proposal content into the ticket, and don't add a timestamp or filename yourself.
+   - **proposal**: the main document — Why (motivation, why now), What Changes (concrete add/modify/remove), Capabilities (New/Modified, each pointing at its \`specs/<name>/spec.md\`), Impact (affected code/API/deps/systems). **Never include file paths or code snippets** in the prose — they go stale fast. Exception: a snippet from an actual prototype that encodes a decision more precisely than prose (a state machine, a schema shape) — inline it, trimmed to the decision, and note it came from a prototype.
+   - **design**: pick the testing seam before writing anything else — prefer an existing seam over a new one, the highest layer that still catches the behavior, and as few seams as possible (ideally one). State the seam explicitly in "Testing Seams" so \`tospec-apply\` knows exactly where to test.
+   - **tasks**: cut the work into **tracer-bullet vertical slices** — each slice cuts a complete path through every layer touched (not "all the schema changes, then all the UI"), is independently demoable, and fits a single implementation pass. Every slice's implementation step is preceded by its own "write the failing test" step (red before green). A **wide mechanical refactor** (rename a shared symbol, retype a column) is the one exception to vertical slicing — sequence it as expand -> migrate-in-batches -> contract instead of forcing it into a tracer bullet.
+
+4. **Validate and auto-fix**
+   \`\`\`bash
+   tospec validate "<name>" --json
+   \`\`\`
+   If invalid, fix the artifact(s) the report points at and re-run until it passes.
+
+**Output**
+
+Summarize the change name and location, the artifacts created, and prompt: "Run \`tospec-apply\` to start implementing."
+
+**Guardrails**
+- Create every artifact \`apply.requires\` needs — don't stop at \`proposal\`
+- The ticket file and its timestamp are CLI-generated — never create, rename, or move ticket files; only edit the Summary in the existing stub
+- Detailed why/what goes in \`proposal.md\`; the ticket stays a thin index
+- Read dependency artifacts before writing the next one
+- \`context\`/\`rules\` from \`instructions\` are constraints for you, never content to copy into the file
+- If a change with that name already exists, ask whether to continue it or pick a new name
+- If context is critically unclear even after checking the conversation, ask — but prefer a reasonable default to keep momentum`;
+export function getTospecProposeSkillTemplate() {
+    return {
+        name: 'tospec-propose',
+        description: 'Synthesize an already-discussed requirement into a complete sdd change (ticket stub, proposal, specs, design, tasks). Use when the user wants a proposal written up from context you already have, not a fresh interview — if the idea is still fuzzy, use tospec-explore first.',
+        instructions: `Turn a converged requirement into a complete sdd change: proposal, delta specs, design, and tracer-bullet tasks (the ticket stub is auto-generated) — ready for \`tospec-apply\`.
+
+**Input**: The user's request should include a change name (kebab-case) OR enough of a description to derive one, plus whatever requirement context already exists in the conversation.
+
+${PROPOSE_BODY}`,
+        license: 'MIT',
+        compatibility: 'Requires tospec CLI.',
+        metadata: { author: 'tospec', version: '1.0' },
+        allowedTools: ['Bash(tospec:*)', 'Read', 'Write', 'Edit', 'Grep', 'Glob', 'AskUserQuestion'],
+    };
+}
+export function getTospecProposeCommandTemplate() {
+    return {
+        name: 'TOSPEC: Propose',
+        description: 'Synthesize an already-discussed requirement into a complete sdd change',
+        category: 'Workflow',
+        tags: ['workflow', 'sdd', 'artifacts'],
+        content: `Turn a converged requirement into a complete sdd change: proposal, delta specs, design, and tracer-bullet tasks (the ticket stub is auto-generated) — ready for \`tospec-apply\`.
+
+**Input**: The argument after \`tospec-propose\` is the change name (kebab-case), or a description to derive one from. Relies on requirement context already in the conversation — if that's missing, run \`tospec-explore\` first.
+
+${PROPOSE_BODY}`,
+    };
+}
+//# sourceMappingURL=propose.js.map

package/dist/core/templates/workflows/propose.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"propose.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/propose.ts"],"names":[],"mappings":"AAQA,MAAM,YAAY,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gIA+C2G,CAAC;AAEjI,MAAM,UAAU,6BAA6B;IAC3C,OAAO;QACL,IAAI,EAAE,gBAAgB;QACtB,WAAW,EAAE,kRAAkR;QAC/R,YAAY,EAAE;;;;EAIhB,YAAY,EAAE;QACZ,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,iBAAiB,CAAC;KAC7F,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,+BAA+B;IAC7C,OAAO;QACL,IAAI,EAAE,iBAAiB;QACvB,WAAW,EAAE,wEAAwE;QACrF,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,KAAK,EAAE,WAAW,CAAC;QACtC,OAAO,EAAE;;;;EAIX,YAAY,EAAE;KACb,CAAC;AACJ,CAAC"}

package/dist/core/templates/workflows/sync.d.ts

@@ -0,0 +1,14 @@
+/**
+ * Skill Template Workflow Modules
+ *
+ * This file is generated by splitting the legacy monolithic
+ * templates file into workflow-focused modules.
+ *
+ * sync is a standalone skill again. The archive workflow proactively decides
+ * whether a sync is warranted and asks the user before archiving; when the
+ * user agrees, this is the procedure that runs.
+ */
+import type { SkillTemplate, CommandTemplate } from '../types.js';
+export declare function getTospecSyncSkillTemplate(): SkillTemplate;
+export declare function getTospecSyncCommandTemplate(): CommandTemplate;
+//# sourceMappingURL=sync.d.ts.map

package/dist/core/templates/workflows/sync.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"sync.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/sync.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AA4DlE,wBAAgB,0BAA0B,IAAI,aAAa,CAc1D;AAED,wBAAgB,4BAA4B,IAAI,eAAe,CAY9D"}

package/dist/core/templates/workflows/sync.js

@@ -0,0 +1,86 @@
+const SYNC_BODY = `Whether a spec still matches the source code is a semantic judgment no CLI can make — that's why this is agent work, not a \`tospec\` subcommand. The CLI's job is the part that IS machine-checkable: the synced spec must still pass full validation, and \`tospec archive --require-sync\` refuses unless \`sync-report.md\` reports PASS.
+
+**Steps**
+
+1. **List the Requirements this change touches**
+
+   For sdd: every Requirement in \`specs/<capability>/spec.md\` under the change directory. For issue: the Requirement(s) referenced in the ticket/\`task.md\`, plus any delta specs the change produced.
+
+   **No-delta case**: an issue fix with no behavior change has no delta specs at all. Don't invent Requirements to check — instead confirm \`task.md\`'s described fix matches what the code actually does, and note this as the no-delta case in the report (see format below).
+
+2. **Compare each Requirement against the actual implementation**
+
+   For each Requirement, locate the corresponding code (the files apply touched are a good starting point) and judge: does the implemented behavior match what the Requirement's scenarios describe?
+
+   **Can't find any corresponding implementation at all**: that's a CODE-BUG, same severity as a behavioral mismatch — the Requirement was agreed to and never built. Don't wave it through as MATCH.
+
+3. **Resolve every mismatch — code wins**
+
+   - If the spec is stale relative to the code (the code is correct, the spec described the old behavior): update the delta spec's Requirement with **MODIFIED**, pasting the complete, corrected Requirement block. Then:
+     \`\`\`bash
+     tospec validate "<name>" --json
+     \`\`\`
+     Must pass before moving to the next Requirement — record the validate result in that Requirement's report entry.
+   - If the code itself is wrong (it doesn't do what was actually agreed in ticket/design, or is missing entirely): **stop**. Do not touch the spec to paper over a bug. Report the mismatch to the user and suggest returning to \`tospec-apply\` to fix the code before archiving.
+
+4. **Write the sync report**
+
+   Create \`sync-report.md\` in the change directory in exactly this format — \`tospec archive --require-sync\` parses the first \`結論:\` line, so the heading and label text must match:
+
+   \`\`\`markdown
+   # Sync Report: <change-name>
+   ## Summary
+   結論: <PASS 或 FAIL>
+   ## Requirements
+   ### <Requirement 名稱>
+   - 對應實作: <模組/函式描述, 非硬路徑>
+   - 判定: MATCH | SPEC-UPDATED (以 code 為準已更新) | CODE-BUG (停止歸檔)
+   - 說明: <差異與處置; SPEC-UPDATED 需附上 validate 結果>
+   \`\`\`
+
+   Fill the \`結論:\` line with exactly one literal — \`結論: PASS\` or \`結論: FAIL\` (FAIL may append a \`(原因)\` note); never leave both options in one line, or \`tospec archive --require-sync\` can't parse it. \`結論:\` is **FAIL** if even one Requirement is CODE-BUG — a single unresolved defect blocks the whole change, not just that Requirement. It's **PASS** only when every Requirement resolved to MATCH or SPEC-UPDATED (with validate passing). For the no-delta case, still emit the Summary and a single Requirements entry describing the task.md-vs-code comparison (module described, not a Requirement name).
+
+5. **Final artifact validation**
+   \`\`\`bash
+   tospec validate "<name>" --json
+   \`\`\`
+   Even when no spec needed updating, run the full change validation before finishing. If it reports an artifact problem, fix the affected artifact and re-run until it passes. Do not write \`結論: PASS\` while validation is failing.
+
+**Output**
+
+Summarize how many Requirements were in sync, how many specs were updated, and whether anything was flagged as a code defect. If \`結論: PASS\`, prompt: "Run \`tospec-archive\` to finish up — it passes \`--require-sync\` for free now that \`sync-report.md\` reports PASS." If \`結論: FAIL\`, prompt to return to \`tospec-apply\` first — do not proceed to archive.
+
+**Guardrails**
+- Code is the source of truth for behavior — spec updates always follow code, never the other way around
+- Never edit source code from this workflow — a code-side mismatch is diagnosis, not a license to patch here
+- Every MODIFIED delta must re-pass \`tospec validate\` before moving to the next Requirement
+- \`sync-report.md\` is required output, in the exact format above — \`tospec archive --require-sync\` depends on both its existence and its \`結論:\` line`;
+export function getTospecSyncSkillTemplate() {
+    return {
+        name: 'tospec-sync',
+        description: 'Compare each Requirement a change touched against the actual implementation and reconcile drift, with the source code as the source of truth, producing sync-report.md. Use before archiving a change with spec deltas — the tospec-archive workflow will offer to run this when it judges a sync is warranted.',
+        instructions: `Reconcile \`specs/\` against the implementation for every Requirement this change touched — code wins on any mismatch. Run this before \`tospec-archive\` when the change's specs may have drifted from the code.
+
+**Input**: The user's request should name the change to sync.
+
+${SYNC_BODY}`,
+        license: 'MIT',
+        compatibility: 'Requires tospec CLI.',
+        metadata: { author: 'tospec', version: '1.0' },
+        allowedTools: ['Bash(tospec:*)', 'Read', 'Write', 'Edit', 'Grep', 'Glob'],
+    };
+}
+export function getTospecSyncCommandTemplate() {
+    return {
+        name: 'TOSPEC: Sync',
+        description: 'Reconcile specs against the implementation, code as source of truth',
+        category: 'Workflow',
+        tags: ['workflow', 'sync', 'archive-gate'],
+        content: `Reconcile \`specs/\` against the implementation for every Requirement this change touched — code wins on any mismatch. Run this before \`tospec-archive\` when the change's specs may have drifted from the code.
+
+**Input**: The argument after \`tospec-sync\` is the change name to sync.
+
+${SYNC_BODY}`,
+    };
+}
+//# sourceMappingURL=sync.js.map

package/dist/core/templates/workflows/sync.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"sync.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/sync.ts"],"names":[],"mappings":"AAYA,MAAM,SAAS,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;0JAwDwI,CAAC;AAE3J,MAAM,UAAU,0BAA0B;IACxC,OAAO;QACL,IAAI,EAAE,aAAa;QACnB,WAAW,EAAE,iTAAiT;QAC9T,YAAY,EAAE;;;;EAIhB,SAAS,EAAE;QACT,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,KAAK,EAAE;QAC9C,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,CAAC;KAC1E,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,4BAA4B;IAC1C,OAAO;QACL,IAAI,EAAE,cAAc;QACpB,WAAW,EAAE,qEAAqE;QAClF,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,MAAM,EAAE,cAAc,CAAC;QAC1C,OAAO,EAAE;;;;EAIX,SAAS,EAAE;KACV,CAAC;AACJ,CAAC"}

package/dist/core/templates/workflows/update.d.ts

@@ -0,0 +1,10 @@
+/**
+ * Skill Template Workflow Modules
+ *
+ * This file is generated by splitting the legacy monolithic
+ * templates file into workflow-focused modules.
+ */
+import type { SkillTemplate, CommandTemplate } from '../types.js';
+export declare function getTospecUpdateSkillTemplate(): SkillTemplate;
+export declare function getTospecUpdateCommandTemplate(): CommandTemplate;
+//# sourceMappingURL=update.d.ts.map

package/dist/core/templates/workflows/update.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"update.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/update.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AAyElE,wBAAgB,4BAA4B,IAAI,aAAa,CAc5D;AAED,wBAAgB,8BAA8B,IAAI,eAAe,CAYhE"}