kstack is a set of Markdown files. That's it.
No runtime. No binary. No framework. Each skill is a SKILL.md that tells Kiro CLI how to think in a specific cognitive mode.
This is intentional. The simpler the mechanism, the more portable and maintainable it is.
~/.kiro/skills/{name}/SKILL.md
Kiro CLI scans ~/.kiro/skills/ for directories containing SKILL.md. The front matter (name, description) is used for discovery. The rest of the file is the system prompt for that mode.
{skill-name}/
├── SKILL.md # The skill definition
└── evals/
└── test_cases.yaml # Eval test cases
./setup creates symlinks:
~/.kiro/skills/plan-product → ~/.kiro/skills/kstack/plan-product
~/.kiro/skills/plan-eng → ~/.kiro/skills/kstack/plan-eng
...
This means:
git pullupdates skills immediately (symlinks follow the source)- No copy/paste drift between repo and installed skills
- Clean uninstall: remove symlinks + repo directory
Each skill defines a distinct cognitive mode:
| Skill | Mode | Key constraint |
|---|---|---|
| plan-product | Divergent thinking | Don't accept the literal request |
| plan-eng | Convergent thinking | Must produce diagrams |
| code-review | Adversarial thinking | No flattery, find problems |
| ship | Execution | No questions, no code changes |
| qa | Verification | Evidence-based, health score |
| retro | Reflection | Data-driven, actionable |
The key insight: these modes are deliberately incompatible. A good product thinker challenges assumptions; a good release engineer doesn't. Blending them produces mediocrity. Separating them produces excellence.
gstack (for Claude Code) includes a compiled Playwright binary for browser automation. kstack deliberately excludes this:
- Portability — Markdown works everywhere Kiro CLI works
- No build step —
git clone && ./setupis the entire install - Composability — users can add their own browser/QA skills alongside kstack
- Maintainability — updating a skill = editing a Markdown file