Start modeling your implementation
kkt applies constrained optimization to coding-agent workflows. Named after the Karush-Kuhn-Tucker conditions, it translates mathematical modeling discipline into a practical framework for identifying application constraints, choosing feasible implementation paths, and validating the result.
Good implementation plans are shaped as much by what not to do as by what to do.
kkt makes those limits explicit. Before choosing an implementation path, it pushes the agent to identify the constraints that define a safe change: public contracts that must not break, architecture boundaries that must not be crossed, data rules that must not be weakened, and validation that must not be skipped.
Instead of:
build xyz
model the work as:
what is the optimized implementation,
given what must stay true?
The result is a more disciplined implementation plan: fewer accidental side effects, clearer tradeoffs, smaller edits, and validation tied to the actual constraints of the work.
For coding agents, those constraints are usually concrete:
- existing architecture and public contracts
- files, modules, endpoints, schemas, and migrations
- security, privacy, and data-integrity rules
- ui and product boundaries
- infrastructure and runtime limits
- validation evidence required to prove completion
The core idea:
choose
x in X
maximize
alignment(user_goal, x)
subject to
C_app(x)
C_arch(x)
C_data(x)
C_ui(x)
C_infra(x)
C_validation(x)
where:
x
is the implementation decision vectorX
is the feasible implementation regionC_*
are application constraints- the selected plan is the best feasible plan, not the first plausible plan
- validation is the certificate that the selected plan satisfies the model
Install with curl:
curl -fsSL https://raw.githubusercontent.com/dannylee1020/kkt/main/scripts/install.sh | bash
By default, this installs the skills for Codex, Claude Code, Pi, and OpenCode using their shared skill locations:
~/.agents/skills
~/.claude/skills
Target-specific paths are also available for agents that prefer their own skill directory:
Codex: ~/.agents/skills
Claude Code: ~/.claude/skills
Pi: ~/.pi/agent/skills
OpenCode: ~/.config/opencode/skills
Useful options:
--target codex
--target claude
--target pi
--target opencode
--local
--dry-run
From a checkout:
scripts/install.sh
Use the skill syntax supported by your agent:
Codex: $kkt
Claude Code: /kkt
Pi: /skill:kkt
OpenCode: ask OpenCode to use the kkt skill
Start with a rough request:
Use $kkt to add export-to-csv for reports.
Add constraints only when you already know them:
Use $kkt to add export-to-csv for reports.
Constraints:
- Reuse the existing reports api.
- Do not change billing code.
- Do not add dependencies.
Validation:
- Add or update the smallest useful test.
- Run the relevant test command if available.
kkt should inspect the repo, infer discoverable constraints, and ask only for decisions that materially affect feasibility, product behavior, risk, or execution mode.
Default agent flow:
user request
-> plausible plan
-> edits
-> summary
with kkt:
user request
-> request intake
-> constraint discovery
-> feasible region
-> selected plan
-> focused edits
-> validation certificate
The contract:
optimization model objective, variables, constraints, feasible region, selected plan
solution audit binding constraints and sensitivity analysis
execution contract acceptance criteria, validation plan, evidence, stop conditions
| skill | use it for | output |
|---|---|---|
$kkt |
||
| normal feature work, bug fixes, and refactors | model, implement, validate | |
$kkt-loop |
||
| long-running or autonomous work | durable workspace, progress, evidence | |
$kkt-model |
||
| architecture choices and tradeoff analysis | selected model or decision brief |
$kkt
is lightweight and does not create durable files by default.
$kkt-loop
creates .kkt/<slug>/
with:
model.md
plan.md
evidence.md
progress.md
notes.md
$kkt-model
is non-mutating by default. It inspects, models, compares feasible alternatives, and asks for user input only when the tradeoff cannot be resolved from the repo.
kkt turns rough input into a request frame before modeling:
objective
known non-goals
constraints
validation expectations
The user does not need to provide all of this upfront. Missing fields are inferred from the codebase when possible and marked as assumptions when needed.
Expected final audit:
Objective: satisfied
Hard constraints: satisfied
Binding constraints: respected
Validation evidence: tests, checks, artifacts, or reason validation was not possible
Residual risk: remaining uncertainty
Apache-2.0