[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M72SFAQ9B9F3XM6X3QRGAKWP":3,"skill-same:01M72SFAQ9B9F3XM6X3QRGAKWP":48},{"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":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":27,"commitSha":28,"skillDirectory":29,"forksCount":30,"repositoryHtmlUrl":31,"repositoryHomepageUrl":6,"ownerHtmlUrl":32,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":33,"install":34,"resources":47},"01M72SFAQ9B9F3XM6X3QRGAKWP","speckit-tasks",null,"Break down implementation plans into actionable task lists.","EHotwagner\u002FFS-Skia-UI","EHotwagner","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1645484?v=4","01M72S7CTBDPQDQHQJKKHY87K9","01M72S7CVFD0JN82RVX21NFEVC",2,"MIT","https:\u002F\u002Fgithub.com\u002FEHotwagner\u002FFS-Skia-UI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fspeckit-tasks\u002FSKILL.md",[],[],"2026-11-10 22:39:42",false,"---\nname: speckit-tasks\ndescription: Break down implementation plans into actionable task lists.\ncompatibility: Requires spec-kit project structure with .specify\u002F directory\nmetadata:\n  author: github-spec-kit\n  source: preset:fsharp-opinionated\n---\n\n# Speckit Tasks Skill\n\n# \u002Fspeckit.tasks\n\n## Pre-Execution Checks\n\n**Check for extension hooks (before tasks)**:\n- Discover hooks across **all** extension files (multi-file discovery), not just the central file:\n  - Read `.specify\u002Fextensions.yml` from the project root (if present) and collect entries under the `hooks.before_tasks` key.\n  - Then enumerate every `.specify\u002Fextensions\u002F*\u002F*.yml` file in sorted order, parse each, and collect its `hooks.before_tasks` entries too — so a hook registered only in a per-extension file (e.g. the `feedback` extension at `.specify\u002Fextensions\u002Ffeedback\u002Ffeedback.yml`) is still discovered and runs.\n  - Merge all collected entries and dedupe by `(extension, command)` (first occurrence wins, so a hook declared in both files runs once).\n  - If a file is absent or its YAML cannot be parsed\u002Fis invalid, skip that file silently and continue.\n- For every `optional: true` hook that is discovered but not executed this phase, emit one line so the skip is a visible decision: `Note: optional hook {extension}:{command} is registered but was not run (skipped).`\n- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled.\n- For each remaining hook, do **not** 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 it and leave condition evaluation to the HookExecutor implementation\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 task generation.\n    ```\n- If no hooks are registered or `.specify\u002Fextensions.yml` does not exist, skip silently\n\nGenerate the feature's task breakdown from its spec and plan. This preset\nrequires TWO files, both in `specs\u002F[FEATURE_ID]\u002F`:\n\n1. **`tasks.md`** — the human checklist. Status legend:\n   - `[ ]` pending \u002F `[X]` done (real evidence) \u002F `[S]` synthetic-only \u002F\n     `[F]` failed \u002F `[-]` skipped.\n   - Never write `[S*]` yourself. That marker is computed by the evidence\n     audit from the DAG; writing it by hand will confuse the script.\n   - `[SEH]` is an annotation, not a completion status. Use it only for\n     design-approved synthetic error-handling tasks that will remain `[S]`\n     when completed with malformed-input or explicit error-path synthetic\n     evidence.\n\n2. **`tasks.deps.yml`** — the dependency topology and task skill metadata.\n   Sibling to `tasks.md`. It MUST begin with a `schema_version` scalar and a\n   top-level `tasks:` mapping (the wrapper). Every Tnnn id in `tasks.md` MUST\n   appear as a key under `tasks:` with `deps` and `skillist` fields, and MAY\n   carry an optional `owns:` field. `skillist` is an ordered list of applicable\n   capability skill identifiers, or `[]` when no capability skill applies.\n\n   ```yaml\n   schema_version: \"1.0\"\n   tasks:\n     T001:\n       deps: []\n       skillist: []\n       owns: []                       # owns nothing — most tasks\n     T002:\n       deps: [T001]\n       skillist: [\"fs-skia-layout-readability\"]\n       owns: []\n     T033:\n       deps: [T032]\n       skillist: [\"speckit-evidence-audit\"]\n       owns: [\"evidence-audit\"]        # this task owns the audit evidence\n   ```\n\n   The single structural fact that gates validation is the `tasks:` wrapper.\n   If you write bare `Tnnn:` keys at the top level (no wrapper), validation\n   stops with one directive error naming the missing `tasks:` mapping — fix\n   that first.\n\nStart from the preset's templates at the **exact** paths\n`.specify\u002Fpresets\u002Ffsharp-opinionated\u002Ftemplates\u002Ftasks-template.md` and\n`.specify\u002Fpresets\u002Ffsharp-opinionated\u002Ftemplates\u002Ftasks-deps-template.yml`,\nreplacing the example task bodies with real work items from the spec and plan.\nDo **not** start from the generic `.specify\u002Ftemplates\u002Ftasks-template.md` — that\ncopy is the non-preset Spec Kit fallback and points back here; for a\n`fsharp-opinionated` project the preset copy above is authoritative.\n\n## Discipline\n\n- **Lockstep emission.** You MUST write both files in the same turn. Never\n  emit `tasks.md` without `tasks.deps.yml`, and vice versa. If you only\n  have partial information, write placeholder object metadata (`deps: []`,\n  `skillist: []`) and note which ones need review in your summary.\n- **Compulsory skill evaluation.** Immediately after drafting tasks, evaluate\n  every task against available capability skills: `.agents\u002Fskills\u002F*\u002FSKILL.md`,\n  `src\u002F*\u002Fskill\u002FSKILL.md`, template capability skill paths, and active\n  generated product skill destinations when applicable. Choose the minimal\n  ordered set that would materially help implementation. Capability skills\n  are preferred over generic guidance when both match.\n- **What the assessment actually checks (be honest).** The validator does\n  **not** re-derive skills from your task titles. It trusts each declared\n  `skillist` as-written, and only adds a structured requirement where a task\n  declares gated evidence via its `owns:` field: each `owns:` value implies a\n  required skill that MUST appear in that task's `skillist`. Everything else is\n  reported as trusted-as-declared. Task titles are fully free-form and are never\n  scanned for capability phrases.\n- **Visible skill mirror.** Every task line in `tasks.md` MUST mirror the\n  structured `skillist` value as `[skillist: ...]`. Use `[skillist: []]` for\n  an empty list. Non-empty mirrors preserve the exact structured order, for\n  example `[skillist: speckit-tasks, speckit-evidence-graph]`.\n- **Task graph pitfall guidance.** Task titles are free-form — write them in\n  plain language. `tasks.deps.yml` MUST use one key per task id under the\n  top-level `tasks:` wrapper; the required object shape is one entry per task id\n  with indented `deps`, `skillist`, and optional `owns` fields. Inline maps such\n  as `T001: { deps: [], skillist: [] }`, duplicate keys, bare task lists (no\n  `tasks:` wrapper), malformed indentation, dangling dependency ids, and\n  mismatched visible `skillist` mirrors are invalid.\n- **Structured evidence ownership (`owns:`).** Whether a task owns gated\n  graph\u002Faudit (or other) evidence is declared **only** by its `owns:` field,\n  never inferred from the title. The closed vocabulary and the skill each value\n  implies:\n\n  | `owns:` value            | Task owns…                            | Required skill in `skillist` |\n  |--------------------------|---------------------------------------|------------------------------|\n  | `graph-validation`       | task-graph \u002F readiness validation     | `speckit-evidence-graph`     |\n  | `evidence-audit`         | synthetic-propagation \u002F diff-scan     | `speckit-evidence-audit`     |\n  | `task-generation`        | `\u002Fspeckit.tasks` task-generation      | `speckit-tasks`              |\n  | `implementation-loading` | `\u002Fspeckit.implement` skill-loading    | `speckit-implement`          |\n  | `constitution`           | constitution authoring                | `speckit-constitution`       |\n\n  Most tasks own nothing — omit `owns:` or use `owns: []`. When a task declares\n  an `owns:` value, its `skillist` MUST include the implied skill or validation\n  fails with a directive error; an unknown `owns:` value is also a directive\n  error naming the allowed set.\n- **Migration (from the removed title-trigger matcher).** Earlier task files\n  relied on a title-trigger matcher that scanned titles for capability phrases;\n  that matcher is removed. Re-express any ownership by adding `owns: [\u003Cvalue>]`\n  to the owning task, and drop any awkward title rewording (or the\n  `Complete readiness notes` prefix) that only existed to satisfy or dodge the\n  old matcher. No `tasks.md` title change is required for correctness anymore.\n- **Declared skill ids resolve from skill names.** The authoritative registry\n  is `.agents\u002Fskills\u002F*\u002FSKILL.md`, `src\u002F*\u002Fskill\u002FSKILL.md`, and\n  `template\u002Ffragments\u002F*\u002Fskill\u002FSKILL.md`. Declare each skill file's `name:`\n  value in `skillist`; do not assume the directory name is accepted when it\n  differs.\n- **Advisory FS.Skia.UI capability hints.** These hints are non-blocking, and\n  every id resolves to a skill a generated consumer registers:\n  rendering\u002Fscene -> `fs-skia-scene`; viewer\u002Fwindow host ->\n  `fs-skia-skiaviewer`; Elmish workflow -> `fs-skia-elmish`;\n  keyboard\u002Finput -> `fs-skia-keyboard-input`; layout readability ->\n  `fs-skia-layout-readability`;\n  controls\u002Fforms\u002Fcharts\u002Fgraphs\u002FDataGrid -> `fs-skia-ui-widgets`;\n  generated game HUD readability and public-scene host update ->\n  `fs-skia-layout-readability`; deterministic evidence mode and host-warning\n  classification -> `fs-skia-evidence-mode`.\n- **Phase-checkpoint edges are implicit.** The graph compute script\n  auto-injects an edge from every task in Phase N+1 to the last foundation\n  task of Phase N. You do NOT repeat those edges in the yml — write only\n  non-phase cross-edges (e.g., `T015: [T011, T013]` says US1 impl depends\n  on US1 tests and US1 fixtures).\n- **Story grouping.** Tasks belong to a phase (Phase 1..N) and optionally a\n  user story (`[US1]`, `[US2]`, ...). Keep phases sequential; stories\n  within a phase may run in parallel.\n- **Tier annotation.** Mark each task `[T1]` or `[T2]` if the phase\n  classification differs from the spec's overall tier. Omit when it\n  matches.\n- **Parallel-safe marker.** `[P]` means \"no deps inside this phase\" — the\n  script can verify it; you SHOULD emit it as a hint.\n- **Elmish\u002FMVU applicability.** For any stateful or I\u002FO-bearing story, emit\n  explicit tasks for the `.fsi` contract (`Model`, `Msg`, `Effect` or\n  `Cmd\u003CMsg>`, `init`, `update`, interpreter boundary), pure transition tests,\n  emitted-effect assertions, and real interpreter evidence where safe. For a\n  simple pure feature, state that Principle IV is not applicable in the\n  evidence-obligations task.\n- **Synthetic-evidence inventory.** Include the empty Synthetic-Evidence\n  Inventory table from the template. It will grow as `\u002Fspeckit.implement`\n  adds `[S]` tasks.\n- **Synthetic error-handling classification.** Assign `[SEH]` plus\n  `synthetic-error-handling-approved` only during design, planning,\n  clarification, or task generation. Each approved row must include the\n  design source, rationale, synthetic input class, expected error behavior,\n  and acceptance status. Eligible examples: malformed parser input, corrupt\n  file content, invalid command arguments, protocol violations, missing\n  required data, hostile payloads, and forced error-result fixtures.\n  Non-eligible examples: convenience mocks, incomplete integrations,\n  unavailable product capability, missing host support, placeholder outputs,\n  speed-only fixtures, and ordinary in-memory substitutes. implementation-time relabeling\n  is forbidden; newly discovered cases return to design\u002Ftask work.\n- **Risk-level evidence.** Generated tasks should name small, medium, and broad\n  governance risk levels, focused validation for the chosen level, when broad\n  validation is required, and how non-authoritative aggregate results are\n  recorded.\n- **Visual demo skill assignment.** Assign scene rendering -> fs-skia-scene,\n  screenshot capture -> fs-skia-skiaviewer, layout readability ->\n  fs-skia-layout-readability, persistent viewer launch -> fs-skia-skiaviewer,\n  deterministic evidence mode -> fs-skia-evidence-mode,\n  generated-package validation -> fs-skia-template-update, graph validation ->\n  speckit-evidence-graph, audit validation -> speckit-evidence-audit. Preserve\n  implementation-before-evidence, graph-before-audit, and\n  debug-before-broad-rerun ordering; the visible mirror\n  `[skillist: speckit-tasks, fs-skia-layout-readability]` illustrates exact\n  structured order.\n- **Visual demo readiness scaffolds.** Enumerate\n  `readiness\u002Fvisual-evidence-honesty.md`, `readiness\u002Fwindow-visibility.md`,\n  `readiness\u002Fgovernance-risk-levels.md`,\n  `readiness\u002Faggregate-hang-diagnostics.md`,\n  `readiness\u002Fruntime-limitations.md`,\n  `readiness\u002Fgenerated-guidance-validation.md`, and\n  `readiness\u002Freal-image-evidence.md` before audit. Each readiness file names the\n  authoritative command, artifact path, failure class, and next action.\n\n## Validation\n\nImmediately after writing both files, validate the task graph with the canonical\nin-process target (this is the same entry point the `speckit-evidence-graph`\nskill documents — the two skills do not contradict each other, and there is\n**no** `run-audit.sh` or other shell\u002Fpython runner):\n\n```bash\n.\u002Ffake.sh build -t EvidenceGraph\n```\n\nThe target resolves the feature to validate from `.specify\u002Ffeature.json`. To\nvalidate a different feature, override with the `SPECKIT_FEATURE_DIR`\nenvironment variable:\n\n```bash\nSPECKIT_FEATURE_DIR=\"specs\u002F\u003CFEATURE_ID>\" .\u002Ffake.sh build -t EvidenceGraph\n```\n\nConfirm the echoed `feature-directory=…` and `tasks=\u003Cn>` match **your** feature\nbefore trusting the verdict. If neither `.specify\u002Ffeature.json` nor an override\nresolves a feature, the target fails loudly — it never falls back to a sample.\n\nThis validates:\n- Every Tnnn in `tasks.md` has a matching key in `tasks.deps.yml`, and vice\n  versa.\n- Every dep reference resolves to a known Tnnn; the graph is acyclic.\n- Every task has structured `skillist` metadata and a matching `tasks.md`\n  mirror.\n- Declared skill ids resolve to exactly one readable skill file.\n- Each declared `owns:` value is in the closed vocabulary and carries its\n  implied skill in the `skillist`.\n\nReport any failures to the user immediately; refuse to declare the tasks\nphase complete until the DAG is clean. For the full merge-gate audit\n(synthetic-propagation + diff-scan), run `.\u002Ffake.sh build -t EvidenceAudit`.\n\n## Post-Execution Checks\n\n**Check for extension hooks (after tasks)**: After the task breakdown is generated, discover hooks across **all** extension files (multi-file discovery), not just the central file:\n- Read `.specify\u002Fextensions.yml` from the project root (if present) and collect entries under the `hooks.after_tasks` key.\n- Then enumerate every `.specify\u002Fextensions\u002F*\u002F*.yml` file in sorted order, parse each, and collect its `hooks.after_tasks` entries too — so a hook registered only in a per-extension file (e.g. the `feedback` extension at `.specify\u002Fextensions\u002Ffeedback\u002Ffeedback.yml`) is still discovered and runs on phase completion.\n- Merge all collected entries and dedupe by `(extension, command)` (first occurrence wins, so a hook declared in both files runs once).\n- **Hook execution precedence** (D1): when `settings.auto_execute_hooks: true` in `.specify\u002Fextensions.yml`, a **mandatory** hook (`optional: false`) **auto-runs** with no confirmation; an **optional** hook (`optional: true`) is **always surfaced** (\"To execute: `\u002F{command}`\") and is **never force-run** by `auto_execute_hooks`; a hook with a non-empty `condition` is **never** evaluated by this skill — evaluation is left to the executor and the notice reports the resolved decision. When `auto_execute_hooks: false`, even mandatory hooks are surfaced for confirmation.\n- **Effective-hooks notice** (D2): after the merge + dedup by `(extension, command)`, emit **one** consolidated notice for the phase so the operator never hand-reconciles files — a promoted feedback hook (`optional: false`) appears as `auto-run`, never as a surfaced optional:\n  ```\n  ## Effective hooks for tasks\n  - {extension}:{command} — auto-run        (mandatory; auto_execute_hooks=true)\n  - {extension}:{command} — surfaced        (optional)\n  - {extension}:{command} — skipped         (enabled: false)\n  - {extension}:{command} — condition-deferred\n  ```\n- If a file is absent or its YAML cannot be parsed\u002Fis invalid, skip that file silently and continue.\n- For every `optional: true` hook that is discovered but not executed this phase, emit one line so the skip is a visible decision: `Note: optional hook {extension}:{command} is registered but was not run (skipped).`\n- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled.\n- For each remaining hook, do **not** 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 it and leave condition evaluation to the HookExecutor implementation\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","# Speckit Tasks Skill\n\n# \u002Fspeckit.tasks\n\n## Pre-Execution Checks\n\n**Check for extension hooks (before tasks)**:\n- Discover hooks across **all** extension files (multi-file discovery), not just the central file:\n  - Read `.specify\u002Fextensions.yml` from the project root (if present) and collect entries under the `hooks.before_tasks` key.\n  - Then enumerate every `.specify\u002Fextensions\u002F*\u002F*.yml` file in sorted order, parse each, and collect its `hooks.before_tasks` entries too — so a hook registered only in a per-extension file (e.g. the `feedback` extension at `.specify\u002Fextensions\u002Ffeedback\u002Ffeedback.yml`) is still discovered and runs.\n  - Merge all collected entries and dedupe by `(extension, command)` (first occurrence wins, so a hook declared in both files runs once).\n  - If a file is absent or its YAML cannot be parsed\u002Fis invalid, skip that file silently and continue.\n- For every `optional: true` hook that is discovered but not executed this phase, emit one line so the skip is a visible decision: `Note: optional hook {extension}:{command} is registered but was not run (skipped).`\n- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled.\n- For each remaining hook, do **not** 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 it and leave condition evaluation to the HookExecutor implementation\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 task generation.\n    ```\n- If no hooks are registered or `.specify\u002Fextensions.yml` does not exist, skip silently\n\nGenerate the feature's task breakdown from its spec and plan. This preset\nrequires TWO files, both in `specs\u002F[FEATURE_ID]\u002F`:\n\n1. **`tasks.md`** — the human checklist. Status legend:\n   - `[ ]` pending \u002F `[X]` done (real evidence) \u002F `[S]` synthetic-only \u002F\n     `[F]` failed \u002F `[-]` skipped.\n   - Never write `[S*]` yourself. That marker is computed by the evidence\n     audit from the DAG; writing it by hand will confuse the script.\n   - `[SEH]` is an annotation, not a completion status. Use it only for\n     design-approved synthetic error-handling tasks that will remain `[S]`\n     when completed with malformed-input or explicit error-path synthetic\n     evidence.\n\n2. **`tasks.deps.yml`** — the dependency topology and task skill metadata.\n   Sibling to `tasks.md`. It MUST begin with a `schema_version` scalar and a\n   top-level `tasks:` mapping (the wrapper). Every Tnnn id in `tasks.md` MUST\n   appear as a key under `tasks:` with `deps` and `skillist` fields, and MAY\n   carry an optional `owns:` field. `skillist` is an ordered list of applicable\n   capability skill identifiers, or `[]` when no capability skill applies.\n\n   ```yaml\n   schema_version: \"1.0\"\n   tasks:\n     T001:\n       deps: []\n       skillist: []\n       owns: []                       # owns nothing — most tasks\n     T002:\n       deps: [T001]\n       skillist: [\"fs-skia-layout-readability\"]\n       owns: []\n     T033:\n       deps: [T032]\n       skillist: [\"speckit-evidence-audit\"]\n       owns: [\"evidence-audit\"]        # this task owns the audit evidence\n   ```\n\n   The single structural fact that gates validation is the `tasks:` wrapper.\n   If you write bare `Tnnn:` keys at the top level (no wrapper), validation\n   stops with one directive error naming the missing `tasks:` mapping — fix\n   that first.\n\nStart from the preset's templates at the **exact** paths\n`.specify\u002Fpresets\u002Ffsharp-opinionated\u002Ftemplates\u002Ftasks-template.md` and\n`.specify\u002Fpresets\u002Ffsharp-opinionated\u002Ftemplates\u002Ftasks-deps-template.yml`,\nreplacing the example task bodies with real work items from the spec and plan.\nDo **not** start from the generic `.specify\u002Ftemplates\u002Ftasks-template.md` — that\ncopy is the non-preset Spec Kit fallback and points back here; for a\n`fsharp-opinionated` project the preset copy above is authoritative.\n\n## Discipline\n\n- **Lockstep emission.** You MUST write both files in the same turn. Never\n  emit `tasks.md` without `tasks.deps.yml`, and vice versa. If you only\n  have partial information, write placeholder object metadata (`deps: []`,\n  `skillist: []`) and note which ones need review in your summary.\n- **Compulsory skill evaluation.** Immediately after drafting tasks, evaluate\n  every task against available capability skills: `.agents\u002Fskills\u002F*\u002FSKILL.md`,\n  `src\u002F*\u002Fskill\u002FSKILL.md`, template capability skill paths, and active\n  generated product skill destinations when applicable. Choose the minimal\n  ordered set that would materially help implementation. Capability skills\n  are preferred over generic guidance when both match.\n- **What the assessment actually checks (be honest).** The validator does\n  **not** re-derive skills from your task titles. It trusts each declared\n  `skillist` as-written, and only adds a structured requirement where a task\n  declares gated evidence via its `owns:` field: each `owns:` value implies a\n  required skill that MUST appear in that task's `skillist`. Everything else is\n  reported as trusted-as-declared. Task titles are fully free-form and are never\n  scanned for capability phrases.\n- **Visible skill mirror.** Every task line in `tasks.md` MUST mirror the\n  structured `skillist` value as `[skillist: ...]`. Use `[skillist: []]` for\n  an empty list. Non-empty mirrors preserve the exact structured order, for\n  example `[skillist: speckit-tasks, speckit-evidence-graph]`.\n- **Task graph pitfall guidance.** Task titles are free-form — write them in\n  plain language. `tasks.deps.yml` MUST use one key per task id under the\n  top-level `tasks:` wrapper; the required object shape is one entry per task id\n  with indented `deps`, `skillist`, and optional `owns` fields. Inline maps such\n  as `T001: { deps: [], skillist: [] }`, duplicate keys, bare task lists (no\n  `tasks:` wrapper), malformed indentation, dangling dependency ids, and\n  mismatched visible `skillist` mirrors are invalid.\n- **Structured evidence ownership (`owns:`).** Whether a task owns gated\n  graph\u002Faudit (or other) evidence is declared **only** by its `owns:` field,\n  never inferred from the title. The closed vocabulary and the skill each value\n  implies:\n\n  | `owns:` value            | Task owns…                            | Required skill in `skillist` |\n  |--------------------------|---------------------------------------|------------------------------|\n  | `graph-validation`       | task-graph \u002F readiness validation     | `speckit-evidence-graph`     |\n  | `evidence-audit`         | synthetic-propagation \u002F diff-scan     | `speckit-evidence-audit`     |\n  | `task-generation`        | `\u002Fspeckit.tasks` task-generation      | `speckit-tasks`              |\n  | `implementation-loading` | `\u002Fspeckit.implement` skill-loading    | `speckit-implement`          |\n  | `constitution`           | constitution authoring                | `speckit-constitution`       |\n\n  Most tasks own nothing — omit `owns:` or use `owns: []`. When a task declares\n  an `owns:` value, its `skillist` MUST include the implied skill or validation\n  fails with a directive error; an unknown `owns:` value is also a directive\n  error naming the allowed set.\n- **Migration (from the removed title-trigger matcher).** Earlier task files\n  relied on a title-trigger matcher that scanned titles for capability phrases;\n  that matcher is removed. Re-express any ownership by adding `owns: [\u003Cvalue>]`\n  to the owning task, and drop any awkward title rewording (or the\n  `Complete readiness notes` prefix) that only existed to satisfy or dodge the\n  old matcher. No `tasks.md` title change is required for correctness anymore.\n- **Declared skill ids resolve from skill names.** The authoritative registry\n  is `.agents\u002Fskills\u002F*\u002FSKILL.md`, `src\u002F*\u002Fskill\u002FSKILL.md`, and\n  `template\u002Ffragments\u002F*\u002Fskill\u002FSKILL.md`. Declare each skill file's `name:`\n  value in `skillist`; do not assume the directory name is accepted when it\n  differs.\n- **Advisory FS.Skia.UI capability hints.** These hints are non-blocking, and\n  every id resolves to a skill a generated consumer registers:\n  rendering\u002Fscene -> `fs-skia-scene`; viewer\u002Fwindow host ->\n  `fs-skia-skiaviewer`; Elmish workflow -> `fs-skia-elmish`;\n  keyboard\u002Finput -> `fs-skia-keyboard-input`; layout readability ->\n  `fs-skia-layout-readability`;\n  controls\u002Fforms\u002Fcharts\u002Fgraphs\u002FDataGrid -> `fs-skia-ui-widgets`;\n  generated game HUD readability and public-scene host update ->\n  `fs-skia-layout-readability`; deterministic evidence mode and host-warning\n  classification -> `fs-skia-evidence-mode`.\n- **Phase-checkpoint edges are implicit.** The graph compute script\n  auto-injects an edge from every task in Phase N+1 to the last foundation\n  task of Phase N. You do NOT repeat those edges in the yml — write only\n  non-phase cross-edges (e.g., `T015: [T011, T013]` says US1 impl depends\n  on US1 tests and US1 fixtures).\n- **Story grouping.** Tasks belong to a phase (Phase 1..N) and optionally a\n  user story (`[US1]`, `[US2]`, ...). Keep phases sequential; stories\n  within a phase may run in parallel.\n- **Tier annotation.** Mark each task `[T1]` or `[T2]` if the phase\n  classification differs from the spec's overall tier. Omit when it\n  matches.\n- **Parallel-safe marker.** `[P]` means \"no deps inside this phase\" — the\n  script can verify it; you SHOULD emit it as a hint.\n- **Elmish\u002FMVU applicability.** For any stateful or I\u002FO-bearing story, emit\n  explicit tasks for the `.fsi` contract (`Model`, `Msg`, `Effect` or\n  `Cmd\u003CMsg>`, `init`, `update`, interpreter boundary), pure transition tests,\n  emitted-effect assertions, and real interpreter evidence where safe. For a\n  simple pure feature, state that Principle IV is not applicable in the\n  evidence-obligations task.\n- **Synthetic-evidence inventory.** Include the empty Synthetic-Evidence\n  Inventory table from the template. It will grow as `\u002Fspeckit.implement`\n  adds `[S]` tasks.\n- **Synthetic error-handling classification.** Assign `[SEH]` plus\n  `synthetic-error-handling-approved` only during design, planning,\n  clarification, or task generation. Each approved row must include the\n  design source, rationale, synthetic input class, expected error behavior,\n  and acceptance status. Eligible examples: malformed parser input, corrupt\n  file content, invalid command arguments, protocol violations, missing\n  required data, hostile payloads, and forced error-result fixtures.\n  Non-eligible examples: convenience mocks, incomplete integrations,\n  unavailable product capability, missing host support, placeholder outputs,\n  speed-only fixtures, and ordinary in-memory substitutes. implementation-time relabeling\n  is forbidden; newly discovered cases return to design\u002Ftask work.\n- **Risk-level evidence.** Generated tasks should name small, medium, and broad\n  governance risk levels, focused validation for the chosen level, when broad\n  validation is required, and how non-authoritative aggregate results are\n  recorded.\n- **Visual demo skill assignment.** Assign scene rendering -> fs-skia-scene,\n  screenshot capture -> fs-skia-skiaviewer, layout readability ->\n  fs-skia-layout-readability, persistent viewer launch -> fs-skia-skiaviewer,\n  deterministic evidence mode -> fs-skia-evidence-mode,\n  generated-package validation -> fs-skia-template-update, graph validation ->\n  speckit-evidence-graph, audit validation -> speckit-evidence-audit. Preserve\n  implementation-before-evidence, graph-before-audit, and\n  debug-before-broad-rerun ordering; the visible mirror\n  `[skillist: speckit-tasks, fs-skia-layout-readability]` illustrates exact\n  structured order.\n- **Visual demo readiness scaffolds.** Enumerate\n  `readiness\u002Fvisual-evidence-honesty.md`, `readiness\u002Fwindow-visibility.md`,\n  `readiness\u002Fgovernance-risk-levels.md`,\n  `readiness\u002Faggregate-hang-diagnostics.md`,\n  `readiness\u002Fruntime-limitations.md`,\n  `readiness\u002Fgenerated-guidance-validation.md`, and\n  `readiness\u002Freal-image-evidence.md` before audit. Each readiness file names the\n  authoritative command, artifact path, failure class, and next action.\n\n## Validation\n\nImmediately after writing both files, validate the task graph with the canonical\nin-process target (this is the same entry point the `speckit-evidence-graph`\nskill documents — the two skills do not contradict each other, and there is\n**no** `run-audit.sh` or other shell\u002Fpython runner):\n\n```bash\n.\u002Ffake.sh build -t EvidenceGraph\n```\n\nThe target resolves the feature to validate from `.specify\u002Ffeature.json`. To\nvalidate a different feature, override with the `SPECKIT_FEATURE_DIR`\nenvironment variable:\n\n```bash\nSPECKIT_FEATURE_DIR=\"specs\u002F\u003CFEATURE_ID>\" .\u002Ffake.sh build -t EvidenceGraph\n```\n\nConfirm the echoed `feature-directory=…` and `tasks=\u003Cn>` match **your** feature\nbefore trusting the verdict. If neither `.specify\u002Ffeature.json` nor an override\nresolves a feature, the target fails loudly — it never falls back to a sample.\n\nThis validates:\n- Every Tnnn in `tasks.md` has a matching key in `tasks.deps.yml`, and vice\n  versa.\n- Every dep reference resolves to a known Tnnn; the graph is acyclic.\n- Every task has structured `skillist` metadata and a matching `tasks.md`\n  mirror.\n- Declared skill ids resolve to exactly one readable skill file.\n- Each declared `owns:` value is in the closed vocabulary and carries its\n  implied skill in the `skillist`.\n\nReport any failures to the user immediately; refuse to declare the tasks\nphase complete until the DAG is clean. For the full merge-gate audit\n(synthetic-propagation + diff-scan), run `.\u002Ffake.sh build -t EvidenceAudit`.\n\n## Post-Execution Checks\n\n**Check for extension hooks (after tasks)**: After the task breakdown is generated, discover hooks across **all** extension files (multi-file discovery), not just the central file:\n- Read `.specify\u002Fextensions.yml` from the project root (if present) and collect entries under the `hooks.after_tasks` key.\n- Then enumerate every `.specify\u002Fextensions\u002F*\u002F*.yml` file in sorted order, parse each, and collect its `hooks.after_tasks` entries too — so a hook registered only in a per-extension file (e.g. the `feedback` extension at `.specify\u002Fextensions\u002Ffeedback\u002Ffeedback.yml`) is still discovered and runs on phase completion.\n- Merge all collected entries and dedupe by `(extension, command)` (first occurrence wins, so a hook declared in both files runs once).\n- **Hook execution precedence** (D1): when `settings.auto_execute_hooks: true` in `.specify\u002Fextensions.yml`, a **mandatory** hook (`optional: false`) **auto-runs** with no confirmation; an **optional** hook (`optional: true`) is **always surfaced** (\"To execute: `\u002F{command}`\") and is **never force-run** by `auto_execute_hooks`; a hook with a non-empty `condition` is **never** evaluated by this skill — evaluation is left to the executor and the notice reports the resolved decision. When `auto_execute_hooks: false`, even mandatory hooks are surfaced for confirmation.\n- **Effective-hooks notice** (D2): after the merge + dedup by `(extension, command)`, emit **one** consolidated notice for the phase so the operator never hand-reconciles files — a promoted feedback hook (`optional: false`) appears as `auto-run`, never as a surfaced optional:\n  ```\n  ## Effective hooks for tasks\n  - {extension}:{command} — auto-run        (mandatory; auto_execute_hooks=true)\n  - {extension}:{command} — surfaced        (optional)\n  - {extension}:{command} — skipped         (enabled: false)\n  - {extension}:{command} — condition-deferred\n  ```\n- If a file is absent or its YAML cannot be parsed\u002Fis invalid, skip that file silently and continue.\n- For every `optional: true` hook that is discovered but not executed this phase, emit one line so the skip is a visible decision: `Note: optional hook {extension}:{command} is registered but was not run (skipped).`\n- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled.\n- For each remaining hook, do **not** 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 it and leave condition evaluation to the HookExecutor implementation\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":23,"description":7,"compatibility":26},{"author":24,"source":25},"github-spec-kit","preset:fsharp-opinionated","Requires spec-kit project structure with .specify\u002F directory","main","f943406829a9218b2882e09eb88d4ddb539c5e72",".claude\u002Fskills\u002Fspeckit-tasks",0,"https:\u002F\u002Fgithub.com\u002FEHotwagner\u002FFS-Skia-UI","https:\u002F\u002Fgithub.com\u002FEHotwagner","2026-06-16 16:16:52",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add EHotwagner\u002FFS-Skia-UI --skill speckit-tasks",{"tool":40,"command":41},"bunx","bunx skills add EHotwagner\u002FFS-Skia-UI --skill speckit-tasks",{"tool":43,"command":44},"pnpm","pnpm dlx skills add EHotwagner\u002FFS-Skia-UI --skill speckit-tasks","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FEHotwagner\u002FFS-Skia-UI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fspeckit-tasks\u002FSKILL.md",true,[],[49,56,63,70,77,84],{"skillNo":50,"name":51,"nameZh":6,"description":52,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":53,"categories":54,"keywords":55,"publishedAt":18},"01M72SGYR4T02T1HTS175E0V86","fs-skia-ui-widgets","Generated product guidance for Skia-rendered FS.Skia.UI Controls, rich text, chart controls, graph controls, DataGrid, and custom wrappers.","https:\u002F\u002Fgithub.com\u002FEHotwagner\u002FFS-Skia-UI\u002Fblob\u002Fmain\u002Ftemplate\u002Fproduct-skills\u002Ffs-skia-ui-widgets\u002FSKILL.md",[],[],{"skillNo":57,"name":58,"nameZh":6,"description":59,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":60,"categories":61,"keywords":62,"publishedAt":18},"01M72SGVZJR1B117QK7TCC6E0J","fs-skia-testing","Assert generated-product expectations and evidence in a governed FS.Skia.UI product.","https:\u002F\u002Fgithub.com\u002FEHotwagner\u002FFS-Skia-UI\u002Fblob\u002Fmain\u002Ftemplate\u002Fproduct-skills\u002Ffs-skia-testing\u002FSKILL.md",[],[],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":18},"01M72SGTC5HZYEVVVZT4X51AZ3","fs-skia-skiaviewer","Wire a generated FS.Skia.UI product to the desktop viewer host.","https:\u002F\u002Fgithub.com\u002FEHotwagner\u002FFS-Skia-UI\u002Fblob\u002Fmain\u002Ftemplate\u002Fproduct-skills\u002Ffs-skia-skiaviewer\u002FSKILL.md",[],[],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":18},"01M72SGS47RPYPC9JTC39CC6EF","fs-skia-scene","Build pure scene descriptions in a generated FS.Skia.UI product.","https:\u002F\u002Fgithub.com\u002FEHotwagner\u002FFS-Skia-UI\u002Fblob\u002Fmain\u002Ftemplate\u002Fproduct-skills\u002Ffs-skia-scene\u002FSKILL.md",[],[],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":18},"01M72SGQF4G76C4NGSF69KZRRF","fs-skia-keyboard-input","Map keyboard input to product commands in a generated FS.Skia.UI product.","https:\u002F\u002Fgithub.com\u002FEHotwagner\u002FFS-Skia-UI\u002Fblob\u002Fmain\u002Ftemplate\u002Fproduct-skills\u002Ffs-skia-keyboard-input\u002FSKILL.md",[],[],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":18},"01M72SGNJP3PMSS2VRP98G7Z42","fs-skia-elmish","Drive a generated FS.Skia.UI product through the pure Elmish adapter.","https:\u002F\u002Fgithub.com\u002FEHotwagner\u002FFS-Skia-UI\u002Fblob\u002Fmain\u002Ftemplate\u002Fproduct-skills\u002Ffs-skia-elmish\u002FSKILL.md",[],[]]