菜单
Use when starting a new task, feature, bugfix, or refactor in a Loom project — "let's start", "new task", "working on", "implement", "begin". Ensures a board task exists with a clear scope and a sharp definition of done, then loads context before any code changes.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Apply whenever writing or editing documentation, notes, or knowledge files (vault notes, READMEs, design/architecture docs, changelogs). Enforces rewrite-in-place over append, no contradictions, bounded docs, and no hard-wrapped prose. Shipped and kept current by Loom.
Use when wrapping up work — "done for now", "wrapping up", "end session", "log this", "save progress". Records progress + decisions on the board task and leaves the work clean and resumable by the next session.
The operating doctrine for the Loom Platform operator — a friendly, user-facing workspace operator that gets a brand-new user set up and helps maintain their workspace thereafter. Load at the start of any setup-assistant session to help the user create, configure, and archive projects, define agents and profiles, pick default skills and a workflow, and act on their behalf over the curated loom-setup tool surface — confirming big or irreversible actions first. NOT a self-improving Platform Lead.
Use when resuming work or getting up to speed on a Loom task — "pickup", "continue", "what were we doing", "get back to". Reads the project board, recent git history, CLAUDE.md, and (if relevant) your living resume doc to brief the current state and a concrete next step.
The operating doctrine for a Loom lead / orchestrator (manager) session. Load at the start of any orchestrator agent to run the lead-manages-workers loop — plan, decompose, delegate, review, merge, recycle — over the loom-orchestration tools. Your agent prompt supplies the project-specifics; this is the cross-project HOW.
The operating doctrine for the Loom Platform Lead — the standing, human-driven operator ABOVE all projects. Load at the start of any platform-lead session to run the cross-project admin + self-improvement loop (create/maintain projects, agents, profiles and sessions; field manager bug-escalations; own platform-wide concerns) over the loom-platform tool surface. Your agent prompt supplies the platform specifics; this is the cross-project HOW.
| name | loom-task-start |
| description | Use when starting a new task, feature, bugfix, or refactor in a Loom project — "let's start", "new task", "working on", "implement", "begin". Ensures a board task exists with a clear scope and a sharp definition of done, then loads context before any code changes. |
Make the work trackable on the board before diving in. The board is the source of truth — one task = one focused, independently-mergeable change.
tasks_list (the loom-tasks MCP); if none matches, tasks_create
with a clear, specific title in Conventional-Commits form (type(scope): summary — lowercase
type like feat/fix/refactor, imperative summary), drawing the scope from the project's
CLAUDE.md "Commit scopes".tasks_update
body). The DoD states what proves it works — a command that exits clean, a manual repro, a
regression check. A task without a DoD isn't ready to work. If an open decision blocks pinning the
DoD, ask the human via question_ask (the Requests inbox) rather than guessing. Keep it to one
logical change; if it's really several, split it.active column (the in-progress ROLE) via tasks_update
columnKey. First, skip any card flagged held (an owner brake) or deferred (the manager
hasn't sequenced it) — don't begin work on those.git log --oneline -15, read CLAUDE.md, and read
the relevant code/notes so your change matches what's there. Reuse existing shapes over inventing
new ones.Then implement: keep the change small and matched to the surrounding code, meet the DoD, and build/ verify before reporting it done.