neo

Scope a GOAL (release / initiative / major objective) into a few coherent owned LANES — the planning front-end of the epic lifecycle. Convert goals into lanes (not scrap tickets); peers self-select lanes; the planner defines goal+lanes but never assigns a peer. Triggers: before decomposing a release/initiative/major-goal into work; when a goal needs scoping into owned streams; when work is being chased as scattered micro-tickets with no owned lanes; when tempted to skip planning OR to assign peers to lanes.

Authoritative protocol for pre-work review of epics. Six-stage gating chain — roadmap fit, approach elegance, source discussion mapping, sub-structure coherence, prescription layer, avoided-traps completeness — posted as a structured comment on the epic ticket. Per-agent-per-epic one-shot; subsequent sub pickups cite the prior review. Triggers: Use this skill when an agent is about to pick up its first sub from an unreviewed epic (per model-identity OTHER than the epic's author — you never review your own epic). Also use when a user explicitly requests an epic review, or when an epic is freshly filed and a reviewer pre-validates before any sub pickup begins. Participated in the source Discussion? The participant path narrows the chain; it never exempts it.

Closeout protocol for parent epics — answers "we resolved all epic subs, are we done now?" with a structured matrix + verdict recommendation (close / keep open / create missing subs / retire-supersede). Sibling to epic-review (which handles entry); this is the exit gate. Triggers: Use this skill when the last required sub of an epic closes, when a team member claims an epic is complete or substrate-side complete, before closing an epic as COMPLETED, or when a peer broadcasts an epic-readiness signal that needs reconciliation against parent ACs.

Authoritative protocol for authoring an Epic body — the creation-side dual of `ticket-create` + entry partner of `epic-review`/`epic-resolution`. Enforces: epic body = problem-scope + intended-solution (NOT pseudo-subs / ACs); ACs live in the SUB tickets; subs are LINKED via `update_issue_relationship` + added incrementally; the body MUST NOT hardcode a sub-list (it stales out → FAIL). Triggers: before creating an Epic (a parent issue labeled `epic`) via `create_issue`, or before decomposing one into sub-tickets.

Authoritative guide for Antigravity 2.x MCP authority, duplication forensics, UI-profile isolation, and sqlite workspace recovery. Triggers: Use when the Antigravity MCP panel spins indefinitely, MCP processes appear duplicated, sqlite workspace state throws a `__store` null error, `--user-data-dir` scope is unclear, or global `~/.gemini/config/mcp_config.json` vs workspace `.agents/mcp_config.json` ownership must be established.

Authoritative guide on how to architect, format, and structure new Anthropic Progressive Disclosure skills. Triggers: Use before creating OR modifying any `.agents/skills/**/*.md` files — Progressive Disclosure architecture (Map vs World Atlas), YAML frontmatter, skill structure. Complementary to `turn-memory-pre-flight` (load-runtime-effect dimension vs skill-shape dimension).

Post-compaction recovery runbook for reconstructing active lane state from Memory Core recency, semantic recall, session rollups, and A2A. Triggers: Use immediately after context compaction/compression, resuming a summarized session, or noticing the active lane was reconstructed from a lossy summary.

Authoring or revising a public-facing blog post (learn/blog/*.md + portal registration). Enforces hero-piece narrative arc, sourcing every external claim, killing the three over-claim flavors, and the mandatory cross-family review bar.

Authoritative protocol for signaling blocked or input-required task states. Mandates targeted A2A pings using the Task.state envelope rather than global capacity broadcasts. Triggers: Use this skill whenever your execution becomes blocked, requires explicit operator input, or encounters a failure that halts progress.

High-level umbrella router for navigating broad, cross-substrate architectural ambiguity. Triggers: Use when no narrower pre-flight clearly applies, or when work spans multiple trigger families such as new subsystems, protocols, MCP tools, or cross-substrate refactors.