[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CT7RX8G9CJFWR4KPVJ869T":3,"skill-same:01M6CT7RX8G9CJFWR4KPVJ869T":63},{"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":23,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":6,"ownerDescription":47,"updatedAt":48,"install":49,"resources":62},"01M6CT7RX8G9CJFWR4KPVJ869T","deployment-strategy",null,"Designs deployment pipelines, rollout strategies and environment setups. Use when setting up CI\u002FCD (automated build and deploy) or planning a gradual rollout.","vibbs\u002Fcompany-os","vibbs","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F7379149?v=4","01M6CT6M03CAS1H7RA89F3965B","Vibbs Dod","01M6CT6M4MY60C9FFQ3AAR2RSK",6,"MIT","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fdeployment-strategy\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35],"deployment","strategy","deployment strategy","deploy","planning","ci","environment","use","rollout","up","pipelines","build","2026-11-10 10:12:30",false,"---\nname: deployment-strategy\ndescription: Designs deployment pipelines, rollout strategies and environment setups. Use when setting up CI\u002FCD (automated build and deploy) or planning a gradual rollout.\nuser-invocable: false\n---\n\n# Deployment Strategy\n\n## Reference\n- **ID**: S-ENG-07\n- **Category**: Engineering\n- **Inputs**: company.config.yaml, existing RFCs\n- **Outputs**: deployment strategy (standards\u002Fops\u002F), per-feature deployment plan (in RFC)\n- **Used by**: Engineering Agent\n- **Tool scripts**: .\u002Ftools\u002Fdeploy\u002Fpre-deploy.sh, .\u002Ftools\u002Fqa\u002Fsmoke-test.sh, .\u002Ftools\u002Fdb\u002Fmigration-check.sh\n\n## Purpose\n\nDefine a repeatable, safe deployment pipeline that moves code from a developer's machine to production with confidence. This skill produces environment configurations, pipeline designs, rollout strategies, and rollback procedures tailored to the configured tech stack.\n\n## Procedure\n\n### Step 1: Load Context\n\nBefore designing the deployment strategy:\n\n1. **Read `company.config.yaml`** -- understand hosting provider, CI system, branching conventions, and `architecture.deployment_model`\n2. **Read existing RFCs** in `artifacts\u002Frfcs\u002F` -- understand system dependencies and data flow\n3. **Check existing standards** in `standards\u002Fops\u002F` -- avoid contradicting existing operational procedures\n4. **Identify deployment constraints** -- database migrations, external service dependencies, feature flags\n\n### Step 2: Generate Deployment Strategy\n\nProduce `standards\u002Fops\u002Fdeployment-strategy.md` with the following sections:\n\n#### Environment Ladder\n\nDefine three environments with specific configuration differences:\n\n| Environment | Purpose | Database | Data | Monitoring | Access |\n|-------------|---------|----------|------|------------|--------|\n| **Local** | Developer machine, hot reload, fast iteration | Local DB instance (SQLite, local Postgres, etc.) | Seed data from `.\u002Ftools\u002Fdb\u002Fseed.sh` | Console logging only | Developer only |\n| **Staging** | Mirror of production for pre-release validation | Staging DB (same engine as production) | Anonymized test data, never real user data | Full monitoring enabled, alerts to staging channel | Developer + QA |\n| **Production** | Live users, real data, revenue-generating | Production DB with backups and replication | Real user data, strict access controls | Full monitoring, alerting, on-call notifications | Restricted, deploy via CI only |\n\nKey differences to document:\n- Environment variable sets per environment\n- Feature flags: which are enabled where\n- External service endpoints: sandbox vs. production APIs\n- Log levels: debug (local), info (staging), warn+error (production)\n\n#### Deployment Pipeline\n\nDesign the pipeline based on the configured CI provider:\n\n```\nPush to branch\n    |\n    v\nCI Pipeline Triggered\n    |\n    +-- Run tests (unit, integration)\n    +-- Run linter\n    +-- Run security scan (dependency-scan.sh)\n    +-- Run migration check (migration-check.sh)\n    |\n    v\nAll checks pass?\n    |\n    +-- No --> Block merge, notify developer\n    +-- Yes --> Continue\n    |\n    v\nMerge to main branch\n    |\n    v\nDeploy to Staging\n    |\n    v\nRun smoke tests (smoke-test.sh) against staging\n    |\n    v\nSmoke tests pass?\n    |\n    +-- No --> Block production deploy, notify\n    +-- Yes --> Continue\n    |\n    v\nManual approval gate (for P0-risk changes) or auto-promote\n    |\n    v\nDeploy to Production\n    |\n    v\nRun smoke tests against production\n    |\n    v\nMonitor error rates for 15 minutes\n    |\n    +-- Error spike --> Auto-rollback (if configured) or alert\n    +-- Stable --> Deploy complete\n```\n\n#### Rollout Strategy Per Deployment Model\n\n**Serverless** (Vercel, Netlify, AWS Lambda, Cloudflare Workers):\n- Atomic deploys: the entire deployment is swapped at once\n- Instant rollback: redeploy the previous version through the platform dashboard or CLI\n- No partial rollouts by default; use feature flags for gradual exposure\n- Edge functions deploy regionally; verify in multiple regions\n\n**Containers** (Docker, ECS, Kubernetes, Fly.io, Railway):\n- **Rolling update** (default): replace instances one at a time; zero downtime if health checks pass\n- **Blue-green**: run new version alongside old; switch traffic via load balancer; instant rollback by switching back\n- **Canary**: route a small percentage of traffic (5-10%) to the new version; monitor error rates; expand if stable\n\n**VMs** (EC2, DigitalOcean Droplets, traditional hosting):\n- Blue-green with load balancer swap: spin up new instances, validate, swap load balancer target\n- Rollback: swap load balancer back to old instances (keep them running for 1 hour post-deploy)\n\n**Edge** (Cloudflare Workers, Deno Deploy, edge functions):\n- Regional rollout: deploy to one region first, monitor, then expand globally\n- Instant rollback: redeploy previous version to all regions\n\n#### Rollback Procedure\n\nStep-by-step, stack-specific rollback:\n\n1. **Detect the issue** -- error rate spike, failing smoke tests, user reports\n2. **Decide to rollback** -- if fix is not obvious within 15 minutes, rollback\n3. **Execute rollback**:\n   - Revert to the previous deployment using the hosting provider's rollback mechanism\n   - If database migration was applied: run the rollback migration (see migration safety below)\n   - If feature flag was enabled: disable the flag\n4. **Verify rollback** -- run `.\u002Ftools\u002Fops\u002Fstatus-check.sh` and `.\u002Ftools\u002Fqa\u002Fsmoke-test.sh`\n5. **Communicate** -- notify stakeholders that a rollback occurred and why\n6. **Investigate** -- determine root cause before re-attempting the deploy\n\n#### Database Migration Safety\n\nThese rules apply to every deployment that includes schema or data changes:\n\n1. **Always backwards-compatible migrations** -- the old code must work with the new schema, and the new code must work with the old schema (during the transition window)\n2. **Schema changes deployed before code changes** -- deploy the migration first, verify it succeeds, then deploy the code that depends on it\n3. **Data migrations in a separate deploy from schema changes** -- never mix `ALTER TABLE` with bulk `UPDATE` in the same deployment\n4. **Rollback migration for every forward migration** -- every `up` must have a corresponding `down`; verify the down migration works in staging\n5. **Coordinate with `.\u002Ftools\u002Fdb\u002Fmigration-check.sh`** -- run before every deploy to validate migration ordering, syntax, and rollback capability\n6. **Large data migrations run as background jobs** -- do not block the deploy pipeline with long-running data transformations\n\n#### Environment Variable Management\n\n1. **Never hardcode secrets** -- no API keys, database URLs, or tokens in source code\n2. **Use platform-native secret management** -- Vercel environment variables, AWS Secrets Manager, Railway variables, Fly.io secrets, or equivalent for the configured hosting provider\n3. **Validate required env vars before deploy** -- `.\u002Ftools\u002Fdeploy\u002Fpre-deploy.sh` checks that all required variables are set\n4. **Document all environment variables** -- maintain a `.env.example` file with variable names, descriptions, and example values (never real values)\n5. **Separate secrets per environment** -- staging and production must use different credentials\n6. **Rotate secrets on a schedule** -- document rotation procedure for each secret type\n\n#### Smoke Test Integration\n\nAfter every deployment to any environment:\n\n1. Run `.\u002Ftools\u002Fqa\u002Fsmoke-test.sh` against the deployed environment URL\n2. Smoke tests verify: health endpoint responds, authentication works, critical user flows complete, external integrations respond\n3. If smoke tests fail on staging: block production deploy\n4. If smoke tests fail on production: trigger rollback procedure\n\n### Step 3: Per-Feature Deployment Plan\n\nWhen designing deployment for a specific feature (added to the feature's RFC):\n\n**Migration Order:**\n- Does this feature require schema changes? If yes, deploy schema first.\n- Are the migrations backwards-compatible? Document compatibility window.\n- Is a data migration needed? Schedule it separately.\n\n**Feature Flag Gating:**\n- Should this feature be gated behind a flag? (Recommended for any user-facing change.)\n- Progressive rollout plan: 0% -> 5% -> 25% -> 50% -> 100%\n- Rollout timeline: how long at each percentage before expanding\n- Flag cleanup: when to remove the flag after full rollout\n\n**Rollback Trigger:**\n- What metrics or errors trigger a rollback? (Error rate >1%, p99 latency >5s, etc.)\n- Is automatic rollback configured, or is it manual?\n- What is the maximum acceptable time in a degraded state before rollback?\n\n**Canary Criteria** (if using canary deployment):\n- What percentage of traffic goes to canary? (Start with 5%)\n- How long does the canary run before expanding? (Minimum 15 minutes)\n- What metrics are compared between canary and baseline?\n- What is the automatic rollback threshold for the canary?\n\n### Step 4: Pre-Deployment Validation\n\nBefore every deployment, reference `.\u002Ftools\u002Fdeploy\u002Fpre-deploy.sh` for automated checks:\n\n1. No uncommitted changes in the working tree\n2. On the expected branch (main\u002Fmaster per branching config)\n3. All tests pass\n4. Linting passes\n5. No secrets detected in the codebase\n6. Database migrations reviewed and validated\n7. Required environment variables are set\n\nIf any check fails, the deploy is blocked until the issue is resolved.\n\n### Step 5: Verify\n\n- [ ] All three environments (local, staging, production) are defined with specific configuration differences\n- [ ] Deployment pipeline matches the configured CI provider\n- [ ] Rollout strategy matches the configured `deployment_model`\n- [ ] Rollback procedure is step-by-step and specific to the tech stack\n- [ ] Database migration safety rules are explicit and enforced\n- [ ] Environment variable management does not permit hardcoded secrets\n- [ ] Smoke tests are integrated after every deployment\n\n## Quality Checklist\n\n- [ ] All environments defined with specific config differences\n- [ ] Pipeline matches configured CI provider\n- [ ] Rollout strategy matches deployment_model\n- [ ] Rollback is step-by-step and stack-specific\n- [ ] Migration safety rules are explicit\n- [ ] Env var management does not hardcode secrets\n- [ ] Smoke tests are integrated post-deploy\n","# Deployment Strategy\n\n## Reference\n- **ID**: S-ENG-07\n- **Category**: Engineering\n- **Inputs**: company.config.yaml, existing RFCs\n- **Outputs**: deployment strategy (standards\u002Fops\u002F), per-feature deployment plan (in RFC)\n- **Used by**: Engineering Agent\n- **Tool scripts**: .\u002Ftools\u002Fdeploy\u002Fpre-deploy.sh, .\u002Ftools\u002Fqa\u002Fsmoke-test.sh, .\u002Ftools\u002Fdb\u002Fmigration-check.sh\n\n## Purpose\n\nDefine a repeatable, safe deployment pipeline that moves code from a developer's machine to production with confidence. This skill produces environment configurations, pipeline designs, rollout strategies, and rollback procedures tailored to the configured tech stack.\n\n## Procedure\n\n### Step 1: Load Context\n\nBefore designing the deployment strategy:\n\n1. **Read `company.config.yaml`** -- understand hosting provider, CI system, branching conventions, and `architecture.deployment_model`\n2. **Read existing RFCs** in `artifacts\u002Frfcs\u002F` -- understand system dependencies and data flow\n3. **Check existing standards** in `standards\u002Fops\u002F` -- avoid contradicting existing operational procedures\n4. **Identify deployment constraints** -- database migrations, external service dependencies, feature flags\n\n### Step 2: Generate Deployment Strategy\n\nProduce `standards\u002Fops\u002Fdeployment-strategy.md` with the following sections:\n\n#### Environment Ladder\n\nDefine three environments with specific configuration differences:\n\n| Environment | Purpose | Database | Data | Monitoring | Access |\n|-------------|---------|----------|------|------------|--------|\n| **Local** | Developer machine, hot reload, fast iteration | Local DB instance (SQLite, local Postgres, etc.) | Seed data from `.\u002Ftools\u002Fdb\u002Fseed.sh` | Console logging only | Developer only |\n| **Staging** | Mirror of production for pre-release validation | Staging DB (same engine as production) | Anonymized test data, never real user data | Full monitoring enabled, alerts to staging channel | Developer + QA |\n| **Production** | Live users, real data, revenue-generating | Production DB with backups and replication | Real user data, strict access controls | Full monitoring, alerting, on-call notifications | Restricted, deploy via CI only |\n\nKey differences to document:\n- Environment variable sets per environment\n- Feature flags: which are enabled where\n- External service endpoints: sandbox vs. production APIs\n- Log levels: debug (local), info (staging), warn+error (production)\n\n#### Deployment Pipeline\n\nDesign the pipeline based on the configured CI provider:\n\n```\nPush to branch\n    |\n    v\nCI Pipeline Triggered\n    |\n    +-- Run tests (unit, integration)\n    +-- Run linter\n    +-- Run security scan (dependency-scan.sh)\n    +-- Run migration check (migration-check.sh)\n    |\n    v\nAll checks pass?\n    |\n    +-- No --> Block merge, notify developer\n    +-- Yes --> Continue\n    |\n    v\nMerge to main branch\n    |\n    v\nDeploy to Staging\n    |\n    v\nRun smoke tests (smoke-test.sh) against staging\n    |\n    v\nSmoke tests pass?\n    |\n    +-- No --> Block production deploy, notify\n    +-- Yes --> Continue\n    |\n    v\nManual approval gate (for P0-risk changes) or auto-promote\n    |\n    v\nDeploy to Production\n    |\n    v\nRun smoke tests against production\n    |\n    v\nMonitor error rates for 15 minutes\n    |\n    +-- Error spike --> Auto-rollback (if configured) or alert\n    +-- Stable --> Deploy complete\n```\n\n#### Rollout Strategy Per Deployment Model\n\n**Serverless** (Vercel, Netlify, AWS Lambda, Cloudflare Workers):\n- Atomic deploys: the entire deployment is swapped at once\n- Instant rollback: redeploy the previous version through the platform dashboard or CLI\n- No partial rollouts by default; use feature flags for gradual exposure\n- Edge functions deploy regionally; verify in multiple regions\n\n**Containers** (Docker, ECS, Kubernetes, Fly.io, Railway):\n- **Rolling update** (default): replace instances one at a time; zero downtime if health checks pass\n- **Blue-green**: run new version alongside old; switch traffic via load balancer; instant rollback by switching back\n- **Canary**: route a small percentage of traffic (5-10%) to the new version; monitor error rates; expand if stable\n\n**VMs** (EC2, DigitalOcean Droplets, traditional hosting):\n- Blue-green with load balancer swap: spin up new instances, validate, swap load balancer target\n- Rollback: swap load balancer back to old instances (keep them running for 1 hour post-deploy)\n\n**Edge** (Cloudflare Workers, Deno Deploy, edge functions):\n- Regional rollout: deploy to one region first, monitor, then expand globally\n- Instant rollback: redeploy previous version to all regions\n\n#### Rollback Procedure\n\nStep-by-step, stack-specific rollback:\n\n1. **Detect the issue** -- error rate spike, failing smoke tests, user reports\n2. **Decide to rollback** -- if fix is not obvious within 15 minutes, rollback\n3. **Execute rollback**:\n   - Revert to the previous deployment using the hosting provider's rollback mechanism\n   - If database migration was applied: run the rollback migration (see migration safety below)\n   - If feature flag was enabled: disable the flag\n4. **Verify rollback** -- run `.\u002Ftools\u002Fops\u002Fstatus-check.sh` and `.\u002Ftools\u002Fqa\u002Fsmoke-test.sh`\n5. **Communicate** -- notify stakeholders that a rollback occurred and why\n6. **Investigate** -- determine root cause before re-attempting the deploy\n\n#### Database Migration Safety\n\nThese rules apply to every deployment that includes schema or data changes:\n\n1. **Always backwards-compatible migrations** -- the old code must work with the new schema, and the new code must work with the old schema (during the transition window)\n2. **Schema changes deployed before code changes** -- deploy the migration first, verify it succeeds, then deploy the code that depends on it\n3. **Data migrations in a separate deploy from schema changes** -- never mix `ALTER TABLE` with bulk `UPDATE` in the same deployment\n4. **Rollback migration for every forward migration** -- every `up` must have a corresponding `down`; verify the down migration works in staging\n5. **Coordinate with `.\u002Ftools\u002Fdb\u002Fmigration-check.sh`** -- run before every deploy to validate migration ordering, syntax, and rollback capability\n6. **Large data migrations run as background jobs** -- do not block the deploy pipeline with long-running data transformations\n\n#### Environment Variable Management\n\n1. **Never hardcode secrets** -- no API keys, database URLs, or tokens in source code\n2. **Use platform-native secret management** -- Vercel environment variables, AWS Secrets Manager, Railway variables, Fly.io secrets, or equivalent for the configured hosting provider\n3. **Validate required env vars before deploy** -- `.\u002Ftools\u002Fdeploy\u002Fpre-deploy.sh` checks that all required variables are set\n4. **Document all environment variables** -- maintain a `.env.example` file with variable names, descriptions, and example values (never real values)\n5. **Separate secrets per environment** -- staging and production must use different credentials\n6. **Rotate secrets on a schedule** -- document rotation procedure for each secret type\n\n#### Smoke Test Integration\n\nAfter every deployment to any environment:\n\n1. Run `.\u002Ftools\u002Fqa\u002Fsmoke-test.sh` against the deployed environment URL\n2. Smoke tests verify: health endpoint responds, authentication works, critical user flows complete, external integrations respond\n3. If smoke tests fail on staging: block production deploy\n4. If smoke tests fail on production: trigger rollback procedure\n\n### Step 3: Per-Feature Deployment Plan\n\nWhen designing deployment for a specific feature (added to the feature's RFC):\n\n**Migration Order:**\n- Does this feature require schema changes? If yes, deploy schema first.\n- Are the migrations backwards-compatible? Document compatibility window.\n- Is a data migration needed? Schedule it separately.\n\n**Feature Flag Gating:**\n- Should this feature be gated behind a flag? (Recommended for any user-facing change.)\n- Progressive rollout plan: 0% -> 5% -> 25% -> 50% -> 100%\n- Rollout timeline: how long at each percentage before expanding\n- Flag cleanup: when to remove the flag after full rollout\n\n**Rollback Trigger:**\n- What metrics or errors trigger a rollback? (Error rate >1%, p99 latency >5s, etc.)\n- Is automatic rollback configured, or is it manual?\n- What is the maximum acceptable time in a degraded state before rollback?\n\n**Canary Criteria** (if using canary deployment):\n- What percentage of traffic goes to canary? (Start with 5%)\n- How long does the canary run before expanding? (Minimum 15 minutes)\n- What metrics are compared between canary and baseline?\n- What is the automatic rollback threshold for the canary?\n\n### Step 4: Pre-Deployment Validation\n\nBefore every deployment, reference `.\u002Ftools\u002Fdeploy\u002Fpre-deploy.sh` for automated checks:\n\n1. No uncommitted changes in the working tree\n2. On the expected branch (main\u002Fmaster per branching config)\n3. All tests pass\n4. Linting passes\n5. No secrets detected in the codebase\n6. Database migrations reviewed and validated\n7. Required environment variables are set\n\nIf any check fails, the deploy is blocked until the issue is resolved.\n\n### Step 5: Verify\n\n- [ ] All three environments (local, staging, production) are defined with specific configuration differences\n- [ ] Deployment pipeline matches the configured CI provider\n- [ ] Rollout strategy matches the configured `deployment_model`\n- [ ] Rollback procedure is step-by-step and specific to the tech stack\n- [ ] Database migration safety rules are explicit and enforced\n- [ ] Environment variable management does not permit hardcoded secrets\n- [ ] Smoke tests are integrated after every deployment\n\n## Quality Checklist\n\n- [ ] All environments defined with specific config differences\n- [ ] Pipeline matches configured CI provider\n- [ ] Rollout strategy matches deployment_model\n- [ ] Rollback is step-by-step and stack-specific\n- [ ] Migration safety rules are explicit\n- [ ] Env var management does not hardcode secrets\n- [ ] Smoke tests are integrated post-deploy\n",{"name":5,"description":7,"user-invocable":37},"main","e842fb6d0e04360c47db78bc2e2e2987314d64d4",".claude\u002Fskills\u002Fdeployment-strategy",2,"https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os","https:\u002F\u002Fgithub.com\u002Fvibbs","Principal Engineer · Applied AI · building ArcAI @ GrowthArc","2026-10-21 02:08:08",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":61},[51,54,57],{"tool":52,"command":53},"npx","npx skills add vibbs\u002Fcompany-os --skill deployment-strategy",{"tool":55,"command":56},"bunx","bunx skills add vibbs\u002Fcompany-os --skill deployment-strategy",{"tool":58,"command":59},"pnpm","pnpm dlx skills add vibbs\u002Fcompany-os --skill deployment-strategy","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fdeployment-strategy\u002FSKILL.md",true,[],[64,73,81,91,107,123],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":70,"publishedAt":36},"01M6CTHBW1E64ECYGD105N4S5E","typo-field","Fixture skill with a misspelled top-level field.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Ftypo-field\u002FSKILL.md",[],[71,72],"typo field","fixture skill",{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":36},"01M6CTHABTV8FKVDHFMMKPAV51","spaced-comments","Fixture skill with comments and spaces after block keys.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fspaced-comments\u002FSKILL.md",[],[80,72],"spaced comments",{"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":36},"01M6CTH8MHC14KB65ZDHYBJW1N","crlf-comments","Fixture skill with Windows line endings.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fcrlf-comments\u002FSKILL.md",[],[88,89,90,72],"crlf comments","CRLF","windows",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":36},"01M6CTH6TBKTDP9G8QB1Z2K0TY","claude-fields","Fixture skill using top-level fields Claude Code documents.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fclaude-fields\u002FSKILL.md",[],[98,99,100,101,102,103,72,104,105,106],"claude fields","explore","documents","src","grep","read","Bash","code","testing",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":116,"publishedAt":36},"01M6CTH46BGKXH80RWS876Y2CW","workflow-router","Maps an objective to the artifacts, stages and agents it needs. Use when deciding what happens next or which agents to involve.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Fos\u002Fskills\u002Fworkflow-router\u002FSKILL.md",[113],{"categoryNo":114,"categoryName":115,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[117,118,119,120,121,31,122],"workflow","router","workflow router","next","maps","artifacts",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":36},"01M6CTH27653SRVP2FMEQN3J5B","weekly-review","Summarizes your week: what shipped, AI spend, support themes, security health and next priorities. Use at the end of each week.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Fos\u002Fskills\u002Fweekly-review\u002FSKILL.md",[],[130,131,132,120,31,133,134,135,136],"weekly review","review","priorities","health","save","support","security"]