Current version: 0.3.2
Stop AI agents from shipping plausible wrong work.
Krypton is the goal-based planning and proof gate for running Claude Code, Codex, and other AI coding agents against production-grade codebases.
The failure mode Krypton is built for is not bad syntax. It is the right-looking feature that compiles while living on the wrong layer, inventing a second source of truth, skipping cutover, or claiming success without proof from the real path.
Krypton forces the plan before the code:
- truth owner
- contract boundary
- displaced path
- cutover decision
- acceptance evidence
- review gates
Built for /goals, equivalent goal-based agent workflows, Claude Code
skills/plugins, Codex skills, and operators who need agent speed without letting
the codebase rot.
- New beta: VPS Codex setup (
krypton-vps-codex-app): a guided workflow for using a Linux VPS as the remote machine for Codex App work, including VPS readiness questions, SSH aliases, GitHub repo access, local config choices, Codex CLI auth, port forwarding, and proof checks. - Krypton planning (
krypton-planning): turns a request into a goal package with the truth owner, boundary, cutover decision, task plan, review gates, and acceptance evidence. - Krypton execution (
krypton-execution): keeps an approved plan on track while the main agent implements, verifies, and records proof. - GitHub Action beta: checks pull requests for the goal-package evidence Krypton expects before non-trivial code changes ship.
Jump to: Install | Skills And Beta Workflows | VPS Setup Workflow Beta | GitHub Action Beta
Modern agents can create weeks of architectural debt in one enthusiastic session. Krypton turns "build this" into an operational contract before the agent touches code:
- what product or engineering outcome the work serves
- what current behavior is replaced, redirected, deleted, or demoted
- who owns the truth
- what contract crosses the boundary
- what evidence proves the result from the target person's perspective
- what kill criteria prevent duplicate paths from living forever
That contract is what lets an operator keep using agents on production systems without letting the codebase become a pile of current-looking alternatives.
Krypton is best used with /goals or any equivalent goal-based agent workflow.
It is not meant to be a one-shot "please implement this" prompt.
The planning session creates the durable handoff:
docs/goals/<goal-slug>/PLAN.md
docs/goals/<goal-slug>/GOAL.md
docs/goals/<goal-slug>/EVIDENCE.md
PLAN.md is the source plan. GOAL.md is the compact /goal prompt.
EVIDENCE.md is where execution records the actual proof from the real command,
artifact, payload, browser state, trace, or operator-visible result. Start the
execution session with the GOAL prompt, then load krypton-execution so the
main agent preserves the plan's ownership, cutover, review, and evidence gates.
If your harness does not have /goals, paste the contents of GOAL.md into a
fresh Codex or Claude session. The shape still works.
Use the open skills CLI when you want Krypton installed into supported agent skill directories:
Codex only:
npx --yes skills add jturntdev/krypton --skill '*' --agent codex --copy -yClaude Code only:
npx --yes skills add jturntdev/krypton --skill '*' --agent claude-code --copy -yThat installs every Krypton skill for the named agent only. If you want Codex,
Claude Code, OpenCode, or another agent together, run the command without
--agent ... and use the interactive selector:
npx --yes skills add jturntdev/kryptonSee the package page:
https://skills.sh/jturntdev/krypton
This repo ships a Codex marketplace file at .agents/plugins/marketplace.json.
For Codex clients that support repo marketplaces:
codex plugin marketplace add \
"https://github.com/jturntdev/krypton.git" \
--ref "main" \
--sparse ".agents/plugins" \
--sparse ".codex-plugin" \
--sparse "assets" \
--sparse "skills"
codex plugin install krypton --source kryptonUse the plugin route when you want Claude Code to manage Krypton as a plugin:
/plugin marketplace add jturntdev/krypton
/plugin install krypton@krypton-dev
/reload-plugins
Claude Code namespaces plugin skills, so invoke them as:
/krypton:krypton-planning
/krypton:krypton-execution
This repo includes the Claude plugin files Claude Code expects:
.claude-plugin/plugin.json
.claude-plugin/marketplace.json
skills/krypton-planning/SKILL.md
skills/krypton-execution/SKILL.md
Use manual install when you want the skills available as personal Claude Code skills without the plugin marketplace:
git clone https://github.com/jturntdev/krypton.git
mkdir -p ~/.claude/skills
cp -R krypton/skills/krypton-planning ~/.claude/skills/
cp -R krypton/skills/krypton-execution ~/.claude/skills/Manual personal skills invoke without a plugin namespace:
/krypton-planning
/krypton-execution
For Codex skills:
git clone https://github.com/jturntdev/krypton.git
mkdir -p ~/.codex/skills
cp -R krypton/skills/* ~/.codex/skills/Stable skills:
krypton-planning: turn a request into an outcome contract, architecture slice, task plan, evidence gate, and/goalhandoff prompt.krypton-execution: execute an approved plan without drifting from ownership, cutover, or proof requirements.
Beta workflow:
krypton-vps-codex-appbeta: guide a user through setting up a Linux VPS as a Codex App SSH host, including VPS provisioning questions, SSH aliases, GitHub repo access, local config choices, Codex CLI auth, port forwarding, and proof checks.
The beta workflow points at where Krypton is going: not just plans and review gates, but repeatable operator workflows that help a user move from local agent work to durable remote development without hiding the security, credential, and proof decisions.
- Load
krypton-planningwith a feature request, bug, refactor, migration, or architecture goal. - The agent produces a goal package:
docs/goals/<goal-slug>/PLAN.md
docs/goals/<goal-slug>/GOAL.md
docs/goals/<goal-slug>/EVIDENCE.md
PLAN.mdis the full implementation plan.GOAL.mdis the short/goalprompt or handoff prompt for the next session.- Paste or run the
GOAL.mdprompt in Codex or Claude. - Pair it with
krypton-executionwhen you want the main agent to use the same ownership, cutover, review, and evidence discipline. - Finish only when the acceptance evidence is captured from the real route,
artifact, payload, trace, browser state, or operator-visible output and
recorded in
EVIDENCE.md.
The workflow is intentionally two-stage:
rough request
-> krypton-planning
-> PLAN.md + GOAL.md + EVIDENCE.md
-> /goal handoff
-> krypton-execution
-> main-agent implementation + review gates + acceptance evidence
Krypton also ships a reusable PR gate, but treat it as beta until you have
tested it in a throwaway repo that matches your workflow. The primary install
path is still the skills.sh command above.
The gate fails non-trivial code changes that do not include a changed Krypton goal package with:
PLAN.mdGOAL.mdEVIDENCE.md- truth owner text
- deletion or cutover text
- evidence gate and acceptance evidence text
Beta workflow example:
name: Krypton Goal Gate
on:
pull_request:
permissions:
contents: read
jobs:
krypton:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
fetch-depth: 0
- uses: jturntdev/krypton@v0.3.2Run the same gate locally:
python3 scripts/check-krypton-goal.py --base-ref origin/mainGoal package templates live in:
templates/goal-package/
Before relying on the Action in a real repo, test three cases in a throwaway repository:
- code change with no goal package should fail
- docs-only change should pass
- code change with
PLAN.md,GOAL.md, andEVIDENCE.mdshould pass
Krypton also includes a clearly marked beta Codex App remote-development setup
workflow:
krypton-vps-codex-app.
Use it when you want a VPS to be the machine that does the work while Codex App on your Mac or Windows machine connects over SSH. The VPS owns the repo, toolchain, builds, tests, tmux/cmux sessions, dev servers, and Codex CLI auth.
This is beta because VPS providers, Codex App remote connections, GitHub access choices, and project setup commands vary by operator. The goal is for Krypton to become the clean setup lane: Codex asks the right questions, explains the safest default, waits for user-owned steps, runs only approved setup or audit commands, and finishes with proof from the real remote project.
The skill is intentionally consent-based. Codex should ask before each operator-owned decision:
- whether the user already has a VPS or still needs to provision one
- whether Codex may edit
~/.ssh/configor should only show the snippet - whether GitHub should be the source of truth for the VPS checkout
- which GitHub access path to use: GitHub CLI login, account SSH key, read-only deploy key, public HTTPS clone, or no GitHub setup yet
- whether local config should be recreated from examples, copied selectively, or skipped
- whether Codex should only audit or may bootstrap tools over SSH
GitHub is the recommended code path. Local-only config and secrets are a
separate step. The skill tells Codex not to bulk-copy .ssh, .codex, browser
profiles, home directories, caches, node_modules, build outputs, private keys,
or random dotfiles.
Read the beta setup guide:
docs/vps-codex-app-beta.md
The skill includes a read-only audit script:
skills/krypton-vps-codex-app/scripts/audit-vps-codex-app.sh \
--host krypton-vps \
--repo-url git@github.com:ORG/REPO.git \
--repo-path ~/src/REPOPassing the audit proves the SSH host prerequisites. It does not replace the final Codex App remote-thread proof.
Krypton works best when the harness supports named agents:
explorer: read-only source-of-truth and architecture mappingplan-reviewer: PRE and POST alignment checksreviewer: runtime correctness, security, and evidence checkmaintainer: codebase-shape, duplication, and cutover-debt checkverifier: focused proof from the real path
See docs/required-roles.md for the role expectations. If your harness does
not support named agents, the main agent can still follow the same gates, but
independent exploration and review will be weaker.
Krypton keeps prompt templates individual instead of centralizing them into one large prompt file. Each skill owns the prompts it actually uses:
skills/krypton-planning/plan-reviewer-prompt.mdskills/krypton-execution/post-plan-reviewer-prompt.mdskills/krypton-execution/reviewer-prompt.mdskills/krypton-execution/maintainer-prompt.md
Bad agent path:
"Add sentiment to the dashboard."
The agent adds frontend-only sentiment logic and calls it done.
Krypton path:
Truth owner: market intelligence producer
Contract boundary: typed sentiment payload
Cutover: dashboard reads producer output only
Evidence: API response plus browser state showing the real payload
See examples/ and tests/pressure-scenarios/ for more.
This is the first public cut. It is intentionally small: three skills, individual prompt templates, agent role expectations, goal package templates, a local gate script, beta GitHub Action and VPS setup workflows, examples, pressure scenarios, and validation scripts.
Krypton uses SemVer-style versions while the public package stabilizes.
- Version source of truth:
VERSION - Plugin metadata must match:
.codex-plugin/plugin.json,.claude-plugin/plugin.json, and.claude-plugin/marketplace.json - Release tags should use
vX.Y.Z
Version policy:
- Patch: README, examples, prompt wording, metadata, validation improvements
- Minor: new skills, new gates, changed
/goalworkflow shape - Major: breaking skill names, removed gates, incompatible plan or goal format
Run:
./scripts/validate.shThe validator checks required files, skill metadata, JSON plugin metadata, and public-safety issues such as placeholders or private project references.
MIT