[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M751AP85ZJ65DY0Q4MJHND7H":3,"skill-same:01M751AP85ZJ65DY0Q4MJHND7H":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},"01M751AP85ZJ65DY0Q4MJHND7H","partition-planner",null,"Produces a partitioning or sharding plan for an oversized table - range\u002Flist\u002Fhash strategy, partition-key choice, composite-key and pruning constraints, and a verdict on whether to partition at all. Use when one table has grown past tens of millions of rows or hundreds of GB, vacuum\u002Fautovacuum on it runs for hours, retention deletes are giant DELETEs, or you are deciding between range\u002Flist\u002Fhash partitioning or sharding a hot table. Do NOT use when the goal is choosing indexes for specific slow queries - use index-advisor 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\u002Fpartition-planner\u002FSKILL.md",[],[],"2026-11-11 18:11:01",false,"---\nname: partition-planner\ndescription: Produces a partitioning or sharding plan for an oversized table - range\u002Flist\u002Fhash strategy, partition-key choice, composite-key and pruning constraints, and a verdict on whether to partition at all. Use when one table has grown past tens of millions of rows or hundreds of GB, vacuum\u002Fautovacuum on it runs for hours, retention deletes are giant DELETEs, or you are deciding between range\u002Flist\u002Fhash partitioning or sharding a hot table. Do NOT use when the goal is choosing indexes for specific slow queries - use index-advisor instead.\nmetadata:\n  title: \"Table Partition Planner\"\n---\n# Table Partition Planner\n\nPlan how to split one too-large table into partitions (or shards) keyed to its real access and retention patterns - or prove it should stay a single indexed table.\n\n## Workflow\n\n1. **Confirm partitioning is warranted.** Get the row count and on-disk size. Below roughly 50-100M rows or a few hundred GB, a well-indexed single table usually beats a partitioned one; recommend staying single unless retention or vacuum pain forces the issue. Never partition to compensate for a missing index - that is index-advisor's job; add the index first and re-measure.\n2. **Characterize the access pattern.** Capture the hot queries' WHERE clauses, the retention\u002Fdeletion policy, and write distribution. The partition key must come from this evidence, not a guess.\n3. **Pick the strategy from that pattern.**\n   - **Range** - time-series or any naturally ordered key (e.g. `created_at` by month). Old data leaves via `DROP`\u002F`DETACH PARTITION` instead of a giant `DELETE`. Monthly granularity is the sane default for multi-year retention; drop to weekly or daily only when a single month would exceed roughly 50-100 GB.\n   - **List** - a small fixed set of discrete values (region, tenant tier).\n   - **Hash** - no natural range but you must cap any single child's size; use a fixed modulus (a power of two, commonly 8-64) to spread writes evenly, because changing the modulus later means rewriting the table.\n4. **Choose the partition key.** It must appear in the WHERE clause of hot queries (or the planner cannot prune and scans every child), align with the retention policy (drop by time), and align with the largest indexes. Reject any column that is frequently updated - moving a row across partitions on UPDATE is expensive.\n5. **Resolve the constraint and operational requirements.**\n   - In Postgres declarative partitioning, every unique constraint and primary key must include the partition key - design composite keys accordingly.\n   - Automate partition creation (pg_partman or a scheduled job) so writes never hit a missing partition; pre-create at least 3 future partitions as a buffer.\n   - Keep partition count bounded (low hundreds, not thousands) to avoid planning bloat, and size individual partitions so maintenance stays fast - roughly 10-50 GB per child is a comfortable working range.\n   - Verify foreign-key behavior against your engine version's partitioning limits.\n6. **Decide partition vs shard.** Partitioning stays on one node. Reach for sharding (Citus, Vitess, or app-level routing) only when a single node's write throughput or storage is the hard ceiling - it adds distributed-transaction and rebalancing cost. If sharding, pick a shard key with even distribution and no cross-shard joins on the hot path.\n7. **Write the plan.** State chosen strategy, key, composite-key changes, creation\u002Fautomation mechanism, retention operation, and the migration approach to convert the existing table.\n\n## Deliverable\n\nProduce a partitioning plan document containing: the verdict (partition \u002F stay single \u002F shard) with the measured row count and on-disk size backing it, the chosen strategy and partition key with the hot WHERE clauses and retention policy that justify them, the composite-key and constraint changes required, the partition-creation automation mechanism, the retention operation (which partitions get dropped and when), the migration approach for the existing table, and the expected partition count over the table's lifetime.\n\n## Quality bar\n\n- The recommendation is backed by an actual row count and size measurement, not an estimate.\n- The partition key provably appears in the hot queries' WHERE clauses and matches the retention policy.\n- \"Do not partition\" is a valid, expected outcome and must be stated plainly when the evidence supports it.\n- Every Postgres unique\u002Fprimary key in the plan includes the partition key.\n\n## Do NOT\n\n- Do not partition a table that is small or merely missing an index.\n- Do not choose a partition key absent from hot queries' WHERE clauses - it kills pruning.\n- Do not partition on a high-churn updated column - it forces cross-partition row movement.\n- Do not create thousands of partitions; planning time degrades.\n- Do not leave partition creation manual - a missing future partition rejects writes.\n- Do not jump to sharding before single-node partitioning is exhausted.\n- Do not prescribe per-query index sets here - defer that to index-advisor.\n","# Table Partition Planner\n\nPlan how to split one too-large table into partitions (or shards) keyed to its real access and retention patterns - or prove it should stay a single indexed table.\n\n## Workflow\n\n1. **Confirm partitioning is warranted.** Get the row count and on-disk size. Below roughly 50-100M rows or a few hundred GB, a well-indexed single table usually beats a partitioned one; recommend staying single unless retention or vacuum pain forces the issue. Never partition to compensate for a missing index - that is index-advisor's job; add the index first and re-measure.\n2. **Characterize the access pattern.** Capture the hot queries' WHERE clauses, the retention\u002Fdeletion policy, and write distribution. The partition key must come from this evidence, not a guess.\n3. **Pick the strategy from that pattern.**\n   - **Range** - time-series or any naturally ordered key (e.g. `created_at` by month). Old data leaves via `DROP`\u002F`DETACH PARTITION` instead of a giant `DELETE`. Monthly granularity is the sane default for multi-year retention; drop to weekly or daily only when a single month would exceed roughly 50-100 GB.\n   - **List** - a small fixed set of discrete values (region, tenant tier).\n   - **Hash** - no natural range but you must cap any single child's size; use a fixed modulus (a power of two, commonly 8-64) to spread writes evenly, because changing the modulus later means rewriting the table.\n4. **Choose the partition key.** It must appear in the WHERE clause of hot queries (or the planner cannot prune and scans every child), align with the retention policy (drop by time), and align with the largest indexes. Reject any column that is frequently updated - moving a row across partitions on UPDATE is expensive.\n5. **Resolve the constraint and operational requirements.**\n   - In Postgres declarative partitioning, every unique constraint and primary key must include the partition key - design composite keys accordingly.\n   - Automate partition creation (pg_partman or a scheduled job) so writes never hit a missing partition; pre-create at least 3 future partitions as a buffer.\n   - Keep partition count bounded (low hundreds, not thousands) to avoid planning bloat, and size individual partitions so maintenance stays fast - roughly 10-50 GB per child is a comfortable working range.\n   - Verify foreign-key behavior against your engine version's partitioning limits.\n6. **Decide partition vs shard.** Partitioning stays on one node. Reach for sharding (Citus, Vitess, or app-level routing) only when a single node's write throughput or storage is the hard ceiling - it adds distributed-transaction and rebalancing cost. If sharding, pick a shard key with even distribution and no cross-shard joins on the hot path.\n7. **Write the plan.** State chosen strategy, key, composite-key changes, creation\u002Fautomation mechanism, retention operation, and the migration approach to convert the existing table.\n\n## Deliverable\n\nProduce a partitioning plan document containing: the verdict (partition \u002F stay single \u002F shard) with the measured row count and on-disk size backing it, the chosen strategy and partition key with the hot WHERE clauses and retention policy that justify them, the composite-key and constraint changes required, the partition-creation automation mechanism, the retention operation (which partitions get dropped and when), the migration approach for the existing table, and the expected partition count over the table's lifetime.\n\n## Quality bar\n\n- The recommendation is backed by an actual row count and size measurement, not an estimate.\n- The partition key provably appears in the hot queries' WHERE clauses and matches the retention policy.\n- \"Do not partition\" is a valid, expected outcome and must be stated plainly when the evidence supports it.\n- Every Postgres unique\u002Fprimary key in the plan includes the partition key.\n\n## Do NOT\n\n- Do not partition a table that is small or merely missing an index.\n- Do not choose a partition key absent from hot queries' WHERE clauses - it kills pruning.\n- Do not partition on a high-churn updated column - it forces cross-partition row movement.\n- Do not create thousands of partitions; planning time degrades.\n- Do not leave partition creation manual - a missing future partition rejects writes.\n- Do not jump to sharding before single-node partitioning is exhausted.\n- Do not prescribe per-query index sets here - defer that to index-advisor.\n",{"name":5,"metadata":24,"description":7},{"title":25},"Table Partition Planner","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Fpartition-planner",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 partition-planner",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill partition-planner",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill partition-planner","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fpartition-planner\u002FSKILL.md",true,[],[50,58,65,72,79,86],{"skillNo":51,"name":52,"nameZh":6,"description":53,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":54,"categories":55,"keywords":56,"publishedAt":57},"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).","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fzone-2-cardio-plan\u002FSKILL.md",[],[],"2026-11-11 18:27:18",{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":57},"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":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":57},"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":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":57},"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":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":57},"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":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":57},"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",[],[]]