artsmc

Project management database for tracking specs, jobs, tasks, and execution. Use when Codex should run the converted pm-db workflow. Inputs: command.

Mode 2 - Structured execution with quality gates (Part 1-5) with pm-db tracking. Use when Codex should run the converted start-phase-execute workflow. Inputs: task_list_file, extra_instructions, spec_id.

Converted Claude skill for architecture-quality-assess. Use when Codex should run the converted architecture-quality-assess workflow.

Complete feature workflow - from planning to execution with PM-DB tracking. Use when Codex should run the converted feature-new workflow. Inputs: feature_description.

Use this agent when you need to design API contracts BEFORE implementation. This agent enforces contract-first API design, creates OpenAPI specifications, and defines three-tier architecture for Next.js backend APIs. Invoke in these scenarios:. Use when Codex needs this specialist perspective or review style.

Deep analysis of codebase for code duplication. Detects exact, structural, and pattern-level duplicates, generates comprehensive reports with refactoring suggestions and metrics.. Use when Codex should run the converted code-duplication workflow.

Deep analysis of codebase vs documentation alignment. Detects drift, identifies undocumented code, extracts missing glossary terms, and provides actionable recommendations without making changes.. Use when Codex should run the converted document-hub-analyze workflow.

Bootstrap a new project's documentation hub by creating the four core documentation files (systemArchitecture.md, keyPairResponsibility.md, glossary.md, techStack.md) with initial content based on codebase analysis.. Use when Codex should run the converted document-hub-initialize workflow.

Use when Mark wants large or mechanical work fanned out across his machine fleet, or wants long-running/background/remote agents monitored. Triggers on 'distribute among the fleet', 'delegate with tmux and worktrees', 'kick it off fan them out', 'offload to mac-mini, desktop just orchestrate', 'check on the agents every 5 min', 'is it done its been some hours', 'are we ready to delegate', or any dispatch to background workers. This is Mark's dispatch→snapshot→poll→escalate→checkpoint loop — fan independent work to workers (local box orchestrates), hand each a precise state snapshot, then poll on a fixed cadence with trustworthy liveness proxies, error-signature buckets, and hard stop/escalation thresholds — never blocking or assuming success.

Use at the START of anything sizable, before writing code — when Mark says 'want to work out the full plan', 'I want to do some deep research', 'lets start the planning', 'what does complete look like?', 'what tickets/tasks remain', 'how close are we / what are our current gaps', 'do we already have a harness for this', or 'is there a system we can use?'. This is Mark's front-loaded decision discipline — inventory what already exists before building, scope the gap against a concrete target, research and persist the approach as an artifact, sequence prerequisites, and bake quality bars + phase gates with human checkpoints directly into the go-ahead. It decides WHETHER and HOW to enter the execution skills (start-phase-plan, feature-new); run it first.

Use when work is genuinely ambiguous in a way that changes the plan, or big/multi-part/underspecified enough to balloon context — or when the orchestrator's window is trending toward the ~200k cliff where quality and cost degrade. Fires when Mark says 'this is a big one', 'what do you need from me before you start', 'dont drag the whole context through this', 'should we split this up', or 'keep the main thread lean' — or when one thread is doing both the planning AND the execution. This is Mark's triage-then-delegate discipline — decide fast whether real ambiguity or context cost warrants a stop, ask only the few DECISIVE questions, treat the window as a finite budget, and hand each worker a minimal scoped snapshot so the orchestrator plans and synthesizes without accumulating execution detail. Not a hard gate — small clear tasks just proceed.

Use when Mark reports a bug by pasting a raw artifact with little or no prose — a stack trace, an HTTP request/response trace (URL + method + status like 500/403/404/502), a console/React/Prisma error, a ChunkLoadError, a shell error, or a screenshot of a visual defect — or when he says things like 'still failing', 'clicking X does nothing', 'no inline editor on the rendered page', 'do we have local postgres/pgvector?', or 'identify the true error'. This is the front-to-back debugging procedure — extract the trigger and reproduction from terse input, probe whether the underlying plumbing even exists, localize by contrasting known-good vs broken, and drive to a durable root cause rather than a workaround. Reach for this BEFORE proposing any fix.

Use whenever you're about to present Mark with consequential choices, questions, or tradeoffs — structure them as a numbered or lettered menu so a bare reply counts as a full selection, and use this to read his terse picks. Triggers on one-token replies that only resolve against a labeled list you just gave ('go with B', 'lets go with 2', 'run option B', 'c one big commit'), picks carrying a rider ('option 1 and update envs when your done', '1. yes, and execute it'), multi-item sweeps answering every numbered point at once ('1. yes 2. thats fine 3. just aws 4. whats the mcp server? 5. minimal'), ranged picks with a because-clause scope-cut ('do 1-3, 4 wont be needed because...'), and Mark authoring his own numbered decision list to apply across a spec. Format choices as a menu — a bare letter is uninterpretable unless you offered the list first.

Use whenever an agent (or you) is about to claim work is done/fixed/shipped/passing, or when Mark says 'ready?', 'done?', 'did it work?', 'still failing', 'is the live URL responding?', 'check the deploy status', or wants to confirm a fix before pushing. Treat every completion claim, green CI, and passing test as UNPROVEN until the real artifact is exercised end-to-end — drive the actual running app at its real URL/UI/API, confirm the deployed revision is actually live, verify the mutating side-effect (email/queue/DB row) truly fired, gate every forward step on an explicit green signal, audit coverage across the whole surface, and reconcile against the system of record. Then name the specific residual defect with expected-vs-actual.

Use when Mark frames a feature by pointing at a concrete reference instead of describing behavior from scratch — when he names a live product as the target ('an inline editor like editor.js', 'a code editor like monaco-editor dark theme', 'much like openclaw.ai'), points at an internal subsystem as the literal spec to replicate ('the OTP from sentient-monorepo is the pattern we should match', 'use sentient-monorepo as the api source of truth'), or anchors a requirement on an external library as the structural model ('setups similar to CASL', 'building this same CASL boilerplate'). Whenever he says 'build it like THAT', 'same as X', or 'mimic/replicate X', treat the named reference as the executable spec — go observe it, extract its real behavior, and let THAT define correct rather than inventing requirements.

Use mid-flight while executing for Mark, to interpret and apply his terse steering grammar correctly. Triggers on his short directives — greenlights ('yes', 'go for it', 'do it', 'lets do it', '2 and make note of it'), autonomy grants ('you have full autonomy', 'apply it all', 'dont stop', 'run 2-3 goals on your own'), hard overrides ('no remove this', 'no replace X with Y', 'not X but Y'), re-anchoring ('remember the goal', 'get back on track', 'this looks wrong our main objectives are'), method constraints ('no just cli', 'is this not possible via X?'), and preserve-constraints ('keep the save button', 'nothing can break from previous threads'). It encodes when bounded autonomy is granted vs when a human checkpoint is required, and how to read his corrections as the spec.