mtk

---

The Problem

AI code assistants generate code that compiles but silently violates your team's standards. Missing auth checks, unaudited state mutations, N+1 queries, tests that assert nothing meaningful, style drift from one end of the codebase to the other. In serious software — where code touches real money, real users, or regulated data — "it works" is not enough.

Most teams respond by writing a big CLAUDE.md or .cursor/rules. But instructions are advisory. AI assistants follow them about 80% of the time. The other 20% is where production incidents live.

What It Does

MTK closes that gap with workflow enforcement (planning, TDD, batched implementation), adversarial review agents (that find real problems, not style nits), deterministic linters (that catch secrets and SQL injection at confidence 100%), and evidence gates (no "done" claims without cited build output).

Without MTK	With MTK
AI generates code, you review it manually	AI plans, implements in batches, tests, reviews itself adversarially, then reports with evidence
CLAUDE.md rules followed ~80% of the time	Critical rules enforced by hooks (100% deterministic)
"Tests pass" with no proof	Build output, exit codes, and pass/fail counts cited in every completion
Security checks happen if you remember to ask	Security-and-hardening skill activates automatically for auth/secrets/audit changes
Review is one prompt: "review this code"	Two-stage pipeline: compliance first, then test + architecture specialists in parallel
Findings are vague: "consider adding tests"	Findings are structured JSON with severity, confidence scores, rule citations, and file:line references

---

What's New

v7.7.0 — Decision provenance and end-to-end wiring verification (2026-05-18)

• Decision-origin tagging — every entry in the structured learnings store and every reviewer finding carries a decision_origin field (user-directed / claude-recommended-approved / claude-recommended-modified / claude-recommended-rejected / system-inferred). Surfaces how much of the design is the engineer's vs. the model's, so over-deference can be measured and corrected.
• Sycophancy index (π) — scripts/learnings.sh metrics computes π = approved / (approved + modified + rejected); ≥0.70 raises a warning that the model's recommendations are being accepted without enough pushback. Threshold tunable via review-config.
• Wiring check as Definition of Done — verification-before-completion and validate-toolkit.sh --task-scoped confirm every skill, hook, agent, and reference touched in a batch is fully registered (frontmatter name: matches dir, hooks chmod +x and referenced in settings.json, manifest entries present, references-index in sync). Authoring a file without wiring it now fails the gate.