moraine

Run isolated Moraine dev sandbox validation. Use when testing ingest, MCP, monitor, ClickHouse schema, source formats, stack behavior, or any change where QA must not touch the developer's host ~/.moraine install; use before reporting completion for stack-facing changes.

Help prepare and, only with explicit user approval, file a sanitized Moraine bug report for reproducible defects in Moraine itself.

Use Moraine realtime session data to inspect active agent work across harnesses when the user asks what is happening now or what another agent is doing.

Use Moraine MCP tools to recover prior agent-session context when the user refers to earlier work, decisions, failures, branches, files, or other agents.

Cut and publish Moraine releases from a version argument such as /release X.Y.Z or a request to use $moraine-dev:release. Use when Codex is asked to run Moraine's release process, bump release-managed versions, create and merge the release PR, push the vX.Y.Z tag, update GitHub release notes for a general audience, verify the release-moraine workflow, and confirm the PyPI moraine-cli package. Start or continue a Codex goal for the release.

Use Moraine MCP tools to recover prior agent-session context when the user refers to earlier work, decisions, failures, branches, files, or other agents.

Create Moraine pull requests on GitHub. Use when the branch is ready to open a PR; when the user asks to create, push, or open a PR; after local changes are committed; or when documenting user-facing features, bug fixes, performance optimizations, validation, changelog impact, or operational impact in a PR that follows repository conventions without AI attribution.

Use Moraine realtime session data to inspect active agent work across harnesses when the user asks what is happening now or what another agent is doing.

Coordinate a delegated full multi-persona code review for a Moraine PR or local change. Use when asked to review a PR, run review agents, get code review feedback, or iterate on review feedback using all CodeReview personas: elegance, idiom, correctness, completeness, security, YAGNI, and scope. Invoking this skill is an explicit request to launch reviewer subagents.

Start Moraine repository development work safely. Use when an agent takes on new code, docs, test, CI, packaging, or release work in this repo; when it must create or verify an isolated branch/worktree; when sibling agent collisions are possible; or before editing files for a Moraine contributor task.

End-to-end smoke check of the moraine MCP server. Exercises the public retrieval workflow against a live moraine stack and prints a PASS/FAIL matrix.

Review a PR through the CodeReviewCompleteness persona. Use when asked to check whether a PR fully addresses the objectives it claims to address in its title, description, cited issue, PRD, epic, acceptance criteria, or linked discussion.

Review a PR through the CodeReviewCorrectness persona. Use when asked to check whether the implementation does the job correctly, avoids bugs and regressions, preserves data and API contracts, handles relevant edge cases, and has tests that would catch the important failures.

Review a PR through the CodeReviewElegance persona. Use when asked to review code for minimal design, architectural leverage, elegant abstractions, simplification, removing unnecessary moving parts, or finding the design move that sidesteps an entire class of problems.

Review a PR through the CodeReviewIdomatic persona. Use when asked to check whether code is idiomatic for the implementation language, follows standard library and ecosystem conventions, avoids unnecessarily novel implementations, and matches established patterns in this repository.

Review a PR through the CodeReviewScope persona. Use when asked to check whether a PR stays within its intended scope, avoids crossing into unrelated topics, separates incidental cleanup from behavior changes, and keeps review lanes clear.

Review a PR through the CodeReviewSecurityReview persona. Use when asked to check whether code is safe, avoids backdoors, vulnerable dependencies, injection attacks, auth bypasses, secret leaks, unsafe file/network behavior, and other security regressions.

Review a PR through the CodeReviewYAGNI persona. Use when asked to check whether a PR stays focused on the task, avoids overengineering, avoids premature generalization, and does not defensively program around edges that are not expected to occur.

Turn a rough feature, bug, refactor, architecture, documentation, or operations idea into a ready-to-implement local plan file. Use when the user asks to crystallize, shape, refine, plan, spec, or de-risk ambiguous work before implementation; the workflow researches the codebase, public prior art, and relevant history, debates the proposed approach with subagents, and writes a final plan with no open questions.

Rewrite a moraine GitHub release body in the house format — one-sentence pitch, install block, usage-focused "what's new" sections with PR links and optional screenshots, a platform-support table, upgrade notes, and a single deduped auto-generated changelog at the bottom. Use when the user says "/release-notes v0.4.2", "polish the v0.4.2 release notes", or asks to prepare release notes for a tag. NOT auto-invoked by the model.