[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7513N4SWWC19BX89ZMCN0EQ":3,"skill-same:01M7513N4SWWC19BX89ZMCN0EQ":49},{"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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":26,"commitSha":27,"skillDirectory":28,"forksCount":29,"repositoryHtmlUrl":30,"repositoryHomepageUrl":31,"ownerHtmlUrl":32,"ownerBlogUrl":31,"ownerDescription":33,"updatedAt":34,"install":35,"resources":48},"01M7513N4SWWC19BX89ZMCN0EQ","mongodb-expert",null,"Designs MongoDB schemas, indexes, and aggregation pipelines that perform - embed-vs-reference decision rules, the 16MB document limit, ESR compound-index ordering, explain-plan verification, and operational settings for replica sets and sharding. Use when someone asks \"should I embed or reference this\", \"why is my Mongo query slow\", \"design a MongoDB schema for X\", \"how do I structure this aggregation pipeline\", or \"what should my shard key be\". Do NOT use for relational or SQL schema design - use database-schema instead; for tuning SQL queries use sql-query-optimizer; for Postgres-on-Supabase work use supabase-expert.","SkillMedev\u002Fskills","SkillMedev","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F298078254?v=4","01M74ZSGTQ918CB0VXW4EG3RMX","SkillMe","01M74ZSGVBT497NA95CBT8JTY4",25,"MIT","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fmongodb-expert\u002FSKILL.md",[],[],"2026-11-11 18:11:01",false,"---\nname: mongodb-expert\ndescription: Designs MongoDB schemas, indexes, and aggregation pipelines that perform - embed-vs-reference decision rules, the 16MB document limit, ESR compound-index ordering, explain-plan verification, and operational settings for replica sets and sharding. Use when someone asks \"should I embed or reference this\", \"why is my Mongo query slow\", \"design a MongoDB schema for X\", \"how do I structure this aggregation pipeline\", or \"what should my shard key be\". Do NOT use for relational or SQL schema design - use database-schema instead; for tuning SQL queries use sql-query-optimizer; for Postgres-on-Supabase work use supabase-expert.\nmetadata:\n  title: \"MongoDB Expert\"\n---\n\n# MongoDB Expert\n\nModel data, index it, and query it the MongoDB way: around access patterns, not normalization. The costly mistake this skill prevents is a relationally-normalized schema ported into Mongo - a design that forces application-side joins on every read and, in the opposite failure, unbounded embedded arrays that grow until documents hit the 16MB limit and writes start failing in production.\n\n## Operating procedure\n\nSchema first, indexes second, pipelines third - indexes serve queries, and queries are determined by the schema, so working backwards wastes every downstream decision.\n\n### Step 1: Gather inputs\n\n1. The top read and write patterns, ranked by frequency: which entities are fetched together, filtered by what, sorted by what.\n2. Cardinality and growth of every one-to-many relationship: bounded (\"an order has 5-50 line items\") or unbounded (\"a user accrues events forever\"). Label estimates as guesses.\n3. Read\u002Fwrite ratio per collection and expected document counts.\n4. Deployment shape: replica set or sharded cluster, and durability requirements.\n\n### Step 2: Decide embed vs reference per relationship\n\nApply these rules in order; the first that fires decides.\n\n1. Accessed together and the child side is bounded (a known, modest maximum) → embed. One read serves the whole query.\n2. Child is unbounded, large, or shared by multiple parents → reference. Unbounded arrays are the canonical anti-pattern: array growth relocates documents, bloats indexes, and marches toward the 16MB document cap.\n3. Need the most recent few children with the parent, but the full set is unbounded → subset pattern: embed the latest N (say 10) and keep the full history in a referenced collection.\n4. High-volume time-ordered children (events, readings) → bucket pattern: one document per parent per time window (for example, per hour) holding an array capped by the window.\n\nBudget documents well under 16MB - treat a typical document above a few hundred KB as a design smell to justify, not a limit to approach.\n\n### Step 3: Index for the actual queries\n\nIndexes are the single biggest performance lever.\n\n- Follow the ESR rule for compound indexes: Equality fields first, then Sort fields, then Range fields. A query filtering on customerId and sorting by createdAt is fully served by `{ customerId: 1, createdAt: -1 }`.\n- Verify with `explain(\"executionStats\")`: require IXSCAN, never COLLSCAN, on any hot path; check that `totalDocsExamined` is close to `nReturned` - a 100:1 ratio means the index is not selective for that query.\n- Use partial indexes to index only the documents a query can match (for example, only `status: \"active\"`).\n- Use covered queries - projection limited to indexed fields - to skip fetching documents entirely.\n- Cap the index count: every index taxes every write. If a collection carries more than 5-8 indexes, audit for unused ones with `$indexStats`.\n\n### Step 4: Build pipelines that shrink early\n\nFilter early so indexes apply and less data flows downstream:\n\n```js\ndb.orders.aggregate([\n  { $match: { status: \"shipped\", createdAt: { $gte: start } } },\n  { $group: { _id: \"$customerId\", total: { $sum: \"$amount\" }, n: { $sum: 1 } } },\n  { $sort: { total: -1 } },\n  { $limit: 100 }\n])\n```\n\n- Place `$match` and `$project` as early as possible; only a leading `$match` can use indexes.\n- `$lookup` is a join - index the foreign field or the lookup degenerates to a per-document collection scan.\n- Use `$facet` to compute multiple aggregations in one pass over the data.\n- Stages have memory limits; pass `{ allowDiskUse: true }` for large groupings and sorts, and treat needing it on a hot path as a signal to pre-aggregate.\n\n### Step 5: React to changes with change streams\n\n```js\nconst stream = db.collection(\"orders\").watch([\n  { $match: { operationType: \"insert\" } }\n])\nfor await (const change of stream) { handle(change.fullDocument) }\n```\n\nPersist the resume token and resume from it after failures, or events are silently lost. Change streams require a replica set.\n\n### Step 6: Set the operational posture\n\n- Run a replica set for durability; use write concern `w: \"majority\"` for anything you cannot afford to lose on failover.\n- Choose read concern to match consistency needs; defaults favor speed over read-your-own-writes.\n- Shard on a high-cardinality key that distributes writes evenly. Never shard on a monotonically increasing key (timestamps, ObjectId) - all inserts land on one shard. Use a hashed or compound key instead.\n- Enable the database profiler (or slow-query log) with a threshold around 100ms and review it routinely.\n- Use multi-document transactions only when truly needed; single-document operations are already atomic, and a schema that embeds what changes together rarely needs transactions at all.\n\n## Worked artifact: schema pair, bad vs good\n\nThe domain: an e-commerce store with users, orders, and order events (status changes, notifications - unbounded over time).\n\nBad - relational normalization ported into Mongo, plus an unbounded embed:\n\n```js\n\u002F\u002F users:   { _id, name, email }\n\u002F\u002F orders:  { _id, userId, status,\n\u002F\u002F            itemIds: [ObjectId, ...],          \u002F\u002F items referenced -> N+1 reads\n\u002F\u002F            events: [{ ts, type, note }, ...]  \u002F\u002F UNBOUNDED array\n\u002F\u002F          }\n\u002F\u002F items:   { _id, sku, name, price }\n```\n\nRendering one order page costs 1 read for the order, N reads for the items, and the events array grows forever - busy orders churn toward the 16MB cap, every event push rewrites a growing document, and the `events` field bloats every index that includes it.\n\nGood - embed the bounded, reference the unbounded, subset the recent:\n\n```js\n\u002F\u002F orders: {\n\u002F\u002F   _id, userId, status, createdAt,\n\u002F\u002F   items: [                       \u002F\u002F EMBEDDED: bounded (5-50), read together,\n\u002F\u002F     { sku, name, price, qty }    \u002F\u002F price snapshotted at purchase time\n\u002F\u002F   ],\n\u002F\u002F   recentEvents: [                \u002F\u002F SUBSET: latest 10 only, capped with\n\u002F\u002F     { ts, type }                 \u002F\u002F $push + $slice on every insert\n\u002F\u002F   ]\n\u002F\u002F }\n\u002F\u002F order_events: {                  \u002F\u002F REFERENCED: unbounded full history\n\u002F\u002F   _id, orderId, ts, type, note   \u002F\u002F index: { orderId: 1, ts: -1 }\n\u002F\u002F }\n\u002F\u002F users: { _id, name, email }      \u002F\u002F shared by many orders -> referenced\n```\n\nOne read renders the order page (items and recent activity embedded); the full audit trail lives in `order_events`, indexed for the rare \"show all history\" query; documents stay small and stable-sized. Items embed a price snapshot deliberately - the order must show what was paid, not the current catalog price.\n\n## Deliverable\n\nProduce a schema and query design document containing: each relationship with its embed\u002Freference\u002Fsubset\u002Fbucket ruling and the rule that decided it, the collection sketches with representative documents, the index list with the query each serves and its ESR ordering, explain-plan verification notes for the hot paths, and the operational settings (write concern, shard key if sharded, profiler threshold).\n\n## Do NOT\n\n- Do not normalize by habit; every referenced relationship is a join the application pays for on each read.\n- Do not embed unbounded arrays; use the subset or bucket pattern before growth forces an emergency migration.\n- Do not order compound index fields by intuition; violate ESR and the index serves the filter but not the sort, forcing in-memory sorts.\n- Do not ship a query whose explain plan shows COLLSCAN on a hot path, or whose docs-examined dwarfs docs-returned.\n- Do not shard on a monotonically increasing key; a single hot shard absorbs all writes.\n- Do not reach for transactions to patch a schema that split data which changes together - restructure instead.\n\n## Quality bar\n\nThe design ships only when: every relationship's embed\u002Freference decision cites cardinality and access pattern, not preference; no document can grow without bound under any workload; every hot query shows IXSCAN with docs-examined near docs-returned in `explain(\"executionStats\")`; leading `$match` stages hit indexes; and the write-concern and shard-key choices are stated with their failure trade-offs.\n","# MongoDB Expert\n\nModel data, index it, and query it the MongoDB way: around access patterns, not normalization. The costly mistake this skill prevents is a relationally-normalized schema ported into Mongo - a design that forces application-side joins on every read and, in the opposite failure, unbounded embedded arrays that grow until documents hit the 16MB limit and writes start failing in production.\n\n## Operating procedure\n\nSchema first, indexes second, pipelines third - indexes serve queries, and queries are determined by the schema, so working backwards wastes every downstream decision.\n\n### Step 1: Gather inputs\n\n1. The top read and write patterns, ranked by frequency: which entities are fetched together, filtered by what, sorted by what.\n2. Cardinality and growth of every one-to-many relationship: bounded (\"an order has 5-50 line items\") or unbounded (\"a user accrues events forever\"). Label estimates as guesses.\n3. Read\u002Fwrite ratio per collection and expected document counts.\n4. Deployment shape: replica set or sharded cluster, and durability requirements.\n\n### Step 2: Decide embed vs reference per relationship\n\nApply these rules in order; the first that fires decides.\n\n1. Accessed together and the child side is bounded (a known, modest maximum) → embed. One read serves the whole query.\n2. Child is unbounded, large, or shared by multiple parents → reference. Unbounded arrays are the canonical anti-pattern: array growth relocates documents, bloats indexes, and marches toward the 16MB document cap.\n3. Need the most recent few children with the parent, but the full set is unbounded → subset pattern: embed the latest N (say 10) and keep the full history in a referenced collection.\n4. High-volume time-ordered children (events, readings) → bucket pattern: one document per parent per time window (for example, per hour) holding an array capped by the window.\n\nBudget documents well under 16MB - treat a typical document above a few hundred KB as a design smell to justify, not a limit to approach.\n\n### Step 3: Index for the actual queries\n\nIndexes are the single biggest performance lever.\n\n- Follow the ESR rule for compound indexes: Equality fields first, then Sort fields, then Range fields. A query filtering on customerId and sorting by createdAt is fully served by `{ customerId: 1, createdAt: -1 }`.\n- Verify with `explain(\"executionStats\")`: require IXSCAN, never COLLSCAN, on any hot path; check that `totalDocsExamined` is close to `nReturned` - a 100:1 ratio means the index is not selective for that query.\n- Use partial indexes to index only the documents a query can match (for example, only `status: \"active\"`).\n- Use covered queries - projection limited to indexed fields - to skip fetching documents entirely.\n- Cap the index count: every index taxes every write. If a collection carries more than 5-8 indexes, audit for unused ones with `$indexStats`.\n\n### Step 4: Build pipelines that shrink early\n\nFilter early so indexes apply and less data flows downstream:\n\n```js\ndb.orders.aggregate([\n  { $match: { status: \"shipped\", createdAt: { $gte: start } } },\n  { $group: { _id: \"$customerId\", total: { $sum: \"$amount\" }, n: { $sum: 1 } } },\n  { $sort: { total: -1 } },\n  { $limit: 100 }\n])\n```\n\n- Place `$match` and `$project` as early as possible; only a leading `$match` can use indexes.\n- `$lookup` is a join - index the foreign field or the lookup degenerates to a per-document collection scan.\n- Use `$facet` to compute multiple aggregations in one pass over the data.\n- Stages have memory limits; pass `{ allowDiskUse: true }` for large groupings and sorts, and treat needing it on a hot path as a signal to pre-aggregate.\n\n### Step 5: React to changes with change streams\n\n```js\nconst stream = db.collection(\"orders\").watch([\n  { $match: { operationType: \"insert\" } }\n])\nfor await (const change of stream) { handle(change.fullDocument) }\n```\n\nPersist the resume token and resume from it after failures, or events are silently lost. Change streams require a replica set.\n\n### Step 6: Set the operational posture\n\n- Run a replica set for durability; use write concern `w: \"majority\"` for anything you cannot afford to lose on failover.\n- Choose read concern to match consistency needs; defaults favor speed over read-your-own-writes.\n- Shard on a high-cardinality key that distributes writes evenly. Never shard on a monotonically increasing key (timestamps, ObjectId) - all inserts land on one shard. Use a hashed or compound key instead.\n- Enable the database profiler (or slow-query log) with a threshold around 100ms and review it routinely.\n- Use multi-document transactions only when truly needed; single-document operations are already atomic, and a schema that embeds what changes together rarely needs transactions at all.\n\n## Worked artifact: schema pair, bad vs good\n\nThe domain: an e-commerce store with users, orders, and order events (status changes, notifications - unbounded over time).\n\nBad - relational normalization ported into Mongo, plus an unbounded embed:\n\n```js\n\u002F\u002F users:   { _id, name, email }\n\u002F\u002F orders:  { _id, userId, status,\n\u002F\u002F            itemIds: [ObjectId, ...],          \u002F\u002F items referenced -> N+1 reads\n\u002F\u002F            events: [{ ts, type, note }, ...]  \u002F\u002F UNBOUNDED array\n\u002F\u002F          }\n\u002F\u002F items:   { _id, sku, name, price }\n```\n\nRendering one order page costs 1 read for the order, N reads for the items, and the events array grows forever - busy orders churn toward the 16MB cap, every event push rewrites a growing document, and the `events` field bloats every index that includes it.\n\nGood - embed the bounded, reference the unbounded, subset the recent:\n\n```js\n\u002F\u002F orders: {\n\u002F\u002F   _id, userId, status, createdAt,\n\u002F\u002F   items: [                       \u002F\u002F EMBEDDED: bounded (5-50), read together,\n\u002F\u002F     { sku, name, price, qty }    \u002F\u002F price snapshotted at purchase time\n\u002F\u002F   ],\n\u002F\u002F   recentEvents: [                \u002F\u002F SUBSET: latest 10 only, capped with\n\u002F\u002F     { ts, type }                 \u002F\u002F $push + $slice on every insert\n\u002F\u002F   ]\n\u002F\u002F }\n\u002F\u002F order_events: {                  \u002F\u002F REFERENCED: unbounded full history\n\u002F\u002F   _id, orderId, ts, type, note   \u002F\u002F index: { orderId: 1, ts: -1 }\n\u002F\u002F }\n\u002F\u002F users: { _id, name, email }      \u002F\u002F shared by many orders -> referenced\n```\n\nOne read renders the order page (items and recent activity embedded); the full audit trail lives in `order_events`, indexed for the rare \"show all history\" query; documents stay small and stable-sized. Items embed a price snapshot deliberately - the order must show what was paid, not the current catalog price.\n\n## Deliverable\n\nProduce a schema and query design document containing: each relationship with its embed\u002Freference\u002Fsubset\u002Fbucket ruling and the rule that decided it, the collection sketches with representative documents, the index list with the query each serves and its ESR ordering, explain-plan verification notes for the hot paths, and the operational settings (write concern, shard key if sharded, profiler threshold).\n\n## Do NOT\n\n- Do not normalize by habit; every referenced relationship is a join the application pays for on each read.\n- Do not embed unbounded arrays; use the subset or bucket pattern before growth forces an emergency migration.\n- Do not order compound index fields by intuition; violate ESR and the index serves the filter but not the sort, forcing in-memory sorts.\n- Do not ship a query whose explain plan shows COLLSCAN on a hot path, or whose docs-examined dwarfs docs-returned.\n- Do not shard on a monotonically increasing key; a single hot shard absorbs all writes.\n- Do not reach for transactions to patch a schema that split data which changes together - restructure instead.\n\n## Quality bar\n\nThe design ships only when: every relationship's embed\u002Freference decision cites cardinality and access pattern, not preference; no document can grow without bound under any workload; every hot query shows IXSCAN with docs-examined near docs-returned in `explain(\"executionStats\")`; leading `$match` stages hit indexes; and the write-concern and shard-key choices are stated with their failure trade-offs.\n",{"name":5,"metadata":24,"description":7},{"title":25},"MongoDB Expert","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Fmongodb-expert",3,"https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills","https:\u002F\u002Fskillme.dev","https:\u002F\u002Fgithub.com\u002FSkillMedev","MCP-native catalog of Claude Agent Skills. Browse, recommend, install, and auto-apply skills in chat. Open source, every skill free and clonable on GitHub.","2026-10-14 03:19:31",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add SkillMedev\u002Fskills --skill mongodb-expert",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill mongodb-expert",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill mongodb-expert","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fmongodb-expert\u002FSKILL.md",true,[],[50,60,67,74,81,88],{"skillNo":51,"name":52,"nameZh":53,"description":54,"descriptionZh":55,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":56,"categories":57,"keywords":58,"publishedAt":59},"01M75271B256DF3FX2VG5VRYEE","zone-2-cardio-plan","有氧运动计划","Use when someone asks to build a steady-state cardio plan, train an aerobic base or Zone 2, structure easy or endurance weekly cardio, train by heart-rate zones, or improve resting heart rate, VO2, or endurance. Builds a heart-rate-zone aerobic training block with session structure, modality choice, and progression. General fitness guidance, not medical advice. Do NOT use to design a strength or lifting program (use Strength Training Plan), high-intensity interval conditioning, HIIT, or circuits (use Conditioning & HIIT Program), or a mobility\u002Fflexibility routine (use Mobility Routine).","当有人要求制定稳态有氧训练计划、进行有氧基础训练或达到第二区间、安排轻松或耐力型的每周有氧训练、按心率区间训练，或提高静息心率、最大摄氧量或耐力时，可以使用此方案。该方案构建了一个包含训练计划结构、训练方式选择和进度安排的心率区间有氧训练模块。本方案仅提供一般健身指导，不构成医疗建议。请勿用于设计力量或举重训练计划（请使用力量训练计划）、高强度间歇训练 (HIIT) 或循环训练（请使用体能训练和 HIIT 计划），或灵活性\u002F柔韧性训练（请使用灵活性训练计划）。","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fzone-2-cardio-plan\u002FSKILL.md",[],[],"2026-11-11 18:27:18",{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":59},"01M7526VP1QBBKYBE17S1WR86Y","youtube-script-writer","Writes retention-engineered long-form YouTube scripts on a hook\u002Fbody\u002Fpayoff architecture - a first-30-seconds hook that survives the retention cliff, a beat-sheet body with mini-hooks and bridges, timed pattern interrupts, and a payoff that over-delivers - with B-roll and editing cues marked inline. Use when someone says \"script my next video\", \"my retention graph dies at the start\", \"tighten this draft\", or \"outline a video on X\". Do NOT use for the 3-second opener of TikTok, Reels, or Shorts - use video-hook-writer instead; do NOT use for spoken voiceover synced to on-screen tutorial actions - use narration-script instead; do NOT use for a sales demo built on a buyer's discovery notes - use demo-script instead; do NOT use to design the thumbnail and title - use thumbnail-concept instead.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube-script-writer\u002FSKILL.md",[],[],{"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":59},"01M7526P2T0WKMHDXS4Q58237T","win-back-campaign","Designs segmented win-back email sequences for dormant users - dormancy tiers, a three-beat sequence with a single proportional incentive, and a suppression rule - and measures success by re-activation, not opens. Use when someone says \"our users went quiet\", \"design a win-back campaign\", \"how do I re-engage lapsed customers\", \"should we email people who haven't logged in for months\", or lifecycle messaging has stopped landing with a lapsed segment. Do NOT use for recovering an unfinished checkout - use abandoned-cart-sequence instead. Do NOT use for diagnosing and fixing why active customers cancel - use churn-reduction instead. Do NOT use for building always-on onboarding or nurture flows - use email-drip-builder instead.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwin-back-campaign\u002FSKILL.md",[],[],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":59},"01M7526HF2RCDJ50P93WRZRHVV","wikipedia-style","Writes neutral, verifiable, encyclopedic prose following Wikipedia's core content policies and manual of style - NPOV, inline citations, notability-backed claims, and a strict ban on promotional language. Use when someone asks \"write this like a Wikipedia article\", \"draft a Wikipedia page for this company or person\", \"make this neutral and encyclopedic\", or \"why does my article draft keep getting rejected\". Do NOT use for persuasive or opinion writing - use op-ed-writer instead; for thesis-driven academic papers, use academic-essay; for verifying claims in existing text, use fact-checker.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwikipedia-style\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":59},"01M7526D43CTGRKGKNQ2GB0KVX","whitepapers","Structures and writes authoritative B2B whitepapers - a standalone executive summary, a data-sized problem statement, methodology, evidence-driven findings, recommendations, and a soft call to action - flagging every claim that needs a real citation. Use when a marketer asks \"write a whitepaper on this topic\", \"turn our research into a lead-gen asset\", \"make this credible enough for executives\", or a draft reads like a product pitch instead of analysis. Do NOT use for customer-story-driven proof - use case-study-builder instead; for policy audiences, use policy-brief.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwhitepapers\u002FSKILL.md",[],[],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":59},"01M75268423Y3K50SY5WC2NX2G","white-space-analysis","Finds unmet market gaps by ranking jobs-to-be-done on importance versus satisfaction, overlaying them against current solutions and workarounds, and validating that each gap is real, winnable, and worth winning. Use when someone asks \"where are the gaps in this market\", \"what's underserved here\", \"where should we play next\", or is hunting for product, feature, or market-entry opportunities. Do NOT use for profiling competitors and building battle cards - use competitive-intelligence instead; for putting a dollar figure on an identified opportunity - use market-sizing instead; for extracting jobs-to-be-done from raw customer interviews - use jtbd-extractor instead.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwhite-space-analysis\u002FSKILL.md",[],[]]