showdar-skills 0.9.0 → 0.11.0

package/CHANGELOG.md

@@ -6,6 +6,41 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## [Unreleased]
 
+## [0.11.0]
+
+### Added
+
+- Add three independently installable insurance skills for insurer domain terminology, cross-line-of-business workflows, and terminology/API review, with Vietnamese–English–technical mappings and insurer/product-specific scoping.
+- Add an insurance profile and route insurance-domain requests to the relevant skills without limiting the system to motor insurance or HDInsurance.
+
+## [0.10.0]
+
+### Added
+
+- `showdar update-pack <path> --dry-run` read-only snapshot preview using the same canonical planning logic as execution; explicit public projection with deterministic ordering, descriptive change categories (`source-only`, `skill-content`, `workflow-definition`, `profile-definition`, `metadata`, `reference`, `ownership`, `installed-drift`), and `executable` status.
+- Canonical internal pack update planning (`src/pack-plan.js`): `planPackUpdate()`, `verifyPlanPreconditions()`, `executePackUpdate()` with same-lifecycle TOCTOU fingerprint protection (source, installed owned files, relevant manifest state, overrides bytes). Stale plans abort with zero mutation.
+- `showdar inspect-pack <path> --checkpoint <file>` checkpoint compatibility explanation against the candidate effective catalog (current project + candidate pack + project overrides). Deterministic semantic reason codes (`workflow-missing`, `workflow-state-compat-unsupported`, `stage-removed`, `selected-stage-invalid`, `required-stage-conflict`, `skip-policy-invalid`, `recorded-skip-invalid`) with fixed precedence; malformed checkpoints report `schema-invalid` / `malformed-checkpoint`.
+- `showdar list --extensions --json` and `showdar doctor --extensions --json` using the common CLI envelope (`schemaVersion: 1`). Doctor reports `checkpointCompatibility: "not-assessed"` without a checkpoint. Diagnostics exit 0 on successful report.
+
+### Changed
+
+- `src/pack-update.js` refactored around canonical planning; v0.9 staged replacement and rollback safety preserved.
+- `list --extensions` human output now shows pack health status and pack profiles.
+- `create-pack` skill scaffold cleaned up (full required sections, substantive guidance, no filler) with validation guidance output.
+- TOCTOU lifecycle clarified: `--dry-run` is a read-only snapshot, not an authorization token. A later `update-pack` re-plans from current state. Stale-plan protection applies within a single execution lifecycle (`planPackUpdate` → `verifyPlanPreconditions` → `executePackUpdate`).
+
+### Fixed
+
+- `inspectCustomWorkflows` read `validateCustomWorkflowDoc` as `{ok, errors}` but the validator returns an error array, so `valid` was always `undefined` and doctor reported every workflow invalid. Now maps `errors.length === 0` to `valid`. Internal helper shape only; public CLI output unchanged.
+- `executePackUpdate` referenced undefined `manifestPath`; now resolves the project manifest path before writing. Covered by real update-path regression test.
+
+### Compatibility / Safety
+
+- v0.9 `validate-pack --json` (`{ok, errors}`) and plain `inspect-pack --json` shapes unchanged; backward-compat fixture tests added.
+- No persisted preview plans or tokens. No manifest v3, no workflow-state schema change, no WorkflowState key change.
+- Phase 6G authority, 15 primitives, 4 workflows, 6 profiles, 10 trace events frozen.
+- Dry-run is a snapshot, not a stored plan. No migration required. No tarball, remote registry, or executable plugins.
+
 ## [0.9.0]
 
 ### Added

package/README.md

@@ -3,7 +3,7 @@
 [![npm version](https://img.shields.io/npm/v/showdar-skills?logo=npm)](https://www.npmjs.com/package/showdar-skills)
 [![Node >=20](https://img.shields.io/badge/node-%3E%3D20-339933?logo=node.js&logoColor=white)](https://nodejs.org/)
 [![MIT License](https://img.shields.io/badge/license-MIT-blue?logo=opensourceinitiative&logoColor=white)](./LICENSE)
-[![19 skills](https://img.shields.io/badge/skills-19-6f42c1)](#skill-catalog)
+[![22 skills](https://img.shields.io/badge/skills-22-6f42c1)](#skill-catalog)
 
 Production-grade software engineering skills for coding agents. Showdar covers
 the full lifecycle—from requirements and planning through implementation, QA,
@@ -42,7 +42,7 @@ you want all capabilities available.
 
 ## Why Showdar?
 
-- **15 focused primitive skills** plus 4 adaptive workflow skills (19 installable) instead of one oversized agent prompt.
+- **18 focused primitive skills** plus 4 adaptive workflow skills (22 installable), including an opt-in insurance domain profile.
 - **Lifecycle coverage** from product rules to implementation, verification,
   security, operations, release readiness, and Git completion.
 - **Intent-based discovery** that selects the workflow matching the request.
@@ -72,7 +72,7 @@ SKILL.md
           only when needed
 ```
 
-The 15 primitive skills are not eagerly loaded as full prompts. Lightweight
+The 18 primitive skills are not eagerly loaded as full prompts. Lightweight
 descriptions help the agent choose one skill; that skill then loads its
 workflow and deeper knowledge progressively. Workflow skills add a portable
 orchestration layer: a workflow selects the lifecycle stages a task actually
@@ -95,7 +95,7 @@ agent/subagent, or MCP behavior across harnesses.
 
 ## Adapter model
 
-The portable core (15 primitives + 4 workflows) never changes per harness.
+The portable core (18 primitives + 4 workflows) never changes per harness.
 A thin native adapter layer renders harness-specific entry surfaces only:
 
 ```text
@@ -135,8 +135,8 @@ the same canonical semantic body as the `AGENTS.md`/`CLAUDE.md` blocks.
 `/showdar/skill` is generated for OpenCode/Claude as generic
 installed-skill discovery. Commands are generated dynamically from the
 installed skill set: `minimal` yields 8 direct commands plus the generic
-entry; adding `feature` yields 9 plus generic. All 19 commands never exist
-unless all 19 skills are installed.
+entry; adding `feature` yields 9 plus generic. All 22 commands never exist
+unless all 22 skills are installed.
 
 ## Native install examples
 
@@ -226,7 +226,8 @@ skill, but still does not eagerly load every skill body.
 | `backend` | 14 | APIs, services, and runtime operations |
 | `qa` | 9 | Testing and quality workflows |
 | `product` | 6 | Product, requirements, and design work |
-| `full` | 15 | All primitive capabilities |
+| `insurance` | 3 | Insurance terminology, business flows, and UI/API review |
+| `full` | 18 | All primitive capabilities |
 
 Legacy aliases remain compatible:
 
@@ -239,7 +240,7 @@ New manifests store the canonical `developer` profile.
 
 ## Skill catalog
 
-All 15 primitive entries are first-class Showdar skills. Four workflow skills
+All 18 primitive entries are first-class Showdar skills. Four workflow skills
 compose them; see [Workflow skills](#workflow-skills).
 
 ### Analysis and planning
@@ -274,6 +275,14 @@ compose them; see [Workflow skills](#workflow-skills).
 | `showdar-security` | Assessing threat models, attack surfaces, trust boundaries, auth/authz, secrets, exposure, or exploitability. |
 | `showdar-ops` | Inspecting or changing CI/CD, containers, environments, deployment, observability, rollback, or runtime operations. |
 
+### Insurance
+
+| Skill | Use when |
+| --- | --- |
+| `showdar-insurance-domain` | Vietnamese insurer terminology, product taxonomy, coverage concepts, and VI/EN glossary. |
+| `showdar-insurance-workflows` | Product configuration, underwriting, pricing, policy lifecycle, collection, or claims flows. |
+| `showdar-insurance-review` | Reviewing insurer UI, domain/API mappings, validations, and QA scenarios. |
+
 ### Delivery and recovery
 
 | Skill | Use when |
@@ -547,11 +556,27 @@ showdar add feature
 showdar add bugfix --ai cursor
 showdar add release --scope global --ai claude
 showdar add incident
+showdar add insurance-domain
+showdar add insurance-workflows
+showdar add insurance-review
+showdar init --profile insurance
 ```
 
-Accepted names are the short form (`debug`, `feature`) or the canonical form
-(`showdar-debug`, `showdar-feature`). The release ships exactly 15 primitive
-skills plus 4 workflow skills (19 installable total); profiles install
+After a Showdar Skills release containing these entries is published, upgrade the CLI
+and add one insurance skill at a time from the insurer project:
+
+```bash
+npm install -g showdar-skills@latest
+showdar add insurance-domain --ai codex
+```
+
+Use `showdar add insurance-workflows --ai codex` and
+`showdar add insurance-review --ai codex` when those are needed. For a new project
+that wants all three, `showdar init --profile insurance --ai codex` installs the set.
+
+Accepted names are the short form (`debug`, `feature`, `insurance-domain`)
+or the canonical form (`showdar-debug`, `showdar-feature`). The release ships exactly 18 primitive
+skills plus 4 workflow skills (22 installable total); profiles install
 primitive sets only. There is no `showdar workflow ...` command. `showdar add`
 is idempotent, preserves the configured profile, supports `--ai`/`--scope`
 overrides, and refuses to overwrite a foreign same-name skill directory that
@@ -570,23 +595,47 @@ executable hooks, lifecycle scripts, or remote code.
 ```bash
 showdar create-pack <path> [--vendor <v>] [--description <text>] [--with-workflow <id>] [--with-profile <name>]
 showdar validate-pack <local-path> [--json]
-showdar inspect-pack <local-path> [--json]
+showdar inspect-pack <local-path> [--json] [--checkpoint <file>]
 ```
 
 **Install & lifecycle**
 
 ```bash
 showdar add-pack <local-path>
-showdar list --extensions
+showdar list --extensions [--json]
 showdar remove-pack <name>
-showdar update-pack <local-path>
+showdar update-pack <local-path> [--dry-run] [--json]
 ```
 
 **Diagnostics**
 
 ```bash
-showdar doctor --extensions
-```
+showdar doctor --extensions [--json]
+```
+
+`update-pack --dry-run` previews changes without mutation: file add/replace/remove
+counts, descriptive change categories (`source-only`, `skill-content`,
+`workflow-definition`, `profile-definition`, `metadata`, `reference`,
+`ownership`, `installed-drift`), ownership conflicts, and whether the update is
+currently executable. Categories are descriptive only and never claim checkpoint
+compatibility. The preview is a read-only snapshot, not an authorization token:
+a later `update-pack` re-plans from current state. Within a single update
+execution, if source, installed files, manifest, or overrides change between
+planning and applying that same plan, execution aborts as a stale plan with
+zero mutation.
+
+`inspect-pack --checkpoint` validates a workflow checkpoint against the candidate
+effective catalog (current project state + candidate pack + project overrides) and
+reports `compatible`, `workflow-incompatible` (with deterministic reason code and
+`replanRequired`), or `malformed`. Malformed checkpoints report `schema-invalid` /
+`malformed-checkpoint`, never `workflow-incompatible`.
+
+`list --extensions --json` and `doctor --extensions --json` use the common CLI
+envelope (`schemaVersion: 1`, `command`, `ok`, `data`, `warnings`, `errors`).
+Existing `validate-pack --json` and plain `inspect-pack --json` shapes are
+unchanged. `doctor` without a checkpoint reports `checkpointCompatibility:
+"not-assessed"`. Diagnostics exit 0 when they successfully report state, even when
+unhealthy; validation and execution failures exit 1.
 
 **Pack metadata**
 
@@ -617,7 +666,7 @@ Project overrides live in the user-owned `.showdar/overrides.json` file:
 skill descriptions, discovery hints, advisory guidance text, custom
 workflow policy refinement, and new project-owned profiles. Showdar reads
 and validates the file but never rewrites or deletes it; built-in
-workflow semantics and the six built-in profiles cannot be overridden.
+workflow semantics and the seven built-in profiles cannot be overridden.
 Pack-local profiles select pack-owned skills and workflows only.
 
 Showdar computes a full-tree SHA-256 over the validated pack source at
@@ -722,7 +771,7 @@ showdar remove [--scope <project|global>]
 Main flags are `--ai`, `--profile`, and `--scope`. `--ai` accepts `universal`,
 `codex`, `opencode`, `cursor`, `claude`, or `all` for `init` (single targets
 for `add`). `--scope` accepts `project` or `global` and defaults to `project`;
-`--profile` accepts the six canonical profiles and the deprecated
+`--profile` accepts the seven canonical profiles and the deprecated
 `mobile`/`web` aliases. Run `showdar --help` or a command's `--help` for
 current options.
 

package/bin/showdar.js

@@ -4,7 +4,9 @@ import { homedir } from 'node:os';
 import { readFile } from 'node:fs/promises';
 import { fileURLToPath } from 'node:url';
 import { AI_TARGETS, PRIMITIVE_COUNT, PROFILE_ALIASES, PROFILES, SKILLS, TOTAL_COUNT, WORKFLOW_COUNT, canonicalProfile, isDeprecatedProfile, resolveProfile } from '../src/catalog.js';
-import { addPack, addSkill, addWorkflow, globalManifestPath, initGlobal, initProject, inspectGlobal, inspectProject, listExtensions, removeGlobal, removePack, removeProject, validatePackSource, createPack, inspectPack, doctor, updatePack, readProjectOverrides } from '../src/project.js';
+import { addPack, addSkill, addWorkflow, globalManifestPath, initGlobal, initProject, inspectGlobal, inspectProject, listExtensions, listExtensionsDetailed, removeGlobal, removePack, removeProject, validatePackSource, createPack, inspectPack, doctor, updatePack, readProjectOverrides } from '../src/project.js';
+import { formatPlanPreviewHuman, projectPackUpdatePreview } from '../src/pack-plan.js';
+import { assessCheckpointAgainstCandidate } from '../src/pack-inspect.js';
 import { validateRepository } from '../src/validate.js';
 
 const packageRoot = path.resolve(path.dirname(fileURLToPath(import.meta.url)), '..');
@@ -43,7 +45,7 @@ function printHelp(version, command = null) {
     console.log(`Showdar Skills ${version}\n\nUsage:\n  showdar add <skill> [--ai <universal|codex|opencode|cursor|claude>] [--scope <project|global>]\n\nExamples:\n  showdar add debug\n  showdar add showdar-security\n  showdar add test --ai cursor\n  showdar add review --scope global --ai claude\n\nDefault scope: project. Default AI target: universal, or the configured .showdar.json value when present.`);
     return;
   }
-  console.log(`Showdar Skills ${version}\n\nUsage:\n  showdar init ${scopeUsage} [--profile <name>] [--ai <universal|codex|opencode|cursor|claude|all>] [--pack <local-path>]\n  showdar add <skill> [--ai <universal|codex|opencode|cursor|claude>] [--scope <project|global>]\n  showdar add-pack <local-path>\n  showdar remove-pack <name>\n  showdar add-workflow <local-path>\n  showdar status ${scopeUsage}\n  showdar doctor ${scopeUsage}\n  showdar validate\n  showdar list [--extensions]\n  showdar remove ${scopeUsage}\n  showdar create-pack <path> [--vendor <vendor>] [--description <text>] [--with-workflow <id>] [--with-profile <name>]\n  showdar validate-pack <local-path> [--json]\n  showdar inspect-pack <local-path> [--json]\n  showdar doctor ${scopeUsage}\n  showdar update-pack <local-path>\n  showdar validate\n  showdar list [--extensions]\n  showdar remove ${scopeUsage}\n\nExtension packs accept local directories/workspace paths only; tarball, URL, Git, and registry sources are rejected.\n\nDefaults: scope project, profile full, AI target universal.\nProfiles: ${Object.keys(PROFILES).join(', ')}\nDeprecated aliases: ${Object.entries(PROFILE_ALIASES).map(([alias, target]) => `${alias} -> ${target}`).join(', ')}\nAI targets: ${AI_TARGETS.join(', ')}`);
+  console.log(`Showdar Skills ${version}\n\nUsage:\n  showdar init ${scopeUsage} [--profile <name>] [--ai <universal|codex|opencode|cursor|claude|all>] [--pack <local-path>]\n  showdar add <skill> [--ai <universal|codex|opencode|cursor|claude>] [--scope <project|global>]\n  showdar add-pack <local-path>\n  showdar remove-pack <name>\n  showdar add-workflow <local-path>\n  showdar status ${scopeUsage}\n  showdar doctor ${scopeUsage}\n  showdar validate\n  showdar list [--extensions]\n  showdar remove ${scopeUsage}\n  showdar create-pack <path> [--vendor <vendor>] [--description <text>] [--with-workflow <id>] [--with-profile <name>]\n  showdar validate-pack <local-path> [--json]\n  showdar inspect-pack <local-path> [--json] [--checkpoint <file>]\n  showdar doctor ${scopeUsage} [--extensions] [--json]\n  showdar update-pack <local-path> [--dry-run] [--json]\n  showdar validate\n  showdar list [--extensions] [--json]\n  showdar remove ${scopeUsage}\n\nExtension packs accept local directories/workspace paths only; tarball, URL, Git, and registry sources are rejected.\n\nDefaults: scope project, profile full, AI target universal.\nProfiles: ${Object.keys(PROFILES).join(', ')}\nDeprecated aliases: ${Object.entries(PROFILE_ALIASES).map(([alias, target]) => `${alias} -> ${target}`).join(', ')}\nAI targets: ${AI_TARGETS.join(', ')}`);
 }
 
 async function main() {
@@ -63,11 +65,20 @@ async function main() {
 
   if (command === 'list') {
     if (args.includes('--extensions')) {
-      const result = await listExtensions({ cwd: projectRoot });
+      const isJson = args.includes('--json');
+      const result = await listExtensionsDetailed({ cwd: projectRoot });
+      if (isJson) {
+        console.log(JSON.stringify({ schemaVersion: 1, command: 'list', ok: true, data: result, warnings: [], errors: [] }, null, 2));
+        return;
+      }
       console.log('Packs:');
-      for (const pack of result.packs) console.log(`  ${pack.name}@${pack.version}  ${pack.hash}`);
+      for (const pack of result.packs) console.log(`  ${pack.name}@${pack.version}  ${pack.status ?? 'healthy'}  ${pack.hash}`);
       console.log('Custom workflows:');
       for (const workflow of result.customWorkflows) console.log(`  ${workflow.id}  [${workflow.source}]  ${workflow.path}`);
+      if (result.profiles?.length) {
+        console.log('Pack profiles:');
+        for (const profile of result.profiles) console.log(`  ${profile.name}  [${profile.source}]  members: ${(profile.members ?? []).join(', ')}`);
+      }
       console.log(`Project overrides: ${result.overrides.present ? result.overrides.status : 'absent'}`);
       return;
     }
@@ -140,6 +151,31 @@ async function main() {
   }
 
   if (command === 'status' || command === 'doctor') {
+    if (command === 'doctor' && args.includes('--extensions')) {
+      const isJson = args.includes('--json');
+      const result = await doctor({ cwd: projectRoot });
+      if (isJson) {
+        console.log(JSON.stringify({
+          schemaVersion: 1,
+          command: 'doctor',
+          ok: true,
+          data: { ...result, checkpointCompatibility: 'not-assessed' },
+          warnings: result.warnings ?? [],
+          errors: [],
+        }, null, 2));
+        return;
+      }
+      console.log(`Extension diagnostics\nHealth: ${result.healthy ? 'OK' : 'BROKEN'}`);
+      for (const pack of result.packs) console.log(`  ${pack.name}@${pack.version}  ${pack.drift}`);
+      for (const wf of result.customWorkflows) console.log(`  workflow ${wf.id}: ${wf.valid ? 'valid' : 'invalid'}`);
+      for (const issue of result.issues) console.log(`- ${issue}`);
+      for (const warning of result.warnings ?? []) console.log(`warning: ${warning}`);
+      if (!result.healthy) {
+        console.log(`Checkpoint compatibility: not-assessed (supply a checkpoint via inspect-pack --checkpoint)`);
+        if (result.customWorkflows.length) console.log(`Note: checkpoints referencing changed workflow definitions will be revalidated on resume.`);
+      }
+      return;
+    }
     const result = scope === 'global' ? await inspectGlobal() : await inspectProject(projectRoot);
     if (!result.installed) {
       console.log(`Showdar Skills is not installed in the ${scope} scope.`);
@@ -213,8 +249,31 @@ async function main() {
 
   if (command === 'inspect-pack') {
     const packPath = args[1];
-    if (!packPath) throw new Error('Pack path is required. Usage: showdar inspect-pack <local-path> [--json]');
+    if (!packPath) throw new Error('Pack path is required. Usage: showdar inspect-pack <local-path> [--json] [--checkpoint <file>]');
     const isJson = args.includes('--json');
+    const checkpointIdx = args.indexOf('--checkpoint');
+    const checkpointFile = checkpointIdx === -1 ? null : args[checkpointIdx + 1];
+    if (checkpointIdx !== -1 && (!checkpointFile || checkpointFile.startsWith('--'))) {
+      throw new Error('--checkpoint requires a file path');
+    }
+    if (checkpointFile) {
+      const { readFile } = await import('node:fs/promises');
+      const checkpoint = await readFile(path.resolve(projectRoot, checkpointFile), 'utf8');
+      const assessment = await assessCheckpointAgainstCandidate({ cwd: projectRoot, candidatePath: path.resolve(projectRoot, packPath), checkpoint });
+      if (isJson) {
+        console.log(JSON.stringify({ schemaVersion: 1, command: 'inspect-pack', ok: true, data: { checkpoint: assessment }, warnings: [], errors: [] }, null, 2));
+        return;
+      }
+      if (assessment.compatible) {
+        console.log(`Checkpoint compatibility: compatible\nReplan required: no`);
+        return;
+      }
+      console.log(`Checkpoint compatibility: ${assessment.category === 'schema-invalid' ? 'malformed' : 'workflow-incompatible'}\nReplan required: ${assessment.replanRequired ? 'yes' : 'no'}\nCategory: ${assessment.category}\nReason: ${assessment.reason}\nDetail: ${assessment.detail}`);
+      if (assessment.affectedWorkflow) console.log(`Affected workflow: ${assessment.affectedWorkflow}`);
+      if (assessment.affectedStage) console.log(`Affected stage: ${assessment.affectedStage}`);
+      console.log(`\nRun \`showdar update-pack <path> --dry-run\` to preview update.`);
+      return;
+    }
     const result = await inspectPack({ cwd: projectRoot, source: packPath });
     if (isJson) {
       console.log(JSON.stringify(result, null, 2));
@@ -246,9 +305,38 @@ async function main() {
 
   if (command === 'update-pack') {
     const packSource = args[1];
-    if (!packSource) throw new Error('Pack source is required. Usage: showdar update-pack <local-path>');
-    const result = await updatePack({ cwd: projectRoot, source: packSource });
-    console.log(`Showdar pack ${result.status}.\nPack: ${result.pack}\nVersion: ${result.version}${result.oldHash ? `\nOld hash: ${result.oldHash}\nNew hash: ${result.newHash}` : ''}\nFiles: ${result.files}`);
+    if (!packSource) throw new Error('Pack source is required. Usage: showdar update-pack <local-path> [--dry-run] [--json]');
+    const dryRun = args.includes('--dry-run');
+    const isJson = args.includes('--json');
+    if (dryRun) {
+      const { planPackUpdate } = await import('../src/pack-plan.js');
+      const plan = await planPackUpdate({ cwd: projectRoot, source: packSource });
+      if (isJson) {
+        console.log(JSON.stringify(projectPackUpdatePreview(plan), null, 2));
+        if (!plan.ok || !plan.executable) process.exitCode = 1;
+        return;
+      }
+      console.log(formatPlanPreviewHuman(plan));
+      if (!plan.ok || !plan.executable) process.exitCode = 1;
+      return;
+    }
+    if (isJson) {
+      try {
+        const result = await updatePack({ cwd: projectRoot, source: packSource });
+        console.log(JSON.stringify({ schemaVersion: 1, command: 'update-pack', ok: true, data: result, warnings: result.plan?.warnings ?? [], errors: [] }, null, 2));
+      } catch (error) {
+        console.log(JSON.stringify({ schemaVersion: 1, command: 'update-pack', ok: false, data: null, warnings: [], errors: [{ category: 'drift-detected', code: 'DRIFT_DETECTED', message: error.message }] }, null, 2));
+        process.exitCode = 1;
+      }
+      return;
+    }
+    try {
+      const result = await updatePack({ cwd: projectRoot, source: packSource });
+      console.log(`Showdar pack ${result.status}.\nPack: ${result.pack}\nVersion: ${result.version}${result.oldHash ? `\nOld hash: ${result.oldHash}\nNew hash: ${result.newHash}` : ''}\nFiles: ${result.files}`);
+    } catch (error) {
+      console.error(`showdar: ${error.message}`);
+      process.exitCode = 1;
+    }
     return;
   }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "showdar-skills",
-  "version": "0.9.0",
+  "version": "0.11.0",
   "description": "Production-grade software engineering lifecycle skills for coding agents.",
   "type": "module",
   "bin": { "showdar": "./bin/showdar.js" },

package/profiles/full.json

@@ -1 +1 @@
-{"skills":["showdar-understand","showdar-plan","showdar-design","showdar-build","showdar-debug","showdar-test","showdar-review","showdar-upgrade","showdar-ship","showdar-recover","showdar-git","showdar-requirements","showdar-quality","showdar-security","showdar-ops"]}
+{"skills":["showdar-understand","showdar-plan","showdar-design","showdar-build","showdar-debug","showdar-test","showdar-review","showdar-upgrade","showdar-ship","showdar-recover","showdar-git","showdar-requirements","showdar-quality","showdar-security","showdar-ops","showdar-insurance-domain","showdar-insurance-workflows","showdar-insurance-review"]}

package/profiles/insurance.json

@@ -0,0 +1 @@
+{"skills":["showdar-insurance-domain","showdar-insurance-workflows","showdar-insurance-review"]}

package/router/conflicts.yaml

@@ -48,3 +48,11 @@ overlap_matrix:
     boundary: quality plans scenario coverage and confidence; ship decides whether release or handoff evidence is sufficient
   - pair: showdar-upgrade vs showdar-build
     boundary: upgrade changes dependency or platform compatibility; build changes application behavior within the supported stack
+  - pair: showdar-insurance-domain vs showdar-insurance-workflows
+    boundary: insurance-domain resolves terminology and concept mappings; insurance-workflows analyzes scoped business transitions and rules
+  - pair: showdar-insurance-workflows vs showdar-insurance-review
+    boundary: insurance-workflows derives sourced flows and rules; insurance-review checks concrete UI, model, API, and QA mappings against that evidence
+  - pair: showdar-insurance-workflows vs showdar-requirements
+    boundary: insurance-workflows applies insurance concepts to a scoped flow; showdar-requirements owns cross-domain requirement readiness and unresolved stakeholder decisions
+  - pair: showdar-insurance-review vs showdar-review
+    boundary: insurance-review checks business terminology and data mappings; showdar-review checks implementation correctness and maintainability

package/router/skill-map.yaml

@@ -52,3 +52,12 @@ routes:
   ops:
     triggers: ["CI/CD", "GitHub Actions", "Docker", "container", "deployment", "deploy", "observability", "rollback", "runtime operations", "staging"]
     skill: showdar-ops
+  insurance-domain:
+    triggers: ["insurance terminology", "insurance glossary", "bảo hiểm", "thuật ngữ bảo hiểm", "taxonomy bảo hiểm", "line of business", "coverage term", "sum insured meaning"]
+    skill: showdar-insurance-domain
+  insurance-workflows:
+    triggers: ["insurance business flow", "underwriting", "insurance pricing", "premium rating", "policy issuance", "insurance claim flow", "endorsement flow", "renewal flow", "bồi thường", "thẩm định bảo hiểm", "flow thu phí"]
+    skill: showdar-insurance-workflows
+  insurance-review:
+    triggers: ["insurer API mapping", "insurance UI terminology", "review insurance schema", "insurance QA scenarios", "sub-limit mapping", "coverage validation", "mapping UI API bảo hiểm"]
+    skill: showdar-insurance-review

package/router/triggers.yaml

@@ -25,6 +25,10 @@ rules:
   - local Git commit, staging, branch, merge, rebase, conflict, cleanup, and explicit push intent routes to showdar-git
   - explicit rebase, cherry-pick, merge, or Git conflict operations route to showdar-git; interrupted implementation recovery routes to showdar-recover
   - product or business input, missing requirements, business rules, user stories, use cases, acceptance criteria, and requirement readiness route to showdar-requirements
+  - glossary, taxonomy, aliases, and VI/EN insurance concepts route to showdar-insurance-domain
+  - product configuration, underwriting, rating, quote, issuance, collection, endorsement, renewal, cancellation, and claims flows route to showdar-insurance-workflows
+  - concrete insurer UI/domain/API mapping, terminology review, and insurance QA cases route to showdar-insurance-review
+  - generic requirements and QA requests retain their existing routes unless insurance-specific evidence mapping is the task
   - QA scenarios, risk-based coverage, regression scope, compatibility matrices, exploratory checks, and bug-report quality route to showdar-quality
   - explicit security, authz, secrets, exposure, attack-surface, threat, or exploitability intent routes to showdar-security before general review
   - operational CI/CD, container, environment, deployment, observability, rollback, or runtime intent routes to showdar-ops; release readiness remains showdar-ship and Git-only work remains showdar-git

package/skills/showdar-insurance-domain/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: showdar-insurance-domain
+description: Use when Vietnamese insurer work involves insurance terminology, product taxonomy, coverage concepts, VI/EN glossary, or insurer/product-specific vocabulary.
+---
+
+
+# Insurance domain
+
+## Purpose
+
+Reason in insurance business language and preserve exact
+mappings to implementation identifiers. This is a multi-line
+insurer domain: motor, health, accident, travel, property,
+cargo, engineering, liability, personal insurance and other
+supported products. HDInsurance/HDI or motor examples never
+establish the whole system's scope. Do not assume modules
+already exist.
+
+## Sources and scope
+
+Read [source protocol](references/source-protocol.md) for every
+domain task. Read [glossary](references/glossary.md) for
+terminology and [concepts](references/concepts.md) for
+relationships/taxonomy. Load only relevant sections.
+
+For each term, keep five layers separate: industry meaning,
+insurer alias, product/version meaning, UI label, exact
+technical/API identifier. A likely translation is a candidate,
+not an approved insurer term. `planCode` alone does not
+establish whether its meaning is a gói, chương trình, phương án
+or technical grouping.
+
+Keep VI accents; prefer language used by insurer operations.
+Preserve an insurer's approved wording within its scope and
+record aliases instead of overwriting a shared term. Do not
+translate JSON keys, enums or identifiers. Avoid literal
+translations such as policy → “chính sách” or premium → “cao
+cấp”. Do not equate application, quote, contract and
+certificate.
+
+## Workflow
+
+1. Identify the requested module and known market, insurer, product, product version and API version. Unknown scope stays explicit; ask only for missing context that changes the answer.
+2. Extract exact terms and source locations from supplied glossary, wording, BA/spec, SOP, API/schema, screenshots and sample data.
+3. Match by meaning, not spelling. Explain distinctions and relationships before suggesting labels or mappings. Label observed code behavior separately from business requirements.
+4. Record conflicts and ask for verification of the affected interpretation. Continue independent analysis; do not choose the newer document, more convenient term or API name as business authority.
+
+## Term resolution
+
+- Use the legal Vietnamese term for statutory roles and concepts when the applicable
+legal source defines it. Label its EN rendering as a working
+translation unless a bilingual authority confirms the English
+term.
+- Use wording, schedule and endorsements to interpret product coverage and exclusions.
+Keep the exact product/version and effective scope with each
+term.
+- Use the insurer glossary and SOP for approved operator vocabulary. Preserve a
+differing local alias alongside the normalized domain concept.
+- Use API contracts for wire spelling, enum values, types and null behavior. Do not
+silently promote technical names to product names or visible UI
+labels.
+- Use observed screens and implementation to report what exists. Keep observations
+distinct from approved or requested behavior.
+- When one displayed label maps to several API values, or an API value has several
+product-specific meanings, show the conditional mapping instead
+of flattening it.
+- When sources conflict, preserve both meanings, source versions and the affected
+decision. Ask which source governs that scope.
+
+## Output contract
+
+Produce only the requested scope. A glossary/mapping uses:
+
+| VI term | EN term | Meaning/distinction | Insurer/product alias | UI label | API path/type/enum | Scope | Source/location | Evidence status |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+
+Use `unknown` for missing API mappings and `candidate` for
+unapproved labels. Add relationships and unresolved conflicts
+when relevant. Do not generate invented identifiers to fill the
+table.
+
+## Example
+
+Example: a sample `planCode: "A"` proves only that the sample
+contains that field/value. Report its business meaning and UI
+label as unresolved until a glossary, contract or BA definition
+establishes them.
+
+## When to use
+Analyze insurer terminology, taxonomy, business concepts or
+glossary mappings across any supported line of business.
+## When not to use
+For state transitions or rule derivation use
+`showdar-insurance-workflows`; for implementation/UI QA use
+`showdar-insurance-review`.
+## Inputs and assumptions
+Use supplied glossary, BA/spec, wording, SOP, API/schema and
+scoped samples. No insurer-specific source is bundled.
+## Non-negotiable rules
+Keep source, scope and evidence status attached to each mapping.
+A seed translation is not an approved UI label.
+## Decision points
+Exact approved mapping available: preserve it. Meaning
+uncertain: keep mapping unknown. Conflicting definitions: report
+both.
+## Stack detection
+Identify actual models and API versions only when mapping to
+implementation. Framework choice cannot define insurance
+meaning.
+## Failure modes
+Same word can refer to different concepts across products.
+Apparent synonyms can hide different monetary or legal effects.
+## Stop conditions
+Do not finalize a mapping that would change money, coverage,
+party role or contractual meaning without evidence.
+## Escalation conditions
+Ask for the applicable glossary or business-owner verification
+when context cannot distinguish competing meanings.
+## Verification
+Check that each mapping distinguishes legal taxonomy from
+catalog grouping. Check that health, personal insurance and
+non-life are not collapsed by analogy. Verify an alias is
+recorded with its insurer and applicable product/version. Keep
+source-backed wording separate from proposed operator-facing
+wording. Check every asserted API identifier against the
+contract; every insurer alias against its scoped source. Check
+translations preserve the distinctions in the relevant concepts
+reference.
+## Anti-patterns
+Guessing a gói from planCode, rewriting API enums into
+Vietnamese, or treating an insurer sample as an industry
+standard.

package/skills/showdar-insurance-domain/references/concepts.md

@@ -0,0 +1,23 @@
+# Relationships and taxonomy
+
+This is a conceptual checklist, not a prescribed database schema or cardinality.
+
+## Product structure
+
+Keep statutory insurance type, insurer LOB/sub-LOB, product, product version, plan/package, coverage/benefit and risk object separate. An insurer catalog may group health, accident or travel differently from legal categories. “Con người” is a broad business grouping, not proof of a single statutory type. Motor, health, accident, travel, property, cargo, engineering and liability are examples, not a closed enum or mandated hierarchy.
+
+Resolve membership, cardinality and identifiers from supplied taxonomy. One product can combine risks/benefits; a plan can select or configure coverage; each relation is a hypothesis until established by product/schema sources. Product publication does not establish that a particular risk is eligible.
+
+## Contract structure
+
+Distinguish buyer, insured, beneficiary, payer, intermediary and insurer. They can coincide in particular cases but must not be merged by default. Identify insured objects, coverage selections, limits, exclusions, deductible mechanisms, effective period, territory and conditions. Keep quote, application/proposal, underwriting decision, contract, issued documents and payments conceptually separate even if the implementation combines them.
+
+## Money and risk
+
+Eligibility answers whether participation criteria are met; underwriting assesses acceptance and terms. Sum insured, insured value, liability/benefit limit and sub-limit are different concepts. A monetary limit needs currency, unit, insured subject, coverage, event/claim/period basis and aggregation/reset rules where applicable. Deductible may have fixed/percentage/minimum and per-event bases; do not invent their combination. Benefit products need not use an actual-loss indemnity calculation.
+
+## Version and status
+
+Separate product availability/publication, rate-table validity, quote status, application status, underwriting status, policy lifecycle, payment status, document generation and claim status. Preserve actual enum mappings. Never equate `ISSUED` with paid, in force or document delivered without source.
+
+Use product/rate/wording/API versions and applicable dates when tracing historical contracts. Determine whether a transaction snapshots terms or resolves them dynamically; neither is prescribed here. Renewal and endorsement may select different versions only under documented rules. Concurrent configuration changes require an explicit interpretation and test oracle.