[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M751N07S5S813VMS29BQXJVD":3,"skill-same:01M751N07S5S813VMS29BQXJVD":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},"01M751N07S5S813VMS29BQXJVD","rust-patterns",null,"Writes and reviews idiomatic Rust - ownership and borrowing decision rules for API signatures, lifetime avoidance strategies, thiserror vs anyhow error design, iterator-first style, and when Rc\u002FRefCell\u002FArc\u002FMutex are actually justified - with good\u002Fbad code pairs. Use when someone asks \"why won't this borrow check\", \"should this take &str or String\", \"thiserror or anyhow\", \"how do I share state between threads in Rust\", or their code is a wall of clone() calls. Do NOT use for cross-language migration planning - use language-version-migrator instead - and do NOT use for generic API endpoint design - use api-design instead.","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\u002Frust-patterns\u002FSKILL.md",[],[],"2026-11-11 18:21:06",false,"---\nname: rust-patterns\ndescription: Writes and reviews idiomatic Rust - ownership and borrowing decision rules for API signatures, lifetime avoidance strategies, thiserror vs anyhow error design, iterator-first style, and when Rc\u002FRefCell\u002FArc\u002FMutex are actually justified - with good\u002Fbad code pairs. Use when someone asks \"why won't this borrow check\", \"should this take &str or String\", \"thiserror or anyhow\", \"how do I share state between threads in Rust\", or their code is a wall of clone() calls. Do NOT use for cross-language migration planning - use language-version-migrator instead - and do NOT use for generic API endpoint design - use api-design instead.\nmetadata:\n  title: \"Rust Patterns\"\n---\n\n# Rust Patterns\n\nThe borrow checker is a design-feedback tool: when it fights you, the ownership story of the code is unclear, and the fix is almost always restructuring, not sprinkling `clone()` until it compiles. The costly mistake this skill prevents is exactly that clone-and-`unwrap()` dialect - code that compiles, ships, then panics in production or silently copies megabytes per request.\n\n## Operating procedure\n\n### Step 1: Gather inputs\n\n1. Binary or library? Libraries need typed errors and conservative signatures; binaries can be looser.\n2. Threading\u002Fasync story: single-threaded, threaded, or async (which runtime - assume Tokio unless told otherwise).\n3. Performance sensitivity: hot path or glue code. Label guesses as guesses; don't optimize glue.\n4. Existing conventions (error crate in use, MSRV constraints stated by the user).\n\n### Step 2: Decide ownership per signature - the four-question rule\n\nFor every function parameter, in order:\n\n1. Only reads? Take `&T` - and prefer the borrowed view type: `&str` over `&String`, `&[T]` over `&Vec\u003CT>`, `&Path` over `&PathBuf`. This makes the API maximally callable.\n2. Mutates in place? Take `&mut T`.\n3. Stores or consumes the value (moves it into a struct, sends it to a channel, returns it)? Take `T` by value - taking `&T` and cloning inside hides the cost from the caller; taking `T` lets callers who are done with the value move it for free.\n4. Sometimes borrows, sometimes owns? `impl Into\u003CString>` \u002F `Cow\u003C'_, str>` for ergonomic APIs - but only at public boundaries; internally, pick one.\n\nReturn owned values from constructors. Default to borrowing everywhere else. If a signature needs a lifetime annotation you can't explain in one sentence, restructure instead: most lifetimes should stay elided.\n\n### Step 3: Choose the sharing tier - escalate only on proof\n\nWork down this ladder and stop at the first rung that works; each step adds runtime cost and API noise.\n\n1. Plain ownership + borrows (the default, ~95% of code).\n2. `Rc\u003CT>` - single-threaded shared ownership (e.g. a graph node referenced by several parents).\n3. `Rc\u003CRefCell\u003CT>>` - add interior mutability; runtime borrow panics replace compile errors, so keep borrow scopes tiny.\n4. `Arc\u003CT>` \u002F `Arc\u003CMutex\u003CT>>` (or `RwLock`) - cross-thread. In async code, never hold a `std::sync::Mutex` guard across an `.await`; use the runtime's mutex or restructure so the guard drops first.\n\nPrefer owning data in structs over storing references with lifetimes - a struct with a lifetime parameter infects every type that contains it. Self-referential structs are a design smell: use indices into a `Vec`, or an arena, not `Pin` gymnastics.\n\n### Step 4: Design errors by audience\n\n- Library: `thiserror` - a typed enum, `#[error(...)]` messages, `#[from]` for source errors. Callers must be able to match on variants.\n- Application: `anyhow` - `Result\u003CT, anyhow::Error>` with `.context(\"reading config\")` at each layer, so failures carry a breadcrumb trail.\n- `?` for all recoverable errors; `panic!`\u002F`expect` only for invariant violations that indicate a bug, and `expect(\"why this cannot fail\")` with a reason, never bare `unwrap()` on production paths.\n\n```rust\nuse thiserror::Error;\n\n#[derive(Error, Debug)]\nenum AppError {\n    #[error(\"not found: {0}\")]\n    NotFound(String),\n    #[error(transparent)]\n    Io(#[from] std::io::Error),\n}\n\nfn load(path: &str) -> Result\u003CString, AppError> {\n    Ok(std::fs::read_to_string(path)?)\n}\n```\n\n### Step 5: Apply the idiom checklist\n\n- Iterators and combinators (`map`, `filter`, `collect`) over index loops - they eliminate bounds-check noise and off-by-ones.\n- `Option`\u002F`Result` combinators (`map`, `and_then`, `ok_or`, `unwrap_or_else`) over nested `match`; but a `match` is still clearer than a four-combinator chain.\n- Newtypes for domain values (`struct UserId(u64)`) so the compiler catches transposed arguments; implement `From` for conversions; derive `Debug, Clone, PartialEq` where sensible.\n- Make illegal states unrepresentable: an enum with `Connected(Session)` \u002F `Disconnected` beats a struct with `is_connected: bool` and a nullable session.\n- Generics for hot-path polymorphism (monomorphized, inlined); `dyn Trait` for heterogeneous collections and to keep compile times and binary size down at cold boundaries.\n\n### Step 6: Performance and hygiene passes\n\n- Grep for `clone()`: each one is either justified (write a word of why), replaced by a borrow, or replaced by a move.\n- `Vec::with_capacity` when size is known; avoid collecting intermediates you immediately iterate again.\n- Profile before optimizing anything beyond these defaults.\n- `unsafe` stays tiny, wrapped in a safe API, with a `\u002F\u002F SAFETY:` comment stating the invariant.\n- `cargo clippy -- -D warnings` and `cargo fmt --check` run in CI, not just locally.\n\n## Worked artifact: signature and sharing, bad\u002Fgood\n\nBad - fights the checker, hides costs, panics:\n\n```rust\nfn process(names: Vec\u003CString>, cfg: &Config) -> Vec\u003CString> {\n    let mut out = Vec::new();\n    for i in 0..names.len() {\n        let n = names[i].clone();                  \u002F\u002F clone to dodge a move error\n        out.push(format!(\"{}-{}\", cfg.prefix.clone(), n));\n    }\n    out\n}\nlet shared = Arc::new(Mutex::new(state));          \u002F\u002F single-threaded code!\nlet v = map.get(\"k\").unwrap().clone();             \u002F\u002F panic + copy\n```\n\nGood:\n\n```rust\nfn process\u003C'a>(names: impl Iterator\u003CItem = &'a str>, prefix: &str) -> Vec\u003CString> {\n    names.map(|n| format!(\"{prefix}-{n}\")).collect()\n}\nlet shared = Rc::new(RefCell::new(state));          \u002F\u002F right tier for one thread\nlet v = map.get(\"k\").ok_or(AppError::NotFound(\"k\".into()))?;\n```\n\nThe good version borrows what it reads, allocates only the output it must own, uses the cheapest sharing tier, and turns the panic into a typed error.\n\n## Deliverable\n\nProduce code (or a review) where every signature is justified by the four-question rule, sharing primitives are at the lowest sufficient tier, the error strategy matches the audience (thiserror for libraries, anyhow for apps), and every remaining `clone()`, `expect`, and `unsafe` block carries its one-line justification.\n\n## Do NOT\n\n- Do not `clone()` to silence a borrow error - restructure ownership; the checker is pointing at a real design ambiguity.\n- Do not take `&String`\u002F`&Vec\u003CT>`\u002F`&PathBuf` in signatures; the borrowed view types cost nothing and accept more callers.\n- Do not reach for `Arc\u003CMutex\u003CT>>` in single-threaded code, or `Rc\u003CRefCell\u003CT>>` as a default - they are escalations, not conveniences.\n- Do not hold a sync mutex guard across `.await` - it deadlocks or blocks the executor.\n- Do not `unwrap()` on production paths; `?` or `expect(\"reason\")`.\n- Do not store references in structs when owning is feasible; lifetime parameters propagate to every containing type.\n- Do not block the async executor with sync I\u002FO; use the runtime's `spawn_blocking` for it.\n\n## Quality bar\n\n- `cargo clippy -- -D warnings` clean; `cargo fmt` clean.\n- No bare `unwrap()` outside tests; every `expect` states why it can't fail.\n- Every `clone()` in the diff is annotated or eliminated.\n- Public API takes borrowed view types and returns owned values.\n- `unsafe` blocks each have a `\u002F\u002F SAFETY:` invariant comment.\n\n## Escalation\n\nFor migrating a codebase between language versions or from another language, use language-version-migrator. Async architecture questions beyond Rust idiom (queues, services) route to microservices or kafka-pipelines; API surface design to api-design.\n","# Rust Patterns\n\nThe borrow checker is a design-feedback tool: when it fights you, the ownership story of the code is unclear, and the fix is almost always restructuring, not sprinkling `clone()` until it compiles. The costly mistake this skill prevents is exactly that clone-and-`unwrap()` dialect - code that compiles, ships, then panics in production or silently copies megabytes per request.\n\n## Operating procedure\n\n### Step 1: Gather inputs\n\n1. Binary or library? Libraries need typed errors and conservative signatures; binaries can be looser.\n2. Threading\u002Fasync story: single-threaded, threaded, or async (which runtime - assume Tokio unless told otherwise).\n3. Performance sensitivity: hot path or glue code. Label guesses as guesses; don't optimize glue.\n4. Existing conventions (error crate in use, MSRV constraints stated by the user).\n\n### Step 2: Decide ownership per signature - the four-question rule\n\nFor every function parameter, in order:\n\n1. Only reads? Take `&T` - and prefer the borrowed view type: `&str` over `&String`, `&[T]` over `&Vec\u003CT>`, `&Path` over `&PathBuf`. This makes the API maximally callable.\n2. Mutates in place? Take `&mut T`.\n3. Stores or consumes the value (moves it into a struct, sends it to a channel, returns it)? Take `T` by value - taking `&T` and cloning inside hides the cost from the caller; taking `T` lets callers who are done with the value move it for free.\n4. Sometimes borrows, sometimes owns? `impl Into\u003CString>` \u002F `Cow\u003C'_, str>` for ergonomic APIs - but only at public boundaries; internally, pick one.\n\nReturn owned values from constructors. Default to borrowing everywhere else. If a signature needs a lifetime annotation you can't explain in one sentence, restructure instead: most lifetimes should stay elided.\n\n### Step 3: Choose the sharing tier - escalate only on proof\n\nWork down this ladder and stop at the first rung that works; each step adds runtime cost and API noise.\n\n1. Plain ownership + borrows (the default, ~95% of code).\n2. `Rc\u003CT>` - single-threaded shared ownership (e.g. a graph node referenced by several parents).\n3. `Rc\u003CRefCell\u003CT>>` - add interior mutability; runtime borrow panics replace compile errors, so keep borrow scopes tiny.\n4. `Arc\u003CT>` \u002F `Arc\u003CMutex\u003CT>>` (or `RwLock`) - cross-thread. In async code, never hold a `std::sync::Mutex` guard across an `.await`; use the runtime's mutex or restructure so the guard drops first.\n\nPrefer owning data in structs over storing references with lifetimes - a struct with a lifetime parameter infects every type that contains it. Self-referential structs are a design smell: use indices into a `Vec`, or an arena, not `Pin` gymnastics.\n\n### Step 4: Design errors by audience\n\n- Library: `thiserror` - a typed enum, `#[error(...)]` messages, `#[from]` for source errors. Callers must be able to match on variants.\n- Application: `anyhow` - `Result\u003CT, anyhow::Error>` with `.context(\"reading config\")` at each layer, so failures carry a breadcrumb trail.\n- `?` for all recoverable errors; `panic!`\u002F`expect` only for invariant violations that indicate a bug, and `expect(\"why this cannot fail\")` with a reason, never bare `unwrap()` on production paths.\n\n```rust\nuse thiserror::Error;\n\n#[derive(Error, Debug)]\nenum AppError {\n    #[error(\"not found: {0}\")]\n    NotFound(String),\n    #[error(transparent)]\n    Io(#[from] std::io::Error),\n}\n\nfn load(path: &str) -> Result\u003CString, AppError> {\n    Ok(std::fs::read_to_string(path)?)\n}\n```\n\n### Step 5: Apply the idiom checklist\n\n- Iterators and combinators (`map`, `filter`, `collect`) over index loops - they eliminate bounds-check noise and off-by-ones.\n- `Option`\u002F`Result` combinators (`map`, `and_then`, `ok_or`, `unwrap_or_else`) over nested `match`; but a `match` is still clearer than a four-combinator chain.\n- Newtypes for domain values (`struct UserId(u64)`) so the compiler catches transposed arguments; implement `From` for conversions; derive `Debug, Clone, PartialEq` where sensible.\n- Make illegal states unrepresentable: an enum with `Connected(Session)` \u002F `Disconnected` beats a struct with `is_connected: bool` and a nullable session.\n- Generics for hot-path polymorphism (monomorphized, inlined); `dyn Trait` for heterogeneous collections and to keep compile times and binary size down at cold boundaries.\n\n### Step 6: Performance and hygiene passes\n\n- Grep for `clone()`: each one is either justified (write a word of why), replaced by a borrow, or replaced by a move.\n- `Vec::with_capacity` when size is known; avoid collecting intermediates you immediately iterate again.\n- Profile before optimizing anything beyond these defaults.\n- `unsafe` stays tiny, wrapped in a safe API, with a `\u002F\u002F SAFETY:` comment stating the invariant.\n- `cargo clippy -- -D warnings` and `cargo fmt --check` run in CI, not just locally.\n\n## Worked artifact: signature and sharing, bad\u002Fgood\n\nBad - fights the checker, hides costs, panics:\n\n```rust\nfn process(names: Vec\u003CString>, cfg: &Config) -> Vec\u003CString> {\n    let mut out = Vec::new();\n    for i in 0..names.len() {\n        let n = names[i].clone();                  \u002F\u002F clone to dodge a move error\n        out.push(format!(\"{}-{}\", cfg.prefix.clone(), n));\n    }\n    out\n}\nlet shared = Arc::new(Mutex::new(state));          \u002F\u002F single-threaded code!\nlet v = map.get(\"k\").unwrap().clone();             \u002F\u002F panic + copy\n```\n\nGood:\n\n```rust\nfn process\u003C'a>(names: impl Iterator\u003CItem = &'a str>, prefix: &str) -> Vec\u003CString> {\n    names.map(|n| format!(\"{prefix}-{n}\")).collect()\n}\nlet shared = Rc::new(RefCell::new(state));          \u002F\u002F right tier for one thread\nlet v = map.get(\"k\").ok_or(AppError::NotFound(\"k\".into()))?;\n```\n\nThe good version borrows what it reads, allocates only the output it must own, uses the cheapest sharing tier, and turns the panic into a typed error.\n\n## Deliverable\n\nProduce code (or a review) where every signature is justified by the four-question rule, sharing primitives are at the lowest sufficient tier, the error strategy matches the audience (thiserror for libraries, anyhow for apps), and every remaining `clone()`, `expect`, and `unsafe` block carries its one-line justification.\n\n## Do NOT\n\n- Do not `clone()` to silence a borrow error - restructure ownership; the checker is pointing at a real design ambiguity.\n- Do not take `&String`\u002F`&Vec\u003CT>`\u002F`&PathBuf` in signatures; the borrowed view types cost nothing and accept more callers.\n- Do not reach for `Arc\u003CMutex\u003CT>>` in single-threaded code, or `Rc\u003CRefCell\u003CT>>` as a default - they are escalations, not conveniences.\n- Do not hold a sync mutex guard across `.await` - it deadlocks or blocks the executor.\n- Do not `unwrap()` on production paths; `?` or `expect(\"reason\")`.\n- Do not store references in structs when owning is feasible; lifetime parameters propagate to every containing type.\n- Do not block the async executor with sync I\u002FO; use the runtime's `spawn_blocking` for it.\n\n## Quality bar\n\n- `cargo clippy -- -D warnings` clean; `cargo fmt` clean.\n- No bare `unwrap()` outside tests; every `expect` states why it can't fail.\n- Every `clone()` in the diff is annotated or eliminated.\n- Public API takes borrowed view types and returns owned values.\n- `unsafe` blocks each have a `\u002F\u002F SAFETY:` invariant comment.\n\n## Escalation\n\nFor migrating a codebase between language versions or from another language, use language-version-migrator. Async architecture questions beyond Rust idiom (queues, services) route to microservices or kafka-pipelines; API surface design to api-design.\n",{"name":5,"metadata":24,"description":7},{"title":25},"Rust Patterns","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Frust-patterns",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 rust-patterns",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill rust-patterns",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill rust-patterns","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Frust-patterns\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",[],[]]