原始内容
The operating system for agentic engineering work.
RedSkills turns GitHub issues into reviewed PRs, remembers the operational
evidence that prevents repeated mistakes, and gives every repo a local knowledge
surface for Claude Code, Codex, OpenCode, Pi, and GitHub Actions.
RedSkills is reddb.io's plugin suite for serious code-agent workflows. It
started as a reddb.io adaptation of
mattpocock/skills: small SKILL.md
files that teach agents concrete behaviors. RedSkills keeps that core and adds
the pieces teams need when agents are doing real engineering work: issue
automation, isolated worktrees, AFK execution, governed Memory, Brain, MCP
servers, release bundles, status signals, and guardrails.
Attribution is preserved in NOTICE.
Install
Universal Installer
Recommended for normal installs and upgrades:
curl -fsSL https://raw.githubusercontent.com/reddb-io/red-skills/v2/scripts/install.sh | bash
The installer resolves the latest GitHub Release, stores it under
~/.red-skills/versions/<tag>, updates ~/.red-skills/current, detects which
supported CLIs are present (claude, codex, opencode, pi), then installs
the right surface for each host:
| Host | What the installer does |
|---|---|
| Claude Code | Registers the RedSkills marketplace and installs dev, memory, and brain. |
| Codex CLI | Registers the RedSkills marketplace and installs dev, memory, and brain. |
| OpenCode | Generates and installs OpenCode plugin modules, skills, MCP config, provider config, and TUI attention config. |
| Pi | Registers one Pi package per plugin via pi install, exposes the same skill buckets through the standard agent skills protocol. |
OpenCode installs use the published opencode-host.bundle.min.mjs asset when
available, so normal installs need node but do not need a local workspace
build. If that asset is unavailable for a pinned older release, the installer
falls back to building from source with pnpm.
Useful options:
# inspect without writing
curl -fsSL https://raw.githubusercontent.com/reddb-io/red-skills/v2/scripts/install.sh | bash -s -- --dry-run
# install only one host
curl -fsSL https://raw.githubusercontent.com/reddb-io/red-skills/v2/scripts/install.sh | bash -s -- --only opencode
curl -fsSL https://raw.githubusercontent.com/reddb-io/red-skills/v2/scripts/install.sh | bash -s -- --only pi
# pin a release
curl -fsSL https://raw.githubusercontent.com/reddb-io/red-skills/v2/scripts/install.sh | bash -s -- --version v2.6.0
# force plugin reinstall where the host supports removal
curl -fsSL https://raw.githubusercontent.com/reddb-io/red-skills/v2/scripts/install.sh | bash -s -- --force
# uninstall from every detected host
curl -fsSL https://raw.githubusercontent.com/reddb-io/red-skills/v2/scripts/install.sh | bash -s -- --uninstall
# uninstall and remove the ~/.red-skills release cache
curl -fsSL https://raw.githubusercontent.com/reddb-io/red-skills/v2/scripts/install.sh | bash -s -- --uninstall --purge
After installing, restart any already-open CLI sessions so they reload plugin
manifests. Then run /red-setup in a project from Claude Code or
OpenCode, or $dev:red-setup in Codex when the client exposes
namespace-qualified skills.
Manual: Claude Code
/plugin marketplace add reddb-io/red-skills
/plugin install dev@red-skills
/plugin install memory@red-skills
/plugin install brain@red-skills
Common dev commands become native slash commands:
/red-setup
/triage
/afk --once
/go "one concrete demand"
/dashboard
Memory and Brain skills are plugin skills:
$init
$store Decision: cache TTL is 300 seconds because upstream rate limits.
$recall cache TTL
$capture Remember this project decision...
$think What do we know about the billing migration?
Upgrade or remove:
/plugin marketplace update red-skills
/plugin uninstall brain@red-skills
/plugin uninstall memory@red-skills
/plugin uninstall dev@red-skills
/plugin marketplace remove red-skills
Manual: Codex CLI
codex plugin marketplace add reddb-io/red-skills
codex plugin marketplace upgrade red-skills
codex plugin add dev@red-skills
codex plugin add memory@red-skills
codex plugin add brain@red-skills
codex plugin marketplace remove red-skills
Codex invokes skills with $<skill>. Some clients expose plugin skills with
the plugin namespace; use that form when it appears in the skills list:
$dev:red-setup
$dev:triage
$dev:afk --once
$dev:retake #123
$memory:init
$memory:recall cache TTL
$brain:capture Save this project note...
Codex currently supports built-in footer items through tui.status_line, not a
command-backed statusline. Use $dev:afk monitor when the client exposes
namespace-qualified skills, or $afk monitor when it exposes unqualified skill
names.
Codex Manifest Maintenance
Codex manifests are generated artifacts. Do not hand-edit
.agents/plugins/marketplace.json or plugins/*/.codex-plugin/plugin.json.
Change the Claude-side marketplace/plugin manifests or plugin tree, then run:
pnpm codex:manifests
CI runs pnpm codex:manifests:check and fails when committed Codex manifests
drift from the generator output.
Pi Manifest Maintenance
Pi ships two generated artifacts that must stay in sync with the Claude-side plugin tree:
plugins/<name>/package.json— the local-path install surface (ADR 0075-era shape; consumed bypi install <path>).packaging/pi/<name>/package.jsonpluspackaging/pi/<name>/skills/— the npm publish surface (ADR 0110; consumed bypi install npm:@reddb-io/red-skills-<plugin>).
Both are generated. Do not hand-edit either. Change the Claude-side plugin manifest or the plugin tree, then run:
pnpm pi:manifests # regenerates plugins/<name>/package.json
pnpm pi:packages:build # stages packaging/pi/<name>/ from plugins/<name>/
CI runs both pnpm pi:manifests:check and pnpm pi:packages:check and fails
when either committed artifact drifts. The release pipeline runs the build
step before publishing, so a manual regeneration is only required when working
on Pi support itself.
Manual: OpenCode
OpenCode support is generated from the same plugin source tree as Claude Code and Codex. The installer writes skills, plugin modules, MCP config, provider config, and TUI attention config for OpenCode. The universal installer above is preferred for normal user-scoped installs; use the direct script when developing or when installing/removing a checkout in a specific project.
git clone git@github.com:reddb-io/red-skills.git ~/code/red-skills
cd ~/code/red-skills
# user-scoped install into ~/.config/opencode
scripts/install-opencode.sh --global
# user-scoped uninstall from ~/.config/opencode
scripts/install-opencode.sh --uninstall --global
# project-local install into the current repo
scripts/install-opencode.sh
# project-local uninstall from the current repo
scripts/install-opencode.sh --uninstall
# inspect without writing
scripts/install-opencode.sh /path/to/project --dry-run
Then run OpenCode in any configured project:
opencode .
Use /connect inside OpenCode or export one of OPENAI_API_KEY,
MINIMAX_API_KEY, or OPENROUTER_API_KEY. Generated config never stores auth
secrets. Details live in apps/opencode-host.
Manual: Pi
RedSkills ships one Pi package per published plugin on npm under the
@reddb-io scope. The packages are generated from the same Claude-side
manifests the other hosts consume, so the same skill buckets (engineering,
knowledge, productivity, misc, core) Claude Code and Codex already
expose are what Pi discovers.
The natural install is the same one-liner Pi documents for every npm package:
pi install npm:@reddb-io/red-skills-dev
pi install npm:@reddb-io/red-skills-memory
pi install npm:@reddb-io/red-skills-brain
# (optional) maintainer-only — gated by plugins.internal.enabled: true
pi install npm:@reddb-io/red-skills-internal
Updates follow the rest of the release train: pi update --all resolves the
latest matching version from the npm registry and the new skills reload on the
next session start.
For repo-scoped installs that ship with the project (so teammates pick up the same RedSkills surface on first launch), use the bundled installer:
# user-scoped install into ~/.pi/agent/settings.json (npm: surface)
scripts/install-pi.sh
# project-scoped install into <repo>/.pi/settings.json
scripts/install-pi.sh --project /path/to/your-project
# pin a specific published version (e.g. before a tagged release)
RED_SKILLS_PI_VERSION=2.75.2 scripts/install-pi.sh
# dev path: install from a local checkout (in-repo workflow)
scripts/install-pi.sh --source-dir /path/to/red-skills-checkout
# user-scoped uninstall
scripts/install-pi.sh --uninstall
# dry-run + inspect
scripts/install-pi.sh --project . --dry-run
scripts/install-pi.sh writes ~/.pi/agent/redskills-install-manifest.json (or
<project>/.pi/redskills-install-manifest.json for --project) recording each
npm: spec it registered, so a subsequent --uninstall cleanly tears down
exactly that surface. The --source-dir form records local-path specs in the
same manifest under a separate source discriminator.
Known limitations versus the other hosts:
- Pi does not run lifecycle hooks, so the Codex/Claude
SessionStart/Stophooks (the rsp interception bridge, red-fetch, command-guard, branch-lock, statusline wiring) are not active in Pi. Skills that depend on those hooks lose telemetry but stay navigable; AFK runners andnavigatorMCP servers are unaffected. - Two plugins (
memoryandbrain) ship a skill with the samename: view. Pi warns on duplicate skill names and keeps the first one registered, so installmemoryorbrainlast depending on whichviewyou want as the primary entry point. - Pi does not advertise the plugin display metadata Codex uses; the npm
descriptionfield is the only user-visible summary inpi list. - The
internalpackage is gated byplugins.internal.enabled: true(ADR 0067) the same way the Claude and Codex marketplaces expose it. The npm package is public; the gate is what keeps it inactive in non-maintainer repos.
After installing, restart any open Pi session so the new skills reload.
scripts/install-pi.sh --help documents the user/project scope split, the
--source-dir dev path, and the --uninstall flow.
No Marketplace
Older agents, local hacking, or Gemini-style skill loading can install from a checkout:
npx skills@latest add reddb-io/red-skills
For local symlinks:
git clone git@github.com:reddb-io/red-skills.git ~/code/red-skills
cd ~/code/red-skills
./scripts/link-skills.sh
Marketplace installs auto-update. npx skills and manual symlinks do not.
Verify Runners
Before a release, or after upgrading Claude Code/Codex, run:
./scripts/doctor-runners.sh
It checks plugin metadata, shell syntax, runner flags used by /afk, Codex
marketplace registration in a temporary home, and manual skill-link installs.
What Makes It Different
Issue to PR is the product. RedSkills treats GitHub Issues as the work
queue, not a side note. /triage, /to-spec, /to-tickets, /afk, /go,
/hitl, and /retake all speak the same issue-state vocabulary.
Agents work in disposable worktrees. AFK execution and interactive landing keep the primary checkout under human branch control. Work is prepared, validated, committed, pushed, reviewed, and merged through explicit gates.
Memory is evidence, not vibes. The Memory plugin stores decisions, root causes, validation records, reasoning attempts, supersession, freshness, and readiness signals so future agents can verify old claims before acting.
Brain is for human-facing knowledge. Brain captures project notes, personal
facts, sources, questions, bookmarks, typed artifacts, and cited synthesis under
.red/brain/*.
One source tree, several hosts. Claude Code, Codex, OpenCode, GitHub Actions, and MCP servers are generated from the same plugin definitions and runtime apps.
The Loop
Plan -> Spec -> sliced issues -> ready-for-agent -> isolated worktree
-> validation -> PR -> review/checks -> merge -> Memory evidence
The issue lifecycle is intentionally boring:
needs-triage -> /triage -> ready-for-agent -> /afk -> PR/merge -> closed
|
+---- blocked/spec/validation/etc.
-> ready-for-human -> /hitl or /retake
Important states:
| State | Meaning |
|---|---|
ready-for-agent |
The only issue state AFK consumes. |
running |
Timeline state while a worker owns the issue. Live state is local. |
ready-for-human |
A human decision is needed before delegation is safe. |
blocked:dependency |
Waits on req:N labels and should not page a human. |
blocked:validation / blocked:spec |
Can be requeued only after retry guidance is already decided. |
What Ships
| Plugin | Job | Use it when |
|---|---|---|
dev |
Engineering workflow: issue triage, AFK execution, worktree safety, review-gated landing, process dashboards, runner policy, and codebase orientation. | You want an agent to plan, execute, review, or ship code work. |
memory |
Governed operational memory: decisions, validations, reasoning attempts, stale-claim checks, context packs, and skill telemetry evidence. | You want agents to stop repeating old mistakes after context resets. |
brain |
Project-local knowledge: typed artifacts, personal/project facts, sources, graph connections, search, cited answers, and dashboards. | You want durable knowledge the human may ask about later. |
Maintainer-only plugin:
| Plugin | Job | Use it when |
|---|---|---|
internal |
Maintainer-only skills for operating this repository. Installable through the normal marketplace flow, but active only when plugins.internal.enabled: true is present. |
You maintain red-skills itself. |
The short version:
- Dev moves work.
- Memory improves agent execution.
- Brain preserves human-facing knowledge.
Quick Start
1. Bootstrap A Repo
Run this inside a target repository:
/red-setup
It creates and wires the RedSkills operating surface:
.red/config.yamlwith explicitplugins.<name>.enabled: trueflags.- GitHub issue labels such as
needs-triage,ready-for-agent,ready-for-human,running,blocked:*,blocked:dependency, andreq:N. - Domain docs under
.red/CONTEXT-MAP.md,.red/contexts/*/CONTEXT.md, and ADRs under.red/adr/. AGENTS.md/CLAUDE.mdblocks for agent skills and the development workflow.- RedSkills workflows such as
red-issues-needs-triage.yml. - Optional statusline wiring and primary-checkout branch guardrails.
Re-run /red-setup when adoption drifts. Run /red-doctor to inspect drift
and operational probes without changing anything, or /red-doctor --fix for the
approved, per-finding gated repair path.
2. Move Work Through Issues
/start # sharpen a plan against domain language and ADRs
/wayfinder # map work too large for one agent session
/to-spec # publish the plan as a Spec issue
/to-tickets <spec> # cut vertical implementation slices
/triage # make an issue delegable
/afk # drain ready-for-agent work in isolated worktrees
Shortcuts:
- Already have a delegable issue? Use
/afk --issues N. - Already have a spec? Use
/to-ticketsor/triage. - Hit a bug? Use
/report-bug, then/triage. - Something is urgent? Label the issue
priority:urgent; the/afkqueue promotes it ahead of every--spec/--issuesfilter.
3. Use Memory And Brain Deliberately
$init # Memory setup: markdown-only or graph
$store Decision: ...
$recall topic
$capture Long-lived project or personal context...
$search topic
$think question
Use Memory for operational evidence that helps future agents act. Use Brain for knowledge the human wants preserved, searched, and cited later.
Host Support
| Host | Surface | Notes |
|---|---|---|
| Claude Code | Marketplace plugins, slash commands, skills, hooks, MCP servers | Primary interactive host. |
| Codex CLI | Marketplace plugins, $skill invocation, MCP servers, footer integration |
Namespace-qualified skill names may appear depending on client version. |
| OpenCode | Generated .opencode/skills, plugin modules, MCP config, provider config, TUI attention config |
Installed through scripts/install-opencode.sh. |
| Pi | One npm-published package per plugin (@reddb-io/red-skills-<plugin> on npm, staged under packaging/pi/<name>/) carrying the shared skill buckets |
Installed through pi install npm:@reddb-io/red-skills-<plugin>, or via scripts/install-pi.sh for repo-scoped installs and the --source-dir dev path. |
| GitHub Actions | Reusable AFK attempt workflow and composable action | Runs one AFK attempt per issue in adopter repos. |
Plugin Boundaries
Dev
dev owns the engineering workflow: issue pipeline, AFK runtime, interactive
landing, process visibility, setup/adoption checks, codebase orientation, and
the navigator MCP server.
Core responsibilities:
- Bootstrap RedSkills with
red-setup. - Maintain issue state with
triage,to-spec, andto-tickets. - Execute delegable work with
afk, or dispatch one concrete demand withgo. - Land a hand-worked branch with
retake(the retiredshipmigrated there — ADR 0081). - Resolve human gates with
hitlor safe retries withretake.
Dev guard rails:
- When
plugins.dev.enabled: true, the dev PreToolUse proxy enforces the worktree boundary for agent shell commands:git worktree addmust target a registered lane under.red/tmp/, and branch-moving commands in the primary checkout (git switch,git checkout <branch>,git checkout -b,git switch -c,gh pr checkout) are blocked. Create branches throughgit worktree add .red/tmp/worktrees/manual/<slug> -b <branch> ...instead. plugins.dev.lock.primary-branchremains the explicit branch-lock workflow flag that setup writes for compatibility and base-pinning integrations.- The dev shell-command guard is controlled by
command_guardin.red/config.yaml. It runs from the agentPreToolUsehook, stays inert unlessplugins.dev.enabled: true, and blocks matching shell commands before execution. These repo-defined rules are additional to the built-in.red/tmpworktree boundary above.globalrules apply everywhere,mainrules apply in the primary session scope (not specifically the Git branch namedmain), andworktreerules apply in/afkand/goworktrees under.red/tmp/. Deny rules supportregex:<pattern>,prefix:<literal>,suffix:<literal>,exact:<literal>, andglob:<pattern>. Bare entries with*,?, or[are Bash globs; other bare entries match the exact command, a command prefix, or a command suffix at a shell-command boundary.command_guard.denyremains a legacy alias forcommand_guard.global.
Example policy, not a default:
command_guard:
global:
- "rm -Rf /*"
- "git stash"
- sudo
- 'regex:(^|[;&|[:space:]])curl[[:space:]].*\|[[:space:]]*sh'
main:
- "git rebase"
- "git checkout -b"
worktree:
- "git clean"
plugins:
dev:
enabled: true
Memory
memory is governed operational memory for code agents. It stores work
evidence that can make future agents safer and faster: decisions, root causes,
validation evidence, reasoning attempts, stale-claim checks, readiness,
handoffs, and skill telemetry evidence.
Memory modes:
| Mode | Storage | Best for |
|---|---|---|
markdown-only |
Plain notes under .red/memory/notes/. |
Low-risk rollout with explicit store/recall only. |
graph |
Project-local RedDB store at .red/memory/graph.rdb. |
Governed recall, provenance, supersession, readiness, context packs, Workbench, MCP/HTTP, and Skill telemetry. |
Memory is not the Personal-fact store. Personal facts belong in Brain, not Memory. Broad human-facing project knowledge belongs in Brain too.
Start with plugins/memory/README.md.
Brain
brain is a project-local knowledge repository under .red/brain/*. It stores
typed artifacts and graph connections for later search and cited synthesis.
Use Brain for:
- Personal facts, durable preferences, identity context, and relationship notes.
- Project notes, decisions, ideas, questions, sources, bookmarks, and meeting residue.
brain thinkcited answers with confidence and missing-evidence signals.brain dashboardlocal summaries and KPI-style views.- Optional outbound channel actions through the Brain channel bridge.
Start with plugins/brain/README.md.
GitHub Actions Lane
The AFK Actions lane runs one AFK attempt per issue from GitHub Actions. It is for adopter repos that want cloud execution without a local fleet.
| Layer | Artifact | Job |
|---|---|---|
| Trigger + policy | reusable-afk-attempt.yml |
workflow_call, manual dispatch, and trust gate. |
| Execution | .github/actions/afk-attempt |
Sets up Node, runner CLI, auth env, and invokes the AFK launcher. |
| Runtime distribution | afk.mjs + the @reddb-io/red-skills npm package |
Resolves the versioned dev bundle matching the checked-out red-skills ref via npm (ADR 0091), cache-first. |
Adoption paths:
- Turnkey caller: install or copy an
rs-afk-attempt.ymlcaller that wires issue/manual triggers toreddb-io/red-skills/.github/workflows/reusable-afk-attempt.yml@v2. - Composable action: use
reddb-io/red-skills/.github/actions/afk-attempt@v2from your own workflow.
Pin @v2 to track the latest compatible v2 release. Pin a SHA when the caller
needs a fully immutable action/runtime pair.
Workflow naming convention:
| Prefix | Meaning |
|---|---|
reusable-* |
Reusable workflow_call workflow referenced by uses:; never copied into adopters. |
rs-* |
A caller that instantiates a reusable-* workflow with concrete triggers/inputs. |
red-* |
Standalone RedSkills workflow; internal CI or verbatim copy-installable. |
Full guide: AFK Actions lane.
Repo Layout
| Path | Purpose |
|---|---|
plugins/dev |
Plugin definition, skills, hooks, scripts, MCP config, and docs for engineering workflow. |
plugins/memory |
Plugin definition and skills for governed operational memory. Runtime source lives in apps/memory. |
plugins/brain |
Plugin definition and skills for Brain. Runtime source lives in apps/brain. |
plugins/internal |
Maintainer-only plugin definition and skills for operating this repository. |
apps/dev |
AFK, landing, dashboard, triage, runner, release/channel, and workflow runtime code. |
apps/memory |
Memory CLI, graph operations, Workbench, MCP/HTTP surfaces, evals, and diagnostics. |
apps/brain |
Brain CLI, store, MCP server, dashboard, channel bridge, and artifact logic. |
apps/code-nav |
LSP-backed MCP server used by the dev plugin. |
apps/opencode-host |
Adapter that emits OpenCode config, skills, hooks, MCP passthrough, and statusline/toast integration. |
apps/red-browser |
Browser CLI: opens a local annotation bridge for HTML artifacts, long-polls human feedback, and enforces the layout-audit gate. |
packages/shared |
Shared runtime helpers for plugin gates, bundle fetching, args, logging, and channels. |
packages/browser-bridge |
Local CLI-to-browser annotation bridge: injects an annotation SDK into HTML artifacts and long-polls for human feedback and layout-audit results. |
packages/cdp-driver |
CDP-based live-app driver for red-browser: connects to Chrome via DevTools Protocol, captures a11y-tree snapshots, and streams console/network events. |
packages/build-info |
Shared runtime build metadata helpers consumed by bundled apps. |
packages/red-castle |
AFK execution substrate (vendored submodule, @reddb-io/red-castle): sandcastle fork that owns per-attempt worktree isolation, agent spawning, and signal detection. |
packaging/npm |
The publishable @reddb-io/red-skills npm package (outside the pnpm workspace): built plugin bundles plus the three red-skills-* bin shims. The v2 client transport (ADR 0091). |
.red |
RedSkills' own project configuration: context map, glossaries, ADRs, issue-tracker docs, and agent rules. |
.github/workflows |
Release, CI, upstream watch, issue automation, PR review, and reusable AFK attempt workflows. |
Installed plugin trees are definitions and launchers. Runtime bundles are built
from apps/* and shipped inside the @reddb-io/red-skills
npm package (ADR 0091) — one tarball carrying the dev, memory, and brain
JS bundles plus the red-skills-dev / red-skills-memory / red-skills-brain
bin shims. Session-start launchers resolve the version-pinned package via npm
(npx -y @reddb-io/red-skills@<pin> semantics), cache-first, and integrity is
npm's own tarball shasum — no GitHub-release download and no client-side
signature step. The Memory/Brain native red engine binary is the one
per-platform artifact that cannot ride in the tarball; those plugins resolve it
separately at runtime.
Configuration
Per-repo RedSkills config lives in .red/config.yaml. The canonical written
form is namespaced under plugins.<name>.*.
Minimal dev activation:
plugins:
dev:
enabled: true
lock:
primary-branch: true
Example runner/model config:
plugins:
dev:
enabled: true
afk:
models:
opencode:
think:
model: minimax/MiniMax-M3
Model defaults and escalation rules are documented in
model-tier-policy.
The runtime source of truth is CONFIG_DEFAULTS in
apps/dev/src/core/config.ts.
Operator-declared pre-merge checks (backpressure):
plugins:
dev:
afk:
backpressure:
- pnpm lint
- cargo fmt --check
afk.backpressure is an ordered list of shell commands run in the worker-branch
worktree after the implicit feedback gate (test/typecheck/lint/build) passes on
the DONE path. Any non-zero command blocks the merge and parks the issue exactly
like a feedback failure. When the list is non-empty, every executed check — pass
and fail alike — is also rendered as a single aggregated, non-blocking COMMENT
PR review, so the PR carries a legible evidence ledger without adding a new gate.
House rules:
- Labels are kebab-case or
prefix:value:needs-triage,ready-for-agent,ready-for-human,priority:urgent,blocked:dependency,spec:42. - RedSkills-managed workflows use role prefixes:
red-*,reusable-*, orrs-*. - Issues and Specs live on GitHub Issues.
- Project artifacts live under
.red/. - Use SSH git remotes for AFK-managed repositories.
- Do task work in isolated worktrees; the primary checkout's branch is for the human to control.
Skill Map
This is a map, not a replacement for the skill files. Open the linked
SKILL.md before using a skill in a new context.
| Area | Skills |
|---|---|
| Dev setup and issue flow | ask-red, red-setup, red-doctor, start, wayfinder, to-spec, to-tickets, triage, report-bug |
| Dev execution and landing | afk, go, manager, implement, tdd, verify, ground-truth, diagnose, hitl, retake, resolving-merge-conflicts |
| Dev operations and understanding | dashboard, audit-skills, daily-review, red-gains, context, zoom-out, improve-codebase-architecture, review-adrs, model-tier-policy, red-statusline, prototype, code-review, curate |
| Dev knowledge, productivity, and utilities | research, reflect, ff, handoff, write-a-skill, branch-lock, git-guardrails-claude-code, migrate-to-shoehorn, setup-pre-commit |
| Memory | init, store, recall, ingest, extract, context-status, skills-status, health, improve-skills, doctor, export, view, wiki-init, wiki |
| Brain | capture, search, think, status, view |
| MCP servers | castle, navigator, memory-mcp, brain |
Development In This Repo
Install dependencies:
pnpm install
Common checks:
pnpm build
pnpm typecheck
pnpm test
pnpm bundle
./scripts/doctor-runners.sh
The workspace is managed by turbo and
pnpm-workspace.yaml. Root scripts intentionally cover
the runtime apps and shared packages while excluding unrelated heavy packages
where needed.
Releasing
Releases run on changesets in two
halves (ADR 0121). Nothing pushes a commit to main — the version bump is a
reviewed PR like any other.
- Land your change with a changeset. Run
pnpm changeset, pickpatch/minor/major, describe the change in one consumer-facing line, and commit the generated file under.changeset/. A change that ships without one accumulates no bump and never releases. - red-release.yml maintains the Version
Packages PR. On every push to
mainit collects the pending changesets and opens/updates achore(release): version packagesPR. That PR runspnpm release:version—changeset versionplusscripts/sync-version.mjs, the single writer (ADR 0040) that carries the version into the rootpackage.json, the Claude and Codex plugin manifests, and the Pi manifests.pnpm version:sync:checkfails CI if any of them drifts. - Merging that PR cuts the tag.
mainnow has no pending changesets and a version no tag points at, sored-release.ymltagsvX.Y.Z. - red-publish.yml publishes the tag.
It builds the bundles, stages them into the
@reddb-io/red-skillsnpm package, runs the real packaged client against the packed tarball as a producer/consumer contract check,npm publishes, smokes the published package from the registry, cuts the GitHub Release with the assets, and moves the matching major tag such asv2so reusable workflows pinned to@v2keep advancing.
The publish job runs in the GitHub environment named red-release. Repository
settings must keep that environment protected with required reviewers, because
approval is the gate before the job publishes release assets or moves the major
tag. Once an approved reviewer approves the environment deployment, the publish
continues without any extra manual step.
Publishing defers while any open issue carries the running label (an /afk
fleet is mid-iteration); an hourly schedule retries the newest tag that has no
GitHub Release yet, and every stage is idempotent so the retry resumes rather
than conflicts.
License
Apache-2.0. See LICENSE. See NOTICE for upstream MIT attribution and bundled runtime notices.