[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M698V35YF5Z6BB5K1GEE3HTJ":3,"skill-same:01M698V35YF5Z6BB5K1GEE3HTJ":121},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":53,"ownerHtmlUrl":54,"ownerBlogUrl":53,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M698V35YF5Z6BB5K1GEE3HTJ","knowledge-claim-consolidation",null,"Review and consolidate Knowledge claims over a chosen scope - the unlinked residue after relinking, the claims on one hub or over-budget page, or the claims about one subject since a date. File claims on their most specific subject page, create pages for substantial subjects, retire duplicates, supersede status snapshots and replaced claims by an existing claim, and fold durable outcomes into page State. Use for claim cleanup, consolidation, or the Knowledge Consolidation scribe.","openclaw\u002Fopenclaw","openclaw","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F252820863?v=4","01M698P3FSAZ6B4R928ZF19KPT","01M698PDMDRVH56MV30D253NFP",394302,"MIT","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Fknowledge\u002Fskills\u002Fknowledge-claim-consolidation\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"consolidation","claim","knowledge","knowledge claim consolidation","pages","create","state","supersede","consolidate","file","snapshots","Existing","use","cleanup","page","for","scope","duplicates","Fold","review","2026-11-10 10:12:30",false,"---\nname: knowledge-claim-consolidation\ndescription: Review and consolidate Knowledge claims over a chosen scope - the unlinked residue after relinking, the claims on one hub or over-budget page, or the claims about one subject since a date. File claims on their most specific subject page, create pages for substantial subjects, retire duplicates, supersede status snapshots and replaced claims by an existing claim, and fold durable outcomes into page State. Use for claim cleanup, consolidation, or the Knowledge Consolidation scribe.\n---\n\n# Claim consolidation review\n\nRead [shared conventions](references\u002Fconventions.md) and\n[publication](references\u002Fpublication.md) before writes.\n\nClaims accumulate faster than pages are curated. `knowledge_remember` saves a\nclaim without a subject page when no name in it matches exactly one page, and\nscheduled maintenance's `knowledge_relink` links only claims whose source page\nis an entity page or whose text names exactly one page. Linked claims pile up\ntoo: a hub page collects status snapshots, duplicates and claims that belong on\na more specific subject. This review runs one procedure over a chosen scope.\nWork in this order: choose the scope, link, then duplicates, replaced claims\nand snapshot series, then page prose.\n\n## 1. Choose the scope and enumerate it\n\nCall `knowledge_status` for the intended scope and `knowledge_ontology` for the\ncurrent fingerprint. Then enumerate exactly one starting set:\n\n- **Unlinked residue** (the default, and the only scope of scribe runs). Run\n  `knowledge_relink` without `dryRun` first so every remembered claim it can\n  link is linked. Then list the residue with `knowledge_relink` `dryRun: true`,\n  `include: \"all\"` and `limit: 10`, following `nextCursor`: every current\n  claim with no linked page and no source page, whichever tool saved it. Each\n  call reports at most 10 examples per outcome, so a limit of 10 returns every\n  claim it examined.\n- **One page**, for a hub page or a page over its size budget. List its\n  current claims with `knowledge_connections` `id` and `direction: \"claims\"`;\n  each row carries the claim's text, kind, day, linked page titles and\n  16-character hash. Follow `nextOffset` with the same filters. Restart when `snapshot` changes. On a hub, group from the cards\n  first and work one group at a time; do not read every claim in full up front.\n- **One subject, optionally since a date.** When the subject has a page, list\n  its claims with `knowledge_timeline` `entity`, `timeField: \"recorded_at\"`\n  and `since`, following `nextOffset`. Also search for claims filed elsewhere\n  or unlinked with `knowledge_grep` `kind: \"claim\"`, the subject's\n  distinctive names (a PR number, a commit SHA, a feature name) and the same\n  `since`\u002F`timeField`. Keep only claims that are actually about the subject.\n\nState the scope in the report. Read each claim you will change with\n`knowledge_record`. Its `subjectHint`, when\npresent, is the saver's own description of what the claim is about and the\nstrongest clue to its subject. Group the claims by what they are about (one\nfeature, PR, commit, decision thread, person or preference) before choosing\npages. Most claims make sense only next to their neighbours: a series of\nstatus snapshots about one PR usually ends in an outcome claim.\n\n## 2. Choose subject pages\n\nFor each group, find candidate pages with `knowledge_grep` and\n`knowledge_lookup`, and read their State. Ignore withdrawn pages and\nfixture pages.\n\n- The **primary subject** is what the claim asserts something about; list it\n  first in `entities`. Add a secondary subject only when the claim also states\n  something about that entity, such as the person who made the decision or the\n  company whose product was configured. A passing mention is not a subject. Two\n  or three subjects is usually enough.\n- The primary subject is the **most specific** page the claim is about: a\n  claim about one PR belongs on that PR's page, not only on the project the PR\n  belongs to. The broader page stays a subject only when the claim says\n  something about it, such as a project-level decision, policy or release.\n- A preference or decision stated by a person belongs on that person's page.\n  Do not turn one person's preference into a project or company policy.\n- Match identity on evidence, not on similar names. When a claim names something\n  that might be an existing page (for example a product name that could be a\n  different service), confirm it from evidence such as configuration, a URL or\n  the page's own aliases. If it stays uncertain, leave the claim where it is and\n  report it.\n\nLink with `knowledge_annotate` `entities`, passing the complete list (it replaces\nthe existing one) and the claim's current revision and hash. Assertion text,\nevidence and lifecycle stay unchanged. Link a claim before you supersede it:\nsuperseded claims cannot be relinked.\n\n## 3. Create missing pages and relink to them\n\nLinking every claim to the nearest existing page can bury a real subject in a\nbroad page. Create a page when:\n\n- a discrete subject (a feature, project, tool or substantial PR) has roughly\n  five or more claims, or has its own design, proof and outcome history; or\n- a person or organisation authored, owns or decided something in the claims,\n  has no page, and has identity evidence (for example the PR author shown by\n  `gh pr view`).\n\nDo not create a page for a single mention or a one-off fix that a dated claim\ncovers. Use `knowledge_save_page` with the ontology `type`, aliases, and the\nidentity evidence as `source`. Person pages use `identity.status: partial` unless\nthe identity is fully established. Write a short State that cites the claims; its\nTimeline is derived from them. Link the new page from its parent page.\n\nThen relink the group's claims, including the snapshots step 4 will supersede.\nThe new page becomes each claim's primary subject. Keep the broad page the\nclaims were filed on (often the hub this review started from) only for claims\nthat say something about it, by the rule in step 2; drop it from the rest.\nKeep other existing secondary subjects that still qualify. Under the threshold,\nleave the claims on their current pages.\n\n## 4. Retire duplicates, replaced claims and snapshot series\n\n- **Duplicate:** two claims assert the same fact, decision or preference about\n  the same event. Keep the one with owner-approved recall, otherwise the earlier\n  one, otherwise the one with fuller attribution. Copy any evidence the survivor\n  lacks with `knowledge_annotate` `addEvidence`, then `knowledge_withdraw` the\n  other with a reason that names the survivor's ID.\n- **Replaced:** a later claim explicitly corrects the earlier one (for example an\n  assistant correcting its own report) or decides a question the earlier claim\n  left open. Supersede the earlier claim by the later one with\n  `knowledge_supersede`, with a reason that says what replaced it. Do not use\n  `knowledge_correct` here: it publishes a new copy of the replacement, which\n  creates another duplicate.\n- **Snapshot series:** several status snapshots about one specific item (the\n  same PR, commit or decision thread: CI red at one head, review requested,\n  CI green) followed by an outcome claim about the same item (merged, closed,\n  reverted, released, decided, abandoned). Supersede every snapshot in the\n  series by the outcome in one `knowledge_supersede` call (up to 25 claims).\n  All of these must hold, from the claims' own text and dates:\n  - every snapshot and the outcome name the same specific item, not merely the\n    same project;\n  - the outcome is dated after every snapshot it supersedes and states a final\n    state, not another intermediate one;\n  - the outcome and the snapshots share a subject page (link them first, step\n    3); the tool rejects claims with no common page.\n    A snapshot dated after the outcome, or one about a different head or a\n    different item, stays.\n- **Neither:** snapshots of different moments that no later outcome replaces\n  (CI red, then CI green, with no merge yet) are history, not errors. Keep them.\n  Contradiction alone does not justify a withdrawal or a supersession. When\n  unsure, keep both and report the pair.\n\n`knowledge_supersede` keeps every superseded claim's text, evidence, provenance\nand history, records `superseded_by` and the reason on it, and leaves the\nsuperseding claim unchanged. Default reads stop showing superseded claims;\nhistorical reads (`historical: true`, `lifecycle: \"all\"`) and\n`knowledge_history` still do. If a supersession was wrong, call it again with\n`undo: true`, the same `by` claim and the fences from its receipt's `items`.\n\n## 5. Update page prose\n\nLinking makes the claims reachable from their pages; it does not change what a\npage says. Edit a page only when the claims change its durable state: a\ndecision, a preference, a landed or released change, a new capability, a\nresolved open question, or page text that later claims show to be wrong.\n\n- Collapse a series of progress snapshots into its outcome. Snapshots (CI runs,\n  open PRs, local commits) are at most dated event claims, never State.\n- Check mutable status live before writing it as current (for example\n  `gh pr view` for merge state) and say when you checked. A merge is not a\n  deployment, and a deployment is not proof that a given Gateway runs the code.\n- When a design or decision page contradicts a later decision, add a dated\n  amendment next to the original text rather than rewriting it. Mark answered\n  open questions as resolved and keep the original question.\n- Cite every added sentence with `[[claim-id|label]]` links to the claims.\n- Page bodies have a size budget\n  ([page budgets](references\u002Fpublish.md#page-budgets)). A `state: \"rejected\"`\n  edit saved nothing, but the linked claims already hold the facts. Move a\n  section to its subject's page with `knowledge_extract_section` (creating the\n  page per step 3 when needed), reread, and retry. Never shorten other prose to\n  make room. Extraction makes the destination the first subject of the claims\n  the section cites and keeps their existing subjects, including the page you\n  extracted from. Apply step 2 to each of those claims and drop the source page\n  with `knowledge_annotate` `entities` where the claim says nothing about it.\n\nUse `knowledge_edit_body` for section edits. Compute UTF-16 offsets from a fresh\nfull read, and reread the revision and hash before every edit: other sessions\nedit busy pages concurrently. Prefer inserting text over replacing it. Replace a\nwhole State section only when all of it is stale, and keep the claim links it\nalready had.\n\n## 6. Verify and report\n\nRun `knowledge_verify` with `expectedEntities` for each linked claim and\n`expectedLinks` for each new or edited page. Enumerate the scope again: new\nclaims may have arrived while you worked. Handle them the same way or report\nthem.\n\nReport the scope, the number of claims examined, linked and relinked, pages\ncreated, claims superseded (with the superseding claim for each series), claims\nwithdrawn (with the surviving claim for each), pages edited, and claims left\nunchanged that you considered, with the reason for each. When running\nunattended, never ask for a decision and never guess: leave uncertain\nidentities, uncertain duplicates, snapshot series whose outcome is not certain,\nand pages you would only create on a guess untouched, and list them in the\nreport for a person.\n\n## Scribe runs\n\nThe **Knowledge Consolidation** scribe runs this review unattended over the\nunlinked residue, on the schedule in its prompt. Its prompt checks access and\nsets up its automation; this section is only the work of one run.\n\n- Run step 1 for the unlinked residue. When the residue is empty, report zero\n  claims examined and go on to the written Timelines below.\n- Otherwise work through steps 2 to 6, and check the residue again before\n  stopping, since claims saved during the run are part of the same backlog.\n- Then retire up to 10 written `## Timeline` sections, largest first\n  ([retire a written Timeline](references\u002Fprofiles.md#retire-a-written-timeline)).\n  Find them with `knowledge_grep` for `Timeline` and confirm the heading in the\n  page body. Count the sections retired and the pages still carrying one.\n- Do not ask questions. Give the step 6 report; the closing status line counts\n  claims examined, linked, superseded, withdrawn and left, then Timelines\n  retired and left.\n","# Claim consolidation review\n\nRead [shared conventions](references\u002Fconventions.md) and\n[publication](references\u002Fpublication.md) before writes.\n\nClaims accumulate faster than pages are curated. `knowledge_remember` saves a\nclaim without a subject page when no name in it matches exactly one page, and\nscheduled maintenance's `knowledge_relink` links only claims whose source page\nis an entity page or whose text names exactly one page. Linked claims pile up\ntoo: a hub page collects status snapshots, duplicates and claims that belong on\na more specific subject. This review runs one procedure over a chosen scope.\nWork in this order: choose the scope, link, then duplicates, replaced claims\nand snapshot series, then page prose.\n\n## 1. Choose the scope and enumerate it\n\nCall `knowledge_status` for the intended scope and `knowledge_ontology` for the\ncurrent fingerprint. Then enumerate exactly one starting set:\n\n- **Unlinked residue** (the default, and the only scope of scribe runs). Run\n  `knowledge_relink` without `dryRun` first so every remembered claim it can\n  link is linked. Then list the residue with `knowledge_relink` `dryRun: true`,\n  `include: \"all\"` and `limit: 10`, following `nextCursor`: every current\n  claim with no linked page and no source page, whichever tool saved it. Each\n  call reports at most 10 examples per outcome, so a limit of 10 returns every\n  claim it examined.\n- **One page**, for a hub page or a page over its size budget. List its\n  current claims with `knowledge_connections` `id` and `direction: \"claims\"`;\n  each row carries the claim's text, kind, day, linked page titles and\n  16-character hash. Follow `nextOffset` with the same filters. Restart when `snapshot` changes. On a hub, group from the cards\n  first and work one group at a time; do not read every claim in full up front.\n- **One subject, optionally since a date.** When the subject has a page, list\n  its claims with `knowledge_timeline` `entity`, `timeField: \"recorded_at\"`\n  and `since`, following `nextOffset`. Also search for claims filed elsewhere\n  or unlinked with `knowledge_grep` `kind: \"claim\"`, the subject's\n  distinctive names (a PR number, a commit SHA, a feature name) and the same\n  `since`\u002F`timeField`. Keep only claims that are actually about the subject.\n\nState the scope in the report. Read each claim you will change with\n`knowledge_record`. Its `subjectHint`, when\npresent, is the saver's own description of what the claim is about and the\nstrongest clue to its subject. Group the claims by what they are about (one\nfeature, PR, commit, decision thread, person or preference) before choosing\npages. Most claims make sense only next to their neighbours: a series of\nstatus snapshots about one PR usually ends in an outcome claim.\n\n## 2. Choose subject pages\n\nFor each group, find candidate pages with `knowledge_grep` and\n`knowledge_lookup`, and read their State. Ignore withdrawn pages and\nfixture pages.\n\n- The **primary subject** is what the claim asserts something about; list it\n  first in `entities`. Add a secondary subject only when the claim also states\n  something about that entity, such as the person who made the decision or the\n  company whose product was configured. A passing mention is not a subject. Two\n  or three subjects is usually enough.\n- The primary subject is the **most specific** page the claim is about: a\n  claim about one PR belongs on that PR's page, not only on the project the PR\n  belongs to. The broader page stays a subject only when the claim says\n  something about it, such as a project-level decision, policy or release.\n- A preference or decision stated by a person belongs on that person's page.\n  Do not turn one person's preference into a project or company policy.\n- Match identity on evidence, not on similar names. When a claim names something\n  that might be an existing page (for example a product name that could be a\n  different service), confirm it from evidence such as configuration, a URL or\n  the page's own aliases. If it stays uncertain, leave the claim where it is and\n  report it.\n\nLink with `knowledge_annotate` `entities`, passing the complete list (it replaces\nthe existing one) and the claim's current revision and hash. Assertion text,\nevidence and lifecycle stay unchanged. Link a claim before you supersede it:\nsuperseded claims cannot be relinked.\n\n## 3. Create missing pages and relink to them\n\nLinking every claim to the nearest existing page can bury a real subject in a\nbroad page. Create a page when:\n\n- a discrete subject (a feature, project, tool or substantial PR) has roughly\n  five or more claims, or has its own design, proof and outcome history; or\n- a person or organisation authored, owns or decided something in the claims,\n  has no page, and has identity evidence (for example the PR author shown by\n  `gh pr view`).\n\nDo not create a page for a single mention or a one-off fix that a dated claim\ncovers. Use `knowledge_save_page` with the ontology `type`, aliases, and the\nidentity evidence as `source`. Person pages use `identity.status: partial` unless\nthe identity is fully established. Write a short State that cites the claims; its\nTimeline is derived from them. Link the new page from its parent page.\n\nThen relink the group's claims, including the snapshots step 4 will supersede.\nThe new page becomes each claim's primary subject. Keep the broad page the\nclaims were filed on (often the hub this review started from) only for claims\nthat say something about it, by the rule in step 2; drop it from the rest.\nKeep other existing secondary subjects that still qualify. Under the threshold,\nleave the claims on their current pages.\n\n## 4. Retire duplicates, replaced claims and snapshot series\n\n- **Duplicate:** two claims assert the same fact, decision or preference about\n  the same event. Keep the one with owner-approved recall, otherwise the earlier\n  one, otherwise the one with fuller attribution. Copy any evidence the survivor\n  lacks with `knowledge_annotate` `addEvidence`, then `knowledge_withdraw` the\n  other with a reason that names the survivor's ID.\n- **Replaced:** a later claim explicitly corrects the earlier one (for example an\n  assistant correcting its own report) or decides a question the earlier claim\n  left open. Supersede the earlier claim by the later one with\n  `knowledge_supersede`, with a reason that says what replaced it. Do not use\n  `knowledge_correct` here: it publishes a new copy of the replacement, which\n  creates another duplicate.\n- **Snapshot series:** several status snapshots about one specific item (the\n  same PR, commit or decision thread: CI red at one head, review requested,\n  CI green) followed by an outcome claim about the same item (merged, closed,\n  reverted, released, decided, abandoned). Supersede every snapshot in the\n  series by the outcome in one `knowledge_supersede` call (up to 25 claims).\n  All of these must hold, from the claims' own text and dates:\n  - every snapshot and the outcome name the same specific item, not merely the\n    same project;\n  - the outcome is dated after every snapshot it supersedes and states a final\n    state, not another intermediate one;\n  - the outcome and the snapshots share a subject page (link them first, step\n    3); the tool rejects claims with no common page.\n    A snapshot dated after the outcome, or one about a different head or a\n    different item, stays.\n- **Neither:** snapshots of different moments that no later outcome replaces\n  (CI red, then CI green, with no merge yet) are history, not errors. Keep them.\n  Contradiction alone does not justify a withdrawal or a supersession. When\n  unsure, keep both and report the pair.\n\n`knowledge_supersede` keeps every superseded claim's text, evidence, provenance\nand history, records `superseded_by` and the reason on it, and leaves the\nsuperseding claim unchanged. Default reads stop showing superseded claims;\nhistorical reads (`historical: true`, `lifecycle: \"all\"`) and\n`knowledge_history` still do. If a supersession was wrong, call it again with\n`undo: true`, the same `by` claim and the fences from its receipt's `items`.\n\n## 5. Update page prose\n\nLinking makes the claims reachable from their pages; it does not change what a\npage says. Edit a page only when the claims change its durable state: a\ndecision, a preference, a landed or released change, a new capability, a\nresolved open question, or page text that later claims show to be wrong.\n\n- Collapse a series of progress snapshots into its outcome. Snapshots (CI runs,\n  open PRs, local commits) are at most dated event claims, never State.\n- Check mutable status live before writing it as current (for example\n  `gh pr view` for merge state) and say when you checked. A merge is not a\n  deployment, and a deployment is not proof that a given Gateway runs the code.\n- When a design or decision page contradicts a later decision, add a dated\n  amendment next to the original text rather than rewriting it. Mark answered\n  open questions as resolved and keep the original question.\n- Cite every added sentence with `[[claim-id|label]]` links to the claims.\n- Page bodies have a size budget\n  ([page budgets](references\u002Fpublish.md#page-budgets)). A `state: \"rejected\"`\n  edit saved nothing, but the linked claims already hold the facts. Move a\n  section to its subject's page with `knowledge_extract_section` (creating the\n  page per step 3 when needed), reread, and retry. Never shorten other prose to\n  make room. Extraction makes the destination the first subject of the claims\n  the section cites and keeps their existing subjects, including the page you\n  extracted from. Apply step 2 to each of those claims and drop the source page\n  with `knowledge_annotate` `entities` where the claim says nothing about it.\n\nUse `knowledge_edit_body` for section edits. Compute UTF-16 offsets from a fresh\nfull read, and reread the revision and hash before every edit: other sessions\nedit busy pages concurrently. Prefer inserting text over replacing it. Replace a\nwhole State section only when all of it is stale, and keep the claim links it\nalready had.\n\n## 6. Verify and report\n\nRun `knowledge_verify` with `expectedEntities` for each linked claim and\n`expectedLinks` for each new or edited page. Enumerate the scope again: new\nclaims may have arrived while you worked. Handle them the same way or report\nthem.\n\nReport the scope, the number of claims examined, linked and relinked, pages\ncreated, claims superseded (with the superseding claim for each series), claims\nwithdrawn (with the surviving claim for each), pages edited, and claims left\nunchanged that you considered, with the reason for each. When running\nunattended, never ask for a decision and never guess: leave uncertain\nidentities, uncertain duplicates, snapshot series whose outcome is not certain,\nand pages you would only create on a guess untouched, and list them in the\nreport for a person.\n\n## Scribe runs\n\nThe **Knowledge Consolidation** scribe runs this review unattended over the\nunlinked residue, on the schedule in its prompt. Its prompt checks access and\nsets up its automation; this section is only the work of one run.\n\n- Run step 1 for the unlinked residue. When the residue is empty, report zero\n  claims examined and go on to the written Timelines below.\n- Otherwise work through steps 2 to 6, and check the residue again before\n  stopping, since claims saved during the run are part of the same backlog.\n- Then retire up to 10 written `## Timeline` sections, largest first\n  ([retire a written Timeline](references\u002Fprofiles.md#retire-a-written-timeline)).\n  Find them with `knowledge_grep` for `Timeline` and confirm the heading in the\n  page body. Count the sections retired and the pages still carrying one.\n- Do not ask questions. Give the step 6 report; the closing status line counts\n  claims examined, linked, superseded, withdrawn and left, then Timelines\n  retired and left.\n",{"name":5,"description":7},"main","c37e3897be60e2db9db3aefba9cee92bcb193b51","extensions\u002Fknowledge\u002Fskills\u002Fknowledge-claim-consolidation",82862,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw","https:\u002F\u002Fopenclaw.ai","https:\u002F\u002Fgithub.com\u002Fopenclaw","Your personal, open source AI assistant.","2026-11-11 08:46:30",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add openclaw\u002Fopenclaw --skill knowledge-claim-consolidation",{"tool":63,"command":64},"bunx","bunx skills add openclaw\u002Fopenclaw --skill knowledge-claim-consolidation",{"tool":66,"command":67},"pnpm","pnpm dlx skills add openclaw\u002Fopenclaw --skill knowledge-claim-consolidation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Fknowledge\u002Fskills\u002Fknowledge-claim-consolidation\u002FSKILL.md",true,[71,77,81,85,89,93,97,101,105,109,113,117],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fassertions.md","REFERENCE","参考文档",4745,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Fknowledge\u002Fskills\u002Fknowledge-claim-consolidation\u002Freferences\u002Fassertions.md",{"path":78,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fconventions.md",14383,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Fknowledge\u002Fskills\u002Fknowledge-claim-consolidation\u002Freferences\u002Fconventions.md",{"path":82,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002Fidentity.md",4902,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Fknowledge\u002Fskills\u002Fknowledge-claim-consolidation\u002Freferences\u002Fidentity.md",{"path":86,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Fmeeting-entity-example.md",6838,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Fknowledge\u002Fskills\u002Fknowledge-claim-consolidation\u002Freferences\u002Fmeeting-entity-example.md",{"path":90,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Fprofiles.md",5775,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Fknowledge\u002Fskills\u002Fknowledge-claim-consolidation\u002Freferences\u002Fprofiles.md",{"path":94,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":95,"sourceHtmlUrl":96},"references\u002Fpublication.md",22899,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Fknowledge\u002Fskills\u002Fknowledge-claim-consolidation\u002Freferences\u002Fpublication.md",{"path":98,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":99,"sourceHtmlUrl":100},"references\u002Fpublish.md",5450,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Fknowledge\u002Fskills\u002Fknowledge-claim-consolidation\u002Freferences\u002Fpublish.md",{"path":102,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Frecovery.md",2085,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Fknowledge\u002Fskills\u002Fknowledge-claim-consolidation\u002Freferences\u002Frecovery.md",{"path":106,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":107,"sourceHtmlUrl":108},"references\u002Fsetup.md",2151,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Fknowledge\u002Fskills\u002Fknowledge-claim-consolidation\u002Freferences\u002Fsetup.md",{"path":110,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":111,"sourceHtmlUrl":112},"references\u002Fsources.md",3108,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Fknowledge\u002Fskills\u002Fknowledge-claim-consolidation\u002Freferences\u002Fsources.md",{"path":114,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":115,"sourceHtmlUrl":116},"references\u002Fverify.md",2683,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Fknowledge\u002Fskills\u002Fknowledge-claim-consolidation\u002Freferences\u002Fverify.md",{"path":118,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":119,"sourceHtmlUrl":120},"references\u002Fwriting.md",1958,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Fknowledge\u002Fskills\u002Fknowledge-claim-consolidation\u002Freferences\u002Fwriting.md",[122,128,150,168,189,211],{"skillNo":123,"name":124,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":43},"01M698VP84FNM6G9MR1HPX7MF7","lobster","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Flobster\u002FSKILL.md",[],[124],{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":43},"01M698YY8QGQ7S8TJNKJG6VTPH","xurl","xurl CLI for authenticated X posts, replies, reads\u002Fsearch, DMs, media upload, followers, auth status, or raw v2 API calls.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Fxurl\u002FSKILL.md",[],[130,38,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149],"api","calls","replies","posts","upload","tap","install","brew","node","Media","search","npm","status","auth","cli",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"publishedAt":43},"01M698YWT1CJ0WK88WB909R9RT","weather","Current weather and forecasts with web_fetch, falling back to wttr.in curl for locations, rain, temperature, travel planning.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Fweather\u002FSKILL.md",[],[152,157,158,141,159,142,160,161,162,163,164,165,38,166,167],"travel planning","travel","fetch","curl","https","help","planning","web","back","temperature","with",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":179,"publishedAt":43},"01M698YV2Q0R0JJKAWGFS21K0N","visualize","Create inline visuals for code and explanations, or author persistent OpenClaw dashboard widgets with show_widget.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Fvisualize\u002FSKILL.md",[174],{"categoryNo":175,"categoryName":176,"taxonomyType":177,"taxonomyTypeDesc":178},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[170,180,181,182,183,38,167,184,185,28,186,187,9,188],"widgets","openclaw dashboard","author","inline","show","code","visuals","dashboard","widget",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":201,"publishedAt":43},"01M698YS2TRJH9ENG28HD9CD87","trello","Manage Trello boards, lists, and cards via the Trello REST API.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Ftrello\u002FSKILL.md",[195,198],{"categoryNo":196,"categoryName":197,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":199,"categoryName":200,"taxonomyType":177,"taxonomyTypeDesc":178},"01JBSEEDCAT000000000000030","开发工程师",[191,161,202,203,204,205,206,207,141,142,208,160,135,209,210],"cloud","manage","via","rest api","token","atlassian","jq","REST","developer",{"skillNo":212,"name":213,"nameZh":6,"description":214,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":215,"categories":216,"keywords":217,"publishedAt":43},"01M698YQ9Q3M4W78EWV2KSCSVW","tmux","Control tmux sessions\u002Fpanes for interactive CLIs: list, capture output, send keys, paste text, monitor prompts.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Ftmux\u002FSKILL.md",[],[213,141,218,219,38,220,221,222,223,224,225,226,142,227,228,229,230,231,232],"send","darwin","keys","paste","output","control","prompts","interactive","list","capture","panes","text","monitor","sessions","linux"]