Use when writing, editing, reviewing, or testing Kotuku Tiri scripts, Flute tests, .tiri files, scripts/gui modules, examples, tools, or Tiri-facing API usage. Tiri is not standard Lua; use this skill before changing Tiri code or giving Tiri programming guidance.
Review Kōtuku technical documentation for developer usability, clarity, completeness, technical accuracy, and consistency with project documentation standards. Use when Codex is asked to review API docs, module docs, embedded C++ documentation comments, markdown guides, Tiri documentation, release-facing feature docs, or drafts that should let developers implement Kōtuku functionality without reverse-engineering examples or source code.
Use when writing, reviewing, extending, running, or planning coverage for Kotuku Flute tests. This includes creating test_*.tiri files, adding flute_test() CMake registrations, analysing missing test coverage, debugging Flute failures, and validating Tiri-facing module behaviour through the Flute runner.
Use when improving, rewriting, or reviewing Kotuku technical documentation, including embedded C++ API documentation sections marked with -FUNCTION-, -CLASS-, -ACTION-, -METHOD-, or -FIELD-, and markdown technical guides. Use this skill for clearer API references, class and method descriptions, field documentation, examples, and professional documentation edits that must remain technically accurate.
Audit Kotuku C++ modules and related TDL/CMake integration for cleanup opportunities, including dead private functions, stale helpers, duplicated implementation patterns, consolidation candidates, avoidable complexity, and structural anti-patterns. Use when the agent is asked to inspect existing Kotuku module code for maintainability cleanup, refactoring candidates, simplification opportunities, or removal of unused code. This skill is not for primary bug hunting; use bug-sweep for defect discovery and code-quality-reviewer for reviewing concrete changes.
Review Kōtuku code changes for correctness, maintainability, compile risk, and strict project coding standards. Use when Codex is asked to review C++, TDL, Tiri, Flute tests, CMake, or module integration changes; after implementing or modifying code; before committing; or when the user asks for a quality, compliance, regression, or bug-focused review of existing code.