메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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 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.
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 | arukellt-repo-context |
| description | 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 this skill at the start of Arukellt work when repo-specific operating rules matter.
Read these in order when relevant:
docs/current-state.md for current user-visible behaviorissues/open/index.md for the active work queueissues/open/dependency-graph.md for dependency orderingissues/done/ for completed tracked workdocs/adr/ for design rationalescripts/manager.py for the verification contractscripts/gen/generate-docs.py for generated docs behaviorFor large markdown files, prefer markdive over loading the whole file.
npx markdive dive <file> --depth 2
npx markdive dive <file> --path <section-id> --depth 2
npx markdive read <file> --path <section-id>
Use dive first, then narrow with --path, then read only the section you need.
| Mistake | Why It Happens | How to Avoid |
|---|---|---|
| Reading entire large markdown files | "I need to see the full context" | Use markdive instead: npx markdive dive <file> --depth 2 first, then drill down with --path. |
| Hand-editing generated docs | "It's faster to just fix this one line" | Generated docs should be regenerated, not hand-maintained. Modify the generator or manifest input instead. |
| Trusting old roadmap prose | "The README describes the architecture" | Use docs/current-state.md as the behavior contract, not roadmap prose or stale notes. |
| Skipping verification | "The change is too small to verify" | Always run python scripts/manager.py verify quick at minimum, even for small changes. |
| Forgetting to regenerate indexes | "I only moved one issue file" | Run python3 scripts/gen/generate-issue-index.py after any issue file move or status change. |
impl-*, design-*, reviewer, or verify skill to establish repo context.impl-* or design-* skill.reviewer for close review, then verify for issue closure.python scripts/manager.py verify quickpython scripts/manager.py verifyIf behavior changes and generated docs or issue indexes are affected, run:
python3 scripts/gen/generate-docs.py
python3 scripts/check/check-docs-consistency.py
python3 scripts/gen/generate-issue-index.py
ig for code search