Krypton Planning Agent Skill
Use when a user has a feature request, bugfix, refactor, migration, architecture change, or product goal and needs an implementation plan before coding. Use especially when wrong ownership, duplicate paths, stale contracts, weak evidence, or unclear cutover would make plausible agent work dangerous.
Install
one command, takes just this skill from the repositorynpx skills add https://github.com/jturntdev/krypton --skill krypton-planningWhat comes with it
1 557 bytes besides the instructionThe instruction itself
5 sections, as written by the authorKrypton Planning
Krypton Planning turns a request into a goal package that names the outcome, truth owner, contract, cutover, and acceptance evidence before anyone writes code.
Core Rule
Do not treat a task list as a plan. A Krypton plan is ready only when it answers:
What outcome are we serving?
What current behavior is being replaced, redirected, deleted, or demoted?
Who owns the truth?
What contract crosses the boundary?
What is the smallest high-value slice?
What proves the result from the target person's perspective?
What kill criteria stop duplicate paths from living forever?
If ownership, cutover, contract, or evidence is fuzzy, stop and map before planning.
Workflow
- Write the outcome contract:
Plan title:
Intent:
Current behavior:
Expected outcome:
Target-perspective output:
Truth owner:
Contract boundary:
Cutover:
Displaced path:
Value density:
Evidence gate:
Acceptance evidence:
Evidence lane:
Kill criteria:
Non-goals:
Risk if wrong:
- Map the architecture slice before tasks:
Files to create:
Files to modify:
Files to avoid:
Source of truth:
Read path:
Write path:
Contract boundary:
Integration points:
Migration/cutover:
Displaced path:
Acceptance evidence gate:
For broad or unclear repositories, dispatch a read-only explorer if the harness supports agents. Ask one bounded question, such as "map the source of truth, read/write path, unsafe files, and evidence gate." The execution session should use this map instead of rediscovering the same slice.
- Save a goal package unless the user gives another location:
docs/goals/<goal-slug>/PLAN.md
docs/goals/<goal-slug>/GOAL.md
docs/goals/<goal-slug>/EVIDENCE.md
PLAN.md contains the full plan. GOAL.md is a short execution prompt that points to the plan instead of copying it. EVIDENCE.md starts empty and is filled during execution with the real proof captured from the target perspective.
- Start
PLAN.mdwith this header shape:
# [Outcome Title] Implementation Plan
**Intent:** ...
**Current Behavior:** ...
**Expected Outcome:** ...
**Target-Perspective Output:** ...
**Truth Owner:** ...
**Contract Boundary:** ...
**Cutover:** ...
**Displaced Path:** ...
**Value Density:** ...
**Evidence Gate:** ...
**Acceptance Evidence:** ...
**Evidence Lane:** ...
**Kill Criteria:** ...
**Architecture Slice:** ...
**Plan Review Gate:** Requires PRE review before execution.
- Break work into small tasks. Each task names exact files, allowed scope, expected output, verification command, acceptance evidence, and whether it can run in parallel.
- Run a PRE plan review when possible. Use
plan-reviewer-prompt.mdas the individual prompt template. Do not execute until blocker findings are fixed or explicitly accepted by the user.
GOAL.md Shape
Use this compact handoff. This is the /goal prompt or next-session prompt the operator should paste into Codex or Claude:
# Goal: [Outcome Title]
Use Krypton Execution to execute `docs/goals/<goal-slug>/PLAN.md`.
Core rules:
- Treat PLAN.md as the source plan.
- Preserve intent, ownership, contract, cutover, evidence, and kill criteria.
- Do not add a new dominant path without deleting, redirecting, demoting, or shimming the displaced path.
- Capture acceptance evidence from the target perspective and record it in EVIDENCE.md.
- Say "implemented but unproven" if that evidence cannot be captured.
EVIDENCE.md Shape
Create this file with the goal package and update it during execution:
# [Outcome Title] Evidence
## Acceptance Evidence
Record the real artifact that proves the outcome from the target perspective.
## Verification
Record the focused check that passed, including the command and relevant output.
## Review Notes
Record reviewer, maintainer, or verifier findings that changed the result.
Other skills for the same job
different authors, same section of the catalogue
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
Intelligently organizes your files and folders across your computer by understanding context, finding duplicates, suggesting better structures, and automating cleanup tasks. Reduces cognitive load and keeps your digital workspace tidy without manual effort.
Generates creative domain name ideas for your project and checks availability across multiple TLDs (.com, .io, .dev, .ai, etc.). Saves hours of brainstorming and manual checking.
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Implements Manus-style file-based planning for complex tasks. Creates task_plan.md, findings.md, and progress.md. Use when starting complex multi-step tasks, research projects, or any task requiring >5 tool calls.
Creative research ideation and exploration. Use for open-ended brainstorming sessions, exploring interdisciplinary connections, challenging assumptions, or identifying research gaps. Best for early-stage research planning when you do not have specific observations yet. For formulating testable hypotheses from data use hypothesis-generation.
Comprehensive GitHub project management with swarm-coordinated issue tracking, project board automation, and sprint planning
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
How to use it
Take jturntdev/krypton-planning from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.