[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BZCH1G5J3J7ERCBEWRYHGG":3,"skill-same:01M6BZCH1G5J3J7ERCBEWRYHGG":72},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":13,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":71},"01M6BZCH1G5J3J7ERCBEWRYHGG","speckit-analyze",null,"Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.","aulaleslie\u002Ftiga-saudara-ERP","aulaleslie","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F134106027?v=4","01M6BZAMW9CS4RHAM5VZXR4T2B","01M6BZAN0CDB291GCMKPBYGA2B",0,"MIT","https:\u002F\u002Fgithub.com\u002Faulaleslie\u002Ftiga-saudara-ERP\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fspeckit-analyze\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"speckit","analyze","speckit analyze","structure","for","kit","consistency","artifact consistency","false","commands","project","across","focus","artifact","directory","quality","plan","analysis","templates","specify","tasks","project structure","github","spec","2026-11-10 10:12:30",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\u002Fbash\u002Fcheck-prerequisites.sh --json --require-tasks --include-tasks` 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\u002Fbash\u002Fcheck-prerequisites.sh --json --require-tasks --include-tasks` 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":47,"description":7,"argument-hint":50,"compatibility":51,"user-invocable":52,"disable-model-invocation":43},{"author":48,"source":49},"github-spec-kit","templates\u002Fcommands\u002Fanalyze.md","Optional focus areas for analysis","Requires spec-kit project structure with .specify\u002F directory",true,"main","dfa90715374d68e7cc21cb1429b99d9f054865e5",".claude\u002Fskills\u002Fspeckit-analyze","https:\u002F\u002Fgithub.com\u002Faulaleslie\u002Ftiga-saudara-ERP","https:\u002F\u002Fgithub.com\u002Faulaleslie","2026-11-12 22:33:18",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":52},[61,64,67],{"tool":62,"command":63},"npx","npx skills add aulaleslie\u002Ftiga-saudara-ERP --skill speckit-analyze",{"tool":65,"command":66},"bunx","bunx skills add aulaleslie\u002Ftiga-saudara-ERP --skill speckit-analyze",{"tool":68,"command":69},"pnpm","pnpm dlx skills add aulaleslie\u002Ftiga-saudara-ERP --skill speckit-analyze","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Faulaleslie\u002Ftiga-saudara-ERP\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fspeckit-analyze\u002FSKILL.md",[],[73,82,90,98,106,115],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":42},"01M6BZEH108XYP7CVAEZ6EKQDK","speckit-taskstoissues","speckit.taskstoissues","https:\u002F\u002Fgithub.com\u002Faulaleslie\u002Ftiga-saudara-ERP\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fspeckit-taskstoissues\u002FSKILL.md",[],[80,18,81],"speckit taskstoissues","true",{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":42},"01M6BZEG279XMX5T2JJSCN0KPY","speckit-tasks","speckit.tasks","https:\u002F\u002Fgithub.com\u002Faulaleslie\u002Ftiga-saudara-ERP\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fspeckit-tasks\u002FSKILL.md",[],[18,89,38,81],"speckit tasks",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":42},"01M6BZEF4AVDCSBAWM94RVZXPK","speckit-specify","speckit.specify","https:\u002F\u002Fgithub.com\u002Faulaleslie\u002Ftiga-saudara-ERP\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fspeckit-specify\u002FSKILL.md",[],[18,97,37,81],"speckit specify",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":42},"01M6BZEE4Y943HB0TTK3WATPC7","speckit-plan","speckit.plan","https:\u002F\u002Fgithub.com\u002Faulaleslie\u002Ftiga-saudara-ERP\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fspeckit-plan\u002FSKILL.md",[],[105,18,34,81],"speckit plan",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":42},"01M6BZED6FJBQS98EG264A7TDF","speckit-implement","speckit.implement","https:\u002F\u002Fgithub.com\u002Faulaleslie\u002Ftiga-saudara-ERP\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fspeckit-implement\u002FSKILL.md",[],[18,113,114,81],"speckit implement","implement",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":42},"01M6BZEBZJEEH16CTTSQCSYAK9","speckit-git-validate","speckit.git.validate","https:\u002F\u002Fgithub.com\u002Faulaleslie\u002Ftiga-saudara-ERP\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fspeckit-git-validate\u002FSKILL.md",[],[122,18,123,124,81],"validate","speckit git validate","git"]