opc-develop
opc-develop에는 wallkop에서 수집한 skills 12개가 있으며, 저장소 수준 직업 범위와 사이트 내 skill 상세 페이지를 제공합니다.
이 저장소의 skills
definition.md 定案后的自主开发环节：AC 展开为机器可读 Case 并锁死 Oracle，先跑 RED 再实现（TDD，模型自主规划路线），harness drive 全量裁决转 GREEN，仅一次现实评审，最终以 Core-Case 冒烟投影在真实环境收口。裁决全部由项目 Harness 执行，本 skill 不携带任何裁决脚本。
产品定义设计环节：基于 brief.md 与 Demo 决策，深度整合 grill-me，从产品、技术、测试三个维度批量拷问（每轮 5-10 个问题），编写 definition.md（PD 产品底线 + TD 技术决策 + AC 验收标准，TD 首条为架构位置图）与可选的宏观架构图，交人类 review 定案后方可进入 build。取代原 prd / testcase / architect 三个环节。
不动产品定义的局部改动：无需 brief / demo / definition 任何前置输入与设计，直接 TDD 式实现并由 harness 自动验收（先红后绿、证据留痕）。改动复杂度看起来超出判定时仅提醒确认、不强制拦截，用户确认后仍可走 lite。
需求进入开发前的价值拷问环节：用第一性原理和反常识视角发散讨论、击穿需求本质，逼提需者把价值想透、想清楚，平衡复杂度与 ROI；产出 brief.md（原话愿景），按项目标准拉 feature 分支并自动推送。产品意图已经清晰时可跳过。
brief.md 就绪后的纯 vibe-coding 原型环节：基于 Harness 的 Mock 能力，在真实项目前端里用捏泥人的方式快速构建可交互、可体验、功能完整模拟闭环的 Demo，支持独立部署；不做任何门禁与测试，完全由人体感验收。产出是确认的产品决策，代码随缘。
为新项目初始化 Harness：引导提问式，根据项目需求背景逐步明确技术栈、技术标准、技术组件、虚拟化环境与架构立项决策，产出符合 harness.zh-CN.md 要求的开发环境，并以验证用例证明环境真实可用。大量技术决策需要架构师深度参与，模型不代拍板。
存量项目的 Harness 改造：先盘点现状形成差距表，再引导提问式确认迁移决策，基于存量逐步改造和迁移操作面、同构环境、文档体系与裁决能力，不推倒重来；每步以验证用例逐步点亮证明可用。
最快出代码：直接 vibe-coding，不做任何自动验收、测试或验证工作，交给人类自主验收。仅在破坏性 / 生产 / 权限 / 不可逆操作前停下请求批准。
Use when one or more human-accepted Lite or Build increments are merged to trunk and should release to production safely. Build uses fresh acceptance receipts; Lite uses test acceptance, focused evidence, matching risk checks, and the project's complete release gate. Performs fail-closed preflight, backups/rollback, runbook deployment, prod-safe regression, and a watch window. Every destructive step requires explicit human confirmation.
Use when something is wrong in production (or on the test environment): triages severity, investigates through correlation-ID logs, read-only DB queries, traces, and recent releases, produces a root-cause/blast-radius report, executes rollback, a Lite-or-Build hotfix through ship/deploy, or mitigation, and leaves an error-ledger record plus a long-term fix proposal.
Use when a verified Lite or Build increment should deploy to test, be accepted, and merge. Build keeps its approved demo/PRD/testcase, receipt, and review gates. Lite instead uses focused regression evidence, matching risk checks, and the project's complete predeploy gate without manufacturing feature artifacts. Release intent alone never upgrades Lite to Build.
Run the measured loop-engineering pass: audit ledger/usage quality, evaluate executable incident cases and crystallized rules, mine recurrence and rework, then propose verified process changes for human approval.