[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7515SQ2G3M6CD4GCV8VPDX3":3,"skill-same:01M7515SQ2G3M6CD4GCV8VPDX3":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},"01M7515SQ2G3M6CD4GCV8VPDX3","nextjs-app-router",null,"Builds and reviews Next.js App Router code - server\u002Fclient component boundaries, data fetching, caching and revalidation choices, streaming with Suspense, and Server Action mutations - and delivers routes where every dynamic-vs-cached decision is explicit. Use when someone asks \"should this be a client component\", \"why is my data stale\", \"where do I put use client\", \"how do I stream this page\", or \"how do server actions work\". Do NOT use for Vercel-specific runtime and cost tuning of an already-built app - use next-on-vercel-perf instead; for edge middleware and ISR deployment topology - use vercel-edge-and-isr instead; for framework-agnostic Core Web Vitals work - use web-performance instead; for designing an application-wide cache layer beyond the framework - use caching-strategy 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\u002Fnextjs-app-router\u002FSKILL.md",[],[],"2026-11-11 18:11:01",false,"---\nname: nextjs-app-router\ndescription: Builds and reviews Next.js App Router code - server\u002Fclient component boundaries, data fetching, caching and revalidation choices, streaming with Suspense, and Server Action mutations - and delivers routes where every dynamic-vs-cached decision is explicit. Use when someone asks \"should this be a client component\", \"why is my data stale\", \"where do I put use client\", \"how do I stream this page\", or \"how do server actions work\". Do NOT use for Vercel-specific runtime and cost tuning of an already-built app - use next-on-vercel-perf instead; for edge middleware and ISR deployment topology - use vercel-edge-and-isr instead; for framework-agnostic Core Web Vitals work - use web-performance instead; for designing an application-wide cache layer beyond the framework - use caching-strategy instead.\nmetadata:\n  title: \"Next.js App Router\"\n---\n\n# Next.js App Router\n\nDefault to Server Components; reach for Client Components only for interactivity, state, or browser APIs. The two costly mistakes this skill prevents are the accidental client tree - one `'use client'` placed high that drags the whole page into the browser bundle - and accidental caching decisions, where a team assumes data is cached (or fresh) without checking which caching model the app runs on. Since Next.js 15, `fetch` is not cached by default; caching is something you opt into, explicitly.\n\n## Operating procedure\n\n### Step 1: gather inputs\n\nCollect before writing a route (label guesses as guesses):\n\n0. The Next.js version (`next` in package.json) and whether `cacheComponents: true` is set in next.config. The caching model below depends on both: 15+ uncaches `fetch` by default, and Cache Components (16) replaces route-segment caching with `'use cache'`.\n1. Per piece of data on the page: is it per-request\u002Fper-user, or shared and cacheable? If cacheable, what staleness is acceptable (seconds, minutes, hours)?\n2. Which UI elements genuinely need interactivity, state, effects, or browser APIs.\n3. Mutations on the page and what data they invalidate.\n4. Auth model: does rendering depend on cookies\u002Fheaders (forces dynamic rendering)?\n\n### Step 2: draw the client boundary at the leaves\n\n- Mark `'use client'` only at the smallest component that needs it. Everything imported by a client component becomes client code, so a high boundary silently ships the subtree to the browser.\n- If a client component needs server-rendered content inside it, pass it as `children` - composition keeps the inner tree on the server.\n- Pass data down as props; do not lift server data into client state just to share it.\n\nBad:\n\n```tsx\n'use client'                    \u002F\u002F whole page is now client code\nexport default function Page() {\n  const [open, setOpen] = useState(false)\n  \u002F\u002F 40 KB of product listing logic dragged into the bundle for one toggle\n}\n```\n\nGood:\n\n```tsx\n\u002F\u002F page.tsx - server component, fetches and renders\nexport default async function Page() {\n  const products = await getProducts()\n  return \u003CProductList products={products} action={\u003CFilterToggle \u002F>} \u002F>\n}\n\u002F\u002F FilterToggle.tsx - 'use client', only the toggle ships to the browser\n```\n\n### Step 3: fetch on the server, choose caching explicitly\n\n- Fetch in server components with `async`\u002F`await`. No `useEffect` data fetching unless the data is genuinely client-driven (e.g. depends on live client state).\n- `fetch` is NOT cached by default (Next.js 15+). Fresh, per-request data needs no flag; caching is an explicit opt-in per data source:\n  - With Cache Components (`cacheComponents: true`, Next.js 16): put `'use cache'` at the top of the data function or component, pair it with `cacheLife('minutes' | 'hours' | ...)` chosen from the staleness in Step 1, and `cacheTag('products')` when a mutation must invalidate it precisely. Wrap uncached, request-time sections in `\u003CSuspense>` so they stream.\n  - Without Cache Components: opt a fetch in with `{ next: { revalidate: N, tags: ['products'] } }` or `{ cache: 'force-cache' }`. Pick N from acceptable staleness in Step 1 (60 s for dashboard-ish freshness, 3600 s for marketing\u002Fcontent).\n- `cookies()` and `headers()` are async (`await cookies()`); reading them makes that part of the render request-time. Expect it, don't fight it, and keep it inside the smallest component that needs it.\n- Deduplicate: a `fetch` with identical args is memoized per request, so fetch where the data is used rather than prop-drilling from the top.\n\n### Step 4: stream instead of blocking\n\n- Add `loading.tsx` for every route with async work - the shell should render immediately while data streams in.\n- Wrap independently-slow sections in `\u003CSuspense>` with their own fallbacks so one slow query does not hold the whole page. If any single data dependency takes over ~300 ms, it is a streaming candidate; never let one slow fetch block first paint past 1 s when the rest of the page is ready.\n- `error.tsx` for route-level error boundaries; `not-found.tsx` plus `notFound()` for 404s.\n\n### Step 5: mutate with Server Actions and revalidate\n\n- Use Server Actions for mutations. Validate input on the server with a schema - never trust the client; the action is a public endpoint regardless of which form calls it.\n- Check authorization inside the action, not only in the page that renders the form.\n- After a successful mutation, invalidate exactly the data that changed, using the tags from Step 3: `updateTag('products')` inside a Server Action when the user must see their own write immediately; `revalidateTag('products', 'max')` (two arguments; the one-argument form is deprecated) from Route Handlers or when stale-while-revalidate is fine; `revalidatePath` only when a whole route changed.\n- Return typed error state from actions for the form to render; do not throw for expected validation failures.\n\n## Deliverable\n\nProduce the route implementation plus a one-table caching manifest: for each data source on the page - cached or request-time, its cacheLife or revalidate interval, tags, and which mutation invalidates it (and with which call). Every choice explicit, none accidental.\n\n## Do NOT\n\n- Do not put `'use client'` on a page or layout to fix one interactive widget - extract the widget instead; the directive is transitive to every import.\n- Do not fetch in `useEffect` what a server component could fetch - it adds a client-server waterfall and a loading spinner where streamed HTML would do.\n- Do not assume pre-15 defaults: on Next.js 15+ a bare `fetch` is uncached, so \"why is my page slow\" is often missing opt-in caching, not a caching bug. And do not reach for route-wide `force-dynamic` to fix one stale data source.\n- Do not skip validation or auth checks in Server Actions because \"only my form calls it\" - actions are callable endpoints.\n- Do not store server data in client state and manually sync it; revalidation after mutation is the sync mechanism.\n\n## Quality bar\n\n- Every `'use client'` directive is at a leaf and justified by interactivity, state, or a browser API.\n- Every data source has an explicit caching decision for the app's Next.js version and caching model (`'use cache'` + `cacheLife`, or `fetch` options); none is cached or uncached by accident.\n- Every async boundary has a loading state; no route blanks while awaiting data.\n- Every mutation revalidates the specific paths\u002Ftags it affects, and validates + authorizes on the server.\n- The caching manifest exists and matches the code.\n","# Next.js App Router\n\nDefault to Server Components; reach for Client Components only for interactivity, state, or browser APIs. The two costly mistakes this skill prevents are the accidental client tree - one `'use client'` placed high that drags the whole page into the browser bundle - and accidental caching decisions, where a team assumes data is cached (or fresh) without checking which caching model the app runs on. Since Next.js 15, `fetch` is not cached by default; caching is something you opt into, explicitly.\n\n## Operating procedure\n\n### Step 1: gather inputs\n\nCollect before writing a route (label guesses as guesses):\n\n0. The Next.js version (`next` in package.json) and whether `cacheComponents: true` is set in next.config. The caching model below depends on both: 15+ uncaches `fetch` by default, and Cache Components (16) replaces route-segment caching with `'use cache'`.\n1. Per piece of data on the page: is it per-request\u002Fper-user, or shared and cacheable? If cacheable, what staleness is acceptable (seconds, minutes, hours)?\n2. Which UI elements genuinely need interactivity, state, effects, or browser APIs.\n3. Mutations on the page and what data they invalidate.\n4. Auth model: does rendering depend on cookies\u002Fheaders (forces dynamic rendering)?\n\n### Step 2: draw the client boundary at the leaves\n\n- Mark `'use client'` only at the smallest component that needs it. Everything imported by a client component becomes client code, so a high boundary silently ships the subtree to the browser.\n- If a client component needs server-rendered content inside it, pass it as `children` - composition keeps the inner tree on the server.\n- Pass data down as props; do not lift server data into client state just to share it.\n\nBad:\n\n```tsx\n'use client'                    \u002F\u002F whole page is now client code\nexport default function Page() {\n  const [open, setOpen] = useState(false)\n  \u002F\u002F 40 KB of product listing logic dragged into the bundle for one toggle\n}\n```\n\nGood:\n\n```tsx\n\u002F\u002F page.tsx - server component, fetches and renders\nexport default async function Page() {\n  const products = await getProducts()\n  return \u003CProductList products={products} action={\u003CFilterToggle \u002F>} \u002F>\n}\n\u002F\u002F FilterToggle.tsx - 'use client', only the toggle ships to the browser\n```\n\n### Step 3: fetch on the server, choose caching explicitly\n\n- Fetch in server components with `async`\u002F`await`. No `useEffect` data fetching unless the data is genuinely client-driven (e.g. depends on live client state).\n- `fetch` is NOT cached by default (Next.js 15+). Fresh, per-request data needs no flag; caching is an explicit opt-in per data source:\n  - With Cache Components (`cacheComponents: true`, Next.js 16): put `'use cache'` at the top of the data function or component, pair it with `cacheLife('minutes' | 'hours' | ...)` chosen from the staleness in Step 1, and `cacheTag('products')` when a mutation must invalidate it precisely. Wrap uncached, request-time sections in `\u003CSuspense>` so they stream.\n  - Without Cache Components: opt a fetch in with `{ next: { revalidate: N, tags: ['products'] } }` or `{ cache: 'force-cache' }`. Pick N from acceptable staleness in Step 1 (60 s for dashboard-ish freshness, 3600 s for marketing\u002Fcontent).\n- `cookies()` and `headers()` are async (`await cookies()`); reading them makes that part of the render request-time. Expect it, don't fight it, and keep it inside the smallest component that needs it.\n- Deduplicate: a `fetch` with identical args is memoized per request, so fetch where the data is used rather than prop-drilling from the top.\n\n### Step 4: stream instead of blocking\n\n- Add `loading.tsx` for every route with async work - the shell should render immediately while data streams in.\n- Wrap independently-slow sections in `\u003CSuspense>` with their own fallbacks so one slow query does not hold the whole page. If any single data dependency takes over ~300 ms, it is a streaming candidate; never let one slow fetch block first paint past 1 s when the rest of the page is ready.\n- `error.tsx` for route-level error boundaries; `not-found.tsx` plus `notFound()` for 404s.\n\n### Step 5: mutate with Server Actions and revalidate\n\n- Use Server Actions for mutations. Validate input on the server with a schema - never trust the client; the action is a public endpoint regardless of which form calls it.\n- Check authorization inside the action, not only in the page that renders the form.\n- After a successful mutation, invalidate exactly the data that changed, using the tags from Step 3: `updateTag('products')` inside a Server Action when the user must see their own write immediately; `revalidateTag('products', 'max')` (two arguments; the one-argument form is deprecated) from Route Handlers or when stale-while-revalidate is fine; `revalidatePath` only when a whole route changed.\n- Return typed error state from actions for the form to render; do not throw for expected validation failures.\n\n## Deliverable\n\nProduce the route implementation plus a one-table caching manifest: for each data source on the page - cached or request-time, its cacheLife or revalidate interval, tags, and which mutation invalidates it (and with which call). Every choice explicit, none accidental.\n\n## Do NOT\n\n- Do not put `'use client'` on a page or layout to fix one interactive widget - extract the widget instead; the directive is transitive to every import.\n- Do not fetch in `useEffect` what a server component could fetch - it adds a client-server waterfall and a loading spinner where streamed HTML would do.\n- Do not assume pre-15 defaults: on Next.js 15+ a bare `fetch` is uncached, so \"why is my page slow\" is often missing opt-in caching, not a caching bug. And do not reach for route-wide `force-dynamic` to fix one stale data source.\n- Do not skip validation or auth checks in Server Actions because \"only my form calls it\" - actions are callable endpoints.\n- Do not store server data in client state and manually sync it; revalidation after mutation is the sync mechanism.\n\n## Quality bar\n\n- Every `'use client'` directive is at a leaf and justified by interactivity, state, or a browser API.\n- Every data source has an explicit caching decision for the app's Next.js version and caching model (`'use cache'` + `cacheLife`, or `fetch` options); none is cached or uncached by accident.\n- Every async boundary has a loading state; no route blanks while awaiting data.\n- Every mutation revalidates the specific paths\u002Ftags it affects, and validates + authorizes on the server.\n- The caching manifest exists and matches the code.\n",{"name":5,"metadata":24,"description":7},{"title":25},"Next.js App Router","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Fnextjs-app-router",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 nextjs-app-router",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill nextjs-app-router",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill nextjs-app-router","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnextjs-app-router\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",[],[]]