[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7512PD2BQDQD5XZFNDNK2P9":3,"skill-same:01M7512PD2BQDQD5XZFNDNK2P9":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},"01M7512PD2BQDQD5XZFNDNK2P9","mobile-offline-sync",null,"Builds local-first mobile storage with an optimistic local store, durable mutation outbox, per-entity conflict-resolution rules, incremental pull, and idempotent background retry. Use when someone says \"the app has to work offline\", \"how do I sync Room or SQLite or Realm with the server\", \"what happens when two devices edit the same record\", or offline edits must reconcile with the server later. Do NOT use for paginating, caching, and refreshing read-heavy server lists - use pagination-and-sync-engineer instead; and do NOT build offline write support for strong-consistency operations like payments or inventory counts - disable those offline.","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\u002Fmobile-offline-sync\u002FSKILL.md",[],[],"2026-11-11 18:11:01",false,"---\nname: mobile-offline-sync\ndescription: Builds local-first mobile storage with an optimistic local store, durable mutation outbox, per-entity conflict-resolution rules, incremental pull, and idempotent background retry. Use when someone says \"the app has to work offline\", \"how do I sync Room or SQLite or Realm with the server\", \"what happens when two devices edit the same record\", or offline edits must reconcile with the server later. Do NOT use for paginating, caching, and refreshing read-heavy server lists - use pagination-and-sync-engineer instead; and do NOT build offline write support for strong-consistency operations like payments or inventory counts - disable those offline.\nmetadata:\n  title: \"Mobile Offline Sync\"\n---\n# Mobile Offline Sync\n\nMake the local store the source of truth the UI reads and writes, and treat the network as eventual replication. The hard part is never the happy path - it is reconciling divergent edits made while offline. The costly failure is an ad-hoc \"retry the request later\" queue that double-applies mutations, resurrects deleted rows, and silently destroys one user's edits with another's.\n\n## Operating procedure\n\n### Step 1: Gather inputs\n\nCollect per feature before designing:\n\n1. The entities that must work offline, and for each: single-owner or multi-writer? Whole-object edits or field-level edits?\n2. The maximum realistic offline window (a field-service app may need 7-30 days; a consumer app usually hours). This sets tombstone retention.\n3. The local store (Room, SwiftData, SQLite, Realm) and whether the server API can accept client-generated UUIDs and return per-record versions.\n4. Which operations are strong-consistency (payments, inventory decrements, seat booking) - these get disabled offline, not synced.\n5. Expected data volume per user, which decides pull batch sizes.\n\nLabel unknowns as guesses and validate them against the server team before building.\n\n### Step 2: Make the local store the UI's truth\n\nWrite to the local database synchronously and reflect it in the UI immediately (optimistic). Never block the UI on a network round-trip. Tag every row with a sync state - pending, syncing, synced, failed - so the UI can show subtle pending indicators and surface failures.\n\n### Step 3: Queue mutations as intents, not raw requests\n\nRecord each offline change in a durable outbox table: operation (create\u002Fupdate\u002Fdelete), entity id, changed fields, client timestamp, the base version the client last saw, and a client-generated UUID. Send the outbox in order, batched (up to about 50 mutations per request keeps payloads small and retries cheap). The server dedupes on the UUID so a retried request never double-applies.\n\n### Step 4: Choose a conflict-resolution rule per entity and write it down\n\nThere is no universal default. Apply this decision table per entity, top to bottom:\n\n| Question | If yes | If no |\n|---|---|---|\n| Does the server enforce a business invariant on this entity (state machines, balances, assignments)? | Server-authoritative: client proposes, server decides, client rebases local state on the server's answer | Next question |\n| Do multiple writers concurrently edit the same record in normal use? | Next question | Last-write-wins on server-assigned version or hybrid logical clock - never raw device clocks |\n| Do concurrent edits usually touch different fields? | Field-level merge: per-field versions, merge disjoint field sets, LWW per field on true collisions | Next question |\n| Is it collaborative text or a shared set\u002Flist needing convergence without a coordinator? | CRDT (text CRDT for documents, OR-Set for collections) - accept the metadata and complexity cost | Server-authoritative with an explicit user-facing conflict prompt |\n\nRules of thumb: server-authoritative is the simplest correct default when the server can decide. LWW is acceptable only for single-owner, whole-object data where losing an overwritten edit is tolerable. CRDTs are the last resort, not the default - they buy convergence at real complexity cost.\n\n### Step 5: Pull, detect, reconcile\n\nPull incrementally with a server cursor or updated_since watermark - never full table scans. Detect a conflict by comparing the base version the client last saw against the server's current version. Apply the entity's resolution rule, write the reconciled result back locally, and clear the pending flag. Keep tombstones for deletes - retained at least as long as the maximum offline window from Step 1 - so a deletion is not resurrected by a stale upsert.\n\n### Step 6: Retry as if the network is hostile\n\nRetry with exponential backoff plus jitter: 2s base, doubling, capped at 10 minutes, with plus-or-minus 50 percent jitter; cap at roughly 8 attempts, then park the mutation as failed and surface it to the user. Schedule background sync with WorkManager (Android) or BGTaskScheduler (iOS) under OS constraints - the OS decides when it runs. Make every sync operation idempotent so a process kill mid-flight is safe to repeat.\n\n## Worked artifact: conflict-resolution decision for a field-service app\n\n| Entity | Writers | Edit shape | Rule chosen | Why |\n|---|---|---|---|---|\n| Job status (assigned -> en route -> done) | Technician + dispatcher | State transition | Server-authoritative | Server enforces the legal state machine; client rebases if its transition was stale |\n| Technician visit notes | One technician | Append text | LWW on server version | Single owner; concurrent edits effectively impossible |\n| Customer record (phone, address, gate code) | Technician + office staff | Different fields | Field-level merge | Office edits billing fields while tech edits access notes; merging disjoint fields loses nothing |\n| Shared parts checklist on a job | Multiple technicians | Add\u002Fremove items | CRDT (OR-Set) | Concurrent adds\u002Fremoves of the same list must converge without losing anyone's items |\n| Invoice payment capture | Anyone | Money movement | Disabled offline | Strong consistency; show \"reconnect to take payment\" |\n\nThe artifact to keep: this table, one row per synced entity, committed alongside the schema.\n\n## Deliverable\n\nProduce an offline-sync design containing: the entity list with a written conflict rule per entity (table above), the outbox schema (operation, entity id, changed fields, base version, client UUID, client timestamp), the pull watermark strategy, the backoff\u002Fretry parameters, tombstone retention matched to the offline window, and the list of operations deliberately disabled offline.\n\n## Quality bar\n\n- The UI never waits on the network for a write; every local write is visible instantly with a sync-state tag.\n- Every mutation carries a client-generated UUID and base version; replaying the entire outbox produces the same server state every time.\n- Each synced entity has a documented conflict rule from the decision table, and no rule trusts the device clock for correctness.\n- Deletes leave tombstones retained longer than the maximum offline window; a stale upsert cannot resurrect a deleted row.\n- Killing the app mid-sync and relaunching converges to a consistent state with no duplicates and no lost edits.\n\n## Do NOT\n\n- Do NOT replay raw HTTP requests from a log - that loses ordering and idempotency. Queue intents in an outbox instead.\n- Do NOT decide conflicts by comparing raw device clocks; a skewed clock silently destroys data. Use server-assigned versions or a hybrid logical clock.\n- Do NOT default to CRDTs to avoid choosing - they are for genuine multi-writer convergence and cost metadata and complexity.\n- Do NOT pull full tables on every sync; use a cursor or watermark.\n- Do NOT hard-delete rows without a tombstone.\n- Do NOT fake offline support for strong-consistency operations (payments, inventory counts). Disable the action while offline and tell the user why.\n- Do NOT build full offline sync where the UX does not demand it - it is expensive; for read-heavy list caching and refresh, pagination-and-sync-engineer is the right tool.\n","# Mobile Offline Sync\n\nMake the local store the source of truth the UI reads and writes, and treat the network as eventual replication. The hard part is never the happy path - it is reconciling divergent edits made while offline. The costly failure is an ad-hoc \"retry the request later\" queue that double-applies mutations, resurrects deleted rows, and silently destroys one user's edits with another's.\n\n## Operating procedure\n\n### Step 1: Gather inputs\n\nCollect per feature before designing:\n\n1. The entities that must work offline, and for each: single-owner or multi-writer? Whole-object edits or field-level edits?\n2. The maximum realistic offline window (a field-service app may need 7-30 days; a consumer app usually hours). This sets tombstone retention.\n3. The local store (Room, SwiftData, SQLite, Realm) and whether the server API can accept client-generated UUIDs and return per-record versions.\n4. Which operations are strong-consistency (payments, inventory decrements, seat booking) - these get disabled offline, not synced.\n5. Expected data volume per user, which decides pull batch sizes.\n\nLabel unknowns as guesses and validate them against the server team before building.\n\n### Step 2: Make the local store the UI's truth\n\nWrite to the local database synchronously and reflect it in the UI immediately (optimistic). Never block the UI on a network round-trip. Tag every row with a sync state - pending, syncing, synced, failed - so the UI can show subtle pending indicators and surface failures.\n\n### Step 3: Queue mutations as intents, not raw requests\n\nRecord each offline change in a durable outbox table: operation (create\u002Fupdate\u002Fdelete), entity id, changed fields, client timestamp, the base version the client last saw, and a client-generated UUID. Send the outbox in order, batched (up to about 50 mutations per request keeps payloads small and retries cheap). The server dedupes on the UUID so a retried request never double-applies.\n\n### Step 4: Choose a conflict-resolution rule per entity and write it down\n\nThere is no universal default. Apply this decision table per entity, top to bottom:\n\n| Question | If yes | If no |\n|---|---|---|\n| Does the server enforce a business invariant on this entity (state machines, balances, assignments)? | Server-authoritative: client proposes, server decides, client rebases local state on the server's answer | Next question |\n| Do multiple writers concurrently edit the same record in normal use? | Next question | Last-write-wins on server-assigned version or hybrid logical clock - never raw device clocks |\n| Do concurrent edits usually touch different fields? | Field-level merge: per-field versions, merge disjoint field sets, LWW per field on true collisions | Next question |\n| Is it collaborative text or a shared set\u002Flist needing convergence without a coordinator? | CRDT (text CRDT for documents, OR-Set for collections) - accept the metadata and complexity cost | Server-authoritative with an explicit user-facing conflict prompt |\n\nRules of thumb: server-authoritative is the simplest correct default when the server can decide. LWW is acceptable only for single-owner, whole-object data where losing an overwritten edit is tolerable. CRDTs are the last resort, not the default - they buy convergence at real complexity cost.\n\n### Step 5: Pull, detect, reconcile\n\nPull incrementally with a server cursor or updated_since watermark - never full table scans. Detect a conflict by comparing the base version the client last saw against the server's current version. Apply the entity's resolution rule, write the reconciled result back locally, and clear the pending flag. Keep tombstones for deletes - retained at least as long as the maximum offline window from Step 1 - so a deletion is not resurrected by a stale upsert.\n\n### Step 6: Retry as if the network is hostile\n\nRetry with exponential backoff plus jitter: 2s base, doubling, capped at 10 minutes, with plus-or-minus 50 percent jitter; cap at roughly 8 attempts, then park the mutation as failed and surface it to the user. Schedule background sync with WorkManager (Android) or BGTaskScheduler (iOS) under OS constraints - the OS decides when it runs. Make every sync operation idempotent so a process kill mid-flight is safe to repeat.\n\n## Worked artifact: conflict-resolution decision for a field-service app\n\n| Entity | Writers | Edit shape | Rule chosen | Why |\n|---|---|---|---|---|\n| Job status (assigned -> en route -> done) | Technician + dispatcher | State transition | Server-authoritative | Server enforces the legal state machine; client rebases if its transition was stale |\n| Technician visit notes | One technician | Append text | LWW on server version | Single owner; concurrent edits effectively impossible |\n| Customer record (phone, address, gate code) | Technician + office staff | Different fields | Field-level merge | Office edits billing fields while tech edits access notes; merging disjoint fields loses nothing |\n| Shared parts checklist on a job | Multiple technicians | Add\u002Fremove items | CRDT (OR-Set) | Concurrent adds\u002Fremoves of the same list must converge without losing anyone's items |\n| Invoice payment capture | Anyone | Money movement | Disabled offline | Strong consistency; show \"reconnect to take payment\" |\n\nThe artifact to keep: this table, one row per synced entity, committed alongside the schema.\n\n## Deliverable\n\nProduce an offline-sync design containing: the entity list with a written conflict rule per entity (table above), the outbox schema (operation, entity id, changed fields, base version, client UUID, client timestamp), the pull watermark strategy, the backoff\u002Fretry parameters, tombstone retention matched to the offline window, and the list of operations deliberately disabled offline.\n\n## Quality bar\n\n- The UI never waits on the network for a write; every local write is visible instantly with a sync-state tag.\n- Every mutation carries a client-generated UUID and base version; replaying the entire outbox produces the same server state every time.\n- Each synced entity has a documented conflict rule from the decision table, and no rule trusts the device clock for correctness.\n- Deletes leave tombstones retained longer than the maximum offline window; a stale upsert cannot resurrect a deleted row.\n- Killing the app mid-sync and relaunching converges to a consistent state with no duplicates and no lost edits.\n\n## Do NOT\n\n- Do NOT replay raw HTTP requests from a log - that loses ordering and idempotency. Queue intents in an outbox instead.\n- Do NOT decide conflicts by comparing raw device clocks; a skewed clock silently destroys data. Use server-assigned versions or a hybrid logical clock.\n- Do NOT default to CRDTs to avoid choosing - they are for genuine multi-writer convergence and cost metadata and complexity.\n- Do NOT pull full tables on every sync; use a cursor or watermark.\n- Do NOT hard-delete rows without a tombstone.\n- Do NOT fake offline support for strong-consistency operations (payments, inventory counts). Disable the action while offline and tell the user why.\n- Do NOT build full offline sync where the UX does not demand it - it is expensive; for read-heavy list caching and refresh, pagination-and-sync-engineer is the right tool.\n",{"name":5,"metadata":24,"description":7},{"title":25},"Mobile Offline Sync","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Fmobile-offline-sync",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 mobile-offline-sync",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill mobile-offline-sync",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill mobile-offline-sync","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fmobile-offline-sync\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",[],[]]