[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DHDTHF28E4A9JTH7KB1Y41":3,"skill-same:01M6DHDTHF28E4A9JTH7KB1Y41":76},{"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":23,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6DHDTHF28E4A9JTH7KB1Y41","craft",null,"Authoring standard and quality gate for agent-facing instruction text and workflow templates. Use when writing, reviewing, or revising SKILL.md bodies, frontmatter descriptions, agent definitions, subagent prompts, tool descriptions, or workflow templates. Exclude for human-facing prose (specs, reports).","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-openclaw\u002Fskills\u002Fcraft\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"human","prompts","prose","authoring","templates","gate","edit","write","read","quality","text","reports","subagent","workflow","use","writing","tool","quality gate","2026-11-10 10:12:30",false,"---\nname: craft\ndescription: Authoring standard and quality gate for agent-facing instruction text and workflow templates. Use when writing, reviewing, or revising SKILL.md bodies, frontmatter descriptions, agent definitions, subagent prompts, tool descriptions, or workflow templates. Exclude for human-facing prose (specs, reports).\nallowed-tools: Read, Write, Edit\n---\n\n# Instruction Craftsmanship\n\nAuthor and review agent-facing instructions, personas, and workflow templates for operational clarity, contract separation, instruction density, and token efficiency.\n\n## First Principles\n\n1. **Trust the harness, not today's quirks**: Write for durable capabilities. Avoid hard-coding workarounds for transient model behaviors.\n2. **Specify process, not keystrokes**: State when to invoke a capability and what outcome proves it worked. Omit basic sub-steps or flags the agent already knows.\n3. **One component, one job**: Keep instructions and templates focused on their singular purpose. Dispatch to peer skills rather than summarizing their internals. Leave another agent's domain to that agent: name the hand-off, never how it does its work.\n4. **State the contract, not the neighbour**: Specify what a component needs as input and delivers as output. Never couple to specific neighbour names or slugs; composing agents decide what fills each slot.\n5. **Decouple persona from execution (Who vs How)**: Personas establish persistent identity, authority boundaries, and behavioral tone; skills define modular, reusable execution recipes. Personas name capabilities without inlining skill mechanics; skills specify operational contracts, and where one agent owns a skill the skill names that owner in one line so callers route to it, with the body otherwise written for any capable agent.\n6. **Progressive disclosure over monolithic injection**: Expose only routing metadata upfront; load procedural bodies just-in-time, and offload dense references to on-demand files.\n7. **Write for a headless worker**: Assume unattended, asynchronous execution with no interactive human in the loop. A step never pauses or waits for human input; explicit approval boundaries terminate the task and wire dependent tasks as blocked.\n8. **Promise only what the executor delivers**: Output contracts list only artifacts and state the executing agent itself produces. Another party's subsequent act (human sign-off, reviewer verdict) is never an executor deliverable.\n9. **Verification must be real**: Demand direct inspection of live artifacts (outputs, logs, diffs) rather than relying on compliance checklists.\n10. **Instruction density over conversational prose**: Maximize high-signal constraints per token. Every line earns its place; eliminate incident stories, post-mortems, and historical rationales.\n\n## The Deletion Test\n\nDelete or relocate any line whose removal leaves the median task unaffected. Confine rare paths and deep schemas to progressive reference files. Eliminate legacy patches and bug retrospectives; instructions define current state only.\n\n## Persona vs. Skill Boundaries\n\nMaintain strict architectural separation between agent definitions and skill instructions:\n\n1. **Agent Personas (The \"Who\")**: Global, persistent system instructions loaded on every turn. Bound to 5–10% of base token budget. Define role identity (1–3 sentences), authority limits, behavioral postures, output schemas, and safety invariants.\n2. **Skills (The \"How\")**: Modular, transient workflow packages loaded just-in-time when invoked. Define step-by-step procedures, tool calling sequences, input\u002Foutput contracts, and validation criteria.\n3. **Linking and Decoupling**:\n   - **Personas never inline skill mechanics**: An agent persona names available skills or declares tool access, but never prescribes a skill's internal steps, modes, or argument flags. Skills evolve without requiring persona updates.\n   - **Skills name an owner, never a persona's mechanics**: Instructions define objective contracts executable by any capable agent. A skill one agent is responsible for states that owner once (description and opening line) and nothing else about the persona; the procedure carries no persona-specific language or assumptions.\n\n### Three-Level Progressive Disclosure\n\nTo prevent context bloat and instruction dilution, structure skill packages in three tiers:\n\n- **Level 1: Frontmatter Metadata (Router)**: `name` and `description` loaded into the system prompt. Acts as the semantic router.\n- **Level 2: Skill Body (`SKILL.md`)**: Operational instructions loaded just-in-time when the skill is claimed or triggered.\n- **Level 3: Auxiliary References (`references\u002F`, `scripts\u002F`)**: Detailed schemas, reference manuals, or executable tools stored exactly one directory deep and loaded on demand.\n\n#### Incorporating Level 3 References\n\nAgents rarely explore unprompted reference files. To ensure Level 3 assets are read reliably without bloating median context:\n\n1. **Imperative Procedural Gating**: Never rely on passive suggestions (\"see references\u002F...\", \"consult X\"). State an explicit condition, exact relative path, and action in the Level 2 procedure: e.g., `If \u003Ccondition>, read references\u002F\u003Cfile>.md before \u003Caction>`.\n2. **Shape Inline, Depth in Reference**: Provide structural contracts, schema skeletons, and expected shapes inline in the Level 2 body so the agent understands the pattern immediately. Use Level 3 files strictly for exhaustive enumerations, raw schemas, or rare edge cases.\n3. **The Median Path Invariant**: If an agent must read a file on the median execution path, that content belongs inline in Level 2 (refactored to fit the 30–80 line budget), not in Level 3. Level 3 is reserved strictly for off-median branches, deep references, or secondary lookups.\n\n## Length Budgets by Instruction Type\n\nAdhere to quantitative token and line limits to prevent attention degradation (\"Lost in the Middle\") and instruction dilution:\n\n| Instruction Type | Target Length | Hard Ceiling | Contents & Placement |\n| :- | :- | :- | :- |\n| **Agent Persona** | 30–60 lines (~200–500 tokens) | 100 lines (\u003C2,500 chars) | Role identity, behavioral boundaries, safety invariants, output schema. |\n| **Skill Description** | 1–3 sentences (150–400 chars) | 1,024 chars | Frontmatter router: trigger conditions, primary domain, explicit exclusions. |\n| **Skill Body (`SKILL.md`)** | 30–80 lines (~400–1,000 tokens) | 150–200 lines (~1,500 tokens) | Step-by-step procedure, input\u002Foutput contract, verification gate. |\n| **Workflow Template** | 30–60 lines | 100 lines | High-level stage composition and handoff contracts. |\n| **Tool Description** | 150–400 chars | 800 chars | Purpose, when to use, when NOT to use, argument constraints. |\n| **Reference File (Level 3)** | 50–150 lines | 300 lines | Modular single-topic technical documentation or schemas. |\n\n## The Description Is the Router\n\nFrontmatter descriptions are the primary routing surface (target 150–400 chars, ceiling 1,024 chars). Because affirmative instructions yield significantly higher compliance (IFEval, arXiv:2507.22462), descriptions must be affirmative-first:\n\n- **Affirmative-First Structure (1–3 sentences)**:\n  1. _Core Capability_: Active imperative stating the primary domain and outcome (Sentence 1).\n  2. _Trigger Conditions_: Explicit phrases, user asks, and task contexts where the skill applies (Sentence 2).\n  3. _Contrastive Exclusions_: Terse negative boundaries paired with alternative redirects (Sentence 3).\n- **Proportionate Exclusions**: Dedicate at least 75% of the description budget to positive capabilities and trigger conditions. Do NOT compile exhaustive lists of what a skill is not--negative enumerations dilute semantic matching and cause under-triggering.\n- **Contrastive Redirects**: Limit exclusions strictly to real adjacent competitors or collision domains where ambiguity exists, and always name the alternative tool or peer skill (e.g., `Exclude for X (use Y)`).\n- **Consolidate Routing**: Place all triggering logic in the description field. Auxiliary fields (e.g. `when_to_use`) are non-portable.\n\n## The Body Is a Budget\n\nHold operational content strictly under the 200-line ceiling (target 30–80 lines):\n\n- **Structural Anchoring (Primacy & Recency)**: Place critical invariants, boundary constraints, and stopping rules at the very start or very end where model attention is highest.\n- **Progressive disclosure**: Offload dense reference tables, schemas, or script definitions to `references\u002F` or `scripts\u002F`.\n- **Provide shape, not logic**: Provide structural skeletons rather than full worked logic examples that induce overfitting.\n\n## Concision and Instruction Density\n\nMaximize actionable constraints per token:\n\n- **Positive imperatives with functional reasoning**: Frame rules around what the agent must do, paired with functional reasoning (\"Use X because Y\"). Functional clauses help models generalize.\n- **Pair prohibitions with alternatives**: Every prohibition must state the mandatory affirmative path and legitimate escape hatch.\n- **Eliminate conversational padding**: Strip politeness, conversational framing, and rhetorical flourishes.\n- **Static prefix, variable tail**: Structure instructions with invariant rules and templates first, appending dynamic content at the end to maximize prompt cache hits.\n\n## Workflow Templates\n\nWorkflow templates (`type: template`) govern repeatable multi-stage execution and task composition (\u003C100 lines target).\n\n- **Schema**:\n  ```yaml\n  ---\n  title: \u003Chuman name>\n  type: template\n  description: \u003Cone line: what class of work this covers, so a composer can select it>\n  tags: [...]\n  ---\n  ```\n- **Contract over neighbour**: Define input and output contracts per stage. Never name another template slug in frontmatter or body. A composite lists stages as contract expectations in order (\"an independent review verdict on the spec\"), never as slugs.\n- **Headless execution & approval boundaries**: A step never pauses, waits, or prompts a human mid-task. Where approval is required, the step ends there: the worker files the complete artifact on the record and structures the boundary so downstream work remains strictly blocked until approval is recorded (e.g. releasing as `partial` with an explicit decision task or dependency-wired review task). Cut the composition chain at that boundary; work following the decision belongs in a separate dependent task.\n- **Promise only executor deliverables**: Output contracts specify only artifacts and state generated by the executing agent. Future external decisions or approvals are not executor deliverables.\n- **`wf-` prefix**: Templates stating an obligation that blocks acceptance rather than a process that proceeds conventionally carry a `wf-` prefix.\n\n## Quality Gates\n\nEvery agent instruction, skill, persona definition, and subagent prompt must pass these five gates before merging:\n\n1. **Categorical generality (Categorical Imperative)**: Express rules in general terms covering the full class of situations. Prohibit hyper-specific quotas, rigid interaction numbers, or one-off compromises.\n2. **Entity abstraction (Name the process, not the actor)**: Refer to the principal as \"the user\", never by a personal proper noun or name. Refer to collaborators by role or capability.\n3. **No PKB leakage (Data Boundaries)**: Never include private PKB note or task IDs (`aops_...`, `task_...`, `mem_...`, `kb_...`) or Obsidian wikilinks (`[[...]]`) in distributed framework instruction files. Use standard relative markdown links for file references.\n4. **Zero historical provenance (CURRENT STATE ONLY)**: Strictly eliminate incident stories, post-mortem recaps (\"after an incident on...\"), PR\u002Fcommit changelog citations, or historical `sources:` frontmatter arrays. Instructions, workflow templates, and knowledge notes define what is true now, never how it came to be true. No instruction, skill, or workflow template may instruct agents to accumulate or maintain historical source lists or obsolete prior-state material.\n5. **Adjudication against empirical evidence**: When an instruction design choice or length budget is contested during review, cite the empirical findings and sources in `references\u002Fevidence.md`.\n\n## Agent Definitions\n\nLimit agent definition bodies to:\n\n1. **Identity\u002Frole**: 1–3 sentences defining the persona.\n2. **Behavioral rules**: Terse operational constraints.\n3. **Output schema**: Expected report structure and verdict states.\n4. **Routing table**: Clean table without per-route narrative.\n\nName a skill the agent uses; leave its modes, arguments, and when each applies to the skill. A change to a skill's modes or arguments owes the agent definitions that use it no edit.\n\n## Schemas and Construction\n\n- Define strict schemas with `required` fields and `additionalProperties: false`.\n- **Static prefix, variable tail**: Emit invariant template text first and append variable content at the end to maximize prompt caching.\n","# Instruction Craftsmanship\n\nAuthor and review agent-facing instructions, personas, and workflow templates for operational clarity, contract separation, instruction density, and token efficiency.\n\n## First Principles\n\n1. **Trust the harness, not today's quirks**: Write for durable capabilities. Avoid hard-coding workarounds for transient model behaviors.\n2. **Specify process, not keystrokes**: State when to invoke a capability and what outcome proves it worked. Omit basic sub-steps or flags the agent already knows.\n3. **One component, one job**: Keep instructions and templates focused on their singular purpose. Dispatch to peer skills rather than summarizing their internals. Leave another agent's domain to that agent: name the hand-off, never how it does its work.\n4. **State the contract, not the neighbour**: Specify what a component needs as input and delivers as output. Never couple to specific neighbour names or slugs; composing agents decide what fills each slot.\n5. **Decouple persona from execution (Who vs How)**: Personas establish persistent identity, authority boundaries, and behavioral tone; skills define modular, reusable execution recipes. Personas name capabilities without inlining skill mechanics; skills specify operational contracts, and where one agent owns a skill the skill names that owner in one line so callers route to it, with the body otherwise written for any capable agent.\n6. **Progressive disclosure over monolithic injection**: Expose only routing metadata upfront; load procedural bodies just-in-time, and offload dense references to on-demand files.\n7. **Write for a headless worker**: Assume unattended, asynchronous execution with no interactive human in the loop. A step never pauses or waits for human input; explicit approval boundaries terminate the task and wire dependent tasks as blocked.\n8. **Promise only what the executor delivers**: Output contracts list only artifacts and state the executing agent itself produces. Another party's subsequent act (human sign-off, reviewer verdict) is never an executor deliverable.\n9. **Verification must be real**: Demand direct inspection of live artifacts (outputs, logs, diffs) rather than relying on compliance checklists.\n10. **Instruction density over conversational prose**: Maximize high-signal constraints per token. Every line earns its place; eliminate incident stories, post-mortems, and historical rationales.\n\n## The Deletion Test\n\nDelete or relocate any line whose removal leaves the median task unaffected. Confine rare paths and deep schemas to progressive reference files. Eliminate legacy patches and bug retrospectives; instructions define current state only.\n\n## Persona vs. Skill Boundaries\n\nMaintain strict architectural separation between agent definitions and skill instructions:\n\n1. **Agent Personas (The \"Who\")**: Global, persistent system instructions loaded on every turn. Bound to 5–10% of base token budget. Define role identity (1–3 sentences), authority limits, behavioral postures, output schemas, and safety invariants.\n2. **Skills (The \"How\")**: Modular, transient workflow packages loaded just-in-time when invoked. Define step-by-step procedures, tool calling sequences, input\u002Foutput contracts, and validation criteria.\n3. **Linking and Decoupling**:\n   - **Personas never inline skill mechanics**: An agent persona names available skills or declares tool access, but never prescribes a skill's internal steps, modes, or argument flags. Skills evolve without requiring persona updates.\n   - **Skills name an owner, never a persona's mechanics**: Instructions define objective contracts executable by any capable agent. A skill one agent is responsible for states that owner once (description and opening line) and nothing else about the persona; the procedure carries no persona-specific language or assumptions.\n\n### Three-Level Progressive Disclosure\n\nTo prevent context bloat and instruction dilution, structure skill packages in three tiers:\n\n- **Level 1: Frontmatter Metadata (Router)**: `name` and `description` loaded into the system prompt. Acts as the semantic router.\n- **Level 2: Skill Body (`SKILL.md`)**: Operational instructions loaded just-in-time when the skill is claimed or triggered.\n- **Level 3: Auxiliary References (`references\u002F`, `scripts\u002F`)**: Detailed schemas, reference manuals, or executable tools stored exactly one directory deep and loaded on demand.\n\n#### Incorporating Level 3 References\n\nAgents rarely explore unprompted reference files. To ensure Level 3 assets are read reliably without bloating median context:\n\n1. **Imperative Procedural Gating**: Never rely on passive suggestions (\"see references\u002F...\", \"consult X\"). State an explicit condition, exact relative path, and action in the Level 2 procedure: e.g., `If \u003Ccondition>, read references\u002F\u003Cfile>.md before \u003Caction>`.\n2. **Shape Inline, Depth in Reference**: Provide structural contracts, schema skeletons, and expected shapes inline in the Level 2 body so the agent understands the pattern immediately. Use Level 3 files strictly for exhaustive enumerations, raw schemas, or rare edge cases.\n3. **The Median Path Invariant**: If an agent must read a file on the median execution path, that content belongs inline in Level 2 (refactored to fit the 30–80 line budget), not in Level 3. Level 3 is reserved strictly for off-median branches, deep references, or secondary lookups.\n\n## Length Budgets by Instruction Type\n\nAdhere to quantitative token and line limits to prevent attention degradation (\"Lost in the Middle\") and instruction dilution:\n\n| Instruction Type | Target Length | Hard Ceiling | Contents & Placement |\n| :- | :- | :- | :- |\n| **Agent Persona** | 30–60 lines (~200–500 tokens) | 100 lines (\u003C2,500 chars) | Role identity, behavioral boundaries, safety invariants, output schema. |\n| **Skill Description** | 1–3 sentences (150–400 chars) | 1,024 chars | Frontmatter router: trigger conditions, primary domain, explicit exclusions. |\n| **Skill Body (`SKILL.md`)** | 30–80 lines (~400–1,000 tokens) | 150–200 lines (~1,500 tokens) | Step-by-step procedure, input\u002Foutput contract, verification gate. |\n| **Workflow Template** | 30–60 lines | 100 lines | High-level stage composition and handoff contracts. |\n| **Tool Description** | 150–400 chars | 800 chars | Purpose, when to use, when NOT to use, argument constraints. |\n| **Reference File (Level 3)** | 50–150 lines | 300 lines | Modular single-topic technical documentation or schemas. |\n\n## The Description Is the Router\n\nFrontmatter descriptions are the primary routing surface (target 150–400 chars, ceiling 1,024 chars). Because affirmative instructions yield significantly higher compliance (IFEval, arXiv:2507.22462), descriptions must be affirmative-first:\n\n- **Affirmative-First Structure (1–3 sentences)**:\n  1. _Core Capability_: Active imperative stating the primary domain and outcome (Sentence 1).\n  2. _Trigger Conditions_: Explicit phrases, user asks, and task contexts where the skill applies (Sentence 2).\n  3. _Contrastive Exclusions_: Terse negative boundaries paired with alternative redirects (Sentence 3).\n- **Proportionate Exclusions**: Dedicate at least 75% of the description budget to positive capabilities and trigger conditions. Do NOT compile exhaustive lists of what a skill is not--negative enumerations dilute semantic matching and cause under-triggering.\n- **Contrastive Redirects**: Limit exclusions strictly to real adjacent competitors or collision domains where ambiguity exists, and always name the alternative tool or peer skill (e.g., `Exclude for X (use Y)`).\n- **Consolidate Routing**: Place all triggering logic in the description field. Auxiliary fields (e.g. `when_to_use`) are non-portable.\n\n## The Body Is a Budget\n\nHold operational content strictly under the 200-line ceiling (target 30–80 lines):\n\n- **Structural Anchoring (Primacy & Recency)**: Place critical invariants, boundary constraints, and stopping rules at the very start or very end where model attention is highest.\n- **Progressive disclosure**: Offload dense reference tables, schemas, or script definitions to `references\u002F` or `scripts\u002F`.\n- **Provide shape, not logic**: Provide structural skeletons rather than full worked logic examples that induce overfitting.\n\n## Concision and Instruction Density\n\nMaximize actionable constraints per token:\n\n- **Positive imperatives with functional reasoning**: Frame rules around what the agent must do, paired with functional reasoning (\"Use X because Y\"). Functional clauses help models generalize.\n- **Pair prohibitions with alternatives**: Every prohibition must state the mandatory affirmative path and legitimate escape hatch.\n- **Eliminate conversational padding**: Strip politeness, conversational framing, and rhetorical flourishes.\n- **Static prefix, variable tail**: Structure instructions with invariant rules and templates first, appending dynamic content at the end to maximize prompt cache hits.\n\n## Workflow Templates\n\nWorkflow templates (`type: template`) govern repeatable multi-stage execution and task composition (\u003C100 lines target).\n\n- **Schema**:\n  ```yaml\n  ---\n  title: \u003Chuman name>\n  type: template\n  description: \u003Cone line: what class of work this covers, so a composer can select it>\n  tags: [...]\n  ---\n  ```\n- **Contract over neighbour**: Define input and output contracts per stage. Never name another template slug in frontmatter or body. A composite lists stages as contract expectations in order (\"an independent review verdict on the spec\"), never as slugs.\n- **Headless execution & approval boundaries**: A step never pauses, waits, or prompts a human mid-task. Where approval is required, the step ends there: the worker files the complete artifact on the record and structures the boundary so downstream work remains strictly blocked until approval is recorded (e.g. releasing as `partial` with an explicit decision task or dependency-wired review task). Cut the composition chain at that boundary; work following the decision belongs in a separate dependent task.\n- **Promise only executor deliverables**: Output contracts specify only artifacts and state generated by the executing agent. Future external decisions or approvals are not executor deliverables.\n- **`wf-` prefix**: Templates stating an obligation that blocks acceptance rather than a process that proceeds conventionally carry a `wf-` prefix.\n\n## Quality Gates\n\nEvery agent instruction, skill, persona definition, and subagent prompt must pass these five gates before merging:\n\n1. **Categorical generality (Categorical Imperative)**: Express rules in general terms covering the full class of situations. Prohibit hyper-specific quotas, rigid interaction numbers, or one-off compromises.\n2. **Entity abstraction (Name the process, not the actor)**: Refer to the principal as \"the user\", never by a personal proper noun or name. Refer to collaborators by role or capability.\n3. **No PKB leakage (Data Boundaries)**: Never include private PKB note or task IDs (`aops_...`, `task_...`, `mem_...`, `kb_...`) or Obsidian wikilinks (`[[...]]`) in distributed framework instruction files. Use standard relative markdown links for file references.\n4. **Zero historical provenance (CURRENT STATE ONLY)**: Strictly eliminate incident stories, post-mortem recaps (\"after an incident on...\"), PR\u002Fcommit changelog citations, or historical `sources:` frontmatter arrays. Instructions, workflow templates, and knowledge notes define what is true now, never how it came to be true. No instruction, skill, or workflow template may instruct agents to accumulate or maintain historical source lists or obsolete prior-state material.\n5. **Adjudication against empirical evidence**: When an instruction design choice or length budget is contested during review, cite the empirical findings and sources in `references\u002Fevidence.md`.\n\n## Agent Definitions\n\nLimit agent definition bodies to:\n\n1. **Identity\u002Frole**: 1–3 sentences defining the persona.\n2. **Behavioral rules**: Terse operational constraints.\n3. **Output schema**: Expected report structure and verdict states.\n4. **Routing table**: Clean table without per-route narrative.\n\nName a skill the agent uses; leave its modes, arguments, and when each applies to the skill. A change to a skill's modes or arguments owes the agent definitions that use it no edit.\n\n## Schemas and Construction\n\n- Define strict schemas with `required` fields and `additionalProperties: false`.\n- **Static prefix, variable tail**: Emit invariant template text first and append variable content at the end to maximize prompt caching.\n",{"name":5,"description":7,"allowed-tools":47},"Read, Write, Edit","main","b0805858231ceb991f4455a933bb9c2101bc60c7","ida-openclaw\u002Fskills\u002Fcraft",3,"https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps","https:\u002F\u002Fgithub.com\u002Fnicsuzor","https:\u002F\u002Fnic.suzor.net\u002F","2026-11-12 13:01:13",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add nicsuzor\u002FacademicOps --skill craft",{"tool":62,"command":63},"bunx","bunx skills add nicsuzor\u002FacademicOps --skill craft",{"tool":65,"command":66},"pnpm","pnpm dlx skills add nicsuzor\u002FacademicOps --skill craft","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fida-openclaw\u002Fskills\u002Fcraft\u002FSKILL.md",true,[70],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Fevidence.md","REFERENCE","参考文档",4707,"https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fida-openclaw\u002Fskills\u002Fcraft\u002Freferences\u002Fevidence.md",[77,103,108,113,118,141],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":42},"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",[],[84,85,86,87,88,89,90,91,38,92,93,94,95,96,97,98,99,100,101,102],"refresh","refresh questions","questions","actions","telegram mini app","open","decision","context","queue","telegram","stale","chat","active","recommendations","app","keep","replies","closing","for",{"skillNo":104,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":42},"01M6M6JGW7Q0SC5B28TQ7PKE8E","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fida-telegram-openclaw\u002Fskills\u002Frefresh-questions\u002FSKILL.md",[],[84,85,86,87,88,89,90,91,38,92,93,94,95,96,97,98,99,100,101,102],{"skillNo":109,"name":79,"nameZh":6,"description":80,"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":42},"01M6M6J7D0ZTQ4VSS5ADRSA12E","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fida-telegram-claude\u002Fskills\u002Frefresh-questions\u002FSKILL.md",[],[84,85,86,87,88,89,90,91,38,92,93,94,95,96,97,98,99,100,101,102],{"skillNo":114,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":42},"01M6M6EP6BK1DDN2212S7Y95G0","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fcowork\u002Fida-telegram\u002Fskills\u002Frefresh-questions\u002FSKILL.md",[],[84,85,86,87,88,89,90,91,38,92,93,94,95,96,97,98,99,100,101,102],{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"publishedAt":42},"01M6G9Q8538NENA2TE2V4HPRSF","dispatch-queue","Show the user the tasks ready to dispatch, ranked with a recommendation on each, and start workers on the ones the user approves -- redirects to universal workflow template wf-dispatch-queue. Use for \"what's ready\", \"what should we dispatch\", or \"dispatch the queue\". Exclude for starting workers on named tasks without the user's choice (use dispatch) or graph truth maintenance (use reconcile).","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fopenclaw\u002Fida\u002Fskills\u002Fdispatch-queue\u002FSKILL.md",[],[125,92,126,37,127,128,129,130,131,132,38,133,134,135,136,137,138,139,140],"dispatch","dispatch queue","tasks","graph","start","template","choice","user","reconcile","ready","maintenance","workers","show","wf","recommendation","with",{"skillNo":142,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":42},"01M6G9P9M3PQXPX3647RA5E4D0","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fida-openclaw\u002Fskills\u002Fdispatch-queue\u002FSKILL.md",[],[125,92,126,37,127,128,129,130,131,132,38,133,134,135,136,137,138,139,140]]