[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71CM81KHSWDZNFSBFHX16NS":3,"skill-same:01M71CM81KHSWDZNFSBFHX16NS":84},{"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":62,"commitSha":63,"skillDirectory":64,"forksCount":14,"repositoryHtmlUrl":65,"repositoryHomepageUrl":6,"ownerHtmlUrl":66,"ownerBlogUrl":67,"ownerDescription":68,"updatedAt":69,"install":70,"resources":83},"01M71CM81KHSWDZNFSBFHX16NS","business-operations-skills",null,"Use when running, diagnosing, or designing internal business operations — process documentation, vendor SLAs, capacity planning, internal comms, SOP\u002Frunbook authoring, procurement spend. Triggers on \"BizOps review\", \"where's the bottleneck\", \"vendor health\", \"internal SOP\", \"all-hands deck\", \"spend categorization\", \"capacity for Q3\", \"process mapping\". Forks context to route to one of six BizOps sub-skills (process-mapper, vendor-management, capacity-planner, internal-comms, knowledge-ops, procurement-optimizer) and returns a digest. Distinct from business-growth (external sales motion) and c-level-advisor (strategic, not operational).","agency-black\u002FSkills","agency-black","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F234862658?v=4","01M6HWVFPNGNR5N2CX9ECSAD57","agencia.black","01M719WF77BF3HN0N9FK1APEFY",0,"MIT","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fbusiness-operations\u002Fskills\u002Fbusiness-operations-skills\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"operations","business operations skills","business","one","use","motion","strategic","triggers","for","gemini","context","comms","authoring","capacity planning","digest","internal comms","vendor-management","knowledge","bottleneck","procurement","2026-11-10 10:12:30",false,"---\nname: business-operations-skills\ndescription: Use when running, diagnosing, or designing internal business operations — process documentation, vendor SLAs, capacity planning, internal comms, SOP\u002Frunbook authoring, procurement spend. Triggers on \"BizOps review\", \"where's the bottleneck\", \"vendor health\", \"internal SOP\", \"all-hands deck\", \"spend categorization\", \"capacity for Q3\", \"process mapping\". Forks context to route to one of six BizOps sub-skills (process-mapper, vendor-management, capacity-planner, internal-comms, knowledge-ops, procurement-optimizer) and returns a digest. Distinct from business-growth (external sales motion) and c-level-advisor (strategic, not operational).\ncontext: fork\nversion: 2.8.0\nauthor: claude-code-skills\nlicense: MIT\ntags: [bizops, operations, process, vendor, capacity, sop, procurement, coo, orchestrator]\ncompatible_tools: [claude-code, codex-cli, cursor, antigravity, opencode, gemini-cli]\n---\n\n# Business Operations — Domain Orchestrator\n\nThe BizOps surface is **internal**: how the company actually runs. This orchestrator forks its conversation context, routes your inquiry to one of six sub-skills, then returns a tight digest to the parent thread. The heavy ingestion (vendor catalogs, process interviews, multi-doc SOP intake) stays in the forked context.\n\n## When to invoke\n\n| Symptom | Sub-skill to route to |\n|---|---|\n| \"Where does the work spend most of its time waiting?\" | `process-mapper` |\n| \"Is this vendor delivering against the SLA?\" | `vendor-management` |\n| \"Do we have enough people to ship in Q3?\" | `capacity-planner` |\n| \"I need to brief the company on a re-org\" | `internal-comms` |\n| \"Write me a runbook for the incident response process\" | `knowledge-ops` |\n| \"Why is our software spend up 40% YoY?\" | `procurement-optimizer` |\n\n## Routing logic (deterministic)\n\nThe orchestrator classifies the inquiry by **signals** detected in the prompt. Two-signal threshold for confident routing; one-signal triggers a clarifying question.\n\n### Signal table\n\n| Signal class | Keywords | Sub-skill |\n|---|---|---|\n| **PROCESS** | bottleneck, cycle time, waiting, handoff, BPMN, process map, workflow | `process-mapper` |\n| **VENDOR** | vendor, supplier, SLA, contract, third-party, MSA, SaaS subscription, renewal | `vendor-management` |\n| **CAPACITY** | headcount, capacity, utilization, planning, hiring sequence, FTE | `capacity-planner` |\n| **COMMS** | all-hands, internal newsletter, announcement, change management, FAQ, town hall | `internal-comms` |\n| **KNOWLEDGE** | SOP, runbook, knowledge base, wiki, playbook, documentation, onboarding doc | `knowledge-ops` |\n| **PROCUREMENT** | spend, procurement, purchase, supplier rationalization, software audit, SaaS sprawl | `procurement-optimizer` |\n\nIf signals are mixed (e.g., \"vendor SLA + spend audit\"), run the **highest-confidence sub-skill first**, then chain into the second one in a follow-up forked turn.\n\n### Fallback\n\nIf no signal class scores ≥ 2, ask **one** clarifying question naming the two most likely candidates. Do NOT guess silently.\n\n## Workflow (Matt Pocock grill discipline)\n\nDerived from Matt Pocock's `grill-with-docs` pattern: **explore-then-ask, one question per turn with a recommended answer, walk the decision tree depth-first, track dependencies, anchor every challenge in the documented canon** (`references\u002F`).\n\n### Step 1 — Explore before asking\n\nBefore any clarifying question, check:\n- Does the user's working directory already contain a process map, vendor catalog, SOP, or org chart we can grep?\n- Does the inquiry already disambiguate the lane (e.g., \"vendor SLA review\" — that's `vendor-management`, no question needed)?\n- Is the lane unambiguous from filenames mentioned (`procurement-Q3.csv` → procurement)?\n\nIf the codebase resolves the lane, **route silently**. Don't ask.\n\n### Step 2 — If still ambiguous, ONE forcing question with a recommended answer\n\nMatt's rule: never bundle questions. Never default to \"what do you think?\". Always offer your recommendation.\n\nPattern:\n```\nQ1\u002F1: [precise question naming the two candidate lanes]\nRecommended: [Lane X, because \u003Cone-sentence rationale from the signal table>]\n\n(Confirm, or override?)\n```\n\nWait for the user's response. **Then** route. Never guess silently after a turn that asked a question.\n\n### Step 3 — Forking decision-tree walk (only if the inquiry crosses lanes)\n\nIf the user's inquiry legitimately crosses two lanes (e.g., \"vendor SLA + spend audit\" = VENDOR + PROCUREMENT), walk the tree **depth-first**:\n\n1. Resolve the higher-confidence lane first → run that sub-skill in forked context → return digest\n2. Ask: \"Should we now run [second lane]? My recommendation: yes, because [dependency reason].\"\n3. Only after explicit user confirmation, run the second sub-skill\n\nDo NOT chain silently. Each fork is an explicit user-confirmed step.\n\n### Step 4 — Invoke sub-skill in forked context\n\nEach sub-skill is invoked with the original prompt + a digest of any structured inputs (file paths, JSON inputs). The fork keeps heavy ingestion (vendor catalog, process transcripts, SOP source documents) out of the parent context.\n\n### Step 5 — Return digest with cited canon challenge\n\nWhen the sub-skill completes, return a **≤ 200-word digest** to the parent thread:\n\n- What was analyzed\n- Top 3 findings (each anchored in a reference doc citation — e.g., \"Goldratt's Theory of Constraints: optimize the bottleneck, not the non-constraint\")\n- Top 3 next actions (named owners if possible)\n- Path to the artifact(s) produced\n- **One grill challenge** for the user, cited: \"Your value-add ratio is 12%. Lean canon (Womack & Jones 1996) classifies \u003C15% as waste-heavy. What's blocking process redesign — political, technical, or budget?\"\n\nThe parent agent can then ask follow-ups (each triggering new forked invocations).\n\n## Forcing-question library (grill-with-docs pattern)\n\nWhen the user has provided enough context to enter a lane, the orchestrator may grill them on the **decisions inside that lane** before invoking the sub-skill. One question per turn, each with a recommended answer + canon citation. Examples:\n\n- **PROCESS lane**: \"Before mapping: do you have measured cycle times per stage, or only estimates? Recommended: insist on measured data for the top-3 longest stages. Anti-pattern (Goldratt 1984): map estimates, optimize the wrong constraint.\"\n- **VENDOR lane**: \"Before scoring: what's your tier-1 criticality threshold — by spend ($X\u002Fyear), or by operational dependency (revenue-blocking if vendor fails)? Recommended: operational dependency. Anti-pattern (Gartner TPRM): spend-only tiering misses critical low-spend vendors like the HVAC vendor in the Target breach.\"\n- **CAPACITY lane**: \"Before modeling: are you planning for utilization or throughput? Recommended: throughput (Little's Law). Anti-pattern (DORA): planning for utilization > 80% destroys throughput via queueing.\"\n\nNever run a sub-skill until the lane-defining decision is locked.\n\n## Assumptions\n\n1. The user is acting on behalf of an organization with ≥ 10 employees (smaller orgs don't need this surface).\n2. The user has access to the data the sub-skill needs (process docs, vendor list, spend export, etc.) — or accepts the skill's templated dummy data.\n3. The user wants **deterministic, repeatable analysis** over LLM-flavored prose. Every sub-skill ships stdlib-only Python tools.\n\n## Non-goals\n\n- Not a substitute for an ERP, vendor management platform (Vendr, Tropic), or capacity-planning SaaS (Float, Runn).\n- Does not store state across sessions — every invocation is self-contained.\n- Does not call external APIs from Python tools (stdlib only, by design).\n\n## Distinct from\n\n- **`business-growth\u002F*`** — that's the **external sales motion** (CSM, sales engineering, RevOps). BizOps is **internal**.\n- **`c-level-advisor\u002Fcoo-advisor`** — that's strategic COO judgment (\"should we restructure?\"). BizOps is tactical (\"here's the process map with bottlenecks\").\n- **`engineering\u002Fslo-architect`** — that's system reliability with SLO\u002FSLI\u002Ferror budgets. `process-mapper` is **business process** reliability, not system reliability.\n- **`engineering\u002Fllm-wiki`** — that's a **personal** PKM (Karpathy's pattern). `knowledge-ops` is **company-wide** SOP authoring.\n\n## Output artifacts\n\nEvery sub-skill produces at least one artifact (markdown, CSV, or JSON) saved to the user's working directory. The orchestrator surfaces the file path in the digest.\n\n## Anti-patterns (do not)\n\n- ❌ Run all 6 sub-skills \"to be thorough\" — pick one based on signal, return digest, let user chain\n- ❌ Auto-approve a vendor or process change — surface findings; the human decides\n- ❌ Edit production process docs without asking — write to a new file, propose the diff\n- ❌ Skip the digest step — parent context needs ≤ 200-word digest, not the full sub-skill output\n\n## References\n\n- See `c-level-advisor\u002Fcoo-advisor` for strategic COO framing\n- Path-B build pattern: `documentation\u002Fimplementation\u002Fbizops-commercial-expansion-plan.md`\n","# Business Operations — Domain Orchestrator\n\nThe BizOps surface is **internal**: how the company actually runs. This orchestrator forks its conversation context, routes your inquiry to one of six sub-skills, then returns a tight digest to the parent thread. The heavy ingestion (vendor catalogs, process interviews, multi-doc SOP intake) stays in the forked context.\n\n## When to invoke\n\n| Symptom | Sub-skill to route to |\n|---|---|\n| \"Where does the work spend most of its time waiting?\" | `process-mapper` |\n| \"Is this vendor delivering against the SLA?\" | `vendor-management` |\n| \"Do we have enough people to ship in Q3?\" | `capacity-planner` |\n| \"I need to brief the company on a re-org\" | `internal-comms` |\n| \"Write me a runbook for the incident response process\" | `knowledge-ops` |\n| \"Why is our software spend up 40% YoY?\" | `procurement-optimizer` |\n\n## Routing logic (deterministic)\n\nThe orchestrator classifies the inquiry by **signals** detected in the prompt. Two-signal threshold for confident routing; one-signal triggers a clarifying question.\n\n### Signal table\n\n| Signal class | Keywords | Sub-skill |\n|---|---|---|\n| **PROCESS** | bottleneck, cycle time, waiting, handoff, BPMN, process map, workflow | `process-mapper` |\n| **VENDOR** | vendor, supplier, SLA, contract, third-party, MSA, SaaS subscription, renewal | `vendor-management` |\n| **CAPACITY** | headcount, capacity, utilization, planning, hiring sequence, FTE | `capacity-planner` |\n| **COMMS** | all-hands, internal newsletter, announcement, change management, FAQ, town hall | `internal-comms` |\n| **KNOWLEDGE** | SOP, runbook, knowledge base, wiki, playbook, documentation, onboarding doc | `knowledge-ops` |\n| **PROCUREMENT** | spend, procurement, purchase, supplier rationalization, software audit, SaaS sprawl | `procurement-optimizer` |\n\nIf signals are mixed (e.g., \"vendor SLA + spend audit\"), run the **highest-confidence sub-skill first**, then chain into the second one in a follow-up forked turn.\n\n### Fallback\n\nIf no signal class scores ≥ 2, ask **one** clarifying question naming the two most likely candidates. Do NOT guess silently.\n\n## Workflow (Matt Pocock grill discipline)\n\nDerived from Matt Pocock's `grill-with-docs` pattern: **explore-then-ask, one question per turn with a recommended answer, walk the decision tree depth-first, track dependencies, anchor every challenge in the documented canon** (`references\u002F`).\n\n### Step 1 — Explore before asking\n\nBefore any clarifying question, check:\n- Does the user's working directory already contain a process map, vendor catalog, SOP, or org chart we can grep?\n- Does the inquiry already disambiguate the lane (e.g., \"vendor SLA review\" — that's `vendor-management`, no question needed)?\n- Is the lane unambiguous from filenames mentioned (`procurement-Q3.csv` → procurement)?\n\nIf the codebase resolves the lane, **route silently**. Don't ask.\n\n### Step 2 — If still ambiguous, ONE forcing question with a recommended answer\n\nMatt's rule: never bundle questions. Never default to \"what do you think?\". Always offer your recommendation.\n\nPattern:\n```\nQ1\u002F1: [precise question naming the two candidate lanes]\nRecommended: [Lane X, because \u003Cone-sentence rationale from the signal table>]\n\n(Confirm, or override?)\n```\n\nWait for the user's response. **Then** route. Never guess silently after a turn that asked a question.\n\n### Step 3 — Forking decision-tree walk (only if the inquiry crosses lanes)\n\nIf the user's inquiry legitimately crosses two lanes (e.g., \"vendor SLA + spend audit\" = VENDOR + PROCUREMENT), walk the tree **depth-first**:\n\n1. Resolve the higher-confidence lane first → run that sub-skill in forked context → return digest\n2. Ask: \"Should we now run [second lane]? My recommendation: yes, because [dependency reason].\"\n3. Only after explicit user confirmation, run the second sub-skill\n\nDo NOT chain silently. Each fork is an explicit user-confirmed step.\n\n### Step 4 — Invoke sub-skill in forked context\n\nEach sub-skill is invoked with the original prompt + a digest of any structured inputs (file paths, JSON inputs). The fork keeps heavy ingestion (vendor catalog, process transcripts, SOP source documents) out of the parent context.\n\n### Step 5 — Return digest with cited canon challenge\n\nWhen the sub-skill completes, return a **≤ 200-word digest** to the parent thread:\n\n- What was analyzed\n- Top 3 findings (each anchored in a reference doc citation — e.g., \"Goldratt's Theory of Constraints: optimize the bottleneck, not the non-constraint\")\n- Top 3 next actions (named owners if possible)\n- Path to the artifact(s) produced\n- **One grill challenge** for the user, cited: \"Your value-add ratio is 12%. Lean canon (Womack & Jones 1996) classifies \u003C15% as waste-heavy. What's blocking process redesign — political, technical, or budget?\"\n\nThe parent agent can then ask follow-ups (each triggering new forked invocations).\n\n## Forcing-question library (grill-with-docs pattern)\n\nWhen the user has provided enough context to enter a lane, the orchestrator may grill them on the **decisions inside that lane** before invoking the sub-skill. One question per turn, each with a recommended answer + canon citation. Examples:\n\n- **PROCESS lane**: \"Before mapping: do you have measured cycle times per stage, or only estimates? Recommended: insist on measured data for the top-3 longest stages. Anti-pattern (Goldratt 1984): map estimates, optimize the wrong constraint.\"\n- **VENDOR lane**: \"Before scoring: what's your tier-1 criticality threshold — by spend ($X\u002Fyear), or by operational dependency (revenue-blocking if vendor fails)? Recommended: operational dependency. Anti-pattern (Gartner TPRM): spend-only tiering misses critical low-spend vendors like the HVAC vendor in the Target breach.\"\n- **CAPACITY lane**: \"Before modeling: are you planning for utilization or throughput? Recommended: throughput (Little's Law). Anti-pattern (DORA): planning for utilization > 80% destroys throughput via queueing.\"\n\nNever run a sub-skill until the lane-defining decision is locked.\n\n## Assumptions\n\n1. The user is acting on behalf of an organization with ≥ 10 employees (smaller orgs don't need this surface).\n2. The user has access to the data the sub-skill needs (process docs, vendor list, spend export, etc.) — or accepts the skill's templated dummy data.\n3. The user wants **deterministic, repeatable analysis** over LLM-flavored prose. Every sub-skill ships stdlib-only Python tools.\n\n## Non-goals\n\n- Not a substitute for an ERP, vendor management platform (Vendr, Tropic), or capacity-planning SaaS (Float, Runn).\n- Does not store state across sessions — every invocation is self-contained.\n- Does not call external APIs from Python tools (stdlib only, by design).\n\n## Distinct from\n\n- **`business-growth\u002F*`** — that's the **external sales motion** (CSM, sales engineering, RevOps). BizOps is **internal**.\n- **`c-level-advisor\u002Fcoo-advisor`** — that's strategic COO judgment (\"should we restructure?\"). BizOps is tactical (\"here's the process map with bottlenecks\").\n- **`engineering\u002Fslo-architect`** — that's system reliability with SLO\u002FSLI\u002Ferror budgets. `process-mapper` is **business process** reliability, not system reliability.\n- **`engineering\u002Fllm-wiki`** — that's a **personal** PKM (Karpathy's pattern). `knowledge-ops` is **company-wide** SOP authoring.\n\n## Output artifacts\n\nEvery sub-skill produces at least one artifact (markdown, CSV, or JSON) saved to the user's working directory. The orchestrator surfaces the file path in the digest.\n\n## Anti-patterns (do not)\n\n- ❌ Run all 6 sub-skills \"to be thorough\" — pick one based on signal, return digest, let user chain\n- ❌ Auto-approve a vendor or process change — surface findings; the human decides\n- ❌ Edit production process docs without asking — write to a new file, propose the diff\n- ❌ Skip the digest step — parent context needs ≤ 200-word digest, not the full sub-skill output\n\n## References\n\n- See `c-level-advisor\u002Fcoo-advisor` for strategic COO framing\n- Path-B build pattern: `documentation\u002Fimplementation\u002Fbizops-commercial-expansion-plan.md`\n",{"name":5,"tags":44,"author":52,"context":53,"license":15,"version":54,"description":7,"compatible_tools":55},[45,19,46,47,48,49,38,50,51],"bizops","process","vendor","capacity","sop","coo","orchestrator","claude-code-skills","fork","2.8.0",[56,57,58,59,60,61],"claude-code","codex-cli","cursor","antigravity","opencode","gemini-cli","main","681496e0662f4c45c4758fae9d4510ae87311bf2","business-operations\u002Fskills\u002Fbusiness-operations-skills","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills","https:\u002F\u002Fgithub.com\u002Fagency-black","http:\u002F\u002Fwww.dogma.black","Las grandes ideas merecen una ejecución impecable. Construimos plataformas web, aplicaciones y ecosistemas digitales completos. Esta Trinidad es nuestro dogma.","2026-05-29 16:13:55",{"source":8,"skillName":5,"commands":71,"prompt":81,"zipAvailable":82},[72,75,78],{"tool":73,"command":74},"npx","npx skills add agency-black\u002FSkills --skill business-operations-skills",{"tool":76,"command":77},"bunx","bunx skills add agency-black\u002FSkills --skill business-operations-skills",{"tool":79,"command":80},"pnpm","pnpm dlx skills add agency-black\u002FSkills --skill business-operations-skills","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fbusiness-operations\u002Fskills\u002Fbusiness-operations-skills\u002FSKILL.md",true,[],[85,110,140,170,195,220],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":39},"01M71JZVZ0TVW7Z5DQBRWSBG8A","zarr-python","Chunked N-D arrays for cloud storage (Zarr-Python 3). Compressed arrays, parallel I\u002FO, S3\u002FGCS via fsspec, NumPy\u002FDask\u002FXarray compatible, for large-scale scientific computing pipelines.","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fzarr-python\u002FSKILL.md",[],[92,93,94,95,96,97,98,99,100,101,102,103,104,27,105,23,106,107,108,109],"zarr python","python","zarr","arrays","Cloud Storage","remote","workflows","scientific","read","write","edit","parallel","dask","s3fs","numpy","s3","scientific computing","scale",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":114,"sourceHtmlUrl":115,"categories":116,"keywords":122,"publishedAt":39},"01M71JYXC5VAEJT8KXN5GRK32S","xvary-stock-research","Thesis-driven equity analysis from public SEC EDGAR and market data; \u002Fanalyze, \u002Fscore, \u002Fcompare workflows with bundled Python tools (Claude Code, Cursor, Codex).","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fxvary-stock-research\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fxvary-stock-research\u002FSKILL.md",[117],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[123,124,125,126,127,128,129,93,130,98,131,132,133,134,135,136,137,138,58,139],"xvary","stock","research","xvary stock research","sec edgar","community","equity","thesis","analysis","code","Market","compare","market data","analyze","with","codex","2026",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":144,"licenseFileUrl":145,"sourceHtmlUrl":146,"categories":147,"keywords":154,"publishedAt":39},"01M71JVSDPDQ5040YBN6J1ASKY","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fwebapp-testing\u002FSKILL.md",[148,151],{"categoryNo":149,"categoryName":150,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":152,"categoryName":153,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000009","前端开发",[155,156,157,27,158,159,160,161,162,163,164,137,165,166,167,168,169],"webapp","testing","webapp testing","applications","local","frontend","debugging","toolkit","logs","browser","playwright","web","behavior","ui","screenshots",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":144,"licenseFileUrl":174,"sourceHtmlUrl":175,"categories":176,"keywords":178,"publishedAt":39},"01M71JV64CW7R6FYYK9JWWGW0X","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fweb-artifacts-builder\u002FSKILL.md",[177],{"categoryNo":152,"categoryName":153,"taxonomyType":120,"taxonomyTypeDesc":121},[179,180,181,166,182,183,184,27,185,186,160,187,23,188,189,190,191,192,193,194],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","file","components","react","multi","state","routing","state management",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":202,"publishedAt":39},"01M71JS4X2FRY41DE84DEP06MN","vercel-react-view-transitions","Guide for implementing smooth, native-feeling animations using React's View Transition API (`\u003CViewTransition>` component, `addTransitionType`, and CSS view transition pseudo-elements). Use this skill whenever the user wants to add page transitions, animate route changes, create shared element animations, animate enter\u002Fexit of components, animate list reorder, implement directional (forward\u002Fback) navigation animations, or integrate view transitions in Next.js. Also use when the user mentions view transitions, `startViewTransition`, `ViewTransition`, transition types, or asks about animating between UI states in React without third-party animation libraries.","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fvercel-react-view-transitions\u002FSKILL.md",[201],{"categoryNo":152,"categoryName":153,"taxonomyType":120,"taxonomyTypeDesc":121},[190,203,204,205,206,207,208,209,210,184,211,212,213,214,215,189,216,217,218,219],"vercel react view transitions","view","react view transitions","vercel","transitions","shared","back","Animation","types","states","element","implementing","when","api","route","create","libraries",{"skillNo":221,"name":222,"nameZh":6,"description":223,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":224,"categories":225,"keywords":227,"publishedAt":39},"01M71JS1WZ1J4F9YVC2203JBJW","vercel-react-native-skills","React Native and Expo best practices for building performant mobile apps. Use when building React Native components, optimizing list performance, implementing animations, or working with native modules. Triggers on tasks involving React Native, Expo, mobile performance, or native platform APIs.","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fvercel-react-native-skills\u002FSKILL.md",[226],{"categoryNo":152,"categoryName":153,"taxonomyType":120,"taxonomyTypeDesc":121},[206,228,190,229,230,231,232,233,234,27,235,214,26,23,236,237,215,238,239,189],"vercel react native skills","react native","native","react native skills","modules","platform","animations","performance","react native components","apps","best practices","tasks"]