[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M77JF14ASTM4VG3GC48FDTSB":3,"skill-same:01M77JF14ASTM4VG3GC48FDTSB":50},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":29,"commitSha":30,"skillDirectory":31,"forksCount":32,"repositoryHtmlUrl":33,"repositoryHomepageUrl":34,"ownerHtmlUrl":35,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":36,"install":37,"resources":49},"01M77JF14ASTM4VG3GC48FDTSB","speckit-analyze",null,"Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.","Kemetra\u002FSeshat-BI","Kemetra","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F206601658?v=4","01M77J5APND9QAJK8XMBH5B1A8","01M77J5AR4TM1GN2G4GS5KH02J",2,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FKemetra\u002FSeshat-BI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fspeckit-analyze\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: \"speckit-analyze\"\ndescription: \"Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.\"\nargument-hint: \"Optional focus areas for analysis\"\ncompatibility: \"Requires spec-kit project structure with .specify\u002F directory\"\nmetadata:\n  author: \"github-spec-kit\"\n  source: \"templates\u002Fcommands\u002Fanalyze.md\"\nuser-invocable: true\ndisable-model-invocation: false\n---\n\n\n## User Input\n\n```text\n$ARGUMENTS\n```\n\nYou **MUST** consider the user input before proceeding (if not empty).\n\n## Pre-Execution Checks\n\n**Check for extension hooks (before analysis)**:\n- Check if `.specify\u002Fextensions.yml` exists in the project root.\n- If it exists, read it and look for entries under the `hooks.before_analyze` key\n- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally\n- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default.\n- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions:\n  - If the hook has no `condition` field, or it is null\u002Fempty, treat the hook as executable\n  - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation\n- When constructing slash commands from hook command names, replace dots (`.`) with hyphens (`-`). For example, `speckit.git.commit` → `\u002Fspeckit-git-commit`.\n- For each executable hook, output the following based on its `optional` flag:\n  - **Optional hook** (`optional: true`):\n    ```\n    ## Extension Hooks\n\n    **Optional Pre-Hook**: {extension}\n    Command: `\u002F{command}`\n    Description: {description}\n\n    Prompt: {prompt}\n    To execute: `\u002F{command}`\n    ```\n  - **Mandatory hook** (`optional: false`):\n    ```\n    ## Extension Hooks\n\n    **Automatic Pre-Hook**: {extension}\n    Executing: `\u002F{command}`\n    EXECUTE_COMMAND: {command}\n\n    Wait for the result of the hook command before proceeding to the Goal.\n    ```\n- If no hooks are registered or `.specify\u002Fextensions.yml` does not exist, skip silently\n\n## Goal\n\nIdentify inconsistencies, duplications, ambiguities, and underspecified items across the three core artifacts (`spec.md`, `plan.md`, `tasks.md`) before implementation. This command MUST run only after `\u002Fspeckit-tasks` has successfully produced a complete `tasks.md`.\n\n## Operating Constraints\n\n**STRICTLY READ-ONLY**: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands would be invoked manually).\n\n**Constitution Authority**: The project constitution (`.specify\u002Fmemory\u002Fconstitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `\u002Fspeckit-analyze`.\n\n## Execution Steps\n\n### 1. Initialize Analysis Context\n\nRun `.specify\u002Fscripts\u002Fpowershell\u002Fcheck-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` once from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS. Derive absolute paths:\n\n- SPEC = FEATURE_DIR\u002Fspec.md\n- PLAN = FEATURE_DIR\u002Fplan.md\n- TASKS = FEATURE_DIR\u002Ftasks.md\n\nAbort with an error message if any required file is missing (instruct the user to run missing prerequisite command).\nFor single quotes in args like \"I'm Groot\", use escape syntax: e.g 'I'\\''m Groot' (or double-quote if possible: \"I'm Groot\").\n\n### 2. Load Artifacts (Progressive Disclosure)\n\nLoad only the minimal necessary context from each artifact:\n\n**From spec.md:**\n\n- Overview\u002FContext\n- Functional Requirements\n- Success Criteria (measurable outcomes — e.g., performance, security, availability, user success, business impact)\n- User Stories\n- Edge Cases (if present)\n\n**From plan.md:**\n\n- Architecture\u002Fstack choices\n- Data Model references\n- Phases\n- Technical constraints\n\n**From tasks.md:**\n\n- Task IDs\n- Descriptions\n- Phase grouping\n- Parallel markers [P]\n- Referenced file paths\n\n**From constitution:**\n\n- Load `.specify\u002Fmemory\u002Fconstitution.md` for principle validation\n\n### 3. Build Semantic Models\n\nCreate internal representations (do not include raw artifacts in output):\n\n- **Requirements inventory**: For each Functional Requirement (FR-###) and Success Criterion (SC-###), record a stable key. Use the explicit FR-\u002FSC- identifier as the primary key when present, and optionally also derive an imperative-phrase slug for readability (e.g., \"User can upload file\" → `user-can-upload-file`). Include only Success Criteria items that require buildable work (e.g., load-testing infrastructure, security audit tooling), and exclude post-launch outcome metrics and business KPIs (e.g., \"Reduce support tickets by 50%\").\n- **User story\u002Faction inventory**: Discrete user actions with acceptance criteria\n- **Task coverage mapping**: Map each task to one or more requirements or stories (inference by keyword \u002F explicit reference patterns like IDs or key phrases)\n- **Constitution rule set**: Extract principle names and MUST\u002FSHOULD normative statements\n\n### 4. Detection Passes (Token-Efficient Analysis)\n\nFocus on high-signal findings. Limit to 50 findings total; aggregate remainder in overflow summary.\n\n#### A. Duplication Detection\n\n- Identify near-duplicate requirements\n- Mark lower-quality phrasing for consolidation\n\n#### B. Ambiguity Detection\n\n- Flag vague adjectives (fast, scalable, secure, intuitive, robust) lacking measurable criteria\n- Flag unresolved placeholders (TODO, TKTK, ???, `\u003Cplaceholder>`, etc.)\n\n#### C. Underspecification\n\n- Requirements with verbs but missing object or measurable outcome\n- User stories missing acceptance criteria alignment\n- Tasks referencing files or components not defined in spec\u002Fplan\n\n#### D. Constitution Alignment\n\n- Any requirement or plan element conflicting with a MUST principle\n- Missing mandated sections or quality gates from constitution\n\n#### E. Coverage Gaps\n\n- Requirements with zero associated tasks\n- Tasks with no mapped requirement\u002Fstory\n- Success Criteria requiring buildable work (performance, security, availability) not reflected in tasks\n\n#### F. Inconsistency\n\n- Terminology drift (same concept named differently across files)\n- Data entities referenced in plan but absent in spec (or vice versa)\n- Task ordering contradictions (e.g., integration tasks before foundational setup tasks without dependency note)\n- Conflicting requirements (e.g., one requires Next.js while other specifies Vue)\n\n### 5. Severity Assignment\n\nUse this heuristic to prioritize findings:\n\n- **CRITICAL**: Violates constitution MUST, missing core spec artifact, or requirement with zero coverage that blocks baseline functionality\n- **HIGH**: Duplicate or conflicting requirement, ambiguous security\u002Fperformance attribute, untestable acceptance criterion\n- **MEDIUM**: Terminology drift, missing non-functional task coverage, underspecified edge case\n- **LOW**: Style\u002Fwording improvements, minor redundancy not affecting execution order\n\n### 6. Produce Compact Analysis Report\n\nOutput a Markdown report (no file writes) with the following structure:\n\n## Specification Analysis Report\n\n| ID | Category | Severity | Location(s) | Summary | Recommendation |\n|----|----------|----------|-------------|---------|----------------|\n| A1 | Duplication | HIGH | spec.md:L120-134 | Two similar requirements ... | Merge phrasing; keep clearer version |\n\n(Add one row per finding; generate stable IDs prefixed by category initial.)\n\n**Coverage Summary Table:**\n\n| Requirement Key | Has Task? | Task IDs | Notes |\n|-----------------|-----------|----------|-------|\n\n**Constitution Alignment Issues:** (if any)\n\n**Unmapped Tasks:** (if any)\n\n**Metrics:**\n\n- Total Requirements\n- Total Tasks\n- Coverage % (requirements with >=1 task)\n- Ambiguity Count\n- Duplication Count\n- Critical Issues Count\n\n### 7. Provide Next Actions\n\nAt end of report, output a concise Next Actions block:\n\n- If CRITICAL issues exist: Recommend resolving before `\u002Fspeckit-implement`\n- If only LOW\u002FMEDIUM: User may proceed, but provide improvement suggestions\n- Provide explicit command suggestions: e.g., \"Run \u002Fspeckit-specify with refinement\", \"Run \u002Fspeckit-plan to adjust architecture\", \"Manually edit tasks.md to add coverage for 'performance-metrics'\"\n\n### 8. Offer Remediation\n\nAsk the user: \"Would you like me to suggest concrete remediation edits for the top N issues?\" (Do NOT apply them automatically.)\n\n### 9. Check for extension hooks\n\nAfter reporting, check if `.specify\u002Fextensions.yml` exists in the project root.\n- If it exists, read it and look for entries under the `hooks.after_analyze` key\n- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally\n- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default.\n- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions:\n  - If the hook has no `condition` field, or it is null\u002Fempty, treat the hook as executable\n  - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation\n- When constructing slash commands from hook command names, replace dots (`.`) with hyphens (`-`). For example, `speckit.git.commit` → `\u002Fspeckit-git-commit`.\n- For each executable hook, output the following based on its `optional` flag:\n  - **Optional hook** (`optional: true`):\n    ```\n    ## Extension Hooks\n\n    **Optional Hook**: {extension}\n    Command: `\u002F{command}`\n    Description: {description}\n\n    Prompt: {prompt}\n    To execute: `\u002F{command}`\n    ```\n  - **Mandatory hook** (`optional: false`):\n    ```\n    ## Extension Hooks\n\n    **Automatic Hook**: {extension}\n    Executing: `\u002F{command}`\n    EXECUTE_COMMAND: {command}\n    ```\n- If no hooks are registered or `.specify\u002Fextensions.yml` does not exist, skip silently\n\n## Operating Principles\n\n### Context Efficiency\n\n- **Minimal high-signal tokens**: Focus on actionable findings, not exhaustive documentation\n- **Progressive disclosure**: Load artifacts incrementally; don't dump all content into analysis\n- **Token-efficient output**: Limit findings table to 50 rows; summarize overflow\n- **Deterministic results**: Rerunning without changes should produce consistent IDs and counts\n\n### Analysis Guidelines\n\n- **NEVER modify files** (this is read-only analysis)\n- **NEVER hallucinate missing sections** (if absent, report them accurately)\n- **Prioritize constitution violations** (these are always CRITICAL)\n- **Use examples over exhaustive rules** (cite specific instances, not generic patterns)\n- **Report zero issues gracefully** (emit success report with coverage statistics)\n\n## Context\n\n$ARGUMENTS\n","## User Input\n\n```text\n$ARGUMENTS\n```\n\nYou **MUST** consider the user input before proceeding (if not empty).\n\n## Pre-Execution Checks\n\n**Check for extension hooks (before analysis)**:\n- Check if `.specify\u002Fextensions.yml` exists in the project root.\n- If it exists, read it and look for entries under the `hooks.before_analyze` key\n- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally\n- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default.\n- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions:\n  - If the hook has no `condition` field, or it is null\u002Fempty, treat the hook as executable\n  - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation\n- When constructing slash commands from hook command names, replace dots (`.`) with hyphens (`-`). For example, `speckit.git.commit` → `\u002Fspeckit-git-commit`.\n- For each executable hook, output the following based on its `optional` flag:\n  - **Optional hook** (`optional: true`):\n    ```\n    ## Extension Hooks\n\n    **Optional Pre-Hook**: {extension}\n    Command: `\u002F{command}`\n    Description: {description}\n\n    Prompt: {prompt}\n    To execute: `\u002F{command}`\n    ```\n  - **Mandatory hook** (`optional: false`):\n    ```\n    ## Extension Hooks\n\n    **Automatic Pre-Hook**: {extension}\n    Executing: `\u002F{command}`\n    EXECUTE_COMMAND: {command}\n\n    Wait for the result of the hook command before proceeding to the Goal.\n    ```\n- If no hooks are registered or `.specify\u002Fextensions.yml` does not exist, skip silently\n\n## Goal\n\nIdentify inconsistencies, duplications, ambiguities, and underspecified items across the three core artifacts (`spec.md`, `plan.md`, `tasks.md`) before implementation. This command MUST run only after `\u002Fspeckit-tasks` has successfully produced a complete `tasks.md`.\n\n## Operating Constraints\n\n**STRICTLY READ-ONLY**: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands would be invoked manually).\n\n**Constitution Authority**: The project constitution (`.specify\u002Fmemory\u002Fconstitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `\u002Fspeckit-analyze`.\n\n## Execution Steps\n\n### 1. Initialize Analysis Context\n\nRun `.specify\u002Fscripts\u002Fpowershell\u002Fcheck-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` once from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS. Derive absolute paths:\n\n- SPEC = FEATURE_DIR\u002Fspec.md\n- PLAN = FEATURE_DIR\u002Fplan.md\n- TASKS = FEATURE_DIR\u002Ftasks.md\n\nAbort with an error message if any required file is missing (instruct the user to run missing prerequisite command).\nFor single quotes in args like \"I'm Groot\", use escape syntax: e.g 'I'\\''m Groot' (or double-quote if possible: \"I'm Groot\").\n\n### 2. Load Artifacts (Progressive Disclosure)\n\nLoad only the minimal necessary context from each artifact:\n\n**From spec.md:**\n\n- Overview\u002FContext\n- Functional Requirements\n- Success Criteria (measurable outcomes — e.g., performance, security, availability, user success, business impact)\n- User Stories\n- Edge Cases (if present)\n\n**From plan.md:**\n\n- Architecture\u002Fstack choices\n- Data Model references\n- Phases\n- Technical constraints\n\n**From tasks.md:**\n\n- Task IDs\n- Descriptions\n- Phase grouping\n- Parallel markers [P]\n- Referenced file paths\n\n**From constitution:**\n\n- Load `.specify\u002Fmemory\u002Fconstitution.md` for principle validation\n\n### 3. Build Semantic Models\n\nCreate internal representations (do not include raw artifacts in output):\n\n- **Requirements inventory**: For each Functional Requirement (FR-###) and Success Criterion (SC-###), record a stable key. Use the explicit FR-\u002FSC- identifier as the primary key when present, and optionally also derive an imperative-phrase slug for readability (e.g., \"User can upload file\" → `user-can-upload-file`). Include only Success Criteria items that require buildable work (e.g., load-testing infrastructure, security audit tooling), and exclude post-launch outcome metrics and business KPIs (e.g., \"Reduce support tickets by 50%\").\n- **User story\u002Faction inventory**: Discrete user actions with acceptance criteria\n- **Task coverage mapping**: Map each task to one or more requirements or stories (inference by keyword \u002F explicit reference patterns like IDs or key phrases)\n- **Constitution rule set**: Extract principle names and MUST\u002FSHOULD normative statements\n\n### 4. Detection Passes (Token-Efficient Analysis)\n\nFocus on high-signal findings. Limit to 50 findings total; aggregate remainder in overflow summary.\n\n#### A. Duplication Detection\n\n- Identify near-duplicate requirements\n- Mark lower-quality phrasing for consolidation\n\n#### B. Ambiguity Detection\n\n- Flag vague adjectives (fast, scalable, secure, intuitive, robust) lacking measurable criteria\n- Flag unresolved placeholders (TODO, TKTK, ???, `\u003Cplaceholder>`, etc.)\n\n#### C. Underspecification\n\n- Requirements with verbs but missing object or measurable outcome\n- User stories missing acceptance criteria alignment\n- Tasks referencing files or components not defined in spec\u002Fplan\n\n#### D. Constitution Alignment\n\n- Any requirement or plan element conflicting with a MUST principle\n- Missing mandated sections or quality gates from constitution\n\n#### E. Coverage Gaps\n\n- Requirements with zero associated tasks\n- Tasks with no mapped requirement\u002Fstory\n- Success Criteria requiring buildable work (performance, security, availability) not reflected in tasks\n\n#### F. Inconsistency\n\n- Terminology drift (same concept named differently across files)\n- Data entities referenced in plan but absent in spec (or vice versa)\n- Task ordering contradictions (e.g., integration tasks before foundational setup tasks without dependency note)\n- Conflicting requirements (e.g., one requires Next.js while other specifies Vue)\n\n### 5. Severity Assignment\n\nUse this heuristic to prioritize findings:\n\n- **CRITICAL**: Violates constitution MUST, missing core spec artifact, or requirement with zero coverage that blocks baseline functionality\n- **HIGH**: Duplicate or conflicting requirement, ambiguous security\u002Fperformance attribute, untestable acceptance criterion\n- **MEDIUM**: Terminology drift, missing non-functional task coverage, underspecified edge case\n- **LOW**: Style\u002Fwording improvements, minor redundancy not affecting execution order\n\n### 6. Produce Compact Analysis Report\n\nOutput a Markdown report (no file writes) with the following structure:\n\n## Specification Analysis Report\n\n| ID | Category | Severity | Location(s) | Summary | Recommendation |\n|----|----------|----------|-------------|---------|----------------|\n| A1 | Duplication | HIGH | spec.md:L120-134 | Two similar requirements ... | Merge phrasing; keep clearer version |\n\n(Add one row per finding; generate stable IDs prefixed by category initial.)\n\n**Coverage Summary Table:**\n\n| Requirement Key | Has Task? | Task IDs | Notes |\n|-----------------|-----------|----------|-------|\n\n**Constitution Alignment Issues:** (if any)\n\n**Unmapped Tasks:** (if any)\n\n**Metrics:**\n\n- Total Requirements\n- Total Tasks\n- Coverage % (requirements with >=1 task)\n- Ambiguity Count\n- Duplication Count\n- Critical Issues Count\n\n### 7. Provide Next Actions\n\nAt end of report, output a concise Next Actions block:\n\n- If CRITICAL issues exist: Recommend resolving before `\u002Fspeckit-implement`\n- If only LOW\u002FMEDIUM: User may proceed, but provide improvement suggestions\n- Provide explicit command suggestions: e.g., \"Run \u002Fspeckit-specify with refinement\", \"Run \u002Fspeckit-plan to adjust architecture\", \"Manually edit tasks.md to add coverage for 'performance-metrics'\"\n\n### 8. Offer Remediation\n\nAsk the user: \"Would you like me to suggest concrete remediation edits for the top N issues?\" (Do NOT apply them automatically.)\n\n### 9. Check for extension hooks\n\nAfter reporting, check if `.specify\u002Fextensions.yml` exists in the project root.\n- If it exists, read it and look for entries under the `hooks.after_analyze` key\n- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally\n- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default.\n- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions:\n  - If the hook has no `condition` field, or it is null\u002Fempty, treat the hook as executable\n  - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation\n- When constructing slash commands from hook command names, replace dots (`.`) with hyphens (`-`). For example, `speckit.git.commit` → `\u002Fspeckit-git-commit`.\n- For each executable hook, output the following based on its `optional` flag:\n  - **Optional hook** (`optional: true`):\n    ```\n    ## Extension Hooks\n\n    **Optional Hook**: {extension}\n    Command: `\u002F{command}`\n    Description: {description}\n\n    Prompt: {prompt}\n    To execute: `\u002F{command}`\n    ```\n  - **Mandatory hook** (`optional: false`):\n    ```\n    ## Extension Hooks\n\n    **Automatic Hook**: {extension}\n    Executing: `\u002F{command}`\n    EXECUTE_COMMAND: {command}\n    ```\n- If no hooks are registered or `.specify\u002Fextensions.yml` does not exist, skip silently\n\n## Operating Principles\n\n### Context Efficiency\n\n- **Minimal high-signal tokens**: Focus on actionable findings, not exhaustive documentation\n- **Progressive disclosure**: Load artifacts incrementally; don't dump all content into analysis\n- **Token-efficient output**: Limit findings table to 50 rows; summarize overflow\n- **Deterministic results**: Rerunning without changes should produce consistent IDs and counts\n\n### Analysis Guidelines\n\n- **NEVER modify files** (this is read-only analysis)\n- **NEVER hallucinate missing sections** (if absent, report them accurately)\n- **Prioritize constitution violations** (these are always CRITICAL)\n- **Use examples over exhaustive rules** (cite specific instances, not generic patterns)\n- **Report zero issues gracefully** (emit success report with coverage statistics)\n\n## Context\n\n$ARGUMENTS\n",{"name":5,"metadata":23,"description":7,"argument-hint":26,"compatibility":27,"user-invocable":28,"disable-model-invocation":19},{"author":24,"source":25},"github-spec-kit","templates\u002Fcommands\u002Fanalyze.md","Optional focus areas for analysis","Requires spec-kit project structure with .specify\u002F directory",true,"main","6266e304556a72b75d951b9433fd833481c61233",".claude\u002Fskills\u002Fspeckit-analyze",0,"https:\u002F\u002Fgithub.com\u002FKemetra\u002FSeshat-BI","https:\u002F\u002Fpypi.org\u002Fproject\u002Fseshat-bi\u002F","https:\u002F\u002Fgithub.com\u002FKemetra","2026-11-11 21:44:25",{"source":8,"skillName":5,"commands":38,"prompt":48,"zipAvailable":28},[39,42,45],{"tool":40,"command":41},"npx","npx skills add Kemetra\u002FSeshat-BI --skill speckit-analyze",{"tool":43,"command":44},"bunx","bunx skills add Kemetra\u002FSeshat-BI --skill speckit-analyze",{"tool":46,"command":47},"pnpm","pnpm dlx skills add Kemetra\u002FSeshat-BI --skill speckit-analyze","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FKemetra\u002FSeshat-BI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fspeckit-analyze\u002FSKILL.md",[],[51,58,63,69,74,81],{"skillNo":52,"name":53,"nameZh":6,"description":54,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":55,"categories":56,"keywords":57,"publishedAt":18},"01M77JWCTJ88JWPDD25WZ2NEY8","fake-skill","A fixture skill with declaring frontmatter, used as positive shipped evidence.","https:\u002F\u002Fgithub.com\u002FKemetra\u002FSeshat-BI\u002Fblob\u002Fmain\u002Ftests\u002Funit\u002Ffixtures\u002Fcapability_inventory\u002Funlisted\u002F.claude\u002Fskills\u002Ffake-skill\u002FSKILL.md",[],[],{"skillNo":59,"name":53,"nameZh":6,"description":54,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":60,"categories":61,"keywords":62,"publishedAt":18},"01M77JWA0BTG4JB2HR52Q99216","https:\u002F\u002Fgithub.com\u002FKemetra\u002FSeshat-BI\u002Fblob\u002Fmain\u002Ftests\u002Funit\u002Ffixtures\u002Fcapability_inventory\u002Forphan\u002F.claude\u002Fskills\u002Ffake-skill\u002FSKILL.md",[],[],{"skillNo":64,"name":65,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":18},"01M77JW6VE59XEFHWBTNDYAS2Q","bare-skill-no-frontmatter","https:\u002F\u002Fgithub.com\u002FKemetra\u002FSeshat-BI\u002Fblob\u002Fmain\u002Ftests\u002Funit\u002Ffixtures\u002Fcapability_inventory\u002Forphan\u002F.claude\u002Fskills\u002Fbare-skill-no-frontmatter\u002FSKILL.md",[],[],{"skillNo":70,"name":53,"nameZh":6,"description":54,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":18},"01M77JW4TD1FNFSBNP5C0WXAA5","https:\u002F\u002Fgithub.com\u002FKemetra\u002FSeshat-BI\u002Fblob\u002Fmain\u002Ftests\u002Funit\u002Ffixtures\u002Fcapability_inventory\u002Fgood\u002F.claude\u002Fskills\u002Ffake-skill\u002FSKILL.md",[],[],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":18},"01M77JVWCVE3WZ82ZNFCSFVDCP","retail-kpi-knowledge","Retail KPI \u002F metric-contract reasoning layer for BI agents in the Seshat BI project. Use when an agent must reason about the BUSINESS MEANING of a retail KPI before any implementation — defining a KPI in business terms, classifying additivity (fully\u002Fsemi\u002Fnon-additive), identifying grain, listing required source fields, resolving ambiguity (gross vs net, VAT, returns, cost method, same-store), choosing an MVP KPI pack, reviewing a metric contract for completeness, or preparing a clean handoff to an implementation layer. Also use it to classify KPI sufficiency or prepare an owner policy decision packet. This is a meaning\u002Fdefinition + review layer, not an executor: it does not write DAX\u002FSQL\u002FPython, grant readiness, approve policy, or design dashboards. See INDEX.md for live\u002Fplanned routes; registry.yaml is the authoritative machine-readable inventory.","https:\u002F\u002Fgithub.com\u002FKemetra\u002FSeshat-BI\u002Fblob\u002Fmain\u002Fskills\u002Fretail-kpi-knowledge\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":18},"01M77JVNDM1NGYGSCPTBW9ZCF5","bi-sql-knowledge","SQL reasoning, validation, reconciliation, transformation, diagnostics, and anti-pattern knowledge layer for Seshat BI agents. Use when a task involves reasoning about source SQL: source profiling, table grain, keys & uniqueness, joins & fan-out amplification, aggregation correctness, COUNT\u002FNULL semantics, deduplication, validation queries, reconciliation queries, silver\u002Fgold transformation logic, window\u002Fdate-time analytics, SQL anti-patterns, or basic SQL performance reasoning, or interpretation of a supplied sanitized PostgreSQL JSON execution plan. The SQL counterpart to bi-dax-knowledge. It is a thinking & validation layer, not a database executor, runtime validator, dbt\u002FDagster project, or automatic tuning service.","https:\u002F\u002Fgithub.com\u002FKemetra\u002FSeshat-BI\u002Fblob\u002Fmain\u002Fskills\u002Fbi-sql-knowledge\u002FSKILL.md",[],[]]