kiro-stable-core

Category: Tools & Productivity | Uploader: tonitienda | Downloads: 0 | Version: v1.0（Latest）

Use this skill before editing `.ki` files or generating Kiro code. It teaches the stable-core syntax, effects, results/optionals model, canonical stdlib names, project layout, and verification workflow.

Changelog: Source: GitHub https://github.com/tonitienda/kiro-lang

Directory Structure

Current level: docs/llm/

📁 references/
- 📁 examples/
  - 📄 concurrency.ki 473 B
  - 📄 effects.ki 209 B
  - 📄 hello.ki 65 B
  - 📄 result_optional.ki 335 B
  - 📄 service.ki 380 B
- 📄 kiro.json 2.0 KB
📄 assets.go 162 B
📄 SKILL.md 1.9 KB

SKILL.md

---
name: kiro-stable-core
description: Use this skill before editing `.ki` files or generating Kiro code. It teaches the stable-core syntax, effects, results/optionals model, canonical stdlib names, project layout, and verification workflow.
---

# Kiro stable-core skill

Use this bundle when a repository contains Kiro source files.

## Read in this order

1. `references/kiro.json` for the compact machine-readable contract.
2. The example closest to the task in `references/examples/`.
3. The repository's root `AGENTS.md` for project-local workflow.

## Stable-core rules

- Use block-only `fn` bodies with explicit `return`.
- Declare only real operational effects: `env`, `fs`, `io`, `log`, `net`, `panic`, `proc`, `time`.
- Use `R[T,E]` for failure, `?` only to propagate `R[T,E]`, `?T` for optionals, and `nil` only for optional or nil-capable returns.
- Use `group`, `spawn`, and `await` for structured concurrency.
- Prefer documented stdlib module names directly: `env`, `fs`, `http`, `json`, `log`, `parse`, `test`, `time`.
- Keep formatting canonical with `kiro fmt`.

## Canonical project conventions

- Tiny CLI projects usually keep `main.ki` at the root.
- Tiny services use `main.ki`, `app/`, `internal/config/`, and `test/`.
- Put startup/effect boundaries in `main.ki`, handlers in `app/`, config loading in `internal/config/`, and handler tests in `test/`.

## Common repair guidance

- Do not invent alternate function forms; rewrite to a block body.
- Do not add pseudo-effects like `!json`; JSON helpers stay pure.
- Do not use `?T` for failure; use `R[T,E]`.
- Do not return `nil` from non-optional types.
- Scope spawned tasks inside a readable `group { ... }` block.

## Verification workflow

After edits, follow the repo guidance and at minimum run:

- `kiro fmt <paths...>`
- `kiro check <entry-or-path>`

For service-shaped projects, also run the documented tests/build commands such as `kiro test .`.

Comments 0

Latest | Hot

Please login before commenting.

No comments yet. Be the first one!

kiro-stable-core

Directory Structure

SKILL.md

Report

Notice