AI-assisted KTAPEOUT development

KTAPEOUT 0.5.0 can be developed with an AI coding assistant, provided that the assistant is constrained by the protocol, repository boundary and signing authority rules.

• KTAPEOUT Application Engineering Skill — the shared instructions and workflow for an AI coding assistant.
• AI tool installation and use — safe setup guidance for common coding assistants.

AI assistance does not grant wallet custody, signing authority, broadcast authority or Mainnet access. The developer remains responsible for reviewing protocol changes, generated code, dependencies and commands before execution.

AI task workflow

1. Confirm whether the checkout is the minimal public protocol candidate or the full engineering distribution. Do not assume the public candidate includes Studio, Native Host, adapters or a live publisher.
2. Read the current capability boundary and the relevant protocol or guide page before choosing commands.
3. Use the installed CLI's help and the examples shipped with that exact distribution. Do not infer an executable command from a protocol concept or an older Skill.
4. Validate locally and report the exact command, result and remaining boundary. Local validation is not chain inclusion, publisher authorization or production readiness.

The Skill guides task routing; the current architecture, normative specification, shipped implementation and capability status remain the sources of truth.

First application with an AI assistant

Use this repeatable sequence after installing an assistant:

1. Open the KTAPEOUT repository root. The public specification, schemas and this guide are sufficient for local unsigned protocol work. The complete Application Engineering Skill requires the separate engineering distribution.
2. Ask the assistant to read docs/index.md, the normative specification and the first-application tutorial.
3. Require a file-level plan before any edit and ask the assistant to identify the Profile, Package, Recipe, locks and state commitments involved.
4. Run the generated local scaffold and workflow from an external Cargo target directory:

$env:CARGO_TARGET_DIR = Join-Path $env:TEMP "ktapeout-0.5.0-target"
cargo run --manifest-path core/rust-cli/Cargo.toml --locked -- init `
  --template StateMachine --network testnet-10 --output .\my-app
cargo run --manifest-path core/rust-cli/Cargo.toml --locked -- dev workflow `
  .\my-app\workflow.json

1. Review the generated files and require the assistant to validate them against the public schemas and vectors. Keep the result LOCAL_ONLY until a separately reviewed external signing and readback boundary exists.

The assistant must stop and report missing capabilities instead of inventing a provider, wallet, signer or network path. A local scaffold is intentionally enough to begin application development; it is not an on-chain publication.