Risk Assessment Tiering

Evaluate design risk to assign documentation tiers from Basic to Verification.

1|Updated Dec 2, 2025
One-click install
npx skills add https://github.com/kmt-t/fireball --skill risk-assessment-tiering
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: Risk Assessment Tiering
Source: https://github.com/kmt-t/fireball/tree/main/.agent/skills/risk_assessment
Command: npx skills add https://github.com/kmt-t/fireball --skill risk-assessment-tiering

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill provides a structured approach to evaluate design risk and assign an appropriate Tier, reducing ambiguity in documentation and verification planning.

Core Features & Use Cases

  • Tier definitions for Tier 1 (Basic), Tier 2 (Structural), and Tier 3 (Verification) to guide depth of documentation.
  • Criteria mapping to risk factors such as logic complexity, resource constraints, and potential side effects.
  • Clear guidance for producing invariants, decomposition, and verification artifacts to prevent design misinterpretation.

Quick Start

Begin a risk assessment during design reviews: identify the primary risk factors, map them to the appropriate Tier, and document the rationale and expected artifacts.

Frequently Asked Questions about Risk Assessment Tiering

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What is risk assessment tiering in software design documentation?

Risk assessment tiering evaluates design risk to determine the appropriate documentation depth. It assigns Tier 1, 2, or 3 based on logic complexity, resource constraints, and side effects to reduce ambiguity and guide verification planning.

How do I determine the correct documentation tier for my design review?

To determine the documentation tier, identify primary risk factors like logic complexity and potential side effects during a design review. Map these risks to the structured criteria to assign Tier 1, Tier 2, or Tier 3.

When do I need to produce invariants and verification artifacts for software design?

You need to produce invariants and verification artifacts when your design risk assessment assigns a Tier 3 Verification level. This tier enforces structural decomposition and artifact generation to prevent design misinterpretation.

What is the best way to structure design documentation for complex logic and resource constraints?

The best way to structure design documentation is applying a tiered risk assessment. Map logic complexity and resource constraints to defined tiers, ensuring you generate the required invariants and decomposition artifacts for higher risk tiers.

Does risk-based tiering work for basic design changes with low logic complexity?

Risk-based tiering works for basic design changes by assigning them to Tier 1. This level requires minimal documentation depth, allowing you to efficiently process low-risk changes without generating unnecessary structural verification artifacts.