[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X7FP1MR7F8VW88K37F03SW":3,"skill-same:01M6X7FP1MR7F8VW88K37F03SW":66},{"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":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":49,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6X7FP1MR7F8VW88K37F03SW","ralplan",null,"Consensus planning entrypoint that auto-gates vague ralph\u002Fautopilot\u002Fteam requests before execution","Cheggin\u002Frequest-for-startups","Cheggin","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F79483996?v=4","01M6X6MGT5512GJHE8DY5B1ZQJ","Reagan Hsu","01M6X6MGY03X7ZJNVRFM3R1040",1,"GPL-3.0","https:\u002F\u002Fgithub.com\u002FCheggin\u002Frequest-for-startups\u002Fblob\u002Fmain\u002Fskills\u002Fralplan\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35],"auto","vague","entrypoint","requests","-architect","autopilot","gates","task","codex","interactive","consensus","ralph","team","critic","architect","execution","planning","2026-11-10 10:12:30",false,"---\nname: ralplan\ndescription: Consensus planning entrypoint that auto-gates vague ralph\u002Fautopilot\u002Fteam requests before execution\nargument-hint: \"[--interactive] [--deliberate] [--architect codex] [--critic codex] \u003Ctask description>\"\nlevel: 4\n---\n\n# Ralplan (Consensus Planning Alias)\n\nRalplan is a shorthand alias for `\u002Fstartup-harness:omc-plan --consensus`. It triggers iterative planning with Planner, Architect, and Critic agents until consensus is reached, with **RALPLAN-DR structured deliberation** (short mode by default, deliberate mode for high-risk work).\n\n## Usage\n\n```\n\u002Fstartup-harness:ralplan \"task description\"\n```\n\n## Flags\n\n- `--interactive`: Enables user prompts at key decision points (draft review in step 2 and final approval in step 6). Without this flag the workflow runs fully automated — Planner → Architect → Critic loop — and outputs the final plan without asking for confirmation.\n- `--deliberate`: Forces deliberate mode for high-risk work. Adds pre-mortem (3 scenarios) and expanded test planning (unit\u002Fintegration\u002Fe2e\u002Fobservability). Without this flag, deliberate mode can still auto-enable when the request explicitly signals high risk (auth\u002Fsecurity, migrations, destructive changes, production incidents, compliance\u002FPII, public API breakage).\n- `--architect codex`: Use Codex for the Architect pass when Codex CLI is available. Otherwise, briefly note the fallback and keep the default Claude Architect review.\n- `--critic codex`: Use Codex for the Critic pass when Codex CLI is available. Otherwise, briefly note the fallback and keep the default Claude Critic review.\n\n## Usage with interactive mode\n\n```\n\u002Fstartup-harness:ralplan --interactive \"task description\"\n```\n\n## Behavior\n\nThis skill invokes the Plan skill in consensus mode:\n\n```\n\u002Fstartup-harness:omc-plan --consensus \u003Carguments>\n```\n\nThe consensus workflow:\n1. **Planner** creates initial plan and a compact **RALPLAN-DR summary** before review:\n   - Principles (3-5)\n   - Decision Drivers (top 3)\n   - Viable Options (>=2) with bounded pros\u002Fcons\n   - If only one viable option remains, explicit invalidation rationale for alternatives\n   - Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan (unit\u002Fintegration\u002Fe2e\u002Fobservability)\n2. **User feedback** *(--interactive only)*: If `--interactive` is set, use `AskUserQuestion` to present the draft plan **plus the Principles \u002F Drivers \u002F Options summary** before review (Proceed to review \u002F Request changes \u002F Skip review). Otherwise, automatically proceed to review.\n3. **Architect** reviews for architectural soundness and must provide the strongest steelman antithesis, at least one real tradeoff tension, and (when possible) synthesis — **await completion before step 4**. In deliberate mode, Architect should explicitly flag principle violations.\n4. **Critic** evaluates against quality criteria — run only after step 3 completes. Critic must enforce principle-option consistency, fair alternatives, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. In deliberate mode, Critic must reject missing\u002Fweak pre-mortem or expanded test plan.\n5. **Re-review loop** (max 5 iterations): Any non-`APPROVE` Critic verdict (`ITERATE` or `REJECT`) MUST run the same full closed loop:\n   a. Collect Architect + Critic feedback\n   b. Revise the plan with Planner\n   c. Return to Architect review\n   d. Return to Critic evaluation\n   e. Repeat this loop until Critic returns `APPROVE` or 5 iterations are reached\n   f. If 5 iterations are reached without `APPROVE`, present the best version to the user\n6. On Critic approval *(--interactive only)*: If `--interactive` is set, use `AskUserQuestion` to present the plan with approval options (Approve and implement via team (Recommended) \u002F Approve and execute via ralph \u002F Clear context and implement \u002F Request changes \u002F Reject). Final plan must include ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups). Otherwise, output the final plan and stop.\n7. *(--interactive only)* User chooses: Approve (team or ralph), Request changes, or Reject\n8. *(--interactive only)* On approval: invoke `Skill(\"startup-harness:team\")` for parallel team execution (recommended) or `Skill(\"startup-harness:ralph\")` for sequential execution -- never implement directly\n\n> **Important:** Steps 3 and 4 MUST run sequentially. Do NOT issue both agent Task calls in the same parallel batch. Always await the Architect result before issuing the Critic Task.\n\nFollow the Plan skill's full documentation for consensus mode details.\n\n## Pre-Execution Gate\n\n### Why the Gate Exists\n\nExecution modes (ralph, autopilot, team, ultrawork, ultrapilot) spin up heavy multi-agent orchestration. When launched on a vague request like \"ralph improve the app\", agents have no clear target — they waste cycles on scope discovery that should happen during planning, often delivering partial or misaligned work that requires rework.\n\nThe ralplan-first gate intercepts underspecified execution requests and redirects them through the ralplan consensus planning workflow. This ensures:\n- **Explicit scope**: A PRD defines exactly what will be built\n- **Test specification**: Acceptance criteria are testable before code is written\n- **Consensus**: Planner, Architect, and Critic agree on the approach\n- **No wasted execution**: Agents start with a clear, bounded task\n\n### Good vs Bad Prompts\n\n**Passes the gate** (specific enough for direct execution):\n- `ralph fix the null check in src\u002Fhooks\u002Fbridge.ts:326`\n- `autopilot implement issue #42`\n- `team add validation to function processKeywordDetector`\n- `ralph do:\\n1. Add input validation\\n2. Write tests\\n3. Update README`\n- `ultrawork add the user model in src\u002Fmodels\u002Fuser.ts`\n\n**Gated — redirected to ralplan** (needs scoping first):\n- `ralph fix this`\n- `autopilot build the app`\n- `team improve performance`\n- `ralph add authentication`\n- `ultrawork make it better`\n\n**Bypass the gate** (when you know what you want):\n- `force: ralph refactor the auth module`\n- `! autopilot optimize everything`\n\n### When the Gate Does NOT Trigger\n\nThe gate auto-passes when it detects **any** concrete signal. You do not need all of them — one is enough:\n\n| Signal Type | Example prompt | Why it passes |\n|---|---|---|\n| File path | `ralph fix src\u002Fhooks\u002Fbridge.ts` | References a specific file |\n| Issue\u002FPR number | `ralph implement #42` | Has a concrete work item |\n| camelCase symbol | `ralph fix processKeywordDetector` | Names a specific function |\n| PascalCase symbol | `ralph update UserModel` | Names a specific class |\n| snake_case symbol | `team fix user_model` | Names a specific identifier |\n| Test runner | `ralph npm test && fix failures` | Has an explicit test target |\n| Numbered steps | `ralph do:\\n1. Add X\\n2. Test Y` | Structured deliverables |\n| Acceptance criteria | `ralph add login - acceptance criteria: ...` | Explicit success definition |\n| Error reference | `ralph fix TypeError in auth` | Specific error to address |\n| Code block | `ralph add: \\`\\`\\`ts ... \\`\\`\\`` | Concrete code provided |\n| Escape prefix | `force: ralph do it` or `! ralph do it` | Explicit user override |\n\n### End-to-End Flow Example\n\n1. User types: `ralph add user authentication`\n2. Gate detects: execution keyword (`ralph`) + underspecified prompt (no files, functions, or test spec)\n3. Gate redirects to **ralplan** with message explaining the redirect\n4. Ralplan consensus runs:\n   - **Planner** creates initial plan (which files, what auth method, what tests)\n   - **Architect** reviews for soundness\n   - **Critic** validates quality and testability\n5. On consensus approval, user chooses execution path:\n   - **team**: parallel coordinated agents (recommended)\n   - **ralph**: sequential execution with verification\n6. Execution begins with a clear, bounded plan\n\n### Troubleshooting\n\n| Issue | Solution |\n|-------|----------|\n| Gate fires on a well-specified prompt | Add a file reference, function name, or issue number to anchor the request |\n| Want to bypass the gate | Prefix with `force:` or `!` (e.g., `force: ralph fix it`) |\n| Gate does not fire on a vague prompt | The gate only catches prompts with \u003C=15 effective words and no concrete anchors; add more detail or use `\u002Fralplan` explicitly |\n| Redirected to ralplan but want to skip planning | In the ralplan workflow, say \"just do it\" or \"skip planning\" to transition directly to execution |\n","# Ralplan (Consensus Planning Alias)\n\nRalplan is a shorthand alias for `\u002Fstartup-harness:omc-plan --consensus`. It triggers iterative planning with Planner, Architect, and Critic agents until consensus is reached, with **RALPLAN-DR structured deliberation** (short mode by default, deliberate mode for high-risk work).\n\n## Usage\n\n```\n\u002Fstartup-harness:ralplan \"task description\"\n```\n\n## Flags\n\n- `--interactive`: Enables user prompts at key decision points (draft review in step 2 and final approval in step 6). Without this flag the workflow runs fully automated — Planner → Architect → Critic loop — and outputs the final plan without asking for confirmation.\n- `--deliberate`: Forces deliberate mode for high-risk work. Adds pre-mortem (3 scenarios) and expanded test planning (unit\u002Fintegration\u002Fe2e\u002Fobservability). Without this flag, deliberate mode can still auto-enable when the request explicitly signals high risk (auth\u002Fsecurity, migrations, destructive changes, production incidents, compliance\u002FPII, public API breakage).\n- `--architect codex`: Use Codex for the Architect pass when Codex CLI is available. Otherwise, briefly note the fallback and keep the default Claude Architect review.\n- `--critic codex`: Use Codex for the Critic pass when Codex CLI is available. Otherwise, briefly note the fallback and keep the default Claude Critic review.\n\n## Usage with interactive mode\n\n```\n\u002Fstartup-harness:ralplan --interactive \"task description\"\n```\n\n## Behavior\n\nThis skill invokes the Plan skill in consensus mode:\n\n```\n\u002Fstartup-harness:omc-plan --consensus \u003Carguments>\n```\n\nThe consensus workflow:\n1. **Planner** creates initial plan and a compact **RALPLAN-DR summary** before review:\n   - Principles (3-5)\n   - Decision Drivers (top 3)\n   - Viable Options (>=2) with bounded pros\u002Fcons\n   - If only one viable option remains, explicit invalidation rationale for alternatives\n   - Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan (unit\u002Fintegration\u002Fe2e\u002Fobservability)\n2. **User feedback** *(--interactive only)*: If `--interactive` is set, use `AskUserQuestion` to present the draft plan **plus the Principles \u002F Drivers \u002F Options summary** before review (Proceed to review \u002F Request changes \u002F Skip review). Otherwise, automatically proceed to review.\n3. **Architect** reviews for architectural soundness and must provide the strongest steelman antithesis, at least one real tradeoff tension, and (when possible) synthesis — **await completion before step 4**. In deliberate mode, Architect should explicitly flag principle violations.\n4. **Critic** evaluates against quality criteria — run only after step 3 completes. Critic must enforce principle-option consistency, fair alternatives, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. In deliberate mode, Critic must reject missing\u002Fweak pre-mortem or expanded test plan.\n5. **Re-review loop** (max 5 iterations): Any non-`APPROVE` Critic verdict (`ITERATE` or `REJECT`) MUST run the same full closed loop:\n   a. Collect Architect + Critic feedback\n   b. Revise the plan with Planner\n   c. Return to Architect review\n   d. Return to Critic evaluation\n   e. Repeat this loop until Critic returns `APPROVE` or 5 iterations are reached\n   f. If 5 iterations are reached without `APPROVE`, present the best version to the user\n6. On Critic approval *(--interactive only)*: If `--interactive` is set, use `AskUserQuestion` to present the plan with approval options (Approve and implement via team (Recommended) \u002F Approve and execute via ralph \u002F Clear context and implement \u002F Request changes \u002F Reject). Final plan must include ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups). Otherwise, output the final plan and stop.\n7. *(--interactive only)* User chooses: Approve (team or ralph), Request changes, or Reject\n8. *(--interactive only)* On approval: invoke `Skill(\"startup-harness:team\")` for parallel team execution (recommended) or `Skill(\"startup-harness:ralph\")` for sequential execution -- never implement directly\n\n> **Important:** Steps 3 and 4 MUST run sequentially. Do NOT issue both agent Task calls in the same parallel batch. Always await the Architect result before issuing the Critic Task.\n\nFollow the Plan skill's full documentation for consensus mode details.\n\n## Pre-Execution Gate\n\n### Why the Gate Exists\n\nExecution modes (ralph, autopilot, team, ultrawork, ultrapilot) spin up heavy multi-agent orchestration. When launched on a vague request like \"ralph improve the app\", agents have no clear target — they waste cycles on scope discovery that should happen during planning, often delivering partial or misaligned work that requires rework.\n\nThe ralplan-first gate intercepts underspecified execution requests and redirects them through the ralplan consensus planning workflow. This ensures:\n- **Explicit scope**: A PRD defines exactly what will be built\n- **Test specification**: Acceptance criteria are testable before code is written\n- **Consensus**: Planner, Architect, and Critic agree on the approach\n- **No wasted execution**: Agents start with a clear, bounded task\n\n### Good vs Bad Prompts\n\n**Passes the gate** (specific enough for direct execution):\n- `ralph fix the null check in src\u002Fhooks\u002Fbridge.ts:326`\n- `autopilot implement issue #42`\n- `team add validation to function processKeywordDetector`\n- `ralph do:\\n1. Add input validation\\n2. Write tests\\n3. Update README`\n- `ultrawork add the user model in src\u002Fmodels\u002Fuser.ts`\n\n**Gated — redirected to ralplan** (needs scoping first):\n- `ralph fix this`\n- `autopilot build the app`\n- `team improve performance`\n- `ralph add authentication`\n- `ultrawork make it better`\n\n**Bypass the gate** (when you know what you want):\n- `force: ralph refactor the auth module`\n- `! autopilot optimize everything`\n\n### When the Gate Does NOT Trigger\n\nThe gate auto-passes when it detects **any** concrete signal. You do not need all of them — one is enough:\n\n| Signal Type | Example prompt | Why it passes |\n|---|---|---|\n| File path | `ralph fix src\u002Fhooks\u002Fbridge.ts` | References a specific file |\n| Issue\u002FPR number | `ralph implement #42` | Has a concrete work item |\n| camelCase symbol | `ralph fix processKeywordDetector` | Names a specific function |\n| PascalCase symbol | `ralph update UserModel` | Names a specific class |\n| snake_case symbol | `team fix user_model` | Names a specific identifier |\n| Test runner | `ralph npm test && fix failures` | Has an explicit test target |\n| Numbered steps | `ralph do:\\n1. Add X\\n2. Test Y` | Structured deliverables |\n| Acceptance criteria | `ralph add login - acceptance criteria: ...` | Explicit success definition |\n| Error reference | `ralph fix TypeError in auth` | Specific error to address |\n| Code block | `ralph add: \\`\\`\\`ts ... \\`\\`\\`` | Concrete code provided |\n| Escape prefix | `force: ralph do it` or `! ralph do it` | Explicit user override |\n\n### End-to-End Flow Example\n\n1. User types: `ralph add user authentication`\n2. Gate detects: execution keyword (`ralph`) + underspecified prompt (no files, functions, or test spec)\n3. Gate redirects to **ralplan** with message explaining the redirect\n4. Ralplan consensus runs:\n   - **Planner** creates initial plan (which files, what auth method, what tests)\n   - **Architect** reviews for soundness\n   - **Critic** validates quality and testability\n5. On consensus approval, user chooses execution path:\n   - **team**: parallel coordinated agents (recommended)\n   - **ralph**: sequential execution with verification\n6. Execution begins with a clear, bounded plan\n\n### Troubleshooting\n\n| Issue | Solution |\n|-------|----------|\n| Gate fires on a well-specified prompt | Add a file reference, function name, or issue number to anchor the request |\n| Want to bypass the gate | Prefix with `force:` or `!` (e.g., `force: ralph fix it`) |\n| Gate does not fire on a vague prompt | The gate only catches prompts with \u003C=15 effective words and no concrete anchors; add more detail or use `\u002Fralplan` explicitly |\n| Redirected to ralplan but want to skip planning | In the ralplan workflow, say \"just do it\" or \"skip planning\" to transition directly to execution |\n",{"name":5,"level":41,"description":7,"argument-hint":42},4,"[--interactive] [--deliberate] [--architect codex] [--critic codex] \u003Ctask description>","main","92dddf7f6e7b55d1424795ce11586b05dba9d8c8","skills\u002Fralplan",3,"https:\u002F\u002Fgithub.com\u002FCheggin\u002Frequest-for-startups","https:\u002F\u002Fgithub.com\u002FCheggin","reaganhsu.com","MTS @datacurve-ai, prev. founding eng @browser-use ","2026-04-24 08:33:47",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add Cheggin\u002Frequest-for-startups --skill ralplan",{"tool":58,"command":59},"bunx","bunx skills add Cheggin\u002Frequest-for-startups --skill ralplan",{"tool":61,"command":62},"pnpm","pnpm dlx skills add Cheggin\u002Frequest-for-startups --skill ralplan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FCheggin\u002Frequest-for-startups\u002Fblob\u002Fmain\u002Fskills\u002Fralplan\u002FSKILL.md",true,[],[67,91,111,154,169,192],{"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":36},"01M6X7PHK069RZH25A3RXN5049","writer-memory","Agentic memory system for writers - track characters, relationships, scenes, and themes","https:\u002F\u002Fgithub.com\u002FCheggin\u002Frequest-for-startups\u002Fblob\u002Fmain\u002Fskills\u002Fwriter-memory\u002FSKILL.md",[],[74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90],"memory","writer","writer memory","system","characters","track","for","themes","memory system","scenes","relationships","query","export","status","validate","init","agentic",{"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},"01M6X7PC3G9228Z323X5YAKTVW","wiki","LLM Wiki — persistent markdown knowledge base that compounds across sessions (Karpathy model)","https:\u002F\u002Fgithub.com\u002FCheggin\u002Frequest-for-startups\u002Fblob\u002Fmain\u002Fskills\u002Fwiki\u002FSKILL.md",[],[93,98,99,100,101,102,103,104,105,106,107,108,109,85,110],"wiki lint","knowledge","model","llm wiki","markdown","wiki query","knowledge base","lint","sessions","karpathy","add","across","base",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":133,"publishedAt":36},"01M6X7P5XFW5C16H3JE4NFQ7MF","website-creation","Build production-quality SaaS websites with opinionated design presets. Use when creating any startup website. The user MUST pick a design style before building. Enforces shadcn\u002Fui, Figma design principles, specific CSS values per style, and anti-AI-writing. Load alongside anti-ai-writing skill. LIGHT MODE ONLY.","https:\u002F\u002Fgithub.com\u002FCheggin\u002Frequest-for-startups\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-creation\u002FSKILL.md",[117,122,125,130],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":123,"categoryName":124,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":126,"categoryName":127,"taxonomyType":128,"taxonomyTypeDesc":129},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":131,"categoryName":132,"taxonomyType":128,"taxonomyTypeDesc":129},"01JBSEEDCAT000000000000036","内容创作者",[134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153],"website creation","website","creation","when","design style","mode","brand-guidelines","full","ui","writing","design principles","only","pick","polish","audit","shadcn","figma","css","Anti-AI","design",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":36},"01M6X7P3PCEAKA2SBETXHHTNBA","visual-verdict","Structured visual QA verdict for screenshot-to-reference comparisons","https:\u002F\u002Fgithub.com\u002FCheggin\u002Frequest-for-startups\u002Fblob\u002Fmain\u002Fskills\u002Fvisual-verdict\u002FSKILL.md",[],[161,162,163,80,164,165,166,167,168],"visual verdict","verdict","visual","visual qa","structured","reference","screenshot","qa",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":183,"publishedAt":36},"01M6X7NXEWWC4NFT0ZK1RRSGES","visual-qa-pipeline","Screenshot every page with Playwright, feed to visual QA agent for design evaluation, report results to Slack. Use after every build phase to verify UI matches the chosen design preset. Integrates with the Playwright skill and the website-creation preset system.","https:\u002F\u002Fgithub.com\u002FCheggin\u002Frequest-for-startups\u002Fblob\u002Fmain\u002Fskills\u002Fvisual-qa-pipeline\u002FSKILL.md",[175,178,181,182],{"categoryNo":176,"categoryName":177,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000005","邮件与沟通",{"categoryNo":179,"categoryName":180,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},{"categoryNo":126,"categoryName":127,"taxonomyType":128,"taxonomyTypeDesc":129},[163,184,164,168,185,186,113,136,141,187,147,188,142,135,167,80,189,153,190,191],"pipeline","visual qa pipeline","slack","page","Evaluation","review","verify ui","phase",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":196,"categories":197,"keywords":198,"publishedAt":36},"01M6X7NSNW00RQ8J531F52YHV9","verify","Verify that a change really works before you claim completion","https:\u002F\u002Fgithub.com\u002FCheggin\u002Frequest-for-startups\u002Fblob\u002Fmain\u002Fskills\u002Fverify\u002FSKILL.md",[],[194,199,200,201,202,203,184,204,205],"deploy-pipeline","true","you","claim","quality","deploy","change"]