loom

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.

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.

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.

The cross-project doctrine for writing, reviewing, and integrating rigorous multi-perspective deep-dive research notes in an Obsidian history/geopolitics vault — source tiers, the blocklist, hedging contested claims, the credibility-laundering trap, the note format, and cross-linking + Wikimedia imagery. Load in any research project's deep-dive, orchestrator, or integration agent (alongside /worker or /orchestrate).

The operating doctrine for a Loom worker session — a session dispatched by a manager to implement ONE assigned task on an isolated worktree branch. Load at the start of any worker (Dev / Bugfix / Deep-Dive / etc.) agent. Your agent prompt and kickoff supply the task and its project-specifics; this is the cross-project HOW.

Apply when designing, building, or reviewing web UI / frontend — visual polish, typography, color, layout, spacing, motion, accessibility, and UX copy. Use to avoid the generic "AI default" look and to make deliberate, restrained design choices. Shipped and kept current by Loom.

The operating doctrine for the Loom Platform Auditor — a scheduled, read-mostly transcript reviewer with three narrow daemon-local writes. Load at the start of any platform-audit session to scan recent session transcripts across projects for Loom bugs, agent friction, vague skill/prompt instructions, and recurring prompts worth saving as presets — filing structured, deduped findings onto the Platform backlog and emitting preset suggestions. Your agent prompt supplies the cadence/scope specifics; this is the cross-project HOW.

How Loom agents should use Codescape (the code-graph MCP) when a project exposes it — the graph for structure, coordinates, and reachability (orient the shape, get exact file:line, ask "what could render / what scenarios are possible"), then a small number of targeted reads at those coordinates. NOT a nicer index to grep from; do not re-orient by reading. Shipped and kept current by Loom.

The operating doctrine for a Loom thought-partner / ideation session — brainstorm and pressure-test ideas WITH the owner, research them rigorously, and turn only the ideas that survive into well-scoped board cards. Load at the start of any ideation / sparring-partner agent. Anti-sycophantic by design: it disagrees by default, keeps divergent and convergent thinking separate, and files a crisp card only for ideas that clear explicit criteria. Your agent prompt supplies the project specifics; this is the cross-project HOW.

The operating doctrine for the Workspace Auditor — a read-mostly, suggest-only reviewer of the USER'S OWN workspace (their sessions, agents, agent prompts, and skills) for their workflow quality. Load at the start of any workspace-audit session to scan recent session transcripts for vague or ambiguous instructions in the user's own agent prompts/skills, and recurring prompts worth saving as one-click presets — suggesting improvements as board cards on the user's home and emitting preset suggestions. It does NOT hunt Loom bugs and does NOT touch Loom's own development.

Use to orient in an unfamiliar codebase with graphify, a local tree-sitter code graph — "what does this symbol touch", "how do these two connect", "trace this call chain". Opt-in (the human installs graphify once). A forward-orientation aid, NOT a reliable reverse-dependency tool. Shipped and kept current by Loom.