assesment_skill

Overview

This skill performs an autonomous risk assessment during design and planning stages to surface hidden assumptions, root causes, and concrete mitigation strategies. It prompts targeted self-questions before action, discouraging shallow fixes and favoring durable solutions. The output is pragmatic: validated premises, risk lists, recommended strategies, and decisions suitable for recording in ADRs.

How this skill works

The skill runs a five-part inspection: premise validation, root-cause (why-why) analysis, depth verification of proposed solutions, systematic risk identification, and design-decision evaluation. For each area it generates concise findings, alternative options, and suggested mitigation or transfer approaches (avoid, mitigate, transfer, accept). It also recommends when to capture decisions as ADRs and provides guardrails against common anti-patterns.

When to use it

• Entering plan mode or making major architecture decisions
• Before implementation or starting a new sprint
• Prior to opening a PR that introduces infrastructure or security changes
• When an error or outage occurs and root cause needs identification
• When a decision has trade-offs that should be recorded as an ADR

Best practices

• Always question assumptions early: ask whether a requested component is truly required
• Prefer root-cause analysis over surface-level fixes (use iterative why-why)
• Generate at least two alternative approaches and evaluate trade-offs
• Classify each risk with impact/probability and pick one of four strategies (avoid/mitigate/transfer/accept)
• Record significant, long-lived decisions in ADRs using present-tense, stable wording

Example use cases

• A request to add a VPC Endpoint — validate need, compare with Public ALB, weigh security vs cost
• Debugging frequent undefined/null errors — trace asynchronous initialization and redesign if needed
• Introducing CI integration — focus on user value (automation, visibility) and propose concrete templates
• Post-infra deployment review — audit tfstate handling, IAM scope, tagging, and cost risks
• Deciding access policies for production DB — propose least-privilege roles, CI-only changes, and monitoring