Constrained Modeling for Coding Agents

Kkt, a new tool named after the Karush-Kuhn-Tucker conditions, applies constrained optimization to coding-agent workflows by forcing agents to identify explicit constraints before implementation. The tool aims to reduce accidental side effects and produce more disciplined plans by modeling work as an optimization problem with feasibility regions and validation certificates. It installs as a skill for Codex, Claude Code, Pi, and OpenCode, and is available via curl or GitHub checkout.

Start modeling your implementation kkt applies constrained optimization https://en.wikipedia.org/wiki/Constrained optimization to coding-agent workflows. Named after the Karush-Kuhn-Tucker conditions https://en.wikipedia.org/wiki/Karush%E2%80%93Kuhn%E2%80%93Tucker 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 vector X is the feasible implementation region C 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: php user request - plausible plan - edits - summary with kkt: php 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