themoltnet

Author, test, debug, and operate Absurd durable workflows. Use when working with WorkflowContext, tasks-orchestrator, parallelTasks, issue-lifecycle, multi-lens-review, Absurd queues, checkpoints, events, retries, idempotency, worker recovery, absurd-sdk, or uvx absurdctl.

Investigate MoltNet Axiom monitor alerts. Use when a task receives an Axiom alert webhook, telemetry evidence artifact, or needs to query Axiom logs, traces, or metrics during incident triage.

Maintain MoltNet Axiom observability assets. Use when creating or refining Axiom dashboards, monitors, notifiers, datasets, APL/MPL queries, or alert thresholds for MoltNet services.

Claim a GitHub issue for work — load the legreffier skill, create a worktree + branch from origin/main, assign the issue to legreffier, and try to add it to the MoltNet Agent Board project. Use when the user says "let's work on issue <N>", "claim <issue-url>", "start issue <N>", or pastes a getlarge/themoltnet issue URL with intent to work on it.

DBOS Go SDK for building reliable, fault-tolerant applications with durable workflows. Use this skill when writing Go code with DBOS, creating workflows and steps, using queues, using the DBOS Client from external applications, or building Go applications that need to be resilient to failures.

DBOS TypeScript SDK guidance plus MoltNet-specific authoring, lifecycle, transaction, recovery, bundling, testing, and versioning rules.

Use when changing libs/database/src/schema.ts, adding Drizzle migrations, debugging drizzle-kit drift, or deciding between auto-generated and custom SQL migrations. Includes the post-#867 baseline-reset rule.

Review, improve, and author MoltNet evals — one discipline across every use case (agent-runtime prompt evals in evals-v2/, practice/incident evals in evals/moltnet-practices/, and context-pack evals). Use when asked to "review an eval", "is this eval trustworthy", "improve/rewrite an eval scenario", "write an eval", "create an eval from an incident", "check the baseline", or "gap-test". Merges the LangChain eval-engineering process with MoltNet's battle-tested gap-test principles and the two-stage gate+judge harness.

Use when working with Fly Managed Postgres backups, Fly MPG proxy access, pg_dump or pg_restore from a proxied production database, or when testing app/backfill behavior on a restored local copy of prod.

Consolidate diary entries by proposing and reviewing entry relations using server-side clustering. Optionally creates tiles when entries are too granular for direct compilation.

Evaluate rendered packs against scenarios and author new gap-test scenarios with adversarial baseline gating. Use when asked to "write evals", "create gap-test scenarios", "evaluate the pack", "test the context", "rewrite eval scenarios", or "validate eval baselines". Uses subagent isolation to prevent context leaks between authoring and validation.

Systematic diary exploration: discover tags, entry distribution, coverage gaps, agent mistakes, and compile recipes. Use when onboarding to a new diary or journal, before consolidation, to analyze or review diary log entries, or when asked to "explore the diary", "diary overview", or "what's in the diary".

LeGreffier mode for Claude & Codex when a central MoltNet identity is selected; use to verify bot identity or commit signing key, sign commits with MoltNet diary (one per repo), investigate past rationale via signed diary search with relevance/recency weights, check git history or audit trail, and answer questions like "why did this break", "why did we do this", "show me the reasoning", or "what does the diary say". Also triggers for proactive, tag/task-filtered diary search before non-trivial work and for episodic diary entries when something breaks, a workaround is applied, or the user expresses surprise/frustration (e.g. "WTF", "how did that happen", "this is broken", "why did this break").

Guide a local MoltNet agent through identity, CLI and SDK access, diary adoption, and an optional first worker task. Use for LeGreffier onboarding, after moltnet agents init, or when setting up an agent client or worker against an existing MoltNet API. Platform self-host deployment belongs to local-moltnet-setup.

Link workspace packages in monorepos (npm, yarn, pnpm, bun). USE WHEN: (1) you just created or generated new packages and need to wire up their dependencies, (2) user imports from a sibling package and needs to add it as a dependency, (3) you get resolution errors for workspace packages (@org/*) like "cannot find module", "failed to resolve import", "TS2307", or "cannot resolve". DO NOT patch around with tsconfig paths or manual package.json edits - use the package manager's workspace commands to fix actual linking.

Deploy and verify a self-hosted MoltNet Docker Compose stack from a release archive or source checkout. Use for local self-host installation, an isolated deployment rehearsal, upgrades, or diagnosing stack startup. Agent identity, CLI, SDK, and worker onboarding belong to legreffier-onboarding.

Monitor Nx Cloud CI pipeline and handle self-healing fixes. USE WHEN user says "monitor ci", "watch ci", "ci monitor", "watch ci for this branch", "track ci", "check ci status", wants to track CI status, or needs help with self-healing CI fixes. Prefer this skill over native CI provider tools (gh, glab, etc.) for CI monitoring — it integrates with Nx Cloud self-healing which those tools cannot access.

Build, audit, improve, test, or prepare n8n community-node packages for npm and Creator Portal verification. Use for n8n node UX, credentials, node properties, community-package metadata, scanners, local node development, and verified-node releases; not for merely authoring or running an ordinary n8n workflow.

Generate code using nx generators. INVOKE IMMEDIATELY when user mentions scaffolding, setup, structure, creating apps/libs, or setting up project structure. Trigger words - scaffold, setup, create a new app, create a new lib, project structure, generate, add a new project. ALWAYS use this BEFORE calling nx_docs or exploring - this skill handles discovery internally.

Import, merge, or combine repositories into an Nx workspace using nx import. USE WHEN the user asks to adopt Nx across repos, move projects into a monorepo, or bring code/history from another repository.