一键导入
starter-l1-semantic-kernel
Preserve continuity, sources and boundaries for Starter L1.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Preserve continuity, sources and boundaries for Starter L1.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when working inside a RepoKernel repository on context-aware project structure, current state, source bootstrap, memory delta, skill lifecycle, templates, audit scripts or promotion packets.
Use when a RepoKernel project has dirty, untracked, stale, duplicate or unclear files and needs a non-destructive classification before cleanup, commit, archive, ignore or owner review.
Use when a RepoKernel project must convert an approved event and persistent intent into a bounded observe-align-distill-evaluate cycle without allowing the same process to approve its own goals, actions or evolution.
Use when a project needs a higher-leverage improvement than the visible task suggests, especially under ambiguity, repeated friction, architectural impact, conflicting sources or a transferable local insight.
Use when converting project intent, supplied documents, existing repository state and environment constraints into a custom RepoKernel seed specification and a safe generation or retrofit plan.
Use when creating a new repository or retrofitting an existing repository with RepoKernel structure: AGENTS gate, CURRENT_STATE, source bootstrap, semantic kernel, process packet, templates and audit checks.
| name | starter-l1-semantic-kernel |
| description | Preserve continuity, sources and boundaries for Starter L1. |
Mission: Create a minimal L1 RepoKernel project kernel
Use this skill only inside reviewed RepoKernel proposal/staging flows. It does not grant target write authority.
When work on this project produces a useful correction, ask whether it: changes the next action, prevents a repeated error, clarifies a boundary or identifies a reusable method. If yes, propose a memory delta or project-local skill candidate with evidence and review status. If not, leave it as non-durable chat.
When a reusable invariant appears in this project, distinguish the invariant from its local incarnation. Do not copy the rule everywhere. Propose adoption only when the invariant improves this project and the owner, source, gate, validation and receipt are clear. Record why the local incarnation is useful here, and keep runtime authority, hooks, publication and target writes blocked until separately approved.
Before action, resolve acting context, state provider, active surface and write owner as separate facts. Do not infer authority from visibility, shared memory, a selected adapter or a prior packet. Adjacent surfaces remain inactive unless selected by current evidence or the owner.
At reentry, reconstruct the field before continuing. Reconcile historical instructions with current source, repository or runtime evidence and operator corrections. Classify material actions as local-only, source-remote, production-bound or external; never repeat a side effect from transcript or packet memory alone. Record validation, receipt, recovery and next legal action.
Keep only state that changes surface selection, authority, boundary, validation or next action. Treat repeated work as a routine candidate only when its trigger, inputs, outputs, owner, gate, validation and stop condition are clear. A routine proposal does not install a hook or grant runtime authority.
When the worktree or project memory contains dirty, unclear or unowned files, treat that as clarity debt. Classify before changing anything, prefer a receipt over a cleanup spree, and require explicit owner approval before delete, move, ignore or bulk normalization actions.