[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6F47RAXAV4R4A8QCFHDN7AV":3,"skill-same:01M6F47RAXAV4R4A8QCFHDN7AV":93},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":33,"publishedAt":60,"linkOnly":61,"markdownContent":62,"markdownBody":63,"frontMatter":64,"refName":48,"commitSha":73,"skillDirectory":74,"forksCount":75,"repositoryHtmlUrl":76,"repositoryHomepageUrl":6,"ownerHtmlUrl":77,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":78,"install":79,"resources":92},"01M6F47RAXAV4R4A8QCFHDN7AV","bluebook-writing",null,"Write design-reading books and articles in plain language with a two-layer skeleton: a zero-terminology everyday story first, then the professional layer with formal names, mechanisms, boundaries, and costs. Use when explaining unfamiliar systems to non-programmers.","boisenoise\u002Fskills-collections","boisenoise","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F193180?v=4","01M6CDBDQK6BDN55ZMA6B6PKBM","01M6CDBDVSJ3JPTBYN26FZ7TZK",12,"MIT","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-bluebook-writing\u002FSKILL.md",[17,22,25,30],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":26,"categoryName":27,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":31,"categoryName":32,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000036","内容创作者",[34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59],"writing","bluebook writing","2026","design","when","skeleton","layer","books","reading","technical-communication","design-reading","plain-language","professional","deepseek","main","community","use","write","technical","ZeRO","license","harness","communication","documentation","gemini","safe","2026-11-10 10:12:30",false,"---\nname: bluebook-writing\ndescription: \"Write design-reading books and articles in plain language with a two-layer skeleton: a zero-terminology everyday story first, then the professional layer with formal names, mechanisms, boundaries, and costs. Use when explaining unfamiliar systems to non-programmers.\"\ncategory: writing\nrisk: safe\nsource: community\nsource_repo: TobeMagic\u002Fdeepseek-harness-bluebook\nsource_type: community\ndate_added: \"2026-10-26\"\nauthor: TobeMagic\ntags: [writing, plain-language, design-reading, documentation, technical-communication]\ntools: [claude, cursor, gemini]\nlicense: \"MIT\"\nlicense_source: \"https:\u002F\u002Fgithub.com\u002FTobeMagic\u002Fdeepseek-harness-bluebook\u002Fblob\u002Fmain\u002FLICENSE\"\n---\n\n# Bluebook Writing\n\n## Overview\n\nA repeatable method for writing about *why a system is built the way it is* — design reading, not source-code walkthrough, and not vague simplification. Every section tells the same thing twice: first an everyday story with zero technical terms, then the professional layer that adds what the story structurally cannot (formal names, mechanisms, boundaries, costs).\n\nThe method was extracted from a completed 34k-character book that reads DeepSeek Harness (an open-source agent harness) through 42 hand-drawn flow diagrams for an audience of non-programmers. The skill generalizes it for any system, any audience.\n\n## When to Use This Skill\n\n- Use when explaining an unfamiliar architecture, framework, or open-source project to readers who do not write code.\n- Use when writing \"why is it designed this way\" books, long-form articles, or internal architecture docs.\n- Use when a draft reads AI-flavored: terminology-stacked, filler-heavy, or detached from any concrete example.\n- Use when one real-world story must carry an entire book or course, keeping abstract ideas anchored.\n\n## How It Works\n\n### Step 1: Lock the analogy system before writing\n\nPick one everyday scenario (a repair crew, a workshop, a kitchen) and map every technical term to it in a fixed table. The mapping is a contract: once registered, never switch wording mid-book.\n\n| Technical term | Everyday saying |\n|---|---|\n| model | the crew leader's brain (thinks, cannot touch anything) |\n| harness \u002F runtime shell | the whole crew |\n| tools (read\u002Fwrite files, run commands) | the one who turns screws |\n| session log | the one who takes notes |\n| permissions and sandbox | the doorkeeper |\n| agent loop | the foreman (looks, decides, acts, checks, decides again) |\n| assembly manifest | today's shift roster |\n| plugin | a temp worker |\n| kernel | the head office at the very center |\n| event bus \u002F pub-sub | the bulletin board (anyone can post, everyone can see) |\n\nNew analogies must pass three gates: ① something everyone has seen in daily life; ② sayable in one word; ③ registered in the table.\n\n### Step 2: Write N.1, the plain version — zero terms\n\nTell the section's design point as one scene from the locked analogy. No technical term may appear — not even one. If a term sneaks in, the story is not finished; rewrite the sentence, do not add a glossary line.\n\n### Step 3: Write N.2, the professional layer — add what the story cannot\n\nSame content, now with terms: the formal name, the mechanism as a short bullet list, the applicable boundaries, and the costs. N.2 must not re-tell the story with new labels — it must contribute information the story structurally could not carry. Official quotations belong here, never in N.1.\n\n### Step 4: Close with N.3–N.5\n\n- **N.3 Glossary table** — \"plain saying ↔ professional term\", new terms from this section only. Small sections may drop it.\n- **N.4 Misconceptions** — 2–4 items, each the wrong understanding first, then the right one. Never state the right version alone.\n- **N.5 Transfer point** — 1–2 self-check actions the reader can run on their own project. This is the landing point; the section is not allowed to end on a bare statement.\n\n### Step 5: Run the machine-checkable limits\n\nThese are cheap to check mechanically and catch most AI flavor:\n\n- Section length 1,400–2,200 characters (Chinese), 2–4 diagrams per section.\n- Bold ≤ 2 per thousand characters; em-dash ≤ 2 per thousand.\n- Second person (\"you\") ≤ 4 per section, ideally 0 — let the subject carry the sentence.\n- Banned filler: 综上所述, 值得注意的是, 首先\u002F其次\u002F最后, 强大的, 革命性, 赋能, 众所周知, 不得不说, 简而言之 (and English equivalents: \"in conclusion\", \"it is worth noting\", \"powerful\", \"revolutionary\").\n- Paragraphs 2–6 sentences, alternating long and short.\n\n### Step 6: Apply the terminology firewall and the core test\n\nPackage names, file paths, code, and raw statistics never enter the main text — they go to an appendix. The test: delete every package name from a paragraph. If something remains, it is design. If nothing remains, it is a code walkthrough — rewrite.\n\n### Step 7: Write titles as questions\n\n1. The title is a question, not an answer.\n2. The title contains a concrete object, number, or action.\n3. Declarative titles only when the statement is counter-intuitive enough to create suspense.\n\nDiagrams are the skeleton, not decoration: each one gets a conclusion-style caption (a finding, not a topic) plus a paragraph tying it back to the section's argument.\n\n## Examples\n\n### Example 1: A section on \"the kernel can be empty\"\n\n**User prompt**: \"Explain why DeepSeek Harness can have an empty kernel — the agent loop itself is a plugin.\"\n\n**N.1 (plain version, zero terms)**: A repair crew where even the foreman is a temp worker. Pull the foreman out today, hire a new one tomorrow — the rest of the crew clocks in exactly as before, because nobody reports to the foreman personally; everyone reads the shift roster.\n\n**N.2 (professional layer)**: Kernel vacancy. The kernel defines interfaces, not implementations. The agent loop is one plugin among many; replacing it touches only the assembly manifest. Boundaries: this buys reversibility at the price of indirection — complexity shifts from implementer to user.\n\n**N.3**: 临时工 ↔ plugin; 排班表 ↔ assembly manifest.\n\n**N.4**: Wrong — \"an empty kernel means there is no kernel.\" Right — the kernel is the thinnest possible interface layer, which is exactly why it can stay empty.\n\n**N.5**: Self-check — list your own system's components and ask which one, if pulled out, forces changes elsewhere. That answer is your real kernel.\n\n### Example 2: Repairing an AI-flavored draft\n\n**Input**: \"综上所述，这个强大的架构利用了革命性的插件系统来赋能开发者。\"\n\n**Output after skill**: \"这套架构最反常识的一点：最中间的内核是空的。连 agent 循环本身都是插件——抽走它，别处一行都不用改。代价是间接层变多，复杂度转移给了使用者。\"\n\nNote: no banned filler, subject carries the sentence, concrete object (\"the kernel\"), a stated cost, and a transferable point.\n\n## Best Practices\n\n- ✅ Write N.1 first and freeze it; treat any leaked term as a build failure.\n- ✅ Give every diagram a conclusion caption plus an interpretation paragraph.\n- ✅ Keep one analogy table for the whole project; new analogies must pass the three gates.\n- ✅ End every section on \"why designed this way\" + \"where this transfers\".\n- ✅ Run the style limits mechanically before delivering — they are regexes, not taste.\n- ❌ Do not put citations, commit hashes, or source attributions in the main text; state the口径 in-line and push details to an appendix.\n- ❌ Do not let N.2 re-tell the story with new labels — it must add boundaries, costs, or official wording.\n- ❌ Do not end a section on \"it is what it is\" or a bare count of parts.\n\n## Limitations\n\n- This skill does not replace environment-specific validation, testing, or expert review.\n- The analogy table is a contract: changing wording mid-project breaks readers' mental model. If a better analogy appears, register it deliberately and revise earlier chapters.\n- Stop and ask for clarification if the target system, audience, or section scope is missing.\n\n## Security & Safety Notes\n\n- This skill produces prose only. It includes no shell commands, network fetches, credentials, or mutation guidance.\n- When the subject matter touches security topics, keep the same evidence discipline in the writing: state findings and boundaries in-line, without unverifiable statistics.\n\n## Common Pitfalls\n\n- **Problem:** The plain version slowly accumulates technical terms (\"just this one, readers will know it\").\n  **Solution:** One term is a failure. Rewrite the sentence in everyday words, or move the whole explanation to N.2.\n- **Problem:** N.2 becomes a vocabulary-swapped copy of N.1.\n  **Solution:** Check whether N.2 contains boundaries, costs, or official wording. If not, it is a re-tell — rewrite.\n- **Problem:** The analogy table grows until every term has a different metaphor.\n  **Solution:** One scenario, one consistent cast. Reuse the same characters; do not introduce a new story per chapter.\n- **Problem:** Density checks pass but the text still reads like AI.\n  **Solution:** Read one paragraph aloud. If no concrete object or action appears, replace the abstraction with a scene from the locked analogy.\n\n## Related Skills\n\n- `technical-writer` - For API references and task-based docs where procedure, not design rationale, is the goal.\n- `content-research-writer` - When the draft needs external citations and research before writing.\n- `skill-creator` - When packaging a workflow like this one into a distributable skill.\n","# Bluebook Writing\n\n## Overview\n\nA repeatable method for writing about *why a system is built the way it is* — design reading, not source-code walkthrough, and not vague simplification. Every section tells the same thing twice: first an everyday story with zero technical terms, then the professional layer that adds what the story structurally cannot (formal names, mechanisms, boundaries, costs).\n\nThe method was extracted from a completed 34k-character book that reads DeepSeek Harness (an open-source agent harness) through 42 hand-drawn flow diagrams for an audience of non-programmers. The skill generalizes it for any system, any audience.\n\n## When to Use This Skill\n\n- Use when explaining an unfamiliar architecture, framework, or open-source project to readers who do not write code.\n- Use when writing \"why is it designed this way\" books, long-form articles, or internal architecture docs.\n- Use when a draft reads AI-flavored: terminology-stacked, filler-heavy, or detached from any concrete example.\n- Use when one real-world story must carry an entire book or course, keeping abstract ideas anchored.\n\n## How It Works\n\n### Step 1: Lock the analogy system before writing\n\nPick one everyday scenario (a repair crew, a workshop, a kitchen) and map every technical term to it in a fixed table. The mapping is a contract: once registered, never switch wording mid-book.\n\n| Technical term | Everyday saying |\n|---|---|\n| model | the crew leader's brain (thinks, cannot touch anything) |\n| harness \u002F runtime shell | the whole crew |\n| tools (read\u002Fwrite files, run commands) | the one who turns screws |\n| session log | the one who takes notes |\n| permissions and sandbox | the doorkeeper |\n| agent loop | the foreman (looks, decides, acts, checks, decides again) |\n| assembly manifest | today's shift roster |\n| plugin | a temp worker |\n| kernel | the head office at the very center |\n| event bus \u002F pub-sub | the bulletin board (anyone can post, everyone can see) |\n\nNew analogies must pass three gates: ① something everyone has seen in daily life; ② sayable in one word; ③ registered in the table.\n\n### Step 2: Write N.1, the plain version — zero terms\n\nTell the section's design point as one scene from the locked analogy. No technical term may appear — not even one. If a term sneaks in, the story is not finished; rewrite the sentence, do not add a glossary line.\n\n### Step 3: Write N.2, the professional layer — add what the story cannot\n\nSame content, now with terms: the formal name, the mechanism as a short bullet list, the applicable boundaries, and the costs. N.2 must not re-tell the story with new labels — it must contribute information the story structurally could not carry. Official quotations belong here, never in N.1.\n\n### Step 4: Close with N.3–N.5\n\n- **N.3 Glossary table** — \"plain saying ↔ professional term\", new terms from this section only. Small sections may drop it.\n- **N.4 Misconceptions** — 2–4 items, each the wrong understanding first, then the right one. Never state the right version alone.\n- **N.5 Transfer point** — 1–2 self-check actions the reader can run on their own project. This is the landing point; the section is not allowed to end on a bare statement.\n\n### Step 5: Run the machine-checkable limits\n\nThese are cheap to check mechanically and catch most AI flavor:\n\n- Section length 1,400–2,200 characters (Chinese), 2–4 diagrams per section.\n- Bold ≤ 2 per thousand characters; em-dash ≤ 2 per thousand.\n- Second person (\"you\") ≤ 4 per section, ideally 0 — let the subject carry the sentence.\n- Banned filler: 综上所述, 值得注意的是, 首先\u002F其次\u002F最后, 强大的, 革命性, 赋能, 众所周知, 不得不说, 简而言之 (and English equivalents: \"in conclusion\", \"it is worth noting\", \"powerful\", \"revolutionary\").\n- Paragraphs 2–6 sentences, alternating long and short.\n\n### Step 6: Apply the terminology firewall and the core test\n\nPackage names, file paths, code, and raw statistics never enter the main text — they go to an appendix. The test: delete every package name from a paragraph. If something remains, it is design. If nothing remains, it is a code walkthrough — rewrite.\n\n### Step 7: Write titles as questions\n\n1. The title is a question, not an answer.\n2. The title contains a concrete object, number, or action.\n3. Declarative titles only when the statement is counter-intuitive enough to create suspense.\n\nDiagrams are the skeleton, not decoration: each one gets a conclusion-style caption (a finding, not a topic) plus a paragraph tying it back to the section's argument.\n\n## Examples\n\n### Example 1: A section on \"the kernel can be empty\"\n\n**User prompt**: \"Explain why DeepSeek Harness can have an empty kernel — the agent loop itself is a plugin.\"\n\n**N.1 (plain version, zero terms)**: A repair crew where even the foreman is a temp worker. Pull the foreman out today, hire a new one tomorrow — the rest of the crew clocks in exactly as before, because nobody reports to the foreman personally; everyone reads the shift roster.\n\n**N.2 (professional layer)**: Kernel vacancy. The kernel defines interfaces, not implementations. The agent loop is one plugin among many; replacing it touches only the assembly manifest. Boundaries: this buys reversibility at the price of indirection — complexity shifts from implementer to user.\n\n**N.3**: 临时工 ↔ plugin; 排班表 ↔ assembly manifest.\n\n**N.4**: Wrong — \"an empty kernel means there is no kernel.\" Right — the kernel is the thinnest possible interface layer, which is exactly why it can stay empty.\n\n**N.5**: Self-check — list your own system's components and ask which one, if pulled out, forces changes elsewhere. That answer is your real kernel.\n\n### Example 2: Repairing an AI-flavored draft\n\n**Input**: \"综上所述，这个强大的架构利用了革命性的插件系统来赋能开发者。\"\n\n**Output after skill**: \"这套架构最反常识的一点：最中间的内核是空的。连 agent 循环本身都是插件——抽走它，别处一行都不用改。代价是间接层变多，复杂度转移给了使用者。\"\n\nNote: no banned filler, subject carries the sentence, concrete object (\"the kernel\"), a stated cost, and a transferable point.\n\n## Best Practices\n\n- ✅ Write N.1 first and freeze it; treat any leaked term as a build failure.\n- ✅ Give every diagram a conclusion caption plus an interpretation paragraph.\n- ✅ Keep one analogy table for the whole project; new analogies must pass the three gates.\n- ✅ End every section on \"why designed this way\" + \"where this transfers\".\n- ✅ Run the style limits mechanically before delivering — they are regexes, not taste.\n- ❌ Do not put citations, commit hashes, or source attributions in the main text; state the口径 in-line and push details to an appendix.\n- ❌ Do not let N.2 re-tell the story with new labels — it must add boundaries, costs, or official wording.\n- ❌ Do not end a section on \"it is what it is\" or a bare count of parts.\n\n## Limitations\n\n- This skill does not replace environment-specific validation, testing, or expert review.\n- The analogy table is a contract: changing wording mid-project breaks readers' mental model. If a better analogy appears, register it deliberately and revise earlier chapters.\n- Stop and ask for clarification if the target system, audience, or section scope is missing.\n\n## Security & Safety Notes\n\n- This skill produces prose only. It includes no shell commands, network fetches, credentials, or mutation guidance.\n- When the subject matter touches security topics, keep the same evidence discipline in the writing: state findings and boundaries in-line, without unverifiable statistics.\n\n## Common Pitfalls\n\n- **Problem:** The plain version slowly accumulates technical terms (\"just this one, readers will know it\").\n  **Solution:** One term is a failure. Rewrite the sentence in everyday words, or move the whole explanation to N.2.\n- **Problem:** N.2 becomes a vocabulary-swapped copy of N.1.\n  **Solution:** Check whether N.2 contains boundaries, costs, or official wording. If not, it is a re-tell — rewrite.\n- **Problem:** The analogy table grows until every term has a different metaphor.\n  **Solution:** One scenario, one consistent cast. Reuse the same characters; do not introduce a new story per chapter.\n- **Problem:** Density checks pass but the text still reads like AI.\n  **Solution:** Read one paragraph aloud. If no concrete object or action appears, replace the abstraction with a scene from the locked analogy.\n\n## Related Skills\n\n- `technical-writer` - For API references and task-based docs where procedure, not design rationale, is the goal.\n- `content-research-writer` - When the draft needs external citations and research before writing.\n- `skill-creator` - When packaging a workflow like this one into a distributable skill.\n",{"name":5,"risk":59,"tags":65,"tools":66,"author":69,"source":49,"license":14,"category":34,"date_added":70,"description":7,"source_repo":71,"source_type":49,"license_source":72},[34,45,44,57,43],[67,68,58],"claude","cursor","TobeMagic","2026-10-26","TobeMagic\u002Fdeepseek-harness-bluebook","https:\u002F\u002Fgithub.com\u002FTobeMagic\u002Fdeepseek-harness-bluebook\u002Fblob\u002Fmain\u002FLICENSE","7bf2279c8a65758319526a721d5c4b75683aec9c","skills\u002Fantigravity-bluebook-writing",3,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections","https:\u002F\u002Fgithub.com\u002Fboisenoise","2026-11-12 14:21:24",{"source":8,"skillName":5,"commands":80,"prompt":90,"zipAvailable":91},[81,84,87],{"tool":82,"command":83},"npx","npx skills add boisenoise\u002Fskills-collections --skill bluebook-writing",{"tool":85,"command":86},"bunx","bunx skills add boisenoise\u002Fskills-collections --skill bluebook-writing",{"tool":88,"command":89},"pnpm","pnpm dlx skills add boisenoise\u002Fskills-collections --skill bluebook-writing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-bluebook-writing\u002FSKILL.md",true,[],[94,122,146,170,189,212],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":98,"licenseFileUrl":99,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":60},"01M6WNH92BHVFXHGPDZCPJ0AG0","web-access","Use Treg for public web or platform data only when existing search, browser and connected tools cannot cover the task, with explicit cost and data boundaries.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-web-access\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-web-access\u002FSKILL.md",[],[103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,38,36],"web","access","web access","official","development","browser","search","data","Tools","read","fetch","only","youtube","free tools","platform","critical","free","cover","normal",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":98,"licenseFileUrl":126,"sourceHtmlUrl":127,"categories":128,"keywords":132,"publishedAt":60},"01M6WNF9XAYAB2CZDDJBAKNM93","treg","Use the Treg CLI or MCP catalog to discover, price and call authorized external tools with team-scoped credentials and a user-approved budget.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-treg\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-treg\u002FSKILL.md",[129],{"categoryNo":130,"categoryName":131,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[124,133,134,135,106,107,54,111,136,137,138,139,50,140,141,118,142,143,144,145,36],"MCP","cli","github","Budget","credentials","team","catalog","call","discover","external tools","with","scoped","blob",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":98,"licenseFileUrl":150,"sourceHtmlUrl":151,"categories":152,"keywords":156,"publishedAt":60},"01M6WN93MEAZ4E41DYAHJRPHQT","recruit","Turn a job description into an evidence-linked candidate shortlist through Treg, with job-related ranking and optional authorized business contact enrichment.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-recruit\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-recruit\u002FSKILL.md",[153],{"categoryNo":154,"categoryName":155,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000038","人力资源",[148,135,106,54,157,158,159,160,161,162,118,163,164,165,143,166,167,168,169,145,124,36],"https","email","enrichment","business","evidence","phone","ranking","post","job description","for","person","candidate","reason",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":98,"licenseFileUrl":174,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":60},"01M6WN8R5RXSMHM9B4D9FAFX42","rea-growth","Analyze a company’s public growth and content through Treg, distinguish observations from hypotheses, and produce an evidence-linked playbook within an approved budget.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-rea-growth\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-rea-growth\u002FSKILL.md",[],[178,179,180,135,106,54,181,182,157,183,136,184,185,186,161,118,187,188,145,124,36],"growth","rea","rea growth","produce","content","playbook","marketing","analyze","public","observations","company",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":98,"licenseFileUrl":193,"sourceHtmlUrl":194,"categories":195,"keywords":196,"publishedAt":60},"01M6WN2EVE3RQRGWAKBT4S7YT2","make-ugc","Create original AI UGC-style product videos through Treg: research hooks, approve a licensed presenter and voice, generate clips, add captions and report costs.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-make-ugc\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-make-ugc\u002FSKILL.md",[],[197,198,135,199,106,200,54,201,202,203,204,205,118,206,207,208,209,210,211,145],"make","make ugc","research","create","Video","Captions","ads","short","hooks","head","style","niche","trending","talking-head","approve",{"skillNo":213,"name":214,"nameZh":6,"description":215,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":98,"licenseFileUrl":216,"sourceHtmlUrl":217,"categories":218,"keywords":219,"publishedAt":60},"01M6WN10ARAA63Y8K1YNGXJ2RM","lead-signals","Find and qualify public buying signals through Treg, rank fitting business accounts and optionally enrich authorized business contact information.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-lead-signals\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-lead-signals\u002FSKILL.md",[],[220,221,222,135,106,54,223,224,160,225,226,118,227,228,229,230,231,232,233,145],"signals","lead","lead signals","how","find","ready","as","how to","qualify","people","information","enrich","changes","funding"]