[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DGZTHAMR2KXB05W25BJ74J":3,"skill-same:01M6DGZTHAMR2KXB05W25BJ74J":53},{"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":26,"linkOnly":27,"markdownContent":28,"markdownBody":29,"frontMatter":30,"refName":31,"commitSha":32,"skillDirectory":33,"forksCount":34,"repositoryHtmlUrl":35,"repositoryHomepageUrl":6,"ownerHtmlUrl":36,"ownerBlogUrl":37,"ownerDescription":6,"updatedAt":38,"install":39,"resources":52},"01M6DGZTHAMR2KXB05W25BJ74J","pull",null,"Claim and execute a queued PKB task to completion, record verified results, and hand over via \u002Fdump.","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\u002Fcowork\u002Fida\u002Fskills\u002Fpull\u002FSKILL.md",[],[5,19,20,21,22,23,24,25],"claim","record","execute","results","task","dump","subagents","2026-11-10 10:12:30",false,"---\nname: pull\ndescription: Claim and execute a queued PKB task to completion, record verified results, and hand over via \u002Fdump.\n---\n\n# Pull\n\nClaim and execute a queued PKB task to deliver against stated acceptance criteria, coordinating subagents where appropriate, then invoke `\u002Fdump` to log results and hand over.\n\n## Procedure\n\n### 1. Claim Task\n\n- Claim your assigned task ID via PKB task claiming tools (`pkb_claim_task`, setting `assignee` to your agent or role). If missing, locate it via PKB search.\n- Authority extends strictly to the claimed task and its descendants. If blocked by external dependencies, complete what is possible and release remaining work.\n- **Intake Contract:** When claiming a tracked task, the receiving agent records its summary stating deliverables as a frozen `## Acceptance` checklist on the claimed PKB task before work starts. Internal in-session subagents, lookups, and fast-path dispatch workflows never create additional tasks on the graph.\n- Coordinator sessions use `\u002Fpull` strictly for lightweight documentation, synthesis, or coordination tasks running no test suites or large codebase greps; substantive implementation, codebase sweeps, and test execution tasks must be dispatched to polecats via `\u002Fdispatch`.\n\n### 2. Execute and Supervise\n\n- Execute task requirements, coordinating subagents in parallel where warranted.\n- Break work into sequenced steps, managing failures upstream without applying hidden workarounds.\n- **Full-context file inspection**: Before modifying any repository file, the worker must read the entire target file in full to understand surrounding architecture, conventions, and helper abstractions. Keyhole line-slice reads (`read_file` with narrow line windows around advisory line hints) in isolation without prior whole-file context are strictly prohibited; line numbers are advisory starting pointers only. If a target file exceeds tool page limits, inspect the complete file via sequential discovery before editing.\n\n### 3. Consolidate Findings\n\n- Write the handback proof `\u002Fdump` records under `## Report`: the `premise-check` `argdown` block, asked by the task's frozen ask ids, with the basis of every load-bearing premise.\n\n### 4. Validate Against Criteria\n\n- Verify deliverables against literal acceptance criteria using primary evidence and pinpoint citations. An item is ticked only with evidence of that item itself; any other item stays unticked with its limit stated.\n- Mark the task `done` via `\u002Fdump` only when its `## Report` argument answers each `\u003Ctask id>\u002FAC\u003Cn>` from concrete evidence: quoted output, `file:line` citations, counts, and the specimen run where the task asks for one. Asserting that tests ran or that work was done without concrete evidence in the report is insufficient; if any acceptance item lacks evidence in the Report, release as `partial` naming the missing evidence.\n- Release as `done` or `partial` by default. A worker whose deliverable is a PR marks any draft PR ready for review as soon as its code step completes without waiting for approval, releases `done` once the PR is open, with `pr_url` and branch recorded on the record, and exits without waiting for CI, review or merge: releasing `done` immediately unblocks dependent QA and review follow-up tasks on the graph. `partial` is reserved strictly for the worker's own unfinished acceptance items. Never release as `review` or send a complete deliverable to `partial` because of a dependent check or follow-up.\n- If the worker's own deliverable is incomplete -- an external blocker, a missing tool, or a scope seam -- release as `partial` naming unfinished items or missing evidence in `reason`. Workers never create or name follow-up tasks, and reports carry no 'Next task' pointer; the reconcile pass notes partial and failed tasks and decides next actions from the parent epic.\n- A worker whose check fails (e.g. QA or review) releases its task as `failed` documenting failure evidence and root cause. Never file fix tasks or follow-up tasks; the reconcile pass notes failed tasks and decides next actions from the parent epic.\n- Deliver work where Output names: if Output says nothing is pushed or names only a PKB task or note, do not push. Ephemeral container and session scratch paths (`\u003CappDataDir>\u002Fbrain\u002F`, `\u002Ftmp\u002F`, unpushed container working trees) vanish on exit; non-git evaluation datasets, specimen tables, and reports must be persisted in the PKB with durable pointers rather than stored in ephemeral directories.\n- Never release as `review`. If a worker's own deliverable is incomplete due to an external blocker, missing tool, or scope seam, release as `partial` naming unfinished items and missing evidence in `reason`. When an approval boundary or decision point is reached, file the complete artifact on the record and release as `partial` documenting what decision is needed; never release as `review`.\n\n### 5. Handover\n\nInvoke `\u002Fdump` at the end of every job, whatever its release status (`done`, `partial`, `failed`, `cancelled`, or `in_progress`). `\u002Fdump` is mandatory for the final handover and for logging results at the end of every job, because exiting or releasing directly omits the `## Report` argument and session handover report.\n","# Pull\n\nClaim and execute a queued PKB task to deliver against stated acceptance criteria, coordinating subagents where appropriate, then invoke `\u002Fdump` to log results and hand over.\n\n## Procedure\n\n### 1. Claim Task\n\n- Claim your assigned task ID via PKB task claiming tools (`pkb_claim_task`, setting `assignee` to your agent or role). If missing, locate it via PKB search.\n- Authority extends strictly to the claimed task and its descendants. If blocked by external dependencies, complete what is possible and release remaining work.\n- **Intake Contract:** When claiming a tracked task, the receiving agent records its summary stating deliverables as a frozen `## Acceptance` checklist on the claimed PKB task before work starts. Internal in-session subagents, lookups, and fast-path dispatch workflows never create additional tasks on the graph.\n- Coordinator sessions use `\u002Fpull` strictly for lightweight documentation, synthesis, or coordination tasks running no test suites or large codebase greps; substantive implementation, codebase sweeps, and test execution tasks must be dispatched to polecats via `\u002Fdispatch`.\n\n### 2. Execute and Supervise\n\n- Execute task requirements, coordinating subagents in parallel where warranted.\n- Break work into sequenced steps, managing failures upstream without applying hidden workarounds.\n- **Full-context file inspection**: Before modifying any repository file, the worker must read the entire target file in full to understand surrounding architecture, conventions, and helper abstractions. Keyhole line-slice reads (`read_file` with narrow line windows around advisory line hints) in isolation without prior whole-file context are strictly prohibited; line numbers are advisory starting pointers only. If a target file exceeds tool page limits, inspect the complete file via sequential discovery before editing.\n\n### 3. Consolidate Findings\n\n- Write the handback proof `\u002Fdump` records under `## Report`: the `premise-check` `argdown` block, asked by the task's frozen ask ids, with the basis of every load-bearing premise.\n\n### 4. Validate Against Criteria\n\n- Verify deliverables against literal acceptance criteria using primary evidence and pinpoint citations. An item is ticked only with evidence of that item itself; any other item stays unticked with its limit stated.\n- Mark the task `done` via `\u002Fdump` only when its `## Report` argument answers each `\u003Ctask id>\u002FAC\u003Cn>` from concrete evidence: quoted output, `file:line` citations, counts, and the specimen run where the task asks for one. Asserting that tests ran or that work was done without concrete evidence in the report is insufficient; if any acceptance item lacks evidence in the Report, release as `partial` naming the missing evidence.\n- Release as `done` or `partial` by default. A worker whose deliverable is a PR marks any draft PR ready for review as soon as its code step completes without waiting for approval, releases `done` once the PR is open, with `pr_url` and branch recorded on the record, and exits without waiting for CI, review or merge: releasing `done` immediately unblocks dependent QA and review follow-up tasks on the graph. `partial` is reserved strictly for the worker's own unfinished acceptance items. Never release as `review` or send a complete deliverable to `partial` because of a dependent check or follow-up.\n- If the worker's own deliverable is incomplete -- an external blocker, a missing tool, or a scope seam -- release as `partial` naming unfinished items or missing evidence in `reason`. Workers never create or name follow-up tasks, and reports carry no 'Next task' pointer; the reconcile pass notes partial and failed tasks and decides next actions from the parent epic.\n- A worker whose check fails (e.g. QA or review) releases its task as `failed` documenting failure evidence and root cause. Never file fix tasks or follow-up tasks; the reconcile pass notes failed tasks and decides next actions from the parent epic.\n- Deliver work where Output names: if Output says nothing is pushed or names only a PKB task or note, do not push. Ephemeral container and session scratch paths (`\u003CappDataDir>\u002Fbrain\u002F`, `\u002Ftmp\u002F`, unpushed container working trees) vanish on exit; non-git evaluation datasets, specimen tables, and reports must be persisted in the PKB with durable pointers rather than stored in ephemeral directories.\n- Never release as `review`. If a worker's own deliverable is incomplete due to an external blocker, missing tool, or scope seam, release as `partial` naming unfinished items and missing evidence in `reason`. When an approval boundary or decision point is reached, file the complete artifact on the record and release as `partial` documenting what decision is needed; never release as `review`.\n\n### 5. Handover\n\nInvoke `\u002Fdump` at the end of every job, whatever its release status (`done`, `partial`, `failed`, `cancelled`, or `in_progress`). `\u002Fdump` is mandatory for the final handover and for logging results at the end of every job, because exiting or releasing directly omits the `## Report` argument and session handover report.\n",{"name":5,"description":7},"main","b0805858231ceb991f4455a933bb9c2101bc60c7","cowork\u002Fida\u002Fskills\u002Fpull",3,"https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps","https:\u002F\u002Fgithub.com\u002Fnicsuzor","https:\u002F\u002Fnic.suzor.net\u002F","2026-11-13 21:19:25",{"source":8,"skillName":5,"commands":40,"prompt":50,"zipAvailable":51},[41,44,47],{"tool":42,"command":43},"npx","npx skills add nicsuzor\u002FacademicOps --skill pull",{"tool":45,"command":46},"bunx","bunx skills add nicsuzor\u002FacademicOps --skill pull",{"tool":48,"command":49},"pnpm","pnpm dlx skills add nicsuzor\u002FacademicOps --skill pull","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fcowork\u002Fida\u002Fskills\u002Fpull\u002FSKILL.md",true,[],[54,81,86,91,96,120],{"skillNo":55,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":58,"categories":59,"keywords":60,"publishedAt":26},"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",[],[61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80],"refresh","refresh questions","questions","actions","telegram mini app","open","decision","context","use","queue","telegram","stale","chat","active","recommendations","app","keep","replies","closing","for",{"skillNo":82,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":26},"01M6M6JGW7Q0SC5B28TQ7PKE8E","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fida-telegram-openclaw\u002Fskills\u002Frefresh-questions\u002FSKILL.md",[],[61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80],{"skillNo":87,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":26},"01M6M6J7D0ZTQ4VSS5ADRSA12E","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fida-telegram-claude\u002Fskills\u002Frefresh-questions\u002FSKILL.md",[],[61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80],{"skillNo":92,"name":56,"nameZh":6,"description":57,"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":26},"01M6M6EP6BK1DDN2212S7Y95G0","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fcowork\u002Fida-telegram\u002Fskills\u002Frefresh-questions\u002FSKILL.md",[],[61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80],{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":26},"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",[],[103,70,104,105,106,107,108,109,110,111,69,112,113,114,115,116,117,118,119],"dispatch","dispatch queue","workflow","tasks","graph","start","template","choice","user","reconcile","ready","maintenance","workers","show","wf","recommendation","with",{"skillNo":121,"name":98,"nameZh":6,"description":99,"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":26},"01M6G9P9M3PQXPX3647RA5E4D0","https:\u002F\u002Fgithub.com\u002Fnicsuzor\u002FacademicOps\u002Fblob\u002Fmain\u002Fida-openclaw\u002Fskills\u002Fdispatch-queue\u002FSKILL.md",[],[103,70,104,105,106,107,108,109,110,111,69,112,113,114,115,116,117,118,119]]