[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DHANHS9NWSQFC1T2XGAQGY":3,"skill-same:01M6DHANHS9NWSQFC1T2XGAQGY":65},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":49,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M6DHANHS9NWSQFC1T2XGAQGY","reify",null,"Bind a situated node or directive to its executor and composed workflow on a combined task body. Use inside container supervision (\u002Fsupervise) or on explicit planning requests to resolve templates across project, PKB, and universal tiers. Exclude for expanding objectives into sub-objectives (use decompose) or starting workers on tasks already written (use dispatch).","nicsuzor\u002FacademicOps","nicsuzor","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F4496978?v=4","01M6DGWCFNDYP03M4DQAHA6DN1","Nicolas Suzor","01M6DGWCPXG37BMXRZZKXR0A1Z",5,"MIT","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fida-claude\u002Fskills\u002Freify\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"use","when","at","about","objective","for","task","tasks","workflow","workers","write","run","dispatch","next","executor","compose","decompose","bind","hydrate","2026-11-10 10:12:30",false,"---\nname: reify\ndescription: Bind a situated node or directive to its executor and composed workflow on a combined task body. Use inside container supervision (\u002Fsupervise) or on explicit planning requests to resolve templates across project, PKB, and universal tiers. Exclude for expanding objectives into sub-objectives (use decompose) or starting workers on tasks already written (use dispatch).\n---\n\n# \u002Freify: Compose the Dispatchable Workflow for a Node or Directive\n\n**Object: one node or directive, at execution or planning time.** Reifying binds the unit of work to an executor class and to the workflow templates current now. Run this skill inside container supervision (`\u002Fsupervise`) or on an explicit planning request (executed by `pauli` or lead executor). Given a parent container, reify only the children ready to run.\n\nThe task is the whole message to the worker. Write it once, keep it short, and leave it on the graph. Questions and lookups answered in-turn need no task.\nNothing is written to the graph until placement and composition pass.\n\n## 0. Verify Placement (\u002Fq Precondition)\n\nReifying binds an already situated node to execution. A node must be situated on the strategic graph under an active parent container (epic or project) and wired per the Three-Purpose Edge Taxonomy (ADR-0002) before it can be reified.\n\n- **Unplaced Asks \u002F Objectives**: If called with a raw natural-language ask or an unplaced objective lacking a parent container, do not write a task to the project root. Invoke `\u002Fq` first to search existing work, place the node under the active governing epic, and wire what it serves.\n- **Unparented Existing Tasks**: If given an unparented task ID, search for its governing epic and update its parentage via `\u002Fq` placement before proceeding with workflow composition.\n\n## 1. Hydrate\n\nCall `\u002Fhydrate` on the objective, or on the task if given an ID. Proof of `\u002Fhydrate` execution (or citation of hydration findings) is required before proceeding to task composition.\n\n- **Idempotency**: Search before creating tasks. Update existing tasks with new criteria rather than minting duplicates. A task already completely specified needs no rewrite; report it as ready.\n- If `\u002Fhydrate` flags an unfinished task with the same objective, continue that task instead of creating a new one.\n- If it flags an unfinished prerequisite, wire a `needs` dependency.\n\n## 2. Compose Workflows\n\n- **Single-Skill Fast-Path**: When a task's sole required work is invoking a single skill (`invoke \u002F\u003Cskill>`), that skill sets the workflow. Skip further template resolution and report the task ready as written.\n- **Three-Tier Template Resolution**: Enumerate composable workflow templates (`type: template`, including `wf-*`) dynamically in strict priority order:\n  1. _Project_: PKB templates with `project: \"\u003Cproject>\"` (strip `\u003Cproject>-` prefix to get the shadowing slug). Scoped to the task's project; foreign-project templates are ignored during composition.\n  2. _PKB_: Portable PKB templates with `project: null`.\n  3. _Universal_: Core templates in the sibling `workflow-library\u002Fworkflows\u002F*.md` directory (`..\u002Fworkflow-library\u002Fworkflows\u002F*.md` relative to this skill; enumerate and read via native file tools rather than shell commands).\n     Higher tiers shadow lower tiers completely; never merge text across tiers. Both PKB tiers resolve from the graph alone.\n- **Groundwork-First Route Decisions Invariant**: An agent given a task does the groundwork and makes the decision itself; it never files the task back to the user as their decision (`assignee: user`) unless the user explicitly requested to make that decision themselves. Research tasks investigating design or implementation trade-offs evaluate alternatives and choose the recommended route directly.\n- **Template Interpretation**: Read each selected template and translate its stages into concise, numbered imperative steps in `## Instructions`. Do not copy narrative rationale, explanatory prose, or background. Skills are invoked directly (`invoke \u002F\u003Cskill-name>`). Where tasks involve qualitative judgment, curation, or evaluation, compose an agent workflow rather than specifying deterministic scripts or wrappers.\n\nHalt when composition comes up short: create nothing and report precisely what failed.\n\n## 3. Write Each Task\n\n- **No-Split Default (Combined Task Body)**: Structure work as a single repository-scoped task body by default (up to 300 words for composite workflows, `## Ask` aside). Keep execution planning, in-session specialist subagent reviews, implementation fan-out, and verification internal to the single supervised session.\n- **Strict Splitting Conditions**: Splitting into separate tasks is prohibited by default and permitted **only** when a workflow step explicitly insists on:\n  1. _Different repository_: Strictly one task per repository.\n  2. _Different time_: A distinct external wait or execution window.\n  3. _Different agent\u002Fsession_: A workflow-mandated external agent or session, including closed-loop user-channel delivery dependent on container tasks via `needs`.\n- **Graph Topology & Edge Invariants**: Never pass `type: \"epic\"` to `pkb_create_task` (epics are organizational containers, not task types). Where splitting is explicitly required, wire execution gating via `needs: [\u003Ctask_id>]`. Top-level deliverable tasks wire `serves` to priced targets or to existing epics that serve priced targets; subtasks never carry redundant `serves` edges (single injection invariant). Contextual references are plain markdown `[[wikilinks]]` under `## Pointers`. Write tasks with status `queued`.\n\nFill the canonical task structure:\n\n```markdown\n## Ask\n\n[ Verbatim authorising ask from the user or delegating agent with message IDs. Immutable referent; do not paraphrase or edit. ]\n\n## Goal\n\n[ Concise description of the unit's end state, naming target repo\u002Fsystem and objective. Restate asks by meaning and distinctions, not wording. ]\n\n## Context\n\n[ Decisions and facts the worker cannot discover for itself (omit if none). ]\n\n## Acceptance\n\n[ Numbered criteria (AC1, AC2, ...). Criteria state observable outcomes and verifiable evidence proving substantive completion, not line numbers, line ranges, or narrow slice prescriptions. ]\n\n## Instructions\n\n[ Concise numbered imperative steps drawn solely from the composed workflow templates, ending with deliverable delivery, evidence recording, and task release. ]\n\n## Output\n\n[ Destination repository and target branch or artifact path per the workflow. ]\n\n## Report\n\n[ Handback reporting contract; default is \u002Fdump with evidence next to each acceptance criterion. ]\n\n## Appendix: Sources\n\n- Composed from: [ One-line list of workflow templates and skills this task was composed from. ]\n```\n\n### Requirements for Writing Tasks\n\n- Filter incoming mechanism prescriptions and translate them into observable outcome criteria. Line numbers, line ranges, and narrow code slice prescriptions are strictly forbidden in `Goal`, `Acceptance`, and `Instructions`. Give the worker the end state and the bounds; leave the method to it.\n- Record the asker's own words once, in `## Ask`, with their ids, and never rewrite them: the task carries the ask as an immutable referent. Link asks to prior context, recompose into a clear logical structure, and cite message ids. Restate terse, fragmented words into clear, complete criteria, judged by fidelity to meaning and distinctions.\n- State the Goal and each criterion over the whole class the request covers. When asked what broke a mechanism, compose the debugging workflow and preserve the full failure question in Acceptance across its lifecycle rather than narrowing to a single symptom.\n- Every heading is a prompt to fill without restriction slots: say what has to be done, not what shouldn't.\n- Keep each task strictly concise: 50–150 words for atomic tasks, up to 300 words for multi-stage composite workflows, `## Ask` aside. Include only what the worker cannot find for itself.\n- Interpret workflow template stages into concise numbered imperative steps; never paste template narrative, rationale, or explanatory background.\n- Assume the worker could run anywhere; never reference local paths, tools, or conventions. Leave out methods, command scripts, tool names, runtime hints, limits, summaries of linked notes, provenance, changelogs, session narratives, counts, SHAs, and history.\n- Change an existing task only for a defect in its text; never rewrite its `## Ask` or renumber its criteria.\n- A skill may be a step (`invoke \u002F\u003Cskill-name>`). A workflow template is never a step; its steps are.\n- Close every task with a one-line appendix section listing the workflow templates and skills it was composed from: `## Appendix: Sources` followed by `- Composed from: \u003Cworkflows and skills>.`\n- Do not create standalone decision tasks or file questions as tasks. Groundwork-first route decisions invariant applies. Competing candidate options stay inside the body of the scoping task or ADR until chosen. Model unknowns as empirical probes (`classification: probe`) wired via `needs: [\u003Cprobe_task_id>]`.\n- Worker state-only vs container supervision boundary: plain leaf workers (`\u002Fpull`) mutate only their claimed task's own state and never mint follow-up tasks; container coordinators (`\u002Fsupervise`) enrich their claimed task via `\u002Freify` and create follow-up tasks solely under the strict out-of-session splitting conditions above.\n- Reify plans, roadmaps, and designs as tasks on the PKB task graph.\n\n## 4. Report\n\nStop once tasks are written to the graph; `\u002Fdispatch` starts their workers. For each task written or confirmed ready, output:\n\n- Title, ID, status, and open `needs` dependencies.\n- Composed sources in the identical one-line format appended to the task body under `## Appendix: Sources` (e.g. `- Composed from: wf-feature, \u002Fcraft`).\n","# \u002Freify: Compose the Dispatchable Workflow for a Node or Directive\n\n**Object: one node or directive, at execution or planning time.** Reifying binds the unit of work to an executor class and to the workflow templates current now. Run this skill inside container supervision (`\u002Fsupervise`) or on an explicit planning request (executed by `pauli` or lead executor). Given a parent container, reify only the children ready to run.\n\nThe task is the whole message to the worker. Write it once, keep it short, and leave it on the graph. Questions and lookups answered in-turn need no task.\nNothing is written to the graph until placement and composition pass.\n\n## 0. Verify Placement (\u002Fq Precondition)\n\nReifying binds an already situated node to execution. A node must be situated on the strategic graph under an active parent container (epic or project) and wired per the Three-Purpose Edge Taxonomy (ADR-0002) before it can be reified.\n\n- **Unplaced Asks \u002F Objectives**: If called with a raw natural-language ask or an unplaced objective lacking a parent container, do not write a task to the project root. Invoke `\u002Fq` first to search existing work, place the node under the active governing epic, and wire what it serves.\n- **Unparented Existing Tasks**: If given an unparented task ID, search for its governing epic and update its parentage via `\u002Fq` placement before proceeding with workflow composition.\n\n## 1. Hydrate\n\nCall `\u002Fhydrate` on the objective, or on the task if given an ID. Proof of `\u002Fhydrate` execution (or citation of hydration findings) is required before proceeding to task composition.\n\n- **Idempotency**: Search before creating tasks. Update existing tasks with new criteria rather than minting duplicates. A task already completely specified needs no rewrite; report it as ready.\n- If `\u002Fhydrate` flags an unfinished task with the same objective, continue that task instead of creating a new one.\n- If it flags an unfinished prerequisite, wire a `needs` dependency.\n\n## 2. Compose Workflows\n\n- **Single-Skill Fast-Path**: When a task's sole required work is invoking a single skill (`invoke \u002F\u003Cskill>`), that skill sets the workflow. Skip further template resolution and report the task ready as written.\n- **Three-Tier Template Resolution**: Enumerate composable workflow templates (`type: template`, including `wf-*`) dynamically in strict priority order:\n  1. _Project_: PKB templates with `project: \"\u003Cproject>\"` (strip `\u003Cproject>-` prefix to get the shadowing slug). Scoped to the task's project; foreign-project templates are ignored during composition.\n  2. _PKB_: Portable PKB templates with `project: null`.\n  3. _Universal_: Core templates in the sibling `workflow-library\u002Fworkflows\u002F*.md` directory (`..\u002Fworkflow-library\u002Fworkflows\u002F*.md` relative to this skill; enumerate and read via native file tools rather than shell commands).\n     Higher tiers shadow lower tiers completely; never merge text across tiers. Both PKB tiers resolve from the graph alone.\n- **Groundwork-First Route Decisions Invariant**: An agent given a task does the groundwork and makes the decision itself; it never files the task back to the user as their decision (`assignee: user`) unless the user explicitly requested to make that decision themselves. Research tasks investigating design or implementation trade-offs evaluate alternatives and choose the recommended route directly.\n- **Template Interpretation**: Read each selected template and translate its stages into concise, numbered imperative steps in `## Instructions`. Do not copy narrative rationale, explanatory prose, or background. Skills are invoked directly (`invoke \u002F\u003Cskill-name>`). Where tasks involve qualitative judgment, curation, or evaluation, compose an agent workflow rather than specifying deterministic scripts or wrappers.\n\nHalt when composition comes up short: create nothing and report precisely what failed.\n\n## 3. Write Each Task\n\n- **No-Split Default (Combined Task Body)**: Structure work as a single repository-scoped task body by default (up to 300 words for composite workflows, `## Ask` aside). Keep execution planning, in-session specialist subagent reviews, implementation fan-out, and verification internal to the single supervised session.\n- **Strict Splitting Conditions**: Splitting into separate tasks is prohibited by default and permitted **only** when a workflow step explicitly insists on:\n  1. _Different repository_: Strictly one task per repository.\n  2. _Different time_: A distinct external wait or execution window.\n  3. _Different agent\u002Fsession_: A workflow-mandated external agent or session, including closed-loop user-channel delivery dependent on container tasks via `needs`.\n- **Graph Topology & Edge Invariants**: Never pass `type: \"epic\"` to `pkb_create_task` (epics are organizational containers, not task types). Where splitting is explicitly required, wire execution gating via `needs: [\u003Ctask_id>]`. Top-level deliverable tasks wire `serves` to priced targets or to existing epics that serve priced targets; subtasks never carry redundant `serves` edges (single injection invariant). Contextual references are plain markdown `[[wikilinks]]` under `## Pointers`. Write tasks with status `queued`.\n\nFill the canonical task structure:\n\n```markdown\n## Ask\n\n[ Verbatim authorising ask from the user or delegating agent with message IDs. Immutable referent; do not paraphrase or edit. ]\n\n## Goal\n\n[ Concise description of the unit's end state, naming target repo\u002Fsystem and objective. Restate asks by meaning and distinctions, not wording. ]\n\n## Context\n\n[ Decisions and facts the worker cannot discover for itself (omit if none). ]\n\n## Acceptance\n\n[ Numbered criteria (AC1, AC2, ...). Criteria state observable outcomes and verifiable evidence proving substantive completion, not line numbers, line ranges, or narrow slice prescriptions. ]\n\n## Instructions\n\n[ Concise numbered imperative steps drawn solely from the composed workflow templates, ending with deliverable delivery, evidence recording, and task release. ]\n\n## Output\n\n[ Destination repository and target branch or artifact path per the workflow. ]\n\n## Report\n\n[ Handback reporting contract; default is \u002Fdump with evidence next to each acceptance criterion. ]\n\n## Appendix: Sources\n\n- Composed from: [ One-line list of workflow templates and skills this task was composed from. ]\n```\n\n### Requirements for Writing Tasks\n\n- Filter incoming mechanism prescriptions and translate them into observable outcome criteria. Line numbers, line ranges, and narrow code slice prescriptions are strictly forbidden in `Goal`, `Acceptance`, and `Instructions`. Give the worker the end state and the bounds; leave the method to it.\n- Record the asker's own words once, in `## Ask`, with their ids, and never rewrite them: the task carries the ask as an immutable referent. Link asks to prior context, recompose into a clear logical structure, and cite message ids. Restate terse, fragmented words into clear, complete criteria, judged by fidelity to meaning and distinctions.\n- State the Goal and each criterion over the whole class the request covers. When asked what broke a mechanism, compose the debugging workflow and preserve the full failure question in Acceptance across its lifecycle rather than narrowing to a single symptom.\n- Every heading is a prompt to fill without restriction slots: say what has to be done, not what shouldn't.\n- Keep each task strictly concise: 50–150 words for atomic tasks, up to 300 words for multi-stage composite workflows, `## Ask` aside. Include only what the worker cannot find for itself.\n- Interpret workflow template stages into concise numbered imperative steps; never paste template narrative, rationale, or explanatory background.\n- Assume the worker could run anywhere; never reference local paths, tools, or conventions. Leave out methods, command scripts, tool names, runtime hints, limits, summaries of linked notes, provenance, changelogs, session narratives, counts, SHAs, and history.\n- Change an existing task only for a defect in its text; never rewrite its `## Ask` or renumber its criteria.\n- A skill may be a step (`invoke \u002F\u003Cskill-name>`). A workflow template is never a step; its steps are.\n- Close every task with a one-line appendix section listing the workflow templates and skills it was composed from: `## Appendix: Sources` followed by `- Composed from: \u003Cworkflows and skills>.`\n- Do not create standalone decision tasks or file questions as tasks. Groundwork-first route decisions invariant applies. Competing candidate options stay inside the body of the scoping task or ADR until chosen. Model unknowns as empirical probes (`classification: probe`) wired via `needs: [\u003Cprobe_task_id>]`.\n- Worker state-only vs container supervision boundary: plain leaf workers (`\u002Fpull`) mutate only their claimed task's own state and never mint follow-up tasks; container coordinators (`\u002Fsupervise`) enrich their claimed task via `\u002Freify` and create follow-up tasks solely under the strict out-of-session splitting conditions above.\n- Reify plans, roadmaps, and designs as tasks on the PKB task graph.\n\n## 4. Report\n\nStop once tasks are written to the graph; `\u002Fdispatch` starts their workers. For each task written or confirmed ready, output:\n\n- Title, ID, status, and open `needs` dependencies.\n- Composed sources in the identical one-line format appended to the task body under `## Appendix: Sources` (e.g. `- Composed from: wf-feature, \u002Fcraft`).\n",{"name":5,"description":7},"main","2a43a5aed762a03731703bdcf299010a8db68115","ida-claude\u002Fskills\u002Freify",3,"https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps","https:\u002F\u002Fgithub.com\u002Fnicsuzor","https:\u002F\u002Fnic.suzor.net\u002F","2026-11-15 00:29:29",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add nicsuzor\u002FacademicOps --skill reify",{"tool":57,"command":58},"bunx","bunx skills add nicsuzor\u002FacademicOps --skill reify",{"tool":60,"command":61},"pnpm","pnpm dlx skills add nicsuzor\u002FacademicOps --skill reify","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fida-claude\u002Fskills\u002Freify\u002FSKILL.md",true,[],[66,91,96,101,106,126],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":38},"01M6M6JR6VXPDA3MDPVS36DSSP","refresh-questions","Sweep and refresh open questions in the Telegram Mini App by closing questions that are answered elsewhere, superseded, or asking for completed actions, and ensuring active open questions carry recommendations and context. Use when asked to refresh questions, sweep stale questions, or keep the Mini App decision queue current. Exclude for asking new questions or routine chat replies.","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fopenclaw\u002Fida-telegram\u002Fskills\u002Frefresh-questions\u002FSKILL.md",[],[73,74,75,76,77,78,79,24,80,81,82,83,84,85,86,87,19,88,89,90],"refresh","questions","refresh questions","replies","chat","app","closing","active","recommendations","actions","decision","telegram mini app","stale","open","queue","keep","telegram","context",{"skillNo":92,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":38},"01M6M6JGW7Q0SC5B28TQ7PKE8E","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fida-telegram-openclaw\u002Fskills\u002Frefresh-questions\u002FSKILL.md",[],[73,74,75,76,77,78,79,24,80,81,82,83,84,85,86,87,19,88,89,90],{"skillNo":97,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":38},"01M6M6J7D0ZTQ4VSS5ADRSA12E","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fida-telegram-claude\u002Fskills\u002Frefresh-questions\u002FSKILL.md",[],[73,74,75,76,77,78,79,24,80,81,82,83,84,85,86,87,19,88,89,90],{"skillNo":102,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":38},"01M6M6EP6BK1DDN2212S7Y95G0","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fcowork\u002Fida-telegram\u002Fskills\u002Frefresh-questions\u002FSKILL.md",[],[73,74,75,76,77,78,79,24,80,81,82,83,84,85,86,87,19,88,89,90],{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":38},"01M6G9Q8538NENA2TE2V4HPRSF","dispatch-queue","Rank and present queued repo-scoped epic tasks ready for dispatch with recommendations, and launch polecat containers on tasks the user approves per wf-dispatch-queue. Use for \"what's ready\", \"what should we dispatch\", or \"dispatch the queue\". Exclude for non-interactive dispatch of named tasks (use \u002Fdispatch) or graph truth maintenance (use \u002Freconcile).","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fopenclaw\u002Fida\u002Fskills\u002Fdispatch-queue\u002FSKILL.md",[],[31,87,113,114,115,116,117,118,119,120,121,122,123,19,28,27,26,124,125],"dispatch queue","with","ready","show","maintenance","template","recommendation","choice","start","reconcile","wf","user","graph",{"skillNo":127,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":38},"01M6G9P9M3PQXPX3647RA5E4D0","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fida-openclaw\u002Fskills\u002Fdispatch-queue\u002FSKILL.md",[],[31,87,113,114,115,116,117,118,119,120,121,122,123,19,28,27,26,124,125]]