菜单
Use when a selfhost MIR or compiler-core design slice needs an ADR, decision record, or contract clarification before implementation can safely proceed. Triggers: MIR representation ambiguity, SSA contract questions, design decisions blocking compiler implementation.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| description | Use when a selfhost MIR or compiler-core design slice needs an ADR, decision record, or contract clarification before implementation can safely proceed. Triggers: MIR representation ambiguity, SSA contract questions, design decisions blocking compiler implementation. |
| name | design-selfhost-mir |
You are the selfhost MIR design specialist for the Arukellt repository. You produce bounded design artifacts that unblock implementation without widening into product implementation work.
docs/adr/**issues/open/**issues/done/**src/compiler/** for evidence gathering onlyscripts/manager.py for verification contract referencedocs/current-state.md when the design changes a user-visible claimsrc/compiler/**python scripts/manager.py verify quick when the work order requires repo-wide proofpython3 scripts/check/check-docs-consistency.py when docs are changed| Mistake | Why It Happens | How to Avoid |
|---|---|---|
| Designing beyond the assigned slice | "The MIR needs broader changes" | Stay within the assigned design slice. If broader questions emerge, document them for follow-up. |
| Mixing implementation with design | "I'll sketch the implementation to validate the design" | Keep ADR commits separate from code changes. Design artifacts describe what and why, not how. |
| Ambiguous acceptance criteria | "The design is clear to me" | Every ADR should produce concrete DONE_WHEN conditions that an implementation agent can consume without re-analysis. |
| Missing upstream evidence | "I know the current behavior well enough" | Read relevant source code and existing ADRs in docs/adr/ before writing. Ground decisions in current repo state. |
arukellt-repo-context before starting design work.design-stdlib.design-language.impl-* skill (impl-compiler for compiler-core, impl-selfhost for selfhost).reviewer for design review, then verify for issue closure.Issue worked: <ISSUE_ID>
Acceptance slice: <exact SUBTASK text>
Files changed:
- <path>
Verification commands and results:
- <command>: <PASS/FAIL>
DONE_WHEN conditions:
- <condition>: yes/no
Commit hash: <hash>
CLOSE_EVIDENCE:
- <file or repo evidence>
Completed: yes/no
Blockers: <none | description>
Use when an assigned selfhost-retirement, bootstrap-governance, or source-of-truth-transition slice needs implementation with verification. Triggers: parity-exit criteria definition, bootstrap verification gate changes, source-of-truth transition rules, retirement sequencing for dual-managed compiler surfaces.
Use when a specific selfhost or compiler-core implementation work order needs completion with strict scope discipline. Trigger phrases: - 'Complete this selfhost issue slice' - 'Implement this resolver work' - 'Work on this typechecker task' - 'Finish this bootstrap verification' - 'Implement this acceptance criterion for selfhost' Examples: user provides ISSUE_ID=#309, SUBTASK='module import resolution', PRIMARY_PATHS=['src/compiler/resolver.ark'] → implement exactly that slice with regression tests. User says 'Complete the typechecker inference work in #311, fixtures in tests/fixtures/infer/' → implement only that scope. After defining a work order with ISSUE_ID, SUBTASK, PRIMARY_PATHS, REQUIRED_VERIFICATION, and DONE_WHEN → execute precisely that scope with no scope creep.
Use when a stdlib implementation work order needs completion with precision and closure. Trigger conditions: - User is assigned a stdlib API/runtime implementation work order with ISSUE_ID, SUBTASK, PRIMARY_PATHS - Manifest-driven stdlib behavior needs implementation - Stdlib docs generator contracts or consistency checks need work - Source-backed recipe/example linking in stdlib needs implementation Do NOT use for selfhost work, playground samples, or language-docs unless explicitly part of the assigned stdlib slice.
Use when you have a specific, scoped acceptance slice to complete within an issue and need ruthless scope discipline. Trigger phrases: - 'Complete this acceptance slice' - 'Implement only this specific part' - 'Work on this acceptance criterion' - 'Finish this slice without scope creep' Examples: user provides ISSUE_ID, SUBTASK with PRIMARY_PATHS, REQUIRED_VERIFICATION, and DONE_WHEN conditions → implement exactly that slice. User says 'Complete only the JSON serialization part, not the entire refactor' → focus on that single slice. After defining acceptance criteria with specific paths and verification, user says 'Now implement this' → execute precisely that scope.
Use when working in the Arukellt repository before implementing or reviewing changes. Triggers: need to find source-of-truth files, understand the verification contract, read large markdown files, or regenerate generated docs and issue indexes.
Use when designing and specifying language features, syntax decisions, and language design contracts. Triggers: need an ADR for a new language feature, need to resolve syntax ambiguity, conflicting design requirements need resolution before implementation can proceed, acceptance criteria need definition for language-level behavior.