agentsclimarketplace

Kairo risk review

Skill mattharbord/kairo-agents/skills/kairo-risk-review

Agent skills for building useful-now software the Kairo way. Local coding-agent skills for Kairo planning, implementation, and release review.

Install
npx -y skills add mattharbord/kairo-agents --skill kairo-risk-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Run a focused Kairo risk review for an in-progress or release-candidate tool and produce actionable warnings, required evidence requests, and non-blocking go/no-go guidance. Use when the PM asks for a risk pass, write-path safety check, known-gap review, release-readiness review, or conflict check between speed and reliability. Do not use as a formal compliance or certification audit.

SKILL.md

4.1 KB, 833 tokens by cl100k_base, as published. Nobody here has run it

Kairo Risk Review

Run a sharp, non-blocking review that makes risk explicit.

Do not gatekeep.

  • Never hard-stop.
  • Warn clearly.
  • Log protest when PM proceeds against advice.

Reference pages:

Core Definitions

Use these terms consistently in release notes.

  • known_error: Reproducible test failure against approved behavior, including predictable malformed input handling.
  • known_gap: Untested or unproven scenario with no observed failure yet.

Release rule:

  • Release with zero known_error.
  • Allow known_gap only with explicit disclosure.

Participants:

  • PM: The Product Manager working with you
  • Agent: You, acting as a developer
  • Developer: A third-party developer intended to review your work

Review Inputs

Request these artifacts if available:

  • docs/kairo-risk-register.md
  • docs/kairo-known-gaps.md
  • docs/kairo-decision-log.csv
  • docs/kairo-failure-log.csv
  • docs/kairo-io-contract-status.md
  • docs/kairo-session-context.md
  • README_KAIRO_RELEASE.md
  • Current test results and failing/flaky list
  • Dry-run and canary evidence for write paths

If inputs are missing, continue with assumptions and list missing evidence explicitly.

Use checklist:

  • references/review-checklist.md

Review Procedure

  1. Restate scope, intended use, and declared non-goals.
  2. Classify open items:
    • known errors,
    • known gaps,
    • unresolved decisions,
    • open failures from failure log.
  3. Verify release rule:
    • if known_error > 0, recommendation must be do not release.
  4. Verify write-path protocol when applicable:
    • dry-run evidence present,
    • PM confirmation present,
    • single-record canary evidence present.
  5. Verify external I/O contract posture:
    • in-scope paths are marked verified, mismatch, or waived,
    • no in-scope path is silently assumed verified,
    • mismatches affecting in-scope behavior are reflected in known errors.
  6. Verify context continuity posture:
    • session context reflects latest PM decisions,
    • session context matches decision-log intent,
    • next safe step is present and current.
  7. Verify logging hygiene:
    • warnings are present,
    • overrides are explicit,
    • no silent deletion of known gaps.
  8. Produce final review output.

Review Output Contract

Always output these sections:

  1. Risk posture summary
  2. Blocking known errors
  3. Known gaps accepted for this release
  4. Write-path safety status
  5. External I/O contract status
  6. Session context continuity status
  7. Missing evidence
  8. Recommended next safe step
  9. If PM proceeds anyway
  10. Recommended Developer Code Review Sections

In section 9, provide exact protest language for docs/kairo-decision-log.csv. If known_error > 0, section 9 must explicitly state that PM is proceeding against a do-not-release recommendation.

In section 10, locate and identify risk-heavy paths, for easy review by another developer later:

  • auth,
  • external I/O,
  • write/persist paths,
  • security-sensitive transformations.

Severity Model

Use practical severity terms:

  • Critical: likely severe impact or irreversible write risk.
  • High: material user/business risk if triggered.
  • Medium: contained impact with workaround.
  • Low: minor impact or cosmetic behavior.

Non-Blocking Rule

If PM chooses to proceed:

  1. State recommendation to delay.
  2. Provide risk delta in plain language.
  3. Provide exact log entry text.
  4. Continue support.

Canonical Protest Template

Use this when PM proceeds against recommendation:

Agent protest: Proceeding under unresolved risk. Known errors/gaps documented. PM instructed continuation and accepted risk for this release window.

What ships with it: 2 files

2.0 KB alongside SKILL.md

agents/

references/

Keep looking

Skills are one crate of 326,984. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.