[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M750ATNYM80ESWF2R9BNAEJN":3,"skill-same:01M750ATNYM80ESWF2R9BNAEJN":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},"01M750ATNYM80ESWF2R9BNAEJN","docker-compose-wizard",null,"Produces production-minded docker-compose configurations - pinned images, healthchecks with real intervals, health-gated startup ordering, named volumes, explicit networks, and env-file secrets - plus the matching .env.example. Use when someone asks \"write a compose file for this stack\", \"why does my app start before the database is ready\", \"how do I add a healthcheck\", \"my compose setup works on my machine but not in CI\", or is reviewing a docker-compose.yml before it ships. Do NOT use for orchestrating across multiple hosts or cluster workloads - use kubernetes-basics instead; for provisioning the underlying cloud infrastructure - use terraform-expert instead; for CI pipelines that build and push the images - use github-actions instead; for auditing how secrets are stored and rotated - use secrets-hygiene 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\u002Fdocker-compose-wizard\u002FSKILL.md",[],[],"2026-11-11 17:59:37",false,"---\nname: docker-compose-wizard\ndescription: Produces production-minded docker-compose configurations - pinned images, healthchecks with real intervals, health-gated startup ordering, named volumes, explicit networks, and env-file secrets - plus the matching .env.example. Use when someone asks \"write a compose file for this stack\", \"why does my app start before the database is ready\", \"how do I add a healthcheck\", \"my compose setup works on my machine but not in CI\", or is reviewing a docker-compose.yml before it ships. Do NOT use for orchestrating across multiple hosts or cluster workloads - use kubernetes-basics instead; for provisioning the underlying cloud infrastructure - use terraform-expert instead; for CI pipelines that build and push the images - use github-actions instead; for auditing how secrets are stored and rotated - use secrets-hygiene instead.\nmetadata:\n  title: \"Docker Compose Wizard\"\n---\n\n# Docker Compose Wizard\n\nWrite compose files that are reproducible and safe to run, not just ones that start. The costly mistake this skill prevents is the works-on-my-machine file: `latest` tags that drift, an app that races its database on startup and crash-loops in CI, and state in anonymous volumes that vanishes on `down`.\n\n## Operating procedure\n\n### Step 1: gather inputs\n\nCollect before writing (label guesses as guesses):\n\n1. The services and their images or build contexts.\n2. Which services hold state (databases, queues, caches) - these get named volumes.\n3. Startup dependencies: who must be healthy before whom.\n4. Which ports must reach the host; everything else stays internal.\n5. Secrets involved, and where the file will run (dev only, CI, a real host) - a real host raises the bar on restart policy and resource limits.\n\n### Step 2: pin and size the images\n\n- Pin every image to a specific version tag - never `latest`, which makes yesterday's working file fail today. For maximum reproducibility on critical services, pin by digest.\n- Prefer slim\u002Falpine variants where compatible. Guideline budgets: a typical app service image under ~200 MB, utility sidecars under ~50 MB; a 1 GB+ app image usually means a missing multi-stage build (build toolchain shipped in the runtime image) - flag it.\n\n### Step 3: make startup ordering real with healthchecks\n\n- Add a `healthcheck` to every long-running service. `depends_on` without a condition only orders container *creation*; the app will still race the database.\n- Use `depends_on: {db: {condition: service_healthy}}` for actual readiness gating.\n- Healthcheck conventions that work in practice: `interval: 10s`, `timeout: 5s`, `retries: 5`, and `start_period` covering the service's normal boot time (30s for a database, longer for JVM apps) so boot-time failures don't count against retries.\n- The check must probe readiness, not process existence: `pg_isready -U $user` for Postgres, `redis-cli ping` for Redis, an HTTP `\u002Fhealth` endpoint for apps - not `ps aux | grep`.\n\n### Step 4: persist and network deliberately\n\n- State lives in **named volumes**, not bind mounts, for databases - named volumes survive recreation, avoid host-permission drift, and are what `docker volume` tooling manages.\n- Put services on an explicit user-defined network; don't rely on the default. Use two networks when there is a trust split (e.g. `frontend` for the app+proxy, `backend` for app+db, with the db only on `backend`).\n- Expose only the ports the host needs. Inter-service traffic uses service names on the internal network - a database almost never needs a host port outside local debugging.\n\n### Step 5: secrets and hygiene\n\n- Pass secrets via environment from a `.env` file; never hardcode them in the YAML. Ship a `.env.example` with placeholder values and commit that, never the real `.env`. Deeper secret handling routes to secrets-hygiene.\n- `restart: unless-stopped` for services that should survive crashes and host reboots.\n- Constrain resources where it matters (`deploy.resources.limits`) - an unbounded memory leak in one service otherwise takes the host down with it.\n- Run as a non-root user where the image allows (`user:` or the image's own unprivileged user).\n- Comment every non-obvious setting; the file is documentation.\n\n### Step 6: validate\n\nRun `docker compose config` to catch YAML\u002Finterpolation errors, then mentally execute the clean-machine test: fresh clone, `cp .env.example .env`, fill values, `docker compose up` - would it come up healthy with no undocumented steps? If not, fix the file, not the README.\n\n## Template\n\nCopy and replace the [FILL] fields.\n\n```yaml\nname: [FILL: project]\n\nservices:\n  app:\n    image: [FILL: registry\u002Fapp]:[FILL: version]   # pinned; never latest\n    depends_on:\n      db:\n        condition: service_healthy    # gate on readiness, not creation\n    environment:\n      DATABASE_URL: postgres:\u002F\u002F[FILL: user]:${DB_PASSWORD}@db:5432\u002F[FILL: dbname]\n    ports:\n      - \"[FILL: host_port]:8080\"      # only the app is host-reachable\n    healthcheck:\n      test: [\"CMD\", \"curl\", \"-f\", \"http:\u002F\u002Flocalhost:8080\u002Fhealth\"]\n      interval: 10s\n      timeout: 5s\n      retries: 5\n      start_period: 20s\n    restart: unless-stopped\n    networks: [frontend, backend]\n\n  db:\n    image: postgres:[FILL: major.minor]\n    environment:\n      POSTGRES_USER: [FILL: user]\n      POSTGRES_PASSWORD: ${DB_PASSWORD}   # from .env, never inline\n      POSTGRES_DB: [FILL: dbname]\n    volumes:\n      - db_data:\u002Fvar\u002Flib\u002Fpostgresql\u002Fdata  # named volume: survives recreation\n    healthcheck:\n      test: [\"CMD-SHELL\", \"pg_isready -U [FILL: user] -d [FILL: dbname]\"]\n      interval: 10s\n      timeout: 5s\n      retries: 5\n      start_period: 30s\n    restart: unless-stopped\n    networks: [backend]                   # no host port: internal only\n\nvolumes:\n  db_data:\n\nnetworks:\n  frontend:\n  backend:\n```\n\nMatching `.env.example`:\n\n```\nDB_PASSWORD=changeme\n```\n\n## Deliverable\n\nProduce the `docker-compose.yml` with pinned tags, healthchecks and health-gated `depends_on` on every long-running service, named volumes for all state, explicit networks, comments on non-obvious settings - plus the `.env.example` with placeholders.\n\n## Do NOT\n\n- Do not use `latest` tags - the file stops being reproducible the day upstream publishes.\n- Do not use bare `depends_on` and assume readiness - it orders creation only; the race lands in CI.\n- Do not put database state in bind mounts or anonymous volumes; the first `down -v` or permissions mismatch destroys it.\n- Do not publish ports for internal services \"just in case\" - every published port is attack surface, and on a real host it may bypass the firewall.\n- Do not inline secrets in the YAML, even for dev - the file gets committed and the secret is now in history.\n\n## Quality bar\n\n- `docker compose config` passes clean.\n- Every image pinned; every long-running service has a readiness-probing healthcheck with interval\u002Ftimeout\u002Fretries\u002Fstart_period set.\n- Every dependency is health-gated; all state in named volumes; networks explicit.\n- The clean-machine test passes: `.env.example` plus the file is everything a new machine needs.\n- Non-obvious settings carry comments.\n","# Docker Compose Wizard\n\nWrite compose files that are reproducible and safe to run, not just ones that start. The costly mistake this skill prevents is the works-on-my-machine file: `latest` tags that drift, an app that races its database on startup and crash-loops in CI, and state in anonymous volumes that vanishes on `down`.\n\n## Operating procedure\n\n### Step 1: gather inputs\n\nCollect before writing (label guesses as guesses):\n\n1. The services and their images or build contexts.\n2. Which services hold state (databases, queues, caches) - these get named volumes.\n3. Startup dependencies: who must be healthy before whom.\n4. Which ports must reach the host; everything else stays internal.\n5. Secrets involved, and where the file will run (dev only, CI, a real host) - a real host raises the bar on restart policy and resource limits.\n\n### Step 2: pin and size the images\n\n- Pin every image to a specific version tag - never `latest`, which makes yesterday's working file fail today. For maximum reproducibility on critical services, pin by digest.\n- Prefer slim\u002Falpine variants where compatible. Guideline budgets: a typical app service image under ~200 MB, utility sidecars under ~50 MB; a 1 GB+ app image usually means a missing multi-stage build (build toolchain shipped in the runtime image) - flag it.\n\n### Step 3: make startup ordering real with healthchecks\n\n- Add a `healthcheck` to every long-running service. `depends_on` without a condition only orders container *creation*; the app will still race the database.\n- Use `depends_on: {db: {condition: service_healthy}}` for actual readiness gating.\n- Healthcheck conventions that work in practice: `interval: 10s`, `timeout: 5s`, `retries: 5`, and `start_period` covering the service's normal boot time (30s for a database, longer for JVM apps) so boot-time failures don't count against retries.\n- The check must probe readiness, not process existence: `pg_isready -U $user` for Postgres, `redis-cli ping` for Redis, an HTTP `\u002Fhealth` endpoint for apps - not `ps aux | grep`.\n\n### Step 4: persist and network deliberately\n\n- State lives in **named volumes**, not bind mounts, for databases - named volumes survive recreation, avoid host-permission drift, and are what `docker volume` tooling manages.\n- Put services on an explicit user-defined network; don't rely on the default. Use two networks when there is a trust split (e.g. `frontend` for the app+proxy, `backend` for app+db, with the db only on `backend`).\n- Expose only the ports the host needs. Inter-service traffic uses service names on the internal network - a database almost never needs a host port outside local debugging.\n\n### Step 5: secrets and hygiene\n\n- Pass secrets via environment from a `.env` file; never hardcode them in the YAML. Ship a `.env.example` with placeholder values and commit that, never the real `.env`. Deeper secret handling routes to secrets-hygiene.\n- `restart: unless-stopped` for services that should survive crashes and host reboots.\n- Constrain resources where it matters (`deploy.resources.limits`) - an unbounded memory leak in one service otherwise takes the host down with it.\n- Run as a non-root user where the image allows (`user:` or the image's own unprivileged user).\n- Comment every non-obvious setting; the file is documentation.\n\n### Step 6: validate\n\nRun `docker compose config` to catch YAML\u002Finterpolation errors, then mentally execute the clean-machine test: fresh clone, `cp .env.example .env`, fill values, `docker compose up` - would it come up healthy with no undocumented steps? If not, fix the file, not the README.\n\n## Template\n\nCopy and replace the [FILL] fields.\n\n```yaml\nname: [FILL: project]\n\nservices:\n  app:\n    image: [FILL: registry\u002Fapp]:[FILL: version]   # pinned; never latest\n    depends_on:\n      db:\n        condition: service_healthy    # gate on readiness, not creation\n    environment:\n      DATABASE_URL: postgres:\u002F\u002F[FILL: user]:${DB_PASSWORD}@db:5432\u002F[FILL: dbname]\n    ports:\n      - \"[FILL: host_port]:8080\"      # only the app is host-reachable\n    healthcheck:\n      test: [\"CMD\", \"curl\", \"-f\", \"http:\u002F\u002Flocalhost:8080\u002Fhealth\"]\n      interval: 10s\n      timeout: 5s\n      retries: 5\n      start_period: 20s\n    restart: unless-stopped\n    networks: [frontend, backend]\n\n  db:\n    image: postgres:[FILL: major.minor]\n    environment:\n      POSTGRES_USER: [FILL: user]\n      POSTGRES_PASSWORD: ${DB_PASSWORD}   # from .env, never inline\n      POSTGRES_DB: [FILL: dbname]\n    volumes:\n      - db_data:\u002Fvar\u002Flib\u002Fpostgresql\u002Fdata  # named volume: survives recreation\n    healthcheck:\n      test: [\"CMD-SHELL\", \"pg_isready -U [FILL: user] -d [FILL: dbname]\"]\n      interval: 10s\n      timeout: 5s\n      retries: 5\n      start_period: 30s\n    restart: unless-stopped\n    networks: [backend]                   # no host port: internal only\n\nvolumes:\n  db_data:\n\nnetworks:\n  frontend:\n  backend:\n```\n\nMatching `.env.example`:\n\n```\nDB_PASSWORD=changeme\n```\n\n## Deliverable\n\nProduce the `docker-compose.yml` with pinned tags, healthchecks and health-gated `depends_on` on every long-running service, named volumes for all state, explicit networks, comments on non-obvious settings - plus the `.env.example` with placeholders.\n\n## Do NOT\n\n- Do not use `latest` tags - the file stops being reproducible the day upstream publishes.\n- Do not use bare `depends_on` and assume readiness - it orders creation only; the race lands in CI.\n- Do not put database state in bind mounts or anonymous volumes; the first `down -v` or permissions mismatch destroys it.\n- Do not publish ports for internal services \"just in case\" - every published port is attack surface, and on a real host it may bypass the firewall.\n- Do not inline secrets in the YAML, even for dev - the file gets committed and the secret is now in history.\n\n## Quality bar\n\n- `docker compose config` passes clean.\n- Every image pinned; every long-running service has a readiness-probing healthcheck with interval\u002Ftimeout\u002Fretries\u002Fstart_period set.\n- Every dependency is health-gated; all state in named volumes; networks explicit.\n- The clean-machine test passes: `.env.example` plus the file is everything a new machine needs.\n- Non-obvious settings carry comments.\n",{"name":5,"metadata":24,"description":7},{"title":25},"Docker Compose Wizard","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Fdocker-compose-wizard",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 docker-compose-wizard",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill docker-compose-wizard",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill docker-compose-wizard","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdocker-compose-wizard\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",[],[]]