derive-technical-risks

Scan architecture artifacts to generate technical-risks.yaml and a decision manifest.

3|Updated Jan 25, 2026
One-click install
npx skills add https://github.com/kapilvirenahuja/garura --skill derive-technical-risks
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: derive-technical-risks
Source: https://github.com/kapilvirenahuja/garura/tree/main/core/components/skills/derive-technical-risks
Command: npx skills add https://github.com/kapilvirenahuja/garura --skill derive-technical-risks

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It helps teams identify and document concrete technical risks late in the architecture process so failures don’t surprise you during implementation or production rollout.

Core Features & Use Cases

  • Stage-locked risk identification (Stage 6, runs last): Halts if earlier architecture artifacts are missing to avoid blind or speculative risk registers.
  • Eight grounded discovery scans: Derives risks from logical/physical architecture, tech stack conditions (EOL/bleeding-edge), system inventory maturity, quality profile targets, epic failure conditions, compliance patterns, and KB-described failure modes.
  • Decision-manifest traceability: Writes a technical-risks.yaml register plus a decision manifest that records how each risk was surfaced and how it should be handled.

Quick Start

Ask an orchestrator to run derive-technical-risks after Steps 1–5 have produced the quality profile, systems inventory, logical/physical architecture, and tech-stack artifacts to generate technical-risks.yaml and decision-manifest-derive-technical-risks.yaml.

Frequently Asked Questions about derive-technical-risks

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

FAQPage Schema
How do I identify technical risks in a locked architecture before production rollout?

Technical risk identification scans earlier architecture artifacts like quality profiles, system inventory, and physical design to surface concrete risks. It generates a technical-risks.yaml register and decision manifest documenting tiered recommendations and grounding evidence.

What is the process for generating a risk registry during enterprise software delivery?

Risk registry generation applies eight discovery scans to logical architecture, tech stack maturity, and epic failure conditions. It outputs a technical-risks.yaml file with full risk schema and a decision manifest recording how each risk was surfaced and handled.

What architecture artifacts are required to assess compliance readiness and architecture risk?

You must supply completed quality profiles, systems inventory, logical and physical architecture, and tech-stack artifacts. The process halts if earlier architecture artifacts are missing, ensuring the generated risk register is grounded in evidence rather than speculation.

Can I use automated risk detection for enterprise delivery if my logical and physical design is incomplete?

No, automated technical risk derivation halts if earlier architecture artifacts like logical or physical design are missing. This stage-locked approach ensures risk registers are fully grounded in completed quality profiles and system inventories, avoiding blind speculation.

How do I document technical debt and known failure modes using a decision manifest?

Document technical debt and failure modes by generating a decision manifest that records tiered recommendations and grounding evidence for each risk. This manifest pairs with a technical-risks.yaml register to provide full traceability for enterprise delivery decisions.