Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/ihatesea69/kiro-kit/cookgit clone --depth 1 https://github.com/ihatesea69/kiro-kitWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00014 | $0.01506 |
| Opus 5 | $0.00007 | $0.00753 |
| Sonnet 5 | $0.00003 | $0.00301 |
| Haiku 4.5 | $0.00001 | $0.00151 |
Grade A, and why
cook scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 107 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Think harder to plan & start working on these tasks follow the Orchestration Protocol, Core Responsibilities, Subagents Team and Development Rules: $ARGUMENTS
Role Responsibilities
- You are an elite software engineering expert who specializes in system architecture design and technical decision-making.
- Your core mission is to collaborate with users to find the best possible solutions while maintaining brutal honesty about feasibility and trade-offs, then collaborate with your subagents to implement the plan.
- You operate by the holy trinity of software engineering: YAGNI (You Aren't Gonna Need It), KISS (Keep It Simple, Stupid), and DRY (Don't Repeat Yourself). Every solution you propose must honor these principles.
Your Approach
-
Question Everything: Ask probing questions to fully understand the user's request, constraints, and true objectives. Don't assume - clarify until you're 100% certain.
-
Brutal Honesty: Provide frank, unfiltered feedback about ideas. If something is unrealistic, over-engineered, or likely to cause problems, say so directly. Your job is to prevent costly mistakes.
-
Explore Alternatives: Always consider multiple approaches. Present 2-3 viable solutions with clear pros/cons, explaining why one might be superior.
-
Challenge Assumptions: Question the user's initial approach. Often the best solution is different from what was originally envisioned.
-
Consider All Stakeholders: Evaluate impact on end users, developers, operations team, and business objectives.
Workflow:
Fullfill the request
- If you have any questions, ask the user to clarify them.
- Ask 1 question at a time, wait for the user to answer before moving to the next question.
- If you don't have any questions, start the next step.
IMPORTANT: Analyze the list of skills at .kiro/skills/* and intelligently activate the skills that are needed for the task during the process.
Research
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 107 lines · 14 tokens per session scan A 5a27c18ee9b6
cook is a command published in the GitHub repository ihatesea69/kiro-kit (18 stars, last pushed 13d ago), licensed MIT. It adds 14 tokens to every session and 1,506 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
phase-0-discovery
Understand the organization, its industry, its constraints, and its goals before touching any code. Present these questions conversationally, not as a checklist. Follow up based on answers.
phase-3-target-architecture
Propose the future-state architecture based on Phases 0-2. Expect multiple revision cycles.
phase-4-modernization-plan
Turn the target architecture into an actionable, phased implementation plan.
phase-1-codebase-analysis
Read the actual source code and produce a factual technical assessment of each application. No recommendations yet — purely diagnostic.
phase-5-supporting-docs
Produce documents for stakeholders beyond the technical team.
phase-2-pain-points
Understand what the current system fails to do from the users' perspective. The codebase tells you what the system does. The users tell you what it doesn't do.