Skip to main content
Glama
Sign In
junai-mcp

junai-mcp

by saajunaid
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

caddis — a Claude Code harness

License: MIT

Browse every command, skill, agent and hook -> saajunaid.github.io/caddis-plugin — the reference site, rebuilt on every publish.

caddis is a Claude Code harness — a plugin (plus a shared pool of skills, subagents, slash-commands, and hooks) that makes a single Claude Code session dramatically more capable and much harder to derail. It's agent-agnostic: the same pool is exported to other AI CLIs (Codex, Antigravity, Copilot), and CLAUDE.md↔AGENTS.md are mirrors so every agent reads the same conventions.

Before you start

You need

Why

Claude Code, installed and signed in

caddis is a plugin for it

Python 3.11+ on PATH

the hooks and the cross-review tool are Python

Git

several commands read repository state

(optional) an API key for DeepSeek or GLM

only for cross-vendor review and the OSS lanes

Honest about the platform: caddis is developed and used daily on Windows with PowerShell. The hooks are pure Python and cross-platform, and the skills, commands and agents are plain markdown that work anywhere — but some launchers ship as both .ps1 and .sh, the deployment skill is Windows-specific, and the publishing machinery (sync.ps1) is PowerShell-only. Nothing here is hostile to macOS or Linux; it is simply less travelled, so expect rough edges and please report them.

Related MCP server: CodeMentor-AI

Your first five minutes

claude plugin marketplace add saajunaid/caddis-plugin
claude plugin install caddis@caddis

Then, in a Claude Code session, confirm it actually loaded:

/caddis:version

If that prints a version, you are installed. From there, the shortest path to seeing what caddis is for:

Try this

What it does

/caddis:feature-plan add CSV export

writes a phased, TDD-structured plan to .caddis/plans/ — the durable spine the rest of the harness reads

/caddis:implement <plan>

executes that plan phase by phase, committing each, and stops only at a real boundary

/caddis:cross-review

has a different vendor's model review your diff, because a same-vendor reviewer shares your blind spots

/caddis:handoff

writes the resume doc, so the next session starts with zero re-discovery

Everything else is optional. If you only ever use feature-plan → implement → cross-review, you have most of the value.

This repository is the published marketplace mirror: it hosts the caddis and caddis-extras Claude Code plugins, the portable per-harness bundles under bundles/, and the shared pool. It is generated and pushed by the caddis authoring repo's exporter — issues are welcome here, but code changes land upstream and are synced in.

Install (Claude Code)

# 1. Register this repo as a plugin marketplace (once)
claude plugin marketplace add saajunaid/caddis-plugin

# 2. Install the core plugin (always-on, lean context)
claude plugin install caddis@caddis

# 3. (optional) Add the long-tail skill library — cloud/data/media/etc. Disabled by default,
#    so it costs zero always-on context until you enable it.
claude plugin install caddis-extras@caddis

Then, in any repo:

/caddis:setup-project-ai     # deploy the harness into the project

A normal working loop looks like:

/feature-plan      # (or /prd first) → writes .caddis/plans/<slug>.md, the durable spine
/implement         # executes the plan phase-by-phase, TDD, commit per phase
/ship              # express lane: commit → push → CI (hotfixes); feature work: /ship-pr then /ship-merge
/handoff           # ALWAYS end a session with this — writes the resume doc

The one habit that matters most: end every session with /handoff. It writes .caddis/relay.md, which is re-injected automatically at the next session start — you resume with zero re-discovery instead of a cold, forgetful session.

See USERGUIDE.md for the full command/skill/hook reference and the mental models.

What you get

  • Slash-commands — /feature-plan, /prd, /implement, /tdd, /ship · /ship-pr · /ship-merge, /handoff, /kb, /digress · /resume, /cross-review, /usage-review, /mermaid-db · /excalidraw-db, /setup-project-ai, /migrate-dir.

  • Subagents — lean, own-context helpers: anchor (evidence-first verification), code-reviewer, preflight (plan-vs-codebase validation), tester, debug, codebase-audit, security-analyst, data-engineer, sql-expert, knowledge-transfer.

  • A four-layer memory model — session relay (relay.md), automatic Dream Memory (memory.jsonl), a per-repo knowledge base (.caddis/kb/ + DOC-MAP.md), and cross-repo memory.

  • Hooks & safety — a PreToolUse guard for secret/destructive writes, auto-lint on edit, and the SessionStart/Stop hooks behind relay + memory.

  • Tiered skills — the core dev set ships in caddis; the long tail (cloud, data, media, productivity) lives in caddis-extras, off by default.

Installing outside Claude Code (Codex, Antigravity, …)

The knowledge layer (skills + AGENTS.md conventions) works in any harness. Per-harness bundles are published under bundles/ and installed with caddis-init:

# from a checkout of this repo (the installer ships in plugin/scripts/)
python plugin/scripts/claudster_init.py --target codex        --dest /path/to/project
python plugin/scripts/claudster_init.py --target antigravity  --dest /path/to/project

Safe by design: a sha256 manifest tracks what the installer wrote; re-runs update only unmodified files, and anything you edited locally is reported as a conflict, never overwritten.

Repo layout

Path

What it is

.claude-plugin/marketplace.json

The marketplace manifest (caddis + caddis-extras)

plugin/

The core caddis Claude Code plugin (agents, commands, hooks, core skills)

plugin-extras/

The caddis-extras skill library (disabled by default)

bundles/

Portable per-harness exports (codex, antigravity) for caddis-init

.github/

The shared pool: skills, agents, prompts, instructions, tools

sync.ps1, export_runtime_resources.py, validate_pool.py

The build/sync machinery

A note on names

caddis was previously published as claudster (and, before that, this repo hosted the junai Copilot pipeline — see the pre-1.2 entries in CHANGELOG.md). Repos set up under the old name have a .claudster/ artifact dir; everything reads both .caddis/ and .claudster/ and writes where the repo already lives, so nothing breaks. Run /caddis:migrate-dir when you want a repo converted. The ~/.claudster/ user scope (keys, install records) is permanent.

License

MIT. The published plugin bundles (caddis / caddis-extras) carry the same license in their manifests.

Available Tools

11 tools
get_pipeline_statusB

Return current pipeline status and best-effort next transition summary.

Inputs: no named parameters. Returns: object

notify_orchestratorC

Record stage completion and ask pipeline-runner for deterministic next transition.

Inputs: result_status (required), stage_completed (required), artefact_path, result_payload. Returns: object

pipeline_initA

Initialise a new pipeline state file from the template.

Requires confirm=True to proceed — this prevents accidental invocation mid-run. Use when starting a brand-new feature or hotfix pipeline.

If a pipeline-state.json already exists, it will be overwritten.

_bypass_active_check is an internal flag used by pipeline_reset to skip the active-pipeline guard. Do not set this from user-facing calls.

Inputs: feature (required), project (required), type, confirm, +1 more. Returns: object

pipeline_resetA

Reset the current pipeline state and start a new pipeline run.

Identical to pipeline_init but semantically signals resetting an existing pipeline rather than creating a fresh one. Requires confirm=True. Use when a pipeline has closed and the user wants to start the next feature, or when explicitly restarting a failed/stale pipeline.

Inputs: feature (required), project (required), type, confirm. Returns: object

replay_stageA

Reset a single stage to not_started for re-execution without clearing the pipeline.

Only available in supervised mode — too risky for autopilot/assisted. Cannot replay a stage if a downstream stage has already completed (must replay the chain from that point).

Preserves _notes for continuity. Increments the stage's retry_count. Writes a record to _notes._replay_log[].

Inputs: reason (required), stage_name (required). Returns: object

run_commandA

Execute a shell command in the workspace root and return stdout, stderr, exit code.

Use this for running tests (pytest, playwright), linters (black, ruff), formatters, build steps, or any other shell command the pipeline needs to execute hands-free. Intended for use by pipeline agents, not general chat.

Windows note: Do NOT use pytest-xdist parallel flags (-n auto, -n N) in commands passed to this tool. Worker subprocesses inherit stdout/stderr pipe handles and can prevent the tool from returning if a worker exits abnormally. Use plain pytest tests/ -q instead.

Inputs: command (required), timeout, max_output_chars. Returns: object

satisfy_gateC

Set a supervision gate to satisfied (true).

Inputs: gate_name (required). Returns: object

set_pipeline_modeB

Set the pipeline mode to supervised, assisted, or autopilot.

Inputs: mode (required). Returns: object

skip_stageA

Skip the current pipeline stage and advance to the next one.

Use when a stage is not needed for this task (e.g. skipping security review for a docs-only change, or skipping prd for a small bug fix). Only the current stage can be skipped. Gates that the skipped stage would have satisfied are auto-approved.

Returns the result including new current_stage and progress_line.

Inputs: reason (required), stage_to_skip (required). Returns: object

update_notesA

Merge key-value pairs into _notes in pipeline-state.json.

This is the ONLY correct way to write _notes.* fields. Do not use editFiles for _notes — all pipeline-state writes must go through MCP tools to maintain a single authoritative writer and prevent concurrent-write conflicts.

Performs a shallow merge at the top level of _notes: each key in updates replaces the corresponding key in _notes (or creates it if absent). Keys not present in updates are left unchanged.

Inputs: updates (required). Returns: object

validate_deferred_pathsC

Validate deferred item file paths and attempt path correction where possible.

Inputs: deferred_items (required). Returns: object

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    Deploy Server
    One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

    TDQS

    A3.7/5.0

    Scored across 11 tools

    Disambiguation5/5

    Each tool targets a distinct pipeline function (init, reset, status, orchestration, stage manipulation, command execution, notes, path validation). No two tools overlap in purpose.

    Naming Consistency5/5

    All tools use consistent snake_case verb_noun pattern (e.g., get_pipeline_status, notify_orchestrator, replay_stage). No mixing of conventions.

    Tool Count5/5

    11 tools is well-scoped for a pipeline management server, covering all core operations without being excessive or sparse.

    Completeness4/5

    Tools cover the full pipeline lifecycle and key operations. Minor gap: no tool for listing pipeline stages or history, but the set is largely complete.

    Resources

    Related MCP Connectors

    Related MCP Servers