[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KMWQZFHKDQRVC3KBJP8MBY":3,"skill-same:01M6KMWQZFHKDQRVC3KBJP8MBY":71},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":6,"updatedAt":57,"install":58,"resources":70},"01M6KMWQZFHKDQRVC3KBJP8MBY","speckit-tasks",null,"Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts.","AI-native-Systems-Research\u002Fai-native-storage-certus","AI-native-Systems-Research","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F270755458?v=4","01M6KKQWSJX0D4X33E0KKSR4WM","AI-native Systems Research","01M6KKQWXTKR6MYVQMPKVJ5WD5",3,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FAI-native-Systems-Research\u002Fai-native-storage-certus\u002Fblob\u002Funstable\u002Fcomponents\u002Fdispatcher-p2p\u002F.claude\u002Fskills\u002Fspeckit-tasks\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"tasks","speckit tasks","speckit","generation","for","true","kit","with","spec-kit","actionable","false","feature","design","project","structure","task","specify","artifacts","project structure","github","2026-11-10 10:12:30",false,"---\nname: \"speckit-tasks\"\ndescription: \"Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts.\"\nargument-hint: \"Optional task generation constraints\"\ncompatibility: \"Requires spec-kit project structure with .specify\u002F directory\"\nmetadata:\n  author: \"github-spec-kit\"\n  source: \"templates\u002Fcommands\u002Ftasks.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 tasks generation)**:\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_tasks` 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\n1. **Setup**: Run `.specify\u002Fscripts\u002Fbash\u002Fsetup-tasks.sh --json` from repo root and parse FEATURE_DIR, TASKS_TEMPLATE, and AVAILABLE_DOCS list. `FEATURE_DIR` and `TASKS_TEMPLATE` must be absolute paths when provided. `AVAILABLE_DOCS` is a list of document names\u002Frelative paths available under `FEATURE_DIR` (for example `research.md` or `contracts\u002F`). 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 design documents**: Read from FEATURE_DIR:\n   - **Required**: plan.md (tech stack, libraries, structure), spec.md (user stories with priorities)\n   - **Optional**: data-model.md (entities), contracts\u002F (interface contracts), research.md (decisions), quickstart.md (test scenarios)\n   - **IF EXISTS**: Load `.specify\u002Fmemory\u002Fconstitution.md` for project principles and governance constraints\n   - Note: Not all projects have all documents. Generate tasks based on what's available.\n\n3. **Execute task generation workflow**:\n   - Load plan.md and extract tech stack, libraries, project structure\n   - Load spec.md and extract user stories with their priorities (P1, P2, P3, etc.)\n   - If data-model.md exists: Extract entities and map to user stories\n   - If contracts\u002F exists: Map interface contracts to user stories\n   - If research.md exists: Extract decisions for setup tasks\n   - Generate tasks organized by user story (see Task Generation Rules below)\n   - Generate dependency graph showing user story completion order\n   - Create parallel execution examples per user story\n   - Validate task completeness (each user story has all needed tasks, independently testable)\n\n4. **Generate tasks.md**: Read the tasks template from TASKS_TEMPLATE (from the JSON output above) and use it as structure. If TASKS_TEMPLATE is empty, fall back to `.specify\u002Ftemplates\u002Ftasks-template.md`. Fill with:\n   - Correct feature name from plan.md\n   - Phase 1: Setup tasks (project initialization)\n   - Phase 2: Foundational tasks (blocking prerequisites for all user stories)\n   - Phase 3+: One phase per user story (in priority order from spec.md)\n   - Each phase includes: story goal, independent test criteria, tests (if requested), implementation tasks\n   - Final Phase: Polish & cross-cutting concerns\n   - All tasks must follow the strict checklist format (see Task Generation Rules below)\n   - Clear file paths for each task\n   - Dependencies section showing story completion order\n   - Parallel execution examples per story\n   - Implementation strategy section (MVP first, incremental delivery)\n\n## Mandatory Post-Execution Hooks\n\n**You MUST complete this section before reporting completion to the user.**\n\nCheck if `.specify\u002Fextensions.yml` exists in the project root.\n- If it does not exist, or no hooks are registered under `hooks.after_tasks`, skip to the Completion Report.\n- If it exists, read it and look for entries under the `hooks.after_tasks` key.\n- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue to the Completion Report.\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  - **Mandatory hook** (`optional: false`) — **You MUST emit `EXECUTE_COMMAND:` for each mandatory hook**:\n    ```\n    ## Extension Hooks\n\n    **Automatic Hook**: {extension}\n    Executing: `\u002F{command}`\n    EXECUTE_COMMAND: {command}\n    ```\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\n## Completion Report\n\nOutput path to generated tasks.md and summary:\n- Total task count\n- Task count per user story\n- Parallel opportunities identified\n- Independent test criteria for each story\n- Suggested MVP scope (typically just User Story 1)\n- Format validation: Confirm ALL tasks follow the checklist format (checkbox, ID, labels, file paths)\n\nContext for task generation: $ARGUMENTS\n\nThe tasks.md should be immediately executable - each task must be specific enough that an LLM can complete it without additional context.\n\n## Task Generation Rules\n\n**CRITICAL**: Tasks MUST be organized by user story to enable independent implementation and testing.\n\n**Tests are OPTIONAL**: Only generate test tasks if explicitly requested in the feature specification or if user requests TDD approach.\n\n### Checklist Format (REQUIRED)\n\nEvery task MUST strictly follow this format:\n\n```text\n- [ ] [TaskID] [P?] [Story?] Description with file path\n```\n\n**Format Components**:\n\n1. **Checkbox**: ALWAYS start with `- [ ]` (markdown checkbox)\n2. **Task ID**: Sequential number (T001, T002, T003...) in execution order\n3. **[P] marker**: Include ONLY if task is parallelizable (different files, no dependencies on incomplete tasks)\n4. **[Story] label**: REQUIRED for user story phase tasks only\n   - Format: [US1], [US2], [US3], etc. (maps to user stories from spec.md)\n   - Setup phase: NO story label\n   - Foundational phase: NO story label  \n   - User Story phases: MUST have story label\n   - Polish phase: NO story label\n5. **Description**: Clear action with exact file path\n\n**Examples**:\n\n- ✅ CORRECT: `- [ ] T001 Create project structure per implementation plan`\n- ✅ CORRECT: `- [ ] T005 [P] Implement authentication middleware in src\u002Fmiddleware\u002Fauth.py`\n- ✅ CORRECT: `- [ ] T012 [P] [US1] Create User model in src\u002Fmodels\u002Fuser.py`\n- ✅ CORRECT: `- [ ] T014 [US1] Implement UserService in src\u002Fservices\u002Fuser_service.py`\n- ❌ WRONG: `- [ ] Create User model` (missing ID and Story label)\n- ❌ WRONG: `T001 [US1] Create model` (missing checkbox)\n- ❌ WRONG: `- [ ] [US1] Create User model` (missing Task ID)\n- ❌ WRONG: `- [ ] T001 [US1] Create model` (missing file path)\n\n### Task Organization\n\n1. **From User Stories (spec.md)** - PRIMARY ORGANIZATION:\n   - Each user story (P1, P2, P3...) gets its own phase\n   - Map all related components to their story:\n     - Models needed for that story\n     - Services needed for that story\n     - Interfaces\u002FUI needed for that story\n     - If tests requested: Tests specific to that story\n   - Mark story dependencies (most stories should be independent)\n\n2. **From Contracts**:\n   - Map each interface contract → to the user story it serves\n   - If tests requested: Each interface contract → contract test task [P] before implementation in that story's phase\n\n3. **From Data Model**:\n   - Map each entity to the user story(ies) that need it\n   - If entity serves multiple stories: Put in earliest story or Setup phase\n   - Relationships → service layer tasks in appropriate story phase\n\n4. **From Setup\u002FInfrastructure**:\n   - Shared infrastructure → Setup phase (Phase 1)\n   - Foundational\u002Fblocking tasks → Foundational phase (Phase 2)\n   - Story-specific setup → within that story's phase\n\n### Phase Structure\n\n- **Phase 1**: Setup (project initialization)\n- **Phase 2**: Foundational (blocking prerequisites - MUST complete before user stories)\n- **Phase 3+**: User Stories in priority order (P1, P2, P3...)\n  - Within each story: Tests (if requested) → Models → Services → Endpoints → Integration\n  - Each phase should be a complete, independently testable increment\n- **Final Phase**: Polish & Cross-Cutting Concerns\n\n## Done When\n\n- [ ] tasks.md generated with all phases, task IDs, and file paths\n- [ ] Extension hooks dispatched or skipped according to the rules in Mandatory Post-Execution Hooks above\n- [ ] Completion reported to user with task count, story breakdown, and MVP scope\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 tasks generation)**:\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_tasks` 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\n1. **Setup**: Run `.specify\u002Fscripts\u002Fbash\u002Fsetup-tasks.sh --json` from repo root and parse FEATURE_DIR, TASKS_TEMPLATE, and AVAILABLE_DOCS list. `FEATURE_DIR` and `TASKS_TEMPLATE` must be absolute paths when provided. `AVAILABLE_DOCS` is a list of document names\u002Frelative paths available under `FEATURE_DIR` (for example `research.md` or `contracts\u002F`). 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 design documents**: Read from FEATURE_DIR:\n   - **Required**: plan.md (tech stack, libraries, structure), spec.md (user stories with priorities)\n   - **Optional**: data-model.md (entities), contracts\u002F (interface contracts), research.md (decisions), quickstart.md (test scenarios)\n   - **IF EXISTS**: Load `.specify\u002Fmemory\u002Fconstitution.md` for project principles and governance constraints\n   - Note: Not all projects have all documents. Generate tasks based on what's available.\n\n3. **Execute task generation workflow**:\n   - Load plan.md and extract tech stack, libraries, project structure\n   - Load spec.md and extract user stories with their priorities (P1, P2, P3, etc.)\n   - If data-model.md exists: Extract entities and map to user stories\n   - If contracts\u002F exists: Map interface contracts to user stories\n   - If research.md exists: Extract decisions for setup tasks\n   - Generate tasks organized by user story (see Task Generation Rules below)\n   - Generate dependency graph showing user story completion order\n   - Create parallel execution examples per user story\n   - Validate task completeness (each user story has all needed tasks, independently testable)\n\n4. **Generate tasks.md**: Read the tasks template from TASKS_TEMPLATE (from the JSON output above) and use it as structure. If TASKS_TEMPLATE is empty, fall back to `.specify\u002Ftemplates\u002Ftasks-template.md`. Fill with:\n   - Correct feature name from plan.md\n   - Phase 1: Setup tasks (project initialization)\n   - Phase 2: Foundational tasks (blocking prerequisites for all user stories)\n   - Phase 3+: One phase per user story (in priority order from spec.md)\n   - Each phase includes: story goal, independent test criteria, tests (if requested), implementation tasks\n   - Final Phase: Polish & cross-cutting concerns\n   - All tasks must follow the strict checklist format (see Task Generation Rules below)\n   - Clear file paths for each task\n   - Dependencies section showing story completion order\n   - Parallel execution examples per story\n   - Implementation strategy section (MVP first, incremental delivery)\n\n## Mandatory Post-Execution Hooks\n\n**You MUST complete this section before reporting completion to the user.**\n\nCheck if `.specify\u002Fextensions.yml` exists in the project root.\n- If it does not exist, or no hooks are registered under `hooks.after_tasks`, skip to the Completion Report.\n- If it exists, read it and look for entries under the `hooks.after_tasks` key.\n- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue to the Completion Report.\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  - **Mandatory hook** (`optional: false`) — **You MUST emit `EXECUTE_COMMAND:` for each mandatory hook**:\n    ```\n    ## Extension Hooks\n\n    **Automatic Hook**: {extension}\n    Executing: `\u002F{command}`\n    EXECUTE_COMMAND: {command}\n    ```\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\n## Completion Report\n\nOutput path to generated tasks.md and summary:\n- Total task count\n- Task count per user story\n- Parallel opportunities identified\n- Independent test criteria for each story\n- Suggested MVP scope (typically just User Story 1)\n- Format validation: Confirm ALL tasks follow the checklist format (checkbox, ID, labels, file paths)\n\nContext for task generation: $ARGUMENTS\n\nThe tasks.md should be immediately executable - each task must be specific enough that an LLM can complete it without additional context.\n\n## Task Generation Rules\n\n**CRITICAL**: Tasks MUST be organized by user story to enable independent implementation and testing.\n\n**Tests are OPTIONAL**: Only generate test tasks if explicitly requested in the feature specification or if user requests TDD approach.\n\n### Checklist Format (REQUIRED)\n\nEvery task MUST strictly follow this format:\n\n```text\n- [ ] [TaskID] [P?] [Story?] Description with file path\n```\n\n**Format Components**:\n\n1. **Checkbox**: ALWAYS start with `- [ ]` (markdown checkbox)\n2. **Task ID**: Sequential number (T001, T002, T003...) in execution order\n3. **[P] marker**: Include ONLY if task is parallelizable (different files, no dependencies on incomplete tasks)\n4. **[Story] label**: REQUIRED for user story phase tasks only\n   - Format: [US1], [US2], [US3], etc. (maps to user stories from spec.md)\n   - Setup phase: NO story label\n   - Foundational phase: NO story label  \n   - User Story phases: MUST have story label\n   - Polish phase: NO story label\n5. **Description**: Clear action with exact file path\n\n**Examples**:\n\n- ✅ CORRECT: `- [ ] T001 Create project structure per implementation plan`\n- ✅ CORRECT: `- [ ] T005 [P] Implement authentication middleware in src\u002Fmiddleware\u002Fauth.py`\n- ✅ CORRECT: `- [ ] T012 [P] [US1] Create User model in src\u002Fmodels\u002Fuser.py`\n- ✅ CORRECT: `- [ ] T014 [US1] Implement UserService in src\u002Fservices\u002Fuser_service.py`\n- ❌ WRONG: `- [ ] Create User model` (missing ID and Story label)\n- ❌ WRONG: `T001 [US1] Create model` (missing checkbox)\n- ❌ WRONG: `- [ ] [US1] Create User model` (missing Task ID)\n- ❌ WRONG: `- [ ] T001 [US1] Create model` (missing file path)\n\n### Task Organization\n\n1. **From User Stories (spec.md)** - PRIMARY ORGANIZATION:\n   - Each user story (P1, P2, P3...) gets its own phase\n   - Map all related components to their story:\n     - Models needed for that story\n     - Services needed for that story\n     - Interfaces\u002FUI needed for that story\n     - If tests requested: Tests specific to that story\n   - Mark story dependencies (most stories should be independent)\n\n2. **From Contracts**:\n   - Map each interface contract → to the user story it serves\n   - If tests requested: Each interface contract → contract test task [P] before implementation in that story's phase\n\n3. **From Data Model**:\n   - Map each entity to the user story(ies) that need it\n   - If entity serves multiple stories: Put in earliest story or Setup phase\n   - Relationships → service layer tasks in appropriate story phase\n\n4. **From Setup\u002FInfrastructure**:\n   - Shared infrastructure → Setup phase (Phase 1)\n   - Foundational\u002Fblocking tasks → Foundational phase (Phase 2)\n   - Story-specific setup → within that story's phase\n\n### Phase Structure\n\n- **Phase 1**: Setup (project initialization)\n- **Phase 2**: Foundational (blocking prerequisites - MUST complete before user stories)\n- **Phase 3+**: User Stories in priority order (P1, P2, P3...)\n  - Within each story: Tests (if requested) → Models → Services → Endpoints → Integration\n  - Each phase should be a complete, independently testable increment\n- **Final Phase**: Polish & Cross-Cutting Concerns\n\n## Done When\n\n- [ ] tasks.md generated with all phases, task IDs, and file paths\n- [ ] Extension hooks dispatched or skipped according to the rules in Mandatory Post-Execution Hooks above\n- [ ] Completion reported to user with task count, story breakdown, and MVP scope\n",{"name":5,"metadata":44,"description":7,"argument-hint":47,"compatibility":48,"user-invocable":49,"disable-model-invocation":40},{"author":45,"source":46},"github-spec-kit","templates\u002Fcommands\u002Ftasks.md","Optional task generation constraints","Requires spec-kit project structure with .specify\u002F directory",true,"unstable","dc564aa356769b7754391c9fa4fdaa0f179f476c","components\u002Fdispatcher-p2p\u002F.claude\u002Fskills\u002Fspeckit-tasks",4,"https:\u002F\u002Fgithub.com\u002FAI-native-Systems-Research\u002Fai-native-storage-certus","https:\u002F\u002Fgithub.com\u002FAI-native-Systems-Research","https:\u002F\u002Fai-native-systems-research.github.io\u002Fai-native-systems-research\u002F","2026-11-12 06:08:32",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":49},[60,63,66],{"tool":61,"command":62},"npx","npx skills add AI-native-Systems-Research\u002Fai-native-storage-certus --skill speckit-tasks",{"tool":64,"command":65},"bunx","bunx skills add AI-native-Systems-Research\u002Fai-native-storage-certus --skill speckit-tasks",{"tool":67,"command":68},"pnpm","pnpm dlx skills add AI-native-Systems-Research\u002Fai-native-storage-certus --skill speckit-tasks","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FAI-native-Systems-Research\u002Fai-native-storage-certus\u002Fblob\u002Funstable\u002Fcomponents\u002Fdispatcher-p2p\u002F.claude\u002Fskills\u002Fspeckit-tasks\u002FSKILL.md",[],[72,90,105,116,132,144],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":39},"01M6KP29TWSNGADF3AJ47BR7TY","tools-spin-sync","Synchronize Spin\u002FPromela models with current source code and re-verify","https:\u002F\u002Fgithub.com\u002FAI-native-Systems-Research\u002Fai-native-storage-certus\u002Fblob\u002Funstable\u002Fcomponents\u002Fzyre\u002F.claude\u002Fskills\u002Ftools-spin-sync\u002FSKILL.md",[],[79,80,81,82,83,84,85,86,26,87,88,89],"tools spin sync","Tools","sync","code","verify","model","models","name","re","source","source code",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":39},"01M6KP277TDY3ZAJEBP5P6MDT8","tools-spin-model","Create a new Spin\u002FPromela formal verification model for a system property","https:\u002F\u002Fgithub.com\u002FAI-native-Systems-Research\u002Fai-native-storage-certus\u002Fblob\u002Funstable\u002Fcomponents\u002Fzyre\u002F.claude\u002Fskills\u002Ftools-spin-model\u002FSKILL.md",[],[97,84,80,98,99,100,23,101,102,103,104],"tools spin model","system","formal verification","number","prove","new","create","verification",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":39},"01M6KP250W406CEDSF02BRXT9D","tools-creusot-install","Install the Creusot Rust verification tool","https:\u002F\u002Fgithub.com\u002FAI-native-Systems-Research\u002Fai-native-storage-certus\u002Fblob\u002Funstable\u002Fcomponents\u002Fzyre\u002F.claude\u002Fskills\u002Ftools-creusot-install\u002FSKILL.md",[],[112,113,80,114,104,115],"tools creusot install","install","rust","tool",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":39},"01M6KP22H28FQ1X0V7VJHEFWXD","tools-creusot-init","Prepare an existing Cargo project to use Creusot formal verification","https:\u002F\u002Fgithub.com\u002FAI-native-Systems-Research\u002Fai-native-storage-certus\u002Fblob\u002Funstable\u002Fcomponents\u002Fzyre\u002F.claude\u002Fskills\u002Ftools-creusot-init\u002FSKILL.md",[],[123,80,124,32,125,126,127,104,128,99,129,130,131],"tools creusot init","init","directory","components","prepare","use","cargo","manager","Existing",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":39},"01M6KP1V506J9YM8DKKVDG1NRE","tools-creusot-coq-install","Add Coq 8.20 as an additional prover to an existing Creusot installation, for verification conditions that SMT solvers cannot discharge","https:\u002F\u002Fgithub.com\u002FAI-native-Systems-Research\u002Fai-native-storage-certus\u002Fblob\u002Funstable\u002Fcomponents\u002Fzyre\u002F.claude\u002Fskills\u002Ftools-creusot-coq-install\u002FSKILL.md",[],[139,140,113,80,23,131,141,142,104,143],"tools creusot coq install","Coq","as","installation","add",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":39},"01M6KP1PQJF3H765TYZAZ7P3EF","tools-creusot-annotate-interfaces","Formally verify a component's properties with Creusot and annotate its interface definitions","https:\u002F\u002Fgithub.com\u002FAI-native-Systems-Research\u002Fai-native-storage-certus\u002Fblob\u002Funstable\u002Fcomponents\u002Fzyre\u002F.claude\u002Fskills\u002Ftools-creusot-annotate-interfaces\u002FSKILL.md",[],[80,151,152,26,86,153,83,154,155],"tools creusot annotate interfaces","annotate","properties","component","interface"]