showdar-skills 0.10.0 → 0.12.0

package/CHANGELOG.md

@@ -6,6 +6,36 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## [Unreleased]
 
+## [0.12.0]
+
+### Added
+
+- Canonical `showdar route --stdin|--prompt [--json]` runtime bridge projecting lifecycle primary, advisors, the seven public Intent keys, advisory domain matches, and installed/missing skill availability.
+- Specialized domain discovery overlay using deterministic Unicode phrase matching over `router/skill-map.yaml` inline trigger arrays; insurance terminology, underwriting/rating flows, and insurer API/UI review map to `showdar-insurance-domain`, `showdar-insurance-workflows`, and `showdar-insurance-review` without granting authority.
+- `showdar git-start --type --name [--base] [--dry-run] [--json]` for deterministic safe local task-branch preparation without inferred staging, commit, merge, or push.
+- Task branch isolation guidance: branch-before-edit on integration/default branches, repository-policy priority, one branch per coherent task, and conservative dirty-worktree blocking.
+
+### Changed
+
+- Managed harness instructions and commands invoke the canonical runtime router with native/static fallback when the CLI is unavailable.
+- Init/add guidance reflects the complete installed set; add refreshes existing commands and instructions even when the skill is already installed.
+- Showdar Git documents one branch per coherent task, repository-policy priority, and explicit completion/integration authority.
+- Task completion defaults to verify and report; merge and push each require their own explicit authority.
+
+### Safety / Compatibility
+
+- Domain discovery does not grant authority and never replaces the lifecycle primary or rewrites Intent/mutation.
+- Phase 6G authority, state, evidence, trace, and manifest contracts unchanged; no engine vendoring into projects.
+- No implicit branch commit/merge/push; no automatic stash, reset, restore, or clean.
+- Existing v0.11 projects remain compatible; no migration required.
+
+## [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

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,
@@ -40,9 +40,91 @@ Claude Code as supported installation targets. Choose `backend`, `qa`, or
 `product` when that gives discovery a more precise context; use `full` when
 you want all capabilities available.
 
+## Runtime routing and task branches
+
+```bash
+printf '%s\n' 'Implement the approved underwriting form and add tests' | showdar route --stdin --json
+showdar route --prompt "Explain insurance terminology"
+showdar git-start --dry-run --type feature --name "IDP-123 Add pricing form"
+showdar git-start --type feature --name "IDP-123 Add pricing form"
+```
+
+Prefer `--stdin` for arbitrary or multiline prompts. Supply stdin as literal data;
+never interpolate request text into a shell command. Both commands support `--json`
+with a schemaVersion 1 envelope (`command`, `ok`, `data`, `warnings`, `errors`).
+
+`route` is read-only. It consumes the existing Phase 6G authority resolver and thin
+route, projecting exactly the seven public Intent keys plus lifecycle primary and
+advisors. It never exposes internal capabilities, frames or authority diagnostics.
+It neither authorizes work nor creates a branch. It preserves canonical advisor
+semantics: a security-review phrase is not guaranteed to become a security advisor.
+
+Domain discovery is a separate advisory overlay using the canonical
+`router/skill-map.yaml` inline trigger arrays and grouped domain catalog metadata.
+It uses deterministic Unicode phrase matching, not lifecycle scoring. Insurance
+terminology can recommend `showdar-insurance-domain`, underwriting/rating business
+flows `showdar-insurance-workflows`, and insurer API/UI terminology review
+`showdar-insurance-review`. These skills do not replace lifecycle primaryCapability,
+rewrite Intent/mutation, or grant authority. The existing ASCII/token ranking
+helper is unsuitable for Vietnamese phrase discovery. No duplicate trigger table
+or second authority engine is introduced.
+
+When `.showdar.json` exists, availability checks managed native skill files and
+recorded, still-present globally satisfied skills. Missing lifecycle primary,
+advisors and domain matches are reported separately with `showdar add <name>`
+suggestions; another installed skill never substitutes for the canonical route.
+Without a project manifest, `managed` is false and installed/missing fields are
+null (unknown), not fabricated. Invalid manifests fail explicitly. Explicit named
+installed skills may load directly; this adds no mutation authority.
+
+Managed project guidance invokes `showdar route --stdin --json` for automatic
+selection, then loads the installed lifecycle skill, domain overlays and advisors.
+The runtime bridge requires the `showdar` CLI in the harness environment. If it is
+unavailable, native skill descriptions/static discovery are the fallback. No npm
+install, npx fetch, package dependency mutation or remote download happens.
+Projects receive only existing skills/commands/instructions/manifest; no wholesale
+`src/`, `engine/` or `router/` copy. Init and add regenerate complete installed-set
+guidance, including re-adding an existing skill. Global installs keep native discovery
+and do not write project AGENTS.md or CLAUDE.md.
+
+The four workflows remain native discoverable/installable skills; `route` does not
+introduce workflow selection. Profiles remain primitive-only: `full` contains all
+18 primitives, and the insurance profile remains unchanged.
+
+Before the first local-write task source edit on develop/development/dev/main/master
+or the repository default/integration branch, prepare a task branch. Priority is
+repository instructions/documented convention, explicit current user instruction,
+clearly detected convention, then Showdar defaults. Explicit trunk/direct-work policy
+wins. One coherent task uses one branch across plan/build/test/review. Completion
+means verify and report; commit, merge and push need their own authority.
+
+`git-start` prepares local branch state only. Types: feature (new capability), fix
+(defect), refactor (internal structure), test, docs, chore (tooling/config), release,
+hotfix (explicit urgent production repair). Slugs are lowercase, hyphenated, ticket
+preserving and bounded; task text is passed as data and never executed.
+
+Base resolution uses explicit `--base`, repository-local `showdar.gitBase`, established
+local develop/development/dev, then local default/main/master. The helper does not
+parse prose instructions or create develop. Read policy first and supply its base
+when convention differs. Local Git config `showdar.gitBranchPrefix` supports custom
+prefixes; `showdar.gitDirectWork=true` records an explicit direct-work convention.
+Hotfix requires a convention via `--base` or `showdar.gitBase`.
+
+Dry-run validates Git state/type/slug/base/collision and changes no refs. Execution
+revalidates, then creates/switches only a task branch. Already on the matching branch
+is a no-op; another task branch is blocked. An existing target is reused automatically
+only when its tip equals both current HEAD and base; divergent/ambiguous targets stop
+without overwriting history. Detached HEAD and active Git operations stop.
+
+Dirty worktrees are blocked before any switch: the helper cannot prove ownership.
+Confirmed current-task-only changes may use equivalent repository-specific branch
+preparation after explicit ownership inspection. No automatic stash/reset/restore/clean,
+staging, commit, merge or push occurs. Branch preparation itself does not authorize
+source edits.
+
 ## 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 +154,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 +177,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 +217,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 +308,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 +322,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 +357,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 +638,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
@@ -641,7 +748,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
@@ -746,7 +853,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

@@ -1,5 +1,8 @@
 #!/usr/bin/env node
 import path from 'node:path';
+import { parseArgs } from 'node:util';
+import { startTaskBranch, formatGitStart } from '../src/git-start.js';
+import { routeRequest, formatRoute } from '../src/runtime-route.js';
 import { homedir } from 'node:os';
 import { readFile } from 'node:fs/promises';
 import { fileURLToPath } from 'node:url';
@@ -33,6 +36,14 @@ function scopeAfter(args) {
 
 function printHelp(version, command = null) {
   const scopeUsage = '[--scope <project|global>]';
+  if (command === 'route') {
+    console.log('Usage: showdar route (--stdin | --prompt <text>) [--json]');
+    return;
+  }
+  if (command === 'git-start') {
+    console.log('Usage: showdar git-start --type <type> --name <task> [--base <branch>] [--dry-run] [--json]');
+    return;
+  }
   if (command === 'init') {
     console.log(`Showdar Skills ${version}\n\nUsage:\n  showdar init ${scopeUsage} [--profile <name>] [--ai <universal|codex|opencode|cursor|claude|all>]\n\nDefaults: scope project, profile full, AI target universal.\nProject scope writes native skills, one native instruction surface, and project .showdar.json. Global scope writes verified user skill directories and ~/.showdar/global.json without instruction files. Codex and universal use .agents/skills in project scope and ~/.agents/skills in global scope; cursor uses .cursor/skills in project scope and ~/.cursor/skills in global scope; --ai all writes each shared destination once, generates OpenCode and Claude commands, and writes only the AGENTS.md block.\n\nProfiles: ${Object.keys(PROFILES).join(', ')}\nDeprecated aliases: ${Object.entries(PROFILE_ALIASES).map(([alias, target]) => `${alias} -> ${target}`).join(', ')}\nAI targets: ${AI_TARGETS.join(', ')}`);
     return;
@@ -45,7 +56,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] [--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(', ')}`);
+  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 route (--stdin | --prompt <text>) [--json]\n  showdar git-start --type <type> --name <task> [--base <branch>] [--dry-run] [--json]\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() {
@@ -59,10 +70,33 @@ async function main() {
     console.log(version);
     return;
   }
-  if (args.includes('--help') || args.includes('-h')) return printHelp(version, command);
+  if (!['route', 'git-start'].includes(command) && (args.includes('--help') || args.includes('-h'))) return printHelp(version, command);
 
   const scope = ['init', 'status', 'doctor', 'remove', 'add'].includes(command) ? scopeAfter(args) : null;
 
+  if (command === 'git-start') {
+    const { values } = parseArgs({ args: args.slice(1), options: { type: { type: 'string' }, name: { type: 'string' }, base: { type: 'string' }, 'dry-run': { type: 'boolean' }, json: { type: 'boolean' }, help: { type: 'boolean', short: 'h' } } });
+    if (values.help) return printHelp(version, command);
+    const data = startTaskBranch({ cwd: projectRoot, type: values.type, name: values.name, base: values.base, dryRun: values['dry-run'] });
+    console.log(values.json ? JSON.stringify({ schemaVersion: 1, command, ok: true, data, warnings: [], errors: [] }, null, 2) : formatGitStart(data));
+    return;
+  }
+
+  if (command === 'route') {
+    const { values } = parseArgs({ args: args.slice(1), options: { stdin: { type: 'boolean' }, prompt: { type: 'string' }, json: { type: 'boolean' }, help: { type: 'boolean', short: 'h' } } });
+    if (values.help) return printHelp(version, command);
+    if (Boolean(values.stdin) === (values.prompt !== undefined)) throw new Error('Select exactly one of --stdin or --prompt.');
+    let prompt = values.prompt;
+    if (values.stdin) {
+      process.stdin.setEncoding('utf8');
+      prompt = '';
+      for await (const chunk of process.stdin) prompt += chunk;
+    }
+    const data = await routeRequest({ prompt, cwd: projectRoot, packageRoot });
+    console.log(values.json ? JSON.stringify({ schemaVersion: 1, command, ok: true, data, warnings: [], errors: [] }, null, 2) : formatRoute(data));
+    return;
+  }
+
   if (command === 'list') {
     if (args.includes('--extensions')) {
       const isJson = args.includes('--json');
@@ -342,6 +376,9 @@ async function main() {
 }
 
 main().catch((error) => {
-  console.error(`showdar: ${error.message}`);
+  const command = process.argv[2];
+  if (['route', 'git-start'].includes(command) && process.argv.slice(3).includes('--json')) {
+    console.log(JSON.stringify({ schemaVersion: 1, command, ok: false, data: null, warnings: [], errors: [{ code: 'INVALID_REQUEST', message: error.message }] }, null, 2));
+  } else console.error(`showdar: ${error.message}`);
   process.exitCode = 1;
 });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "showdar-skills",
-  "version": "0.10.0",
+  "version": "0.12.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

@@ -38,7 +38,7 @@ routes:
     triggers: ["resume interrupted implementation", "recover partial work", "session stopped", "continue partial work", "missing context"]
     skill: showdar-recover
   git:
-    triggers: ["commit", "stage only task files", "merge branch", "rebase branch", "cherry-pick commit", "git conflict", "push branch", "clean merged branches", "finish git workflow"]
+    triggers: ["commit", "stage only task files", "merge branch", "rebase branch", "cherry-pick commit", "git conflict", "push branch", "clean merged branches", "finish git workflow", "start task branch", "create feature branch", "create fix branch", "branch for this task"]
     skill: showdar-git
   requirements:
     triggers: ["requirements", "business rules", "acceptance criteria", "user stories", "use cases", "requirement matrix", "missing requirement", "ambiguity"]
@@ -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-git/SKILL.md

@@ -46,6 +46,29 @@ This skill owns repository state transitions, not source-code review or GitHub a
 - Push, tag, remote deletion, pull with mutation, GitHub operations, and release actions require explicit intent.
 - Report exactly what changed after each Git mutation.
 
+## Task branch isolation
+
+Before the first task-owned source edit for a local-write engineering task, inspect Git state (`git status --short`, current branch, branch history and repository policy). Direct develop/main edits are not the default: on develop, development, dev, main, master or the default/integration branch, prepare a dedicated task branch before source mutation.
+
+Priority: repository instructions/documented branching convention; explicit current user instruction; clearly detected existing convention; Showdar safe default. Explicit trunk-based/direct-work policy wins: do not impose GitFlow. Branch preparation does not authorize source mutation.
+
+Use one branch per coherent task across understand, requirements, plan, design, build, test and review. Continue the current task branch; never create a branch per skill or nested branches.
+
+Default types: new user-visible capability → `feature`; observed defect → `fix`; internal restructuring → `refactor`; tests only → `test`; documentation only → `docs`; tooling/config/maintenance → `chore`; release preparation → `release`; explicit urgent production repair → `hotfix`. Names use a bounded lowercase hyphen slug preserving ticket keys.
+
+Prefer established local develop for normal work; otherwise the repository default/integration branch. Do not create develop automatically. Explicit hotfix follows repository convention. Read prose policy yourself; the helper does not parse repository instructions. Supply `--base` or repository-local Git config `showdar.gitBase`, `showdar.gitBranchPrefix`, `showdar.gitDirectWork` for deterministic custom conventions.
+
+```bash
+showdar git-start --dry-run --type feature --name "Task description"
+showdar git-start --type feature --name "Task description"
+```
+
+The helper revalidates before creating/switching and never edits source. A clean worktree can branch. Confirmed current-task changes may be carried only through equivalent repository-specific Git preparation with proven ownership and Git permission; the helper conservatively blocks dirty changes before switching because it cannot prove ownership. Unrelated/ambiguous changes → STOP. No hidden stash, reset, restore or clean.
+
+Existing same-name branches must be inspected. The helper reuses only an unused branch with the same tip as both current HEAD and base; an already-active matching branch is a continue/no-op. Any other collision → STOP; never reset or overwrite branch history. Already on another task branch → inspect task identity before switching.
+
+Default completion: task branch → verify → report. No inferred commit, merge or push. Merge only when explicitly requested or clearly included in current repository/user task authority; push remains independently explicit.
+
 ## Workflow
 
 ### 1. Inspect Git state
@@ -273,7 +296,8 @@ report -> SHA, staged paths, exclusions, and clean/dirty final state
 ### Feature completion without push
 
 ```text
-feature branch -> selective commit -> switch develop -> merge using repository convention -> verify
+task branch -> verify -> report
+selective commit only when requested; merge only with current task authority
 remote -> not touched because no push request was given
 ```
 

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.