菜单
Shared development doctrine for aicoder-opencode and its target repos — plugin ownership, overlay split, shared base vs product boundaries
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | control-plane-development-base |
| description | Shared development doctrine for aicoder-opencode and its target repos — plugin ownership, overlay split, shared base vs product boundaries |
| user-invocable | false |
| models | ["ollama-cloud/glm-5.1","ollama-cloud/kimi-k2-thinking","ollama-cloud/minimax-m2.7"] |
| routing_role | architect |
| routing_complexity | medium |
Shared development base for product repos that consume the aicoder-opencode
control plane.
Use this skill when work is about:
aicoder-opencode versus a product repoaicoder-opencode.aicoder-opencode owns the shared plugin and shared skill sources.src/plugins/..agents/skills/..opencode/plugins/
and .agents/skills/.dr-repoletta-workspaceaicoder-opencodeMatch caution to reversibility and blast radius. Approval granted once is scoped to that one action, not a standing license.
Free to do without asking:
Confirm first (state the exact command, wait for a yes):
git push, especially to shared branchesgit reset --hard, amending published commitsOn obstacles, find the root cause. Do not use destructive shortcuts (--no-verify, wiping state, deleting lock files) to make an error disappear. Unfamiliar files or branches may be in-progress work — investigate before overwriting. Resolve merge conflicts, do not discard them.
Memory records capture what was true at one point. Before acting on a remembered fact about code — file paths, function names, exported symbols, flag names, config keys, line ranges — verify it against current state by reading the file. On conflict, trust what you observe now: update or delete the stale memory and, if still useful, save a fresh record. Never let a remembered fact override a current read.
Use when asked to work in a continuous loop until done or truly blocked. Orchestrates pickup, planning, TDD execution, implementation waves when needed, debugging side-chains, verification, and resume behavior.
Use before planning when a feature or change request is underspecified. Resolve high-impact ambiguity around scope, consumers, security, failure handling, and acceptance criteria before writing the implementation plan.
Use for both preparing work for review and responding to review feedback. Keep review evidence local, concrete, and scoped to the real contract. Verify technically before agreeing or changing code.
Use before implementation. Merge design discovery and plan writing into one DR-specific flow: identify the consumer, inspect the repo, debate boundaries with partner and combatant, and produce an execution-ready plan that hands off cleanly into DR-native tasks, TDD, and implementation waves.
Use for the last mile: rerun verification, inspect diffs, commit or push if requested, and perform local docker-compose checks when needed. This is the DR local-tools replacement for MCP-style finish/deploy carryovers.
Use after planning and before implementation when you need a concrete, dependency-ordered task list. Turn the DR feature spec and plan into independently testable task slices with exact file paths and verification commands.