Is Kiyo a fit?

This page helps you decide whether to adopt Kiyo Codejadee Framework. Every statement is based on the framework’s own documented contracts and limits. It does not compare Kiyo with other frameworks.

When should I use Kiyo Codejadee Framework?

Kiyo fits teams that already use an AI coding agent and want its behavior to be predictable, bounded, and auditable:

• You work in Claude Code, Codex CLI, or GitHub Copilot. These are the three ecosystems with generated packages. Claude Code and Copilot are each packaged for both CLI and VS Code.
• Unverified claims are costly. Kiyo’s Evidence Contract requires every check to record its command, scope, status, observed result, and baseline. A check is PASS only if it actually ran.
• Humans and agents change the same code. Kiyo preserves human edits, refuses to reset, stash, or revert your work, and keeps review read-only.
• Some actions need a human decision. Governance levels G1–G4, contextual risk, and scoped approval requests make the agent stop before sensitive effects, such as a migration against a shared database.
• Context should live in the repository. Project Memory stores decisions, conventions, and known issues in .kiyo/memory/ with sources and dates, owned by your team.
• Your stack is varied. Kiyo imposes no architecture or library. Optional profiles for .NET, Angular, Python, and PostgreSQL guide inspection without forcing migrations.

When might it not be the best fit?

• You need enforced guardrails. Kiyo is advisory Markdown. The host enforces permissions, and Kiyo cannot guarantee that an agent complies. It is not a sandbox, DLP, egress filter, or policy engine.
• You need a supported, versioned release now. The framework is a development preview. The product version is UNSET, and publication identity, license confirmation, and publisher are open owner decisions.
• You use only the Codex IDE extension. Native plugins are documented as unsupported there (UNSUPPORTED), and no fallback has been approved.
• You need guaranteed activation. Explicit Skill selection is the documented route. Automatic Core loading and fresh-session activation are NOT_TESTED on every host.
• You want autonomous delivery. Kiyo never commits, pushes, opens pull requests, or deploys implicitly, and it treats production and destructive execution as restricted (G4).
• You need a compliance certificate. Standards mappings (ISO/IEC, NIST SSDF, OWASP) are dated, advisory interpretations, not certification.

Architectural assumptions

Assumption	Consequence
The host agent can read files inside the installed package	Each Skill carries a full copy of the shared rules, so all links resolve inside the Skill folder
The host follows its own instruction hierarchy	Kiyo cannot override higher-priority system or organization instructions (KIYO-AUTH-001)
The user states intent in plain language	Modes such as assess, run, write, and sync are words in the request, not parsed flags
Project state is mutable and user-owned	Memory and policy live in your repository; plugin updates and uninstall never touch them
Verification needs real execution	Unrun checks stay NOT_RUN or BLOCKED; a written test is not a passing test

Responsibilities

Area	Kiyo (Markdown guidance)	Your host	Your team
Permissions and isolation	Describes intended read, write, and execute boundaries	Enforces tools, files, and network access	Configures host and organization policy
Approvals	Prepares concrete approval requests and reuses valid approval	Enforces native denials	Provides accountable human approval
Verification	Requires honest check records	Runs the commands	Owns CI, test environments, and release gates
Project Memory	Specifies the record format and safe update procedure	Performs file reads and writes	Owns and reviews .kiyo/ content
Security	Scoped assessment procedures and AST01–AST10 mapping	Sandboxing and network controls	Incident handling, revocation, disclosure

This split follows the framework’s control ownership model.

Adopting incrementally

The framework is designed so you can start small:

1. Install and select explicitly. No project files are required. A Skill works without Init, reading the packaged bootstrap after selection.
2. Use read-only Skills first. Review, Architecture, Security, Test assess, and Memory check write nothing.
3. Preview Init before creating any state, then initialize only the proposed .kiyo/ files.
4. Add a managed instruction block only if you want persistent project guidance. It stays under 250 words and preserves your existing instructions.
5. Adopt a governance preset such as Balanced engineering, Stricter approval, or Observe/read-only only if it helps. NONE selected is valid.

Extension model

• Stack profiles: add guidance for another technology through the profile extension contract.
• Project and organization policy: fill the neutral policy templates. Adoption needs real acceptance evidence.
• Templates: 34 neutral templates for Memory, policy, and reports. Projects fill them; the shipped copies never change.

There is no plugin API, hook system, or code extension point. Extending Kiyo means authoring Markdown in the canonical source and regenerating packages.

Known trade-offs

Trade-off	Detail
Package size versus portability	Every Skill contains the full 97-file shared snapshot, so packages hold about 794 files. Duplication is deliberate: no runtime resolver or cross-Skill links
Advisory versus enforced	No runtime means nothing to install or trust beyond Markdown, but also no enforcement
Ceremony versus safety	Adaptive depth keeps tiny tasks compact, but approval, evidence, and scope controls always apply
Honesty versus convenience	Reports may end PARTIALLY COMPLETE or BLOCKED where another agent would claim success

Ready to try it? Start with the Quick Start.