[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BZCNB8EAMPH9SN4ED8VRAP":3,"skill-same:01M6BZCNB8EAMPH9SN4ED8VRAP":70},{"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":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":13,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":56,"install":57,"resources":69},"01M6BZCNB8EAMPH9SN4ED8VRAP","speckit-clarify",null,"Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.","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-clarify\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"speckit","speckit clarify","clarify","structure","true","kit","questions","with","spec-kit","false","feature","commands","project","directory","back","up","templates","specify","encoding","project structure","github","spec","2026-11-10 10:12:30",false,"---\nname: \"speckit-clarify\"\ndescription: \"Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.\"\nargument-hint: \"Optional areas to clarify in the spec\"\ncompatibility: \"Requires spec-kit project structure with .specify\u002F directory\"\nmetadata:\n  author: \"github-spec-kit\"\n  source: \"templates\u002Fcommands\u002Fclarify.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 clarification)**:\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_clarify` 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 Outline.\n    ```\n- If no hooks are registered or `.specify\u002Fextensions.yml` does not exist, skip silently\n\n## Outline\n\nGoal: Detect and reduce ambiguity or missing decision points in the active feature specification and record the clarifications directly in the spec file.\n\nNote: This clarification workflow is expected to run (and be completed) BEFORE invoking `\u002Fspeckit-plan`. If the user explicitly states they are skipping clarification (e.g., exploratory spike), you may proceed, but must warn that downstream rework risk increases.\n\nExecution steps:\n\n1. Run `.specify\u002Fscripts\u002Fbash\u002Fcheck-prerequisites.sh --json --paths-only` from repo root **once** (combined `--json --paths-only` mode \u002F `-Json -PathsOnly`). Parse minimal JSON payload fields:\n   - `FEATURE_DIR`\n   - `FEATURE_SPEC`\n   - (Optionally capture `IMPL_PLAN`, `TASKS` for future chained flows.)\n   - If JSON parsing fails, abort and instruct user to re-run `\u002Fspeckit-specify` or verify feature branch environment.\n   - For 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\n2. Load the current spec file. Perform a structured ambiguity & coverage scan using this taxonomy. For each category, mark status: Clear \u002F Partial \u002F Missing. Produce an internal coverage map used for prioritization (do not output raw map unless no questions will be asked).\n\n   Functional Scope & Behavior:\n   - Core user goals & success criteria\n   - Explicit out-of-scope declarations\n   - User roles \u002F personas differentiation\n\n   Domain & Data Model:\n   - Entities, attributes, relationships\n   - Identity & uniqueness rules\n   - Lifecycle\u002Fstate transitions\n   - Data volume \u002F scale assumptions\n\n   Interaction & UX Flow:\n   - Critical user journeys \u002F sequences\n   - Error\u002Fempty\u002Floading states\n   - Accessibility or localization notes\n\n   Non-Functional Quality Attributes:\n   - Performance (latency, throughput targets)\n   - Scalability (horizontal\u002Fvertical, limits)\n   - Reliability & availability (uptime, recovery expectations)\n   - Observability (logging, metrics, tracing signals)\n   - Security & privacy (authN\u002FZ, data protection, threat assumptions)\n   - Compliance \u002F regulatory constraints (if any)\n\n   Integration & External Dependencies:\n   - External services\u002FAPIs and failure modes\n   - Data import\u002Fexport formats\n   - Protocol\u002Fversioning assumptions\n\n   Edge Cases & Failure Handling:\n   - Negative scenarios\n   - Rate limiting \u002F throttling\n   - Conflict resolution (e.g., concurrent edits)\n\n   Constraints & Tradeoffs:\n   - Technical constraints (language, storage, hosting)\n   - Explicit tradeoffs or rejected alternatives\n\n   Terminology & Consistency:\n   - Canonical glossary terms\n   - Avoided synonyms \u002F deprecated terms\n\n   Completion Signals:\n   - Acceptance criteria testability\n   - Measurable Definition of Done style indicators\n\n   Misc \u002F Placeholders:\n   - TODO markers \u002F unresolved decisions\n   - Ambiguous adjectives (\"robust\", \"intuitive\") lacking quantification\n\n   For each category with Partial or Missing status, add a candidate question opportunity unless:\n   - Clarification would not materially change implementation or validation strategy\n   - Information is better deferred to planning phase (note internally)\n\n3. Generate (internally) a prioritized queue of candidate clarification questions (maximum 5). Do NOT output them all at once. Apply these constraints:\n    - Maximum of 5 total questions across the whole session.\n    - Each question must be answerable with EITHER:\n       - A short multiple‑choice selection (2–5 distinct, mutually exclusive options), OR\n       - A one-word \u002F short‑phrase answer (explicitly constrain: \"Answer in \u003C=5 words\").\n    - Only include questions whose answers materially impact architecture, data modeling, task decomposition, test design, UX behavior, operational readiness, or compliance validation.\n    - Ensure category coverage balance: attempt to cover the highest impact unresolved categories first; avoid asking two low-impact questions when a single high-impact area (e.g., security posture) is unresolved.\n    - Exclude questions already answered, trivial stylistic preferences, or plan-level execution details (unless blocking correctness).\n    - Favor clarifications that reduce downstream rework risk or prevent misaligned acceptance tests.\n    - If more than 5 categories remain unresolved, select the top 5 by (Impact * Uncertainty) heuristic.\n\n4. Sequential questioning loop (interactive):\n    - Present EXACTLY ONE question at a time.\n    - For multiple‑choice questions:\n       - **Analyze all options** and determine the **most suitable option** based on:\n          - Best practices for the project type\n          - Common patterns in similar implementations\n          - Risk reduction (security, performance, maintainability)\n          - Alignment with any explicit project goals or constraints visible in the spec\n       - Present your **recommended option prominently** at the top with clear reasoning (1-2 sentences explaining why this is the best choice).\n       - Format as: `**Recommended:** Option [X] - \u003Creasoning>`\n       - Then render all options as a Markdown table:\n\n       | Option | Description |\n       |--------|-------------|\n       | A | \u003COption A description> |\n       | B | \u003COption B description> |\n       | C | \u003COption C description> (add D\u002FE as needed up to 5) |\n       | Short | Provide a different short answer (\u003C=5 words) (Include only if free-form alternative is appropriate) |\n\n       - After the table, add: `You can reply with the option letter (e.g., \"A\"), accept the recommendation by saying \"yes\" or \"recommended\", or provide your own short answer.`\n    - For short‑answer style (no meaningful discrete options):\n       - Provide your **suggested answer** based on best practices and context.\n       - Format as: `**Suggested:** \u003Cyour proposed answer> - \u003Cbrief reasoning>`\n       - Then output: `Format: Short answer (\u003C=5 words). You can accept the suggestion by saying \"yes\" or \"suggested\", or provide your own answer.`\n    - After the user answers:\n       - If the user replies with \"yes\", \"recommended\", or \"suggested\", use your previously stated recommendation\u002Fsuggestion as the answer.\n       - Otherwise, validate the answer maps to one option or fits the \u003C=5 word constraint.\n       - If ambiguous, ask for a quick disambiguation (count still belongs to same question; do not advance).\n       - Once satisfactory, record it in working memory (do not yet write to disk) and move to the next queued question.\n    - Stop asking further questions when:\n       - All critical ambiguities resolved early (remaining queued items become unnecessary), OR\n       - User signals completion (\"done\", \"good\", \"no more\"), OR\n       - You reach 5 asked questions.\n    - Never reveal future queued questions in advance.\n    - If no valid questions exist at start, immediately report no critical ambiguities.\n\n5. Integration after EACH accepted answer (incremental update approach):\n    - Maintain in-memory representation of the spec (loaded once at start) plus the raw file contents.\n    - For the first integrated answer in this session:\n       - Ensure a `## Clarifications` section exists (create it just after the highest-level contextual\u002Foverview section per the spec template if missing).\n       - Under it, create (if not present) a `### Session YYYY-MM-DD` subheading for today.\n    - Append a bullet line immediately after acceptance: `- Q: \u003Cquestion> → A: \u003Cfinal answer>`.\n    - Then immediately apply the clarification to the most appropriate section(s):\n       - Functional ambiguity → Update or add a bullet in Functional Requirements.\n       - User interaction \u002F actor distinction → Update User Stories or Actors subsection (if present) with clarified role, constraint, or scenario.\n       - Data shape \u002F entities → Update Data Model (add fields, types, relationships) preserving ordering; note added constraints succinctly.\n       - Non-functional constraint → Add\u002Fmodify measurable criteria in Success Criteria > Measurable Outcomes (convert vague adjective to metric or explicit target).\n       - Edge case \u002F negative flow → Add a new bullet under Edge Cases \u002F Error Handling (or create such subsection if template provides placeholder for it).\n       - Terminology conflict → Normalize term across spec; retain original only if necessary by adding `(formerly referred to as \"X\")` once.\n    - If the clarification invalidates an earlier ambiguous statement, replace that statement instead of duplicating; leave no obsolete contradictory text.\n    - Save the spec file AFTER each integration to minimize risk of context loss (atomic overwrite).\n    - Preserve formatting: do not reorder unrelated sections; keep heading hierarchy intact.\n    - Keep each inserted clarification minimal and testable (avoid narrative drift).\n\n6. Validation (performed after EACH write plus final pass):\n   - Clarifications session contains exactly one bullet per accepted answer (no duplicates).\n   - Total asked (accepted) questions ≤ 5.\n   - Updated sections contain no lingering vague placeholders the new answer was meant to resolve.\n   - No contradictory earlier statement remains (scan for now-invalid alternative choices removed).\n   - Markdown structure valid; only allowed new headings: `## Clarifications`, `### Session YYYY-MM-DD`.\n   - Terminology consistency: same canonical term used across all updated sections.\n\n7. Write the updated spec back to `FEATURE_SPEC`.\n\n8. Report completion (after questioning loop ends or early termination):\n   - Number of questions asked & answered.\n   - Path to updated spec.\n   - Sections touched (list names).\n   - Coverage summary table listing each taxonomy category with Status: Resolved (was Partial\u002FMissing and addressed), Deferred (exceeds question quota or better suited for planning), Clear (already sufficient), Outstanding (still Partial\u002FMissing but low impact).\n   - If any Outstanding or Deferred remain, recommend whether to proceed to `\u002Fspeckit-plan` or run `\u002Fspeckit-clarify` again later post-plan.\n   - Suggested next command.\n\nBehavior rules:\n\n- If no meaningful ambiguities found (or all potential questions would be low-impact), respond: \"No critical ambiguities detected worth formal clarification.\" and suggest proceeding.\n- If spec file missing, instruct user to run `\u002Fspeckit-specify` first (do not create a new spec here).\n- Never exceed 5 total asked questions (clarification retries for a single question do not count as new questions).\n- Avoid speculative tech stack questions unless the absence blocks functional clarity.\n- Respect user early termination signals (\"stop\", \"done\", \"proceed\").\n- If no questions asked due to full coverage, output a compact coverage summary (all categories Clear) then suggest advancing.\n- If quota reached with unresolved high-impact categories remaining, explicitly flag them under Deferred with rationale.\n\nContext for prioritization: $ARGUMENTS\n\n## Post-Execution Checks\n\n**Check for extension hooks (after clarification)**:\nCheck if `.specify\u002Fextensions.yml` exists in the project root.\n- If it exists, read it and look for entries under the `hooks.after_clarify` 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","## 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 clarification)**:\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_clarify` 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 Outline.\n    ```\n- If no hooks are registered or `.specify\u002Fextensions.yml` does not exist, skip silently\n\n## Outline\n\nGoal: Detect and reduce ambiguity or missing decision points in the active feature specification and record the clarifications directly in the spec file.\n\nNote: This clarification workflow is expected to run (and be completed) BEFORE invoking `\u002Fspeckit-plan`. If the user explicitly states they are skipping clarification (e.g., exploratory spike), you may proceed, but must warn that downstream rework risk increases.\n\nExecution steps:\n\n1. Run `.specify\u002Fscripts\u002Fbash\u002Fcheck-prerequisites.sh --json --paths-only` from repo root **once** (combined `--json --paths-only` mode \u002F `-Json -PathsOnly`). Parse minimal JSON payload fields:\n   - `FEATURE_DIR`\n   - `FEATURE_SPEC`\n   - (Optionally capture `IMPL_PLAN`, `TASKS` for future chained flows.)\n   - If JSON parsing fails, abort and instruct user to re-run `\u002Fspeckit-specify` or verify feature branch environment.\n   - For 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\n2. Load the current spec file. Perform a structured ambiguity & coverage scan using this taxonomy. For each category, mark status: Clear \u002F Partial \u002F Missing. Produce an internal coverage map used for prioritization (do not output raw map unless no questions will be asked).\n\n   Functional Scope & Behavior:\n   - Core user goals & success criteria\n   - Explicit out-of-scope declarations\n   - User roles \u002F personas differentiation\n\n   Domain & Data Model:\n   - Entities, attributes, relationships\n   - Identity & uniqueness rules\n   - Lifecycle\u002Fstate transitions\n   - Data volume \u002F scale assumptions\n\n   Interaction & UX Flow:\n   - Critical user journeys \u002F sequences\n   - Error\u002Fempty\u002Floading states\n   - Accessibility or localization notes\n\n   Non-Functional Quality Attributes:\n   - Performance (latency, throughput targets)\n   - Scalability (horizontal\u002Fvertical, limits)\n   - Reliability & availability (uptime, recovery expectations)\n   - Observability (logging, metrics, tracing signals)\n   - Security & privacy (authN\u002FZ, data protection, threat assumptions)\n   - Compliance \u002F regulatory constraints (if any)\n\n   Integration & External Dependencies:\n   - External services\u002FAPIs and failure modes\n   - Data import\u002Fexport formats\n   - Protocol\u002Fversioning assumptions\n\n   Edge Cases & Failure Handling:\n   - Negative scenarios\n   - Rate limiting \u002F throttling\n   - Conflict resolution (e.g., concurrent edits)\n\n   Constraints & Tradeoffs:\n   - Technical constraints (language, storage, hosting)\n   - Explicit tradeoffs or rejected alternatives\n\n   Terminology & Consistency:\n   - Canonical glossary terms\n   - Avoided synonyms \u002F deprecated terms\n\n   Completion Signals:\n   - Acceptance criteria testability\n   - Measurable Definition of Done style indicators\n\n   Misc \u002F Placeholders:\n   - TODO markers \u002F unresolved decisions\n   - Ambiguous adjectives (\"robust\", \"intuitive\") lacking quantification\n\n   For each category with Partial or Missing status, add a candidate question opportunity unless:\n   - Clarification would not materially change implementation or validation strategy\n   - Information is better deferred to planning phase (note internally)\n\n3. Generate (internally) a prioritized queue of candidate clarification questions (maximum 5). Do NOT output them all at once. Apply these constraints:\n    - Maximum of 5 total questions across the whole session.\n    - Each question must be answerable with EITHER:\n       - A short multiple‑choice selection (2–5 distinct, mutually exclusive options), OR\n       - A one-word \u002F short‑phrase answer (explicitly constrain: \"Answer in \u003C=5 words\").\n    - Only include questions whose answers materially impact architecture, data modeling, task decomposition, test design, UX behavior, operational readiness, or compliance validation.\n    - Ensure category coverage balance: attempt to cover the highest impact unresolved categories first; avoid asking two low-impact questions when a single high-impact area (e.g., security posture) is unresolved.\n    - Exclude questions already answered, trivial stylistic preferences, or plan-level execution details (unless blocking correctness).\n    - Favor clarifications that reduce downstream rework risk or prevent misaligned acceptance tests.\n    - If more than 5 categories remain unresolved, select the top 5 by (Impact * Uncertainty) heuristic.\n\n4. Sequential questioning loop (interactive):\n    - Present EXACTLY ONE question at a time.\n    - For multiple‑choice questions:\n       - **Analyze all options** and determine the **most suitable option** based on:\n          - Best practices for the project type\n          - Common patterns in similar implementations\n          - Risk reduction (security, performance, maintainability)\n          - Alignment with any explicit project goals or constraints visible in the spec\n       - Present your **recommended option prominently** at the top with clear reasoning (1-2 sentences explaining why this is the best choice).\n       - Format as: `**Recommended:** Option [X] - \u003Creasoning>`\n       - Then render all options as a Markdown table:\n\n       | Option | Description |\n       |--------|-------------|\n       | A | \u003COption A description> |\n       | B | \u003COption B description> |\n       | C | \u003COption C description> (add D\u002FE as needed up to 5) |\n       | Short | Provide a different short answer (\u003C=5 words) (Include only if free-form alternative is appropriate) |\n\n       - After the table, add: `You can reply with the option letter (e.g., \"A\"), accept the recommendation by saying \"yes\" or \"recommended\", or provide your own short answer.`\n    - For short‑answer style (no meaningful discrete options):\n       - Provide your **suggested answer** based on best practices and context.\n       - Format as: `**Suggested:** \u003Cyour proposed answer> - \u003Cbrief reasoning>`\n       - Then output: `Format: Short answer (\u003C=5 words). You can accept the suggestion by saying \"yes\" or \"suggested\", or provide your own answer.`\n    - After the user answers:\n       - If the user replies with \"yes\", \"recommended\", or \"suggested\", use your previously stated recommendation\u002Fsuggestion as the answer.\n       - Otherwise, validate the answer maps to one option or fits the \u003C=5 word constraint.\n       - If ambiguous, ask for a quick disambiguation (count still belongs to same question; do not advance).\n       - Once satisfactory, record it in working memory (do not yet write to disk) and move to the next queued question.\n    - Stop asking further questions when:\n       - All critical ambiguities resolved early (remaining queued items become unnecessary), OR\n       - User signals completion (\"done\", \"good\", \"no more\"), OR\n       - You reach 5 asked questions.\n    - Never reveal future queued questions in advance.\n    - If no valid questions exist at start, immediately report no critical ambiguities.\n\n5. Integration after EACH accepted answer (incremental update approach):\n    - Maintain in-memory representation of the spec (loaded once at start) plus the raw file contents.\n    - For the first integrated answer in this session:\n       - Ensure a `## Clarifications` section exists (create it just after the highest-level contextual\u002Foverview section per the spec template if missing).\n       - Under it, create (if not present) a `### Session YYYY-MM-DD` subheading for today.\n    - Append a bullet line immediately after acceptance: `- Q: \u003Cquestion> → A: \u003Cfinal answer>`.\n    - Then immediately apply the clarification to the most appropriate section(s):\n       - Functional ambiguity → Update or add a bullet in Functional Requirements.\n       - User interaction \u002F actor distinction → Update User Stories or Actors subsection (if present) with clarified role, constraint, or scenario.\n       - Data shape \u002F entities → Update Data Model (add fields, types, relationships) preserving ordering; note added constraints succinctly.\n       - Non-functional constraint → Add\u002Fmodify measurable criteria in Success Criteria > Measurable Outcomes (convert vague adjective to metric or explicit target).\n       - Edge case \u002F negative flow → Add a new bullet under Edge Cases \u002F Error Handling (or create such subsection if template provides placeholder for it).\n       - Terminology conflict → Normalize term across spec; retain original only if necessary by adding `(formerly referred to as \"X\")` once.\n    - If the clarification invalidates an earlier ambiguous statement, replace that statement instead of duplicating; leave no obsolete contradictory text.\n    - Save the spec file AFTER each integration to minimize risk of context loss (atomic overwrite).\n    - Preserve formatting: do not reorder unrelated sections; keep heading hierarchy intact.\n    - Keep each inserted clarification minimal and testable (avoid narrative drift).\n\n6. Validation (performed after EACH write plus final pass):\n   - Clarifications session contains exactly one bullet per accepted answer (no duplicates).\n   - Total asked (accepted) questions ≤ 5.\n   - Updated sections contain no lingering vague placeholders the new answer was meant to resolve.\n   - No contradictory earlier statement remains (scan for now-invalid alternative choices removed).\n   - Markdown structure valid; only allowed new headings: `## Clarifications`, `### Session YYYY-MM-DD`.\n   - Terminology consistency: same canonical term used across all updated sections.\n\n7. Write the updated spec back to `FEATURE_SPEC`.\n\n8. Report completion (after questioning loop ends or early termination):\n   - Number of questions asked & answered.\n   - Path to updated spec.\n   - Sections touched (list names).\n   - Coverage summary table listing each taxonomy category with Status: Resolved (was Partial\u002FMissing and addressed), Deferred (exceeds question quota or better suited for planning), Clear (already sufficient), Outstanding (still Partial\u002FMissing but low impact).\n   - If any Outstanding or Deferred remain, recommend whether to proceed to `\u002Fspeckit-plan` or run `\u002Fspeckit-clarify` again later post-plan.\n   - Suggested next command.\n\nBehavior rules:\n\n- If no meaningful ambiguities found (or all potential questions would be low-impact), respond: \"No critical ambiguities detected worth formal clarification.\" and suggest proceeding.\n- If spec file missing, instruct user to run `\u002Fspeckit-specify` first (do not create a new spec here).\n- Never exceed 5 total asked questions (clarification retries for a single question do not count as new questions).\n- Avoid speculative tech stack questions unless the absence blocks functional clarity.\n- Respect user early termination signals (\"stop\", \"done\", \"proceed\").\n- If no questions asked due to full coverage, output a compact coverage summary (all categories Clear) then suggest advancing.\n- If quota reached with unresolved high-impact categories remaining, explicitly flag them under Deferred with rationale.\n\nContext for prioritization: $ARGUMENTS\n\n## Post-Execution Checks\n\n**Check for extension hooks (after clarification)**:\nCheck if `.specify\u002Fextensions.yml` exists in the project root.\n- If it exists, read it and look for entries under the `hooks.after_clarify` 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",{"name":5,"metadata":45,"description":7,"argument-hint":48,"compatibility":49,"user-invocable":50,"disable-model-invocation":41},{"author":46,"source":47},"github-spec-kit","templates\u002Fcommands\u002Fclarify.md","Optional areas to clarify in the spec","Requires spec-kit project structure with .specify\u002F directory",true,"main","dfa90715374d68e7cc21cb1429b99d9f054865e5",".claude\u002Fskills\u002Fspeckit-clarify","https:\u002F\u002Fgithub.com\u002Faulaleslie\u002Ftiga-saudara-ERP","https:\u002F\u002Fgithub.com\u002Faulaleslie","2026-11-11 04:12:37",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":50},[59,62,65],{"tool":60,"command":61},"npx","npx skills add aulaleslie\u002Ftiga-saudara-ERP --skill speckit-clarify",{"tool":63,"command":64},"bunx","bunx skills add aulaleslie\u002Ftiga-saudara-ERP --skill speckit-clarify",{"tool":66,"command":67},"pnpm","pnpm dlx skills add aulaleslie\u002Ftiga-saudara-ERP --skill speckit-clarify","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Faulaleslie\u002Ftiga-saudara-ERP\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fspeckit-clarify\u002FSKILL.md",[],[71,79,88,96,105,114],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":40},"01M6BZEH108XYP7CVAEZ6EKQDK","speckit-taskstoissues","speckit.taskstoissues","https:\u002F\u002Fgithub.com\u002Faulaleslie\u002Ftiga-saudara-ERP\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fspeckit-taskstoissues\u002FSKILL.md",[],[78,18,22],"speckit taskstoissues",{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":40},"01M6BZEG279XMX5T2JJSCN0KPY","speckit-tasks","speckit.tasks","https:\u002F\u002Fgithub.com\u002Faulaleslie\u002Ftiga-saudara-ERP\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fspeckit-tasks\u002FSKILL.md",[],[18,86,87,22],"speckit tasks","tasks",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":40},"01M6BZEF4AVDCSBAWM94RVZXPK","speckit-specify","speckit.specify","https:\u002F\u002Fgithub.com\u002Faulaleslie\u002Ftiga-saudara-ERP\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fspeckit-specify\u002FSKILL.md",[],[18,95,35,22],"speckit specify",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":40},"01M6BZEE4Y943HB0TTK3WATPC7","speckit-plan","speckit.plan","https:\u002F\u002Fgithub.com\u002Faulaleslie\u002Ftiga-saudara-ERP\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fspeckit-plan\u002FSKILL.md",[],[103,18,104,22],"speckit plan","plan",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":40},"01M6BZED6FJBQS98EG264A7TDF","speckit-implement","speckit.implement","https:\u002F\u002Fgithub.com\u002Faulaleslie\u002Ftiga-saudara-ERP\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fspeckit-implement\u002FSKILL.md",[],[18,112,113,22],"speckit implement","implement",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":40},"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",[],[121,18,122,123,22],"validate","speckit git validate","git"]