[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6EZR9FZVGDPNPD3K0Q58MCH":3,"skill-same:01M6EZR9FZVGDPNPD3K0Q58MCH":66},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6EZR9FZVGDPNPD3K0Q58MCH","inbound-opportunity-protocol",null,"End-to-end protocol for when outbound open-source contributions generate inbound relationship opportunities. Covers contact verification, company research, architectural comparison, conversation preparation with multi-register talking points (technical\u002Fhumanities\u002FELI5), response drafting, and honest boundary mapping. Triggers on inbound emails from contribution targets, cold outreach from people who found your PRs, or any signal that an open-source contribution attracted strategic attention.","luokai0\u002Fai-agent-skills-by-luo-kai","luokai0","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F266954973?v=4","01M6E16VNT42JB8B3X3254QWJ7","luo kai","01M6E16VTFVP6S5XJF1V1MPV90",14,"MIT","https:\u002F\u002Fgithub.com\u002Fluokai0\u002Fai-agent-skills-by-luo-kai\u002Fblob\u002Fmain\u002Fai-agent-skills\u002F21-external-registries\u002F18-organvm-skills\u002Fprofessional\u002Finbound-opportunity-protocol\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"inbound opportunity protocol","opportunity","protocol","end","with","strategic","comparison","cold","people","register","contribution","triggers","emails","attention","outbound","cold outreach","relationship","conversation","technical","open","2026-11-10 10:12:30",false,"---\nlicense: MIT\nname: inbound-opportunity-protocol\ndescription: End-to-end protocol for when outbound open-source contributions generate inbound relationship opportunities. Covers contact verification, company research, architectural comparison, conversation preparation with multi-register talking points (technical\u002Fhumanities\u002FELI5), response drafting, and honest boundary mapping. Triggers on inbound emails from contribution targets, cold outreach from people who found your PRs, or any signal that an open-source contribution attracted strategic attention.\n---\nlicense: MIT\n\n# Inbound Opportunity Protocol\n\nWhen outbound contributions attract inbound attention — an email, a follow, a DM, a meeting request — this protocol governs the response. The contribution engine's campaign phases (UNBLOCK → ENGAGE → CULTIVATE → HARVEST → INJECT) produce these moments. This skill handles HARVEST.\n\n## When to Use\n\n- An external person emails after seeing a PR or GitHub activity\n- A company reaches out based on open-source contributions\n- A contributor on your repos proposes collaboration\n- Any signal that code output has converted to human contact\n\n## The Protocol\n\n### Phase 1: Verify (Before Responding)\n\nEstablish who contacted you and why. Never reply before completing verification.\n\n**1.1 Identity verification:**\n- Search GitHub for the person and their org (`gh api search\u002Fusers`, `gh search repos owner:\u003Corg>`)\n- Check their GitHub profile: repos, followers, contribution history, company affiliation\n- Search the web: company website, LinkedIn, Twitter\u002FX, Crunchbase\n- Cross-reference with existing outreach\u002Fcampaign data if the contact traces to a tracked relationship\n\n**1.2 Company research (if applicable):**\n- Fetch and analyze their public website, docs, and product pages\n- Identify: team size, funding stage, tech stack, product architecture\n- Check for job openings (research, don't mention)\n- Assess: is this a potential employer, partner, collaborator, or user?\n\n**1.3 Signal assessment:**\n- What triggered the contact? (specific PR, GitHub profile, repo discovery)\n- How fast did they respond? (same-day = they're monitoring the contributor space)\n- What do they want? (knowledge exchange, hiring, partnership, product feedback)\n- Strategic value: rate across 4 axes:\n  - **Skill acquisition** — what can we learn from them?\n  - **Reputation leverage** — does association increase visibility?\n  - **Relationship depth** — could this become a lasting professional connection?\n  - **Direct improvement** — does their work improve our stack?\n\n### Phase 2: Architecture Comparison\n\nBefore responding, understand how their system compares to yours. This determines conversation strategy.\n\n**2.1 Map their architecture:**\n- Read their docs, API references, and any public code\n- Identify their core primitives (what are their equivalents of your key abstractions?)\n- Note what they've built vs what they're building vs what they're struggling with\n\n**2.2 Find the intersection:**\n- Where do architectures overlap? (shared problems, similar solutions)\n- Where do they diverge? (different trade-offs, complementary approaches)\n- What do you have that they don't? (your distinctive contribution to the conversation)\n- What do they have that you don't? (what you can learn)\n\n**2.3 Identify the hook:**\n- Find one architectural position where your approach differs from the mainstream\n- Frame it as a refinement, not a contradiction — \"I'd push your thesis further\" not \"you're wrong\"\n- The hook must be genuine and grounded in implementation, not theoretical posturing\n\n### Phase 3: Prepare Talking Points\n\nBuild a conversation prep document with three registers. Same architecture, three voices.\n\n**3.1 Technical register:**\nFor each major architectural component:\n- **30-second explanation** — conversational, no jargon, how to explain it to a peer\n- **Design trade-off** — what was the alternative, why this was chosen\n- **Honest limitation** — what doesn't work yet or where the design breaks\n- **Connection to their question** — how this relates to what they asked about\n\n**3.2 Humanities register:**\nTranslate each component into its intellectual lineage:\n- Biological precedent (ecology, ethology, neuroscience)\n- Philosophical framing (phenomenology, systems theory, process philosophy)\n- Cultural\u002Fliterary reference (art, literature, social theory)\n- The humanities register demonstrates depth of understanding — knowing WHY it works at a conceptual level, not just how\n\n**3.3 ELI5 register:**\nTranslate each component into a simple analogy:\n- Everyday metaphor (kitchen, school, office, nature)\n- No technical terms whatsoever\n- The ELI5 register is the escape hatch — when reaching for jargon that can't be backed up, drop to ELI5. It sounds confident, not evasive.\n\n**3.4 Boundary mapping:**\nExplicitly list:\n- **Three things NOT to claim** — areas where depth is thin or implementation is incomplete\n- **Three questions to ask them** — questions that reveal their architecture without directly asking \"show me your code\"\n- **Landmines to avoid** — company-specific sensitivities, naming confusions, things not to dismiss\n\n### Phase 4: Draft Response\n\nThe response follows strict constraints:\n\n**4.1 Length discipline:**\n- Match or beat their brevity. If they wrote 5 sentences, write 4.\n- Never explain full architecture in the first message.\n- The response is a hook, not a presentation.\n\n**4.2 Structure:**\n1. Acknowledge what brought them to you (shows understanding of the connection)\n2. Engage with their thesis — refine it, don't just agree (\"resonates, but I'd push it further\")\n3. Offer the hook — one distinctive architectural position\n4. Accept the meeting\u002Fchat\n5. Sign off\n\n**4.3 What NOT to include:**\n- Don't link to repos (let them discover the iceberg)\n- Don't mention job interest\n- Don't list credentials or projects\n- Don't oversell — a peer being consulted, not an applicant pitching\n\n### Phase 5: Pre-Conversation Preparation\n\nAfter sending the response and before the actual conversation:\n\n**5.1 Code fluency pass:**\nRead key source files — not to memorize, but to have *opinions* about design trade-offs. Know the constants, thresholds, and architectural reasons.\n\n**5.2 Conversation strategy:**\n- Lead with the distinctive claim (the hook from the response)\n- Ask questions that reveal their architecture before exposing yours\n- Cite external validation (contributor threads, community engagement) not just own work\n- If asked about production scale: be honest. \"Architecturally designed and unit-tested, not validated at scale.\"\n\n**5.3 Power position awareness:**\nIf they reached out first, the responder is the expert being consulted. Maintain that framing:\n- Don't volunteer weaknesses unprompted\n- Don't ask about job openings\n- Let employment\u002Fpartnership surface naturally from demonstrated competence\n- The conversation IS the audition without either side calling it that\n\n### Phase 6: Post-Conversation\n\n**6.1 Log the interaction:**\n- Add\u002Fupdate entry in outreach.yaml with event and relationship score adjustment\n- Update campaign.yaml if this advances a campaign phase\n- Add to tracked_conversations.yaml if ongoing\n\n**6.2 Backflow extraction:**\n- What architectural patterns were learned from their system?\n- What questions did they ask that reveal gaps in own thinking?\n- Deposit learnings into backflow.yaml with organ targets\n\n**6.3 Follow-up:**\n- If action items were discussed, execute within 48 hours\n- If they suggested looking at something specific, research and respond\n- If the conversation was purely exploratory, brief follow-up within 24 hours\n\n## Artifacts\n\nThe protocol produces three artifacts, stored in `contrib_engine\u002Fartifacts\u002F`:\n\n1. `\u003Ccompany>-briefing.md` — company profile, architecture, team, competitive positioning\n2. `\u003Ccompany>-conversation-prep.md` — technical talking points, trade-offs, boundaries, questions\n3. `\u003Ccompany>-conversation-filters.md` — humanities and ELI5 translations of the same architecture\n\n## Key Principles\n\n- **Research before responding.** Never reply to an inbound contact without completing Phase 1.\n- **Shorter than theirs.** The response is a hook, not a pitch deck.\n- **Three registers, one architecture.** Technical for depth, humanities for breadth, ELI5 for escape.\n- **Honest boundaries.** Know what NOT to claim before the conversation starts.\n- **The conversation is the demonstration.** Competence surfaces through substance, not credentials.\n","license: MIT\n\n# Inbound Opportunity Protocol\n\nWhen outbound contributions attract inbound attention — an email, a follow, a DM, a meeting request — this protocol governs the response. The contribution engine's campaign phases (UNBLOCK → ENGAGE → CULTIVATE → HARVEST → INJECT) produce these moments. This skill handles HARVEST.\n\n## When to Use\n\n- An external person emails after seeing a PR or GitHub activity\n- A company reaches out based on open-source contributions\n- A contributor on your repos proposes collaboration\n- Any signal that code output has converted to human contact\n\n## The Protocol\n\n### Phase 1: Verify (Before Responding)\n\nEstablish who contacted you and why. Never reply before completing verification.\n\n**1.1 Identity verification:**\n- Search GitHub for the person and their org (`gh api search\u002Fusers`, `gh search repos owner:\u003Corg>`)\n- Check their GitHub profile: repos, followers, contribution history, company affiliation\n- Search the web: company website, LinkedIn, Twitter\u002FX, Crunchbase\n- Cross-reference with existing outreach\u002Fcampaign data if the contact traces to a tracked relationship\n\n**1.2 Company research (if applicable):**\n- Fetch and analyze their public website, docs, and product pages\n- Identify: team size, funding stage, tech stack, product architecture\n- Check for job openings (research, don't mention)\n- Assess: is this a potential employer, partner, collaborator, or user?\n\n**1.3 Signal assessment:**\n- What triggered the contact? (specific PR, GitHub profile, repo discovery)\n- How fast did they respond? (same-day = they're monitoring the contributor space)\n- What do they want? (knowledge exchange, hiring, partnership, product feedback)\n- Strategic value: rate across 4 axes:\n  - **Skill acquisition** — what can we learn from them?\n  - **Reputation leverage** — does association increase visibility?\n  - **Relationship depth** — could this become a lasting professional connection?\n  - **Direct improvement** — does their work improve our stack?\n\n### Phase 2: Architecture Comparison\n\nBefore responding, understand how their system compares to yours. This determines conversation strategy.\n\n**2.1 Map their architecture:**\n- Read their docs, API references, and any public code\n- Identify their core primitives (what are their equivalents of your key abstractions?)\n- Note what they've built vs what they're building vs what they're struggling with\n\n**2.2 Find the intersection:**\n- Where do architectures overlap? (shared problems, similar solutions)\n- Where do they diverge? (different trade-offs, complementary approaches)\n- What do you have that they don't? (your distinctive contribution to the conversation)\n- What do they have that you don't? (what you can learn)\n\n**2.3 Identify the hook:**\n- Find one architectural position where your approach differs from the mainstream\n- Frame it as a refinement, not a contradiction — \"I'd push your thesis further\" not \"you're wrong\"\n- The hook must be genuine and grounded in implementation, not theoretical posturing\n\n### Phase 3: Prepare Talking Points\n\nBuild a conversation prep document with three registers. Same architecture, three voices.\n\n**3.1 Technical register:**\nFor each major architectural component:\n- **30-second explanation** — conversational, no jargon, how to explain it to a peer\n- **Design trade-off** — what was the alternative, why this was chosen\n- **Honest limitation** — what doesn't work yet or where the design breaks\n- **Connection to their question** — how this relates to what they asked about\n\n**3.2 Humanities register:**\nTranslate each component into its intellectual lineage:\n- Biological precedent (ecology, ethology, neuroscience)\n- Philosophical framing (phenomenology, systems theory, process philosophy)\n- Cultural\u002Fliterary reference (art, literature, social theory)\n- The humanities register demonstrates depth of understanding — knowing WHY it works at a conceptual level, not just how\n\n**3.3 ELI5 register:**\nTranslate each component into a simple analogy:\n- Everyday metaphor (kitchen, school, office, nature)\n- No technical terms whatsoever\n- The ELI5 register is the escape hatch — when reaching for jargon that can't be backed up, drop to ELI5. It sounds confident, not evasive.\n\n**3.4 Boundary mapping:**\nExplicitly list:\n- **Three things NOT to claim** — areas where depth is thin or implementation is incomplete\n- **Three questions to ask them** — questions that reveal their architecture without directly asking \"show me your code\"\n- **Landmines to avoid** — company-specific sensitivities, naming confusions, things not to dismiss\n\n### Phase 4: Draft Response\n\nThe response follows strict constraints:\n\n**4.1 Length discipline:**\n- Match or beat their brevity. If they wrote 5 sentences, write 4.\n- Never explain full architecture in the first message.\n- The response is a hook, not a presentation.\n\n**4.2 Structure:**\n1. Acknowledge what brought them to you (shows understanding of the connection)\n2. Engage with their thesis — refine it, don't just agree (\"resonates, but I'd push it further\")\n3. Offer the hook — one distinctive architectural position\n4. Accept the meeting\u002Fchat\n5. Sign off\n\n**4.3 What NOT to include:**\n- Don't link to repos (let them discover the iceberg)\n- Don't mention job interest\n- Don't list credentials or projects\n- Don't oversell — a peer being consulted, not an applicant pitching\n\n### Phase 5: Pre-Conversation Preparation\n\nAfter sending the response and before the actual conversation:\n\n**5.1 Code fluency pass:**\nRead key source files — not to memorize, but to have *opinions* about design trade-offs. Know the constants, thresholds, and architectural reasons.\n\n**5.2 Conversation strategy:**\n- Lead with the distinctive claim (the hook from the response)\n- Ask questions that reveal their architecture before exposing yours\n- Cite external validation (contributor threads, community engagement) not just own work\n- If asked about production scale: be honest. \"Architecturally designed and unit-tested, not validated at scale.\"\n\n**5.3 Power position awareness:**\nIf they reached out first, the responder is the expert being consulted. Maintain that framing:\n- Don't volunteer weaknesses unprompted\n- Don't ask about job openings\n- Let employment\u002Fpartnership surface naturally from demonstrated competence\n- The conversation IS the audition without either side calling it that\n\n### Phase 6: Post-Conversation\n\n**6.1 Log the interaction:**\n- Add\u002Fupdate entry in outreach.yaml with event and relationship score adjustment\n- Update campaign.yaml if this advances a campaign phase\n- Add to tracked_conversations.yaml if ongoing\n\n**6.2 Backflow extraction:**\n- What architectural patterns were learned from their system?\n- What questions did they ask that reveal gaps in own thinking?\n- Deposit learnings into backflow.yaml with organ targets\n\n**6.3 Follow-up:**\n- If action items were discussed, execute within 48 hours\n- If they suggested looking at something specific, research and respond\n- If the conversation was purely exploratory, brief follow-up within 24 hours\n\n## Artifacts\n\nThe protocol produces three artifacts, stored in `contrib_engine\u002Fartifacts\u002F`:\n\n1. `\u003Ccompany>-briefing.md` — company profile, architecture, team, competitive positioning\n2. `\u003Ccompany>-conversation-prep.md` — technical talking points, trade-offs, boundaries, questions\n3. `\u003Ccompany>-conversation-filters.md` — humanities and ELI5 translations of the same architecture\n\n## Key Principles\n\n- **Research before responding.** Never reply to an inbound contact without completing Phase 1.\n- **Shorter than theirs.** The response is a hook, not a pitch deck.\n- **Three registers, one architecture.** Technical for depth, humanities for breadth, ELI5 for escape.\n- **Honest boundaries.** Know what NOT to claim before the conversation starts.\n- **The conversation is the demonstration.** Competence surfaces through substance, not credentials.\n",{"name":5,"license":15,"description":7},"main","4d2fb89cdfb75f3f6fd3c6c5ec9ad90ea129eb3c","ai-agent-skills\u002F21-external-registries\u002F18-organvm-skills\u002Fprofessional\u002Finbound-opportunity-protocol",1,"https:\u002F\u002Fgithub.com\u002Fluokai0\u002Fai-agent-skills-by-luo-kai","https:\u002F\u002Fgithub.com\u002Fluokai0","a solo builder.","2026-05-06 04:29:04",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add luokai0\u002Fai-agent-skills-by-luo-kai --skill inbound-opportunity-protocol",{"tool":58,"command":59},"bunx","bunx skills add luokai0\u002Fai-agent-skills-by-luo-kai --skill inbound-opportunity-protocol",{"tool":61,"command":62},"pnpm","pnpm dlx skills add luokai0\u002Fai-agent-skills-by-luo-kai --skill inbound-opportunity-protocol","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fluokai0\u002Fai-agent-skills-by-luo-kai\u002Fblob\u002Fmain\u002Fai-agent-skills\u002F21-external-registries\u002F18-organvm-skills\u002Fprofessional\u002Finbound-opportunity-protocol\u002FSKILL.md",true,[],[67,94,111,141,172,209],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":39},"01M6F2SKTE208174C7S7JJCZC7","write-contracts","Generates secure Aptos Move V2 smart contracts with Object model, Digital Asset integration, security patterns, and storage type guidance. Includes comprehensive storage decision framework for optimal data structure selection. Triggers on: 'write contract', 'create NFT collection', 'build marketplace', 'implement minting', 'generate Move module', 'create token contract', 'build DAO', 'implement staking'. Ask storage questions when: 'store', 'track', 'registry', 'mapping', 'list', 'collection'.","https:\u002F\u002Fgithub.com\u002Fluokai0\u002Fai-agent-skills-by-luo-kai\u002Fblob\u002Fmain\u002Fai-agent-skills\u002F22-clawhub-skills\u002Fwrite-contracts\u002FSKILL.md",[],[74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93],"write","contracts","write contracts","storage","secure","create","generate","collection","model","decision","ask","smart-contracts","selection","objects","structure","nft","token","aptos","critical","move",{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":39},"01M6F2RFXJ6T9MKW0A7N7GM45B","web-search","通用网络搜索技能，支持多引擎搜索（百度、必应、DuckDuckGo），无需API密钥即可获取实时信息","https:\u002F\u002Fgithub.com\u002Fluokai0\u002Fai-agent-skills-by-luo-kai\u002Fblob\u002Fmain\u002Fai-agent-skills\u002F22-clawhub-skills\u002Fweb-search-ex-skill\u002FSKILL.md",[],[101,102,103,104,105,106,107,108,109,110],"web","search","web search","搜索","baidu","bing","duckduckgo","百度","多引擎","internet",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":122,"publishedAt":39},"01M6F2K968G1FZEZFPW2E6B222","solo-build","Execute implementation plan tasks with TDD workflow, auto-commit, and phase gates. Use when user says \"build it\", \"start building\", \"execute plan\", \"implement tasks\", \"ship it\", or references a track ID. Do NOT use for planning (use \u002Fplan) or scaffolding (use \u002Fscaffold).","https:\u002F\u002Fgithub.com\u002Fluokai0\u002Fai-agent-skills-by-luo-kai\u002Fblob\u002Fmain\u002Fai-agent-skills\u002F22-clawhub-skills\u002Fsolo-build\u002FSKILL.md",[117],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[123,124,125,126,127,128,129,130,102,131,132,133,74,134,135,136,137,138,139,140],"build","solo","solo build","MCP","workflow","commit","tasks","code","Bash","plan","read","auto","references","context7","query","scaffolding","ship it","project",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":153,"publishedAt":39},"01M6F2GKN39SGHSPWYB3662YC8","react-email","Use when building HTML email templates with React components, adding a visual email editor to an application using the React Email visual editor, rendering emails to HTML, or sending emails with Resend. Covers welcome emails, password resets, notifications, order confirmations, newsletters, transactional emails, and the embeddable email editor component.","https:\u002F\u002Fgithub.com\u002Fluokai0\u002Fai-agent-skills-by-luo-kai\u002Fblob\u002Fmain\u002Fai-agent-skills\u002F22-clawhub-skills\u002Freact-email-skills\u002FSKILL.md",[147,150],{"categoryNo":148,"categoryName":149,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000005","邮件与沟通",{"categoryNo":151,"categoryName":152,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000009","前端开发",[154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,31,171,23],"react","email","react email","github","editor","components","react components","component","welcome","https","notifications","password","node","use","html","resend","visual","rendering",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":190,"publishedAt":39},"01M6F2FBVGVDFSG8SSFJGXA40C","APITester Agent-Driven API Testing","Test API endpoints and document responses. Define tests in plain English, run them, get formatted results. Agent-driven Postman alternative.","https:\u002F\u002Fgithub.com\u002Fluokai0\u002Fai-agent-skills-by-luo-kai\u002Fblob\u002Fmain\u002Fai-agent-skills\u002F22-clawhub-skills\u002Fopenclaw-api-tester\u002FSKILL.md",[178,181,184,185],{"categoryNo":179,"categoryName":180,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":182,"categoryName":183,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},{"categoryNo":186,"categoryName":187,"taxonomyType":188,"taxonomyTypeDesc":189},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208],"testing","api","api testing","driven","APITester Agent Driven API Testing","test","run","postman","results","plain english","tester","endpoints","document","get","define","tests","english","api-tester",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":215,"publishedAt":39},"01M6F273Y3NGAPVJZ608BC0G9G","hubspot-implementation-plan","Generate a phased implementation plan from a HubSpot audit report. Creates prioritized, sequenced cleanup processes with effort estimates, dependencies, and automation feasibility. Use after running \u002Fhubspot-audit.","https:\u002F\u002Fgithub.com\u002Fluokai0\u002Fai-agent-skills-by-luo-kai\u002Fblob\u002Fmain\u002Fai-agent-skills\u002F22-clawhub-skills\u002Fhubspot-implementation-plan\u002FSKILL.md",[],[132,216,217,218,219,220,221,80,222,223,224,225,226,167,227,228,23,229],"implementation","hubspot","hubspot implementation plan","automation","feasibility","cleanup","planning","report","audit","audit report","phased implementation","dependencies","processes","hubspot audit"]