[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71RY45SFH07RZAVCRMNN17W":3,"skill-same:01M71RY45SFH07RZAVCRMNN17W":72},{"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":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":14,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M71RY45SFH07RZAVCRMNN17W","deep-research",null,"The playbook for an EXHAUSTIVE, decision-grade research investigation — when the user asks for deep\u002Fin-depth\u002Fthorough\u002Fexhaustive research, says they need it to make a decision, or asks whether an approach\u002Ftool\u002Fconfiguration is a good idea. Audits the assumptions baked into the question, runs multiple search waves with a coverage review between them, considers the alternatives the user did not mention, and has the findings adversarially reviewed before answering. Use instead of a single search-and-summarise pass whenever being incomplete would cost the user a bad decision.","blouargant\u002Fomnis","blouargant","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F5691896?v=4","01M71RWETBTYXSMT6FFC4Q7HPW","Bertrand Louargant","01M71RWEV3G47S696JYH8EA7W2",0,"MIT","https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis\u002Fblob\u002Fdevelop\u002Fregistry\u002Fskills\u002Fdeep-research\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"research","deep research","deep","diligence","review","when","alternatives","for","make","sources","bad","due-diligence","idea","evidence","good","coverage","question","decision","playbook","search","2026-11-10 13:02:02",false,"---\nname: deep-research\ndescription: The playbook for an EXHAUSTIVE, decision-grade research investigation — when the user asks for deep\u002Fin-depth\u002Fthorough\u002Fexhaustive research, says they need it to make a decision, or asks whether an approach\u002Ftool\u002Fconfiguration is a good idea. Audits the assumptions baked into the question, runs multiple search waves with a coverage review between them, considers the alternatives the user did not mention, and has the findings adversarially reviewed before answering. Use instead of a single search-and-summarise pass whenever being incomplete would cost the user a bad decision.\nmetadata:\n  author: blouargant@chapsvision.com\n  tags: \"research, deep-research, investigation, decision, due-diligence, evidence, sources, playbook\"\n---\n\n# Deep Research\n\nThe playbook for **decision-grade** research: the user is going to *act* on your\nanswer, so being merely correct about what they asked is not enough — you must\nalso be right about what they *should have* asked.\n\nThis is a different discipline from a standard lookup:\n\n| | standard research | deep research |\n|---|---|---|\n| Goal | answer the question | equip a decision |\n| Scope | the question as asked | the question **and its premises** |\n| Waves | one search pass | 2 (3 at most), with a coverage review between |\n| Done when | you have an answer | the adversarial review finds no blocker, or the remaining one is stated as open |\n| Failure mode | wrong answer | **complete, well-sourced answer to the wrong question** |\n\nThat last row is the one that bites. A deep-research answer that faithfully\nreasons *inside* a flawed premise the user handed you is worse than useless: it\nis confidently wrong, and it reads as authoritative.\n\n> **Worked failure (the reason this skill exists).** Asked *\"Is LMCache\n> interesting for a quantized 27B model running on 2 GPUs (no NVLink)?\"*, a\n> research pass produced an excellent, well-sourced brief on LMCache — pros,\n> cons, a real bug catalogue — and never once questioned the *2 GPUs* part.\n> vLLM's own documentation says that without NVLink you should prefer\n> **pipeline** parallelism over tensor parallelism, and a 4-bit 27B model may\n> not need two GPUs at all. The single highest-value fact for the user's actual\n> decision was one search away, and nobody searched for it, because it was not\n> in the question. **The setup stated in a question is a claim to verify, not a\n> constraint to obey.**\n\n## Procedure\n\n### Phase 1 — Premise audit (do this BEFORE any search)\n\nWrite the question out and extract, explicitly, two lists.\n\n1. **The asked question(s)** — what the user literally wants to know.\n2. **The premises** — every fact, choice, constraint, or identifier the user\n   stated *as given*. Hunt for these in particular:\n   - **Configuration choices**: a topology, a parallelism mode, a flag, a\n     deployment shape, an architecture (\"on 2 GPUs\", \"behind nginx\", \"with\n     Redis as the queue\"). The user chose it; the choice may be wrong.\n   - **Hardware \u002F environment facts**: interconnect, VRAM, CPU, network, OS,\n     managed-vs-self-hosted.\n   - **Named entities and versions**: a model name, a library, a product, a\n     version number. It may not exist, may be misremembered, or may be\n     superseded — verify the entity is real before researching it in depth.\n   - **The framing itself**: \"should I use X for Y\" presupposes X is a\n     candidate and Y is the goal. Is there a Z that dominates X? Is Y really\n     the goal?\n   - **Implicit goals**: the user says \"throughput\" but the setup implies\n     \"latency\", or vice versa.\n\n3. **Turn every premise into a research question of its own.** Each one gets a\n   line in the matrix below. A premise you do not research is a premise you have\n   silently endorsed.\n\n### Phase 2 — Build the research matrix\n\nBefore searching, write the matrix. It is your definition of \"done\" and the\nchecklist the coverage review (Phase 4) grades against.\n\n| # | Angle | Question | Why it matters to the decision |\n|---|---|---|---|\n| A | **Asked** | the user's literal question(s) | it is what they asked |\n| B | **Premise** | one row per premise from Phase 1 | a bad premise invalidates the answer |\n| C | **Alternatives** | what are the other ways to achieve the user's goal? | the best option may not be on their list |\n| D | **Failure modes** | known bugs, limits, gotchas, regressions, versions | what will bite them in week two |\n| E | **Expert delta** | \"what would a specialist tell this person that they did not think to ask?\" | the highest-value rows usually appear here |\n\nRow E is not decoration. Write it last and force yourself to fill it — if you\ncannot think of anything an expert would add, you have not understood the domain\nwell enough to be giving a decision-grade answer yet.\n\n### Phase 3 — Wave 1: breadth\n\nRun the matrix **in parallel, one search (or one research sub-agent task) per\nangle** — several calls in the same response, not one call containing\neverything. Each must be a precisely worded question; a sub-agent task also\nneeds the context it relies on (a sub-agent is stateless across calls).\n\nRules for the wave:\n\n- **Never fold the premise rows into the asked rows.** \"Is LMCache good for\n  TP=2 on PCIe?\" and \"Is TP=2 on PCIe even the right topology?\" are different\n  searches and one of them will not happen if you merge them.\n- **Prefer first-party sources for anything normative.** For a configuration\n  recommendation, the project's own documentation, its issue tracker, and its\n  release notes outrank a blog post, a Reddit thread, or your memory. A vendor\n  saying \"do not do X on hardware Y\" is a decisive source; a benchmark blog is\n  corroboration.\n- **Version-anchor everything.** A bug, a flag, a default, and a limit are all\n  version-dependent. An unversioned claim is an unusable claim.\n\n### Phase 4 — Coverage review (the step that is always skipped)\n\n**Do not synthesise yet.** Put the wave-1 results next to the matrix and answer,\nrow by row, in writing:\n\n1. **Which rows are actually answered?** An angle that came back thin, generic,\n   or unsourced is *not* answered. Mark it open.\n2. **What contradicts what?** Two sources disagreeing is a finding, not noise.\n   Resolve it with a third, more authoritative source, or report the\n   disagreement explicitly.\n3. **What did the results themselves raise?** Wave 1 almost always surfaces a\n   term, a flag, a bug, or a trade-off you did not know to ask about. These are\n   the best rows in the matrix and they can only appear here. Add them.\n4. **Which claims are load-bearing but unsourced?** Anything the recommendation\n   rests on must trace to a page that was actually fetched in this task.\n\n### Phase 5 — Wave 2: depth\n\nRun a second wave on everything Phase 4 left open: the unanswered rows, the\ncontradictions, the newly discovered angles, the unsourced load-bearing claims.\n\n**A deep-research task is never finished after one wave.** If wave 1 genuinely\nanswered every row, wave 2 exists to attack the answer: search for the strongest\ncase *against* your emerging recommendation, and for the failure reports of\npeople who did what you are about to recommend.\n\n**Run a third wave only when a load-bearing row is still unanswered or\ncontradicted after wave 2** — and aim it at that row alone. Never run a wave to\nre-confirm what is already sourced: a wave that returns only confirmation is\nthe most expensive way to learn nothing. Three waves is the ceiling; what is\nstill open after that goes under \"open questions\" in the deliverable.\n\n**Within a wave, keep each search narrow.** One precise question per search or\nsub-agent call, with the URLs you already have when you want a page checked — a\nbroad one (\"research everything about X\") reads pages for questions nobody\nasked.\n\n### Phase 6 — Adversarial review\n\nHand the **original question** and your **draft brief** to a fresh reviewer (the\n`research_critic` sub-agent when one is mounted; otherwise do this pass yourself,\nexplicitly and in writing, before you answer). The reviewer answers one question:\n*\"If the user acts on this, what will go wrong?\"*\n\nFix the blockers it returns by re-searching — do not defend the draft. Then\nsend the revised brief back **once**, asking the reviewer to check only the\nblockers it raised. A blocker still open after that re-check is stated in the\ndeliverable as an open question, not chased with another loop. Should-fixes and\nnits are fixed without a further review.\n\n### Phase 7 — Deliver\n\nStructure the answer so the decision is easy to make and the reasoning is easy to\naudit:\n\n1. **Verdict first.** The direct answer to the asked question, in one or two\n   sentences, with the condition that governs it.\n2. **Premise check — \"what we challenged in your question\".** Any premise that\n   did not survive Phase 1–5 goes *here, near the top*, not buried in section 4.\n   State the assumption, what the evidence says, and what to do instead. If every\n   premise held, say so in one line — that is a real finding too.\n3. **The analysis** — pros \u002F cons \u002F mechanics, each load-bearing claim carrying\n   its source link and its version.\n4. **Alternatives you did not ask about**, as a comparison table, with the\n   condition under which each wins.\n5. **Recommendation**, with the concrete configuration, and the measurement that\n   would prove or disprove it in the user's own environment.\n6. **Confidence and open questions.** What you could not verify, and what a\n   source disagreed about. Never fill a gap from memory to make the brief look\n   complete.\n\n## Sourcing rules\n\n- Every load-bearing claim traces to a page **fetched in this task**. Training\n  memory is a lead to verify, never a citation.\n- Distinguish **fetched fact** (cite it), **inference** (say \"this implies\"),\n  and **unverified** (say so, and put it under open questions).\n- Version-anchor bugs and behaviour: \"open as of vLLM 0.24 \u002F LMCache 0.4\" beats\n  \"known bug\".\n- Prefer primary sources for normative claims (official docs > maintainer issue\n  comment > vendor blog > third-party blog > forum thread).\n- Do not launder a guess through a confident tone. A gap named honestly is worth\n  more to a decision than a plausible sentence.\n\n## Red flags that you are about to ship a bad brief\n\n- You accepted a number, a topology, or a product name from the question without\n  a single search aimed at it.\n- Your brief answers every question the user asked and raises none they did not.\n- One search pass produced the whole brief.\n- The recommendation has no measurement attached — nothing the user could run\n  tomorrow to falsify it.\n- You \"know\" a fact you did not fetch.\n- The alternatives section is missing, or contains only alternatives the user\n  already named.\n\n## Output rule\n\nFinish with a single line: `Confidence: high | medium | low` — followed by the\none open question that would most change the recommendation if answered.\n","# Deep Research\n\nThe playbook for **decision-grade** research: the user is going to *act* on your\nanswer, so being merely correct about what they asked is not enough — you must\nalso be right about what they *should have* asked.\n\nThis is a different discipline from a standard lookup:\n\n| | standard research | deep research |\n|---|---|---|\n| Goal | answer the question | equip a decision |\n| Scope | the question as asked | the question **and its premises** |\n| Waves | one search pass | 2 (3 at most), with a coverage review between |\n| Done when | you have an answer | the adversarial review finds no blocker, or the remaining one is stated as open |\n| Failure mode | wrong answer | **complete, well-sourced answer to the wrong question** |\n\nThat last row is the one that bites. A deep-research answer that faithfully\nreasons *inside* a flawed premise the user handed you is worse than useless: it\nis confidently wrong, and it reads as authoritative.\n\n> **Worked failure (the reason this skill exists).** Asked *\"Is LMCache\n> interesting for a quantized 27B model running on 2 GPUs (no NVLink)?\"*, a\n> research pass produced an excellent, well-sourced brief on LMCache — pros,\n> cons, a real bug catalogue — and never once questioned the *2 GPUs* part.\n> vLLM's own documentation says that without NVLink you should prefer\n> **pipeline** parallelism over tensor parallelism, and a 4-bit 27B model may\n> not need two GPUs at all. The single highest-value fact for the user's actual\n> decision was one search away, and nobody searched for it, because it was not\n> in the question. **The setup stated in a question is a claim to verify, not a\n> constraint to obey.**\n\n## Procedure\n\n### Phase 1 — Premise audit (do this BEFORE any search)\n\nWrite the question out and extract, explicitly, two lists.\n\n1. **The asked question(s)** — what the user literally wants to know.\n2. **The premises** — every fact, choice, constraint, or identifier the user\n   stated *as given*. Hunt for these in particular:\n   - **Configuration choices**: a topology, a parallelism mode, a flag, a\n     deployment shape, an architecture (\"on 2 GPUs\", \"behind nginx\", \"with\n     Redis as the queue\"). The user chose it; the choice may be wrong.\n   - **Hardware \u002F environment facts**: interconnect, VRAM, CPU, network, OS,\n     managed-vs-self-hosted.\n   - **Named entities and versions**: a model name, a library, a product, a\n     version number. It may not exist, may be misremembered, or may be\n     superseded — verify the entity is real before researching it in depth.\n   - **The framing itself**: \"should I use X for Y\" presupposes X is a\n     candidate and Y is the goal. Is there a Z that dominates X? Is Y really\n     the goal?\n   - **Implicit goals**: the user says \"throughput\" but the setup implies\n     \"latency\", or vice versa.\n\n3. **Turn every premise into a research question of its own.** Each one gets a\n   line in the matrix below. A premise you do not research is a premise you have\n   silently endorsed.\n\n### Phase 2 — Build the research matrix\n\nBefore searching, write the matrix. It is your definition of \"done\" and the\nchecklist the coverage review (Phase 4) grades against.\n\n| # | Angle | Question | Why it matters to the decision |\n|---|---|---|---|\n| A | **Asked** | the user's literal question(s) | it is what they asked |\n| B | **Premise** | one row per premise from Phase 1 | a bad premise invalidates the answer |\n| C | **Alternatives** | what are the other ways to achieve the user's goal? | the best option may not be on their list |\n| D | **Failure modes** | known bugs, limits, gotchas, regressions, versions | what will bite them in week two |\n| E | **Expert delta** | \"what would a specialist tell this person that they did not think to ask?\" | the highest-value rows usually appear here |\n\nRow E is not decoration. Write it last and force yourself to fill it — if you\ncannot think of anything an expert would add, you have not understood the domain\nwell enough to be giving a decision-grade answer yet.\n\n### Phase 3 — Wave 1: breadth\n\nRun the matrix **in parallel, one search (or one research sub-agent task) per\nangle** — several calls in the same response, not one call containing\neverything. Each must be a precisely worded question; a sub-agent task also\nneeds the context it relies on (a sub-agent is stateless across calls).\n\nRules for the wave:\n\n- **Never fold the premise rows into the asked rows.** \"Is LMCache good for\n  TP=2 on PCIe?\" and \"Is TP=2 on PCIe even the right topology?\" are different\n  searches and one of them will not happen if you merge them.\n- **Prefer first-party sources for anything normative.** For a configuration\n  recommendation, the project's own documentation, its issue tracker, and its\n  release notes outrank a blog post, a Reddit thread, or your memory. A vendor\n  saying \"do not do X on hardware Y\" is a decisive source; a benchmark blog is\n  corroboration.\n- **Version-anchor everything.** A bug, a flag, a default, and a limit are all\n  version-dependent. An unversioned claim is an unusable claim.\n\n### Phase 4 — Coverage review (the step that is always skipped)\n\n**Do not synthesise yet.** Put the wave-1 results next to the matrix and answer,\nrow by row, in writing:\n\n1. **Which rows are actually answered?** An angle that came back thin, generic,\n   or unsourced is *not* answered. Mark it open.\n2. **What contradicts what?** Two sources disagreeing is a finding, not noise.\n   Resolve it with a third, more authoritative source, or report the\n   disagreement explicitly.\n3. **What did the results themselves raise?** Wave 1 almost always surfaces a\n   term, a flag, a bug, or a trade-off you did not know to ask about. These are\n   the best rows in the matrix and they can only appear here. Add them.\n4. **Which claims are load-bearing but unsourced?** Anything the recommendation\n   rests on must trace to a page that was actually fetched in this task.\n\n### Phase 5 — Wave 2: depth\n\nRun a second wave on everything Phase 4 left open: the unanswered rows, the\ncontradictions, the newly discovered angles, the unsourced load-bearing claims.\n\n**A deep-research task is never finished after one wave.** If wave 1 genuinely\nanswered every row, wave 2 exists to attack the answer: search for the strongest\ncase *against* your emerging recommendation, and for the failure reports of\npeople who did what you are about to recommend.\n\n**Run a third wave only when a load-bearing row is still unanswered or\ncontradicted after wave 2** — and aim it at that row alone. Never run a wave to\nre-confirm what is already sourced: a wave that returns only confirmation is\nthe most expensive way to learn nothing. Three waves is the ceiling; what is\nstill open after that goes under \"open questions\" in the deliverable.\n\n**Within a wave, keep each search narrow.** One precise question per search or\nsub-agent call, with the URLs you already have when you want a page checked — a\nbroad one (\"research everything about X\") reads pages for questions nobody\nasked.\n\n### Phase 6 — Adversarial review\n\nHand the **original question** and your **draft brief** to a fresh reviewer (the\n`research_critic` sub-agent when one is mounted; otherwise do this pass yourself,\nexplicitly and in writing, before you answer). The reviewer answers one question:\n*\"If the user acts on this, what will go wrong?\"*\n\nFix the blockers it returns by re-searching — do not defend the draft. Then\nsend the revised brief back **once**, asking the reviewer to check only the\nblockers it raised. A blocker still open after that re-check is stated in the\ndeliverable as an open question, not chased with another loop. Should-fixes and\nnits are fixed without a further review.\n\n### Phase 7 — Deliver\n\nStructure the answer so the decision is easy to make and the reasoning is easy to\naudit:\n\n1. **Verdict first.** The direct answer to the asked question, in one or two\n   sentences, with the condition that governs it.\n2. **Premise check — \"what we challenged in your question\".** Any premise that\n   did not survive Phase 1–5 goes *here, near the top*, not buried in section 4.\n   State the assumption, what the evidence says, and what to do instead. If every\n   premise held, say so in one line — that is a real finding too.\n3. **The analysis** — pros \u002F cons \u002F mechanics, each load-bearing claim carrying\n   its source link and its version.\n4. **Alternatives you did not ask about**, as a comparison table, with the\n   condition under which each wins.\n5. **Recommendation**, with the concrete configuration, and the measurement that\n   would prove or disprove it in the user's own environment.\n6. **Confidence and open questions.** What you could not verify, and what a\n   source disagreed about. Never fill a gap from memory to make the brief look\n   complete.\n\n## Sourcing rules\n\n- Every load-bearing claim traces to a page **fetched in this task**. Training\n  memory is a lead to verify, never a citation.\n- Distinguish **fetched fact** (cite it), **inference** (say \"this implies\"),\n  and **unverified** (say so, and put it under open questions).\n- Version-anchor bugs and behaviour: \"open as of vLLM 0.24 \u002F LMCache 0.4\" beats\n  \"known bug\".\n- Prefer primary sources for normative claims (official docs > maintainer issue\n  comment > vendor blog > third-party blog > forum thread).\n- Do not launder a guess through a confident tone. A gap named honestly is worth\n  more to a decision than a plausible sentence.\n\n## Red flags that you are about to ship a bad brief\n\n- You accepted a number, a topology, or a product name from the question without\n  a single search aimed at it.\n- Your brief answers every question the user asked and raises none they did not.\n- One search pass produced the whole brief.\n- The recommendation has no measurement attached — nothing the user could run\n  tomorrow to falsify it.\n- You \"know\" a fact you did not fetch.\n- The alternatives section is missing, or contains only alternatives the user\n  already named.\n\n## Output rule\n\nFinish with a single line: `Confidence: high | medium | low` — followed by the\none open question that would most change the recommendation if answered.\n",{"name":5,"metadata":49,"description":7},{"tags":50,"author":51},"research, deep-research, investigation, decision, due-diligence, evidence, sources, playbook","blouargant@chapsvision.com","develop","c9440489468f6bbafc65e9a10811428ac0ef2619","registry\u002Fskills\u002Fdeep-research","https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis","https:\u002F\u002Fgithub.com\u002Fblouargant","2026-11-10 16:30:07",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add blouargant\u002Fomnis --skill deep-research",{"tool":64,"command":65},"bunx","bunx skills add blouargant\u002Fomnis --skill deep-research",{"tool":67,"command":68},"pnpm","pnpm dlx skills add blouargant\u002Fomnis --skill deep-research","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis\u002Fblob\u002Fdevelop\u002Fregistry\u002Fskills\u002Fdeep-research\u002FSKILL.md",true,[],[73,100,119,146,168,199],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":82,"publishedAt":44},"01M71RZKQ64WTDCV48Z4Y071FA","skill-creator","Create or update a skill playbook (SKILL.md) for the agent. Use when the user wants to create a new skill, add a skill, define a new agent capability, update an existing skill, edit a skill, refine a skill playbook, or specialise the agent for a new domain.","https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis\u002Fblob\u002Fdevelop\u002Fregistry\u002Fskills\u002Fskill-creator\u002FSKILL.md",[79],{"categoryNo":80,"categoryName":81,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[83,84,85,86,31,87,88,89,90,29,91,92,93,42,94,95,96,97,98,99],"skill creator","creator","new agent","domain","new","define","use","Existing","create","update","refine","edit","a skill","new skill","add","user","existing skill",{"skillNo":101,"name":28,"nameZh":6,"description":102,"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":44},"01M71RZJ15NMV6FXBZD1AQF3K7","Review a body of work (source code, configuration, documents, infra manifests, …) for correctness, clarity, and obvious risks. Use this skill whenever the user asks for a review, audit or critique.","https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis\u002Fblob\u002Fdevelop\u002Fregistry\u002Fskills\u002Freview\u002FSKILL.md",[],[28,106,107,108,109,31,110,89,111,112,113,114,115,116,117,118,98],"infra","work","critique","audit","clarity","body","source","manifests","documents","configuration","correctness","code","source code",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":128,"publishedAt":44},"01M71RZFP8KJEANYXAH6AX68G0","pdf","Fallback PDF text extractor using pdftotext (poppler). Use ONLY when the preferred `liteparse` skill is unavailable or for a quick plain-text dump of a simple text PDF — for the best PDF parsing (scanned, multi-column, layout-heavy, or non-PDF formats) prefer the `liteparse` skill.","https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis\u002Fblob\u002Fdevelop\u002Fregistry\u002Fskills\u002Fpdf\u002FSKILL.md",[125],{"categoryNo":126,"categoryName":127,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理",[129,130,131,132,133,134,135,136,31,137,138,139,140,141,89,142,29,143,144,145],"PDF","text","multi","quick","simple","parsing","pdf text extractor","layout","liteparse","plain-text","column","only","formats","pdftotext","plain","pdf parsing","file",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":154,"publishedAt":44},"01M71RZDAHNX7JC52P5HH5XPEG","pandoc","This skill should be used when converting documents between formats (Markdown, DOCX, PDF, HTML, LaTeX, etc.) using pandoc. Use for format conversion, document generation, and preparing markdown for Google Docs or other word processors.","https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis\u002Fblob\u002Fdevelop\u002Fregistry\u002Fskills\u002Fpandoc\u002FSKILL.md",[152,153],{"categoryNo":126,"categoryName":127,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":80,"categoryName":81,"taxonomyType":21,"taxonomyTypeDesc":22},[148,155,129,156,31,157,89,158,114,29,159,160,161,162,163,164,141,165,166,167],"docx","Word","document generation","document","conversion","generation","markdown","format","google","google docs","docs","html","LaTeX",{"skillNo":169,"name":137,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":185,"publishedAt":44},"01M71RZ7PSG17ES4CQWA6860F5","Preferred local parser for extracting text from PDFs, images, and scanned\u002Flayout-heavy documents (OCR, screenshots, complex PDFs) — far better than pdftotext. Use this FIRST for any PDF, image, or OCR text-extraction or conversion task. NOTE for Office documents (DOCX, PPTX, XLSX, ODT) — for plain text extraction prefer the `pandoc` skill, which needs no LibreOffice; only use LiteParse for Office docs when you need its layout\u002FOCR\u002Fscreenshot output. The `pdf` skill (pdftotext) is only a fallback for when LiteParse cannot be installed.","https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis\u002Fblob\u002Fdevelop\u002Fregistry\u002Fskills\u002Fliteparse\u002FSKILL.md",[173,174,177,180],{"categoryNo":126,"categoryName":127,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":175,"categoryName":176,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":178,"categoryName":179,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000004","电子表格",{"categoryNo":181,"categoryName":182,"taxonomyType":183,"taxonomyTypeDesc":184},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[137,186,187,188,155,189,129,190,191,192,193,194,195,140,142,114,29,196,197,198],"images","app","ocr","which","pptx","extracting","xlsx","managed","local","pipx","image","you","needs",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":205,"publishedAt":44},"01M71RZ2Y9KY94NRBV4WMH73G5","linux-admin","Safely make a change to a Linux workstation — install\u002Fremove packages, manage systemd services and timers, edit and validate configuration files, manage users\u002Fpermissions and networking. Detect the distro and package manager, determine whether the target is package-managed or hand-maintained, preview or simulate every change, back up configs before editing, and prefer the package manager and drop-in overrides so the host stays consistent and secure. Use whenever a change to the local Linux host is required (install, remove, enable, disable, start, stop, edit a config, add a user, change permissions or networking).","https:\u002F\u002Fgithub.com\u002Fblouargant\u002Fomnis\u002Fblob\u002Fdevelop\u002Fregistry\u002Fskills\u002Flinux-admin\u002FSKILL.md",[],[206,207,208,209,210,211,212,213,214,193,194,215,216,217,218,219,220,221,222,223],"linux","linux admin","admin","back","workstation","package manager","pacman","remove","up","systemd services","files","host","drop","preview","hand","permissions","packages","change"]