Immutable. This exact content is served forever at /api/v1/blob/da8c57f636777f34.
---
name: risk-evaluator
parent_agent: risk-evaluator-qa-strategy-agent
type: skill
description: Use this skill for risk quantitative analysis, when previous agent provides the behavioral analysis to be transformed into a technical and business risk score.
license: Apache-2.0
compatibility: CLI agents(Clude, Antigravity, Wrappy) and IDE Agents (Cursor IDE, ANTIGRAVITY IDE, VsCode, Windsurf, etc)
metadata:
author: Leticia Perez Gainza
version: 1.0.0
---
# Skill: `risk-evaluator`
**Goal:** Execute a multidimensional analysis to determine the criticality of a requirement, ensuring the evaluation is objective, consistent with project history, and aligned with *ShopSwift* standards.
## Inputs
1. **Functional Artifact:** Path to `bdd_validation_{RF_ID}_{timestamp}.md` (Generated by Agent A).
2. **Project Context (via Orchestrator):**
- *Business_Priorities*
- *or related functionalities*, stability of related functionalities.(Definition of user flow criticality).
- *Tech stack* (to evaluate technical complexity).
3- **Risk Standards:** Parameters for risk evaluation standards: `reference/reference_risk_standards.md` , used as the primary reasoning guide
## **Internal Process:**
The skill operates under a 5-stage process:
1. **Input Validation**
2. **Standard Alignment (`Reference Check`)**
3. **Algorithmic Matrix Calculation (`Data-Driven Score`)**
4. **Historical Consistency Verification (`Peer Review Loop`)**
5. **Self-Validation (Quality Verification):**
Finally **Handoff to `qa-strategy` skill**
### Precondition Request
You must request to the orchestrator agent the context information needed for the evaluation process (as mentioned above) by using the RF-ID and User Story as reference information to find the context information.
### 1. Input Validation
**Handoff Validation**
Validates contract compliance of the previous agents `bdd-validation-analyst-agent`, you must validate that in the body payload are included the next keys and values:
- RF_ID
- User Story
- BDD Validation File Path
**Rule**: The key-values mentionated above are mandatory, which can impact in the quality of the output of this skill, it must be validated before proceeding to the next stage.
**Conditional validation**:
- If the **Iternal Handoff** validation is successful, the agent MUST proceed to the next validation stage.
- If the **Internal Handoff** validation fails or is missing, the agent MUST abort the process and inform to the Orchestrator the validation status and the reason of the failure, return example:
```json
{
"status": "failed",
"reason": " 'bdd-analyst-agent' handoff or its outputs are missing.",
"failure_details": "The bdd_validation_{RF_ID}.md file is missing from the path provided by the previous agent."
}
```
**Rule**:
#### 1.1 File Validation
- **Verify if the input file `bdd_validation_{RF_ID}_{timestamp}.md` is present at the path provided in the paylod and is valid**.
**Rule**: It must contain the following keys and sections with arguments:
- RF-ID + User Story
- Acceptance Criteria (Gherkin format) (at least 5 ACs)
- Validation Rules (Extracted NFRs: Security, Performance, Accessibility / UX, Compliance, Reliability)
This are mandatory input, if it is missing, the skill must stop the evaluation, register validation_status: "Failed", indicate the specific reason, and refrain from inferring missing information.
**Rule**: Within the file could be `Validation Refinement Questions` section. This is enrichment information for user stories clarification, you do need to use this for validation or your analysis process, this is out of the scope of your responsability.
#### 1.2 Business Context Validation
- **Validte the bussines context provided by the Orchestrator Agent**, you should receive from the Orchestrator the **project context** information with this keys and its arguments, some are mandatory, this meand that it must have been informed, and others optional:
| Context Information Rules| Keys |
| --- | --- |
|mandatory| **Business priorities**, **Related functionalities**, **Tech stack** |
|optional| **Stability of related functionalities** and other relevant context information provided by the orchestrator agent |
- **Rule:** If the mandatory fields are missing, the skill must stop the evaluation, register validation_status: "Failed", indicate the specific reason, and refrain from inferring missing information.
### 2. Standard Alignment (`Reference Check`)
- **Cross-reference the analysis provided by `bdd-analyst-agent` and the context information provided by the orchestrator agent with `reference/risk_standards.md` for risk analysis**, this evaluation proccess must include business value criteria and classification by score and OWASP top 10.
- **Rule** Identifies predefined "Red Flags".
- *Example:* If the requirement touches the payments microservice or PII (Sensitive Information), the base severity is automatically locked to **High** or **Critical**, regardless of complexity.
### 3. Algorithmic Matrix Calculation (`Data-Driven Score`)
- **Action:** Execute the logic defined in `scripts/risk_calculator.py`.
- **Input variables for calculation:**
* **Business Impact (Severity):** Based on the `Business_Priorities` (e.g., Checkout = 5/5, Button color change = 1/5).
* **Technical Complexity (Probability of Failure):** Evaluate risk according to the stack. (e.g., Changes in Redis/PostgreSQL logic = High technical risk; Changes in Next.js CSS = Low technical risk).
- **Formula:** `Risk_Score = (Impact * 0.7) + (Complexity * 0.3)`.
- **Threshold Mapping:** The numerical `Risk_Score` MUST map to qualitative severity levels based on the following exact ranges:
* `0.0 - 3.9`: Low
* `4.0 - 6.9`: Medium
* `7.0 - 8.9`: High
* `9.0 - 10.0`: Critical
### 4. Historical Consistency Verification (`Peer Review Loop`)
#### Risk Log Revision
- Read the `assets/logs/risk.jsonl` and identify similar requirement risk analysis patterns to mantain concistency, (e.g: Authentication Vulnerability -> User Login Requirement, User Register Requirement, User Logout Requirement, User Forgot Password Requirement, Role Managment Requirement, User Profile Management Requirement etc.):
- **Criterion:** If a similar requirement was previously rated as **Medium**, but the current calculation gives **High**, the skill must generate a clarification note in the `technical_justification` field explaining the deviation.
#### Update Architectural Decision Recording (ADR)
- - Update `agents/risk-evaluator-qa-strategy-agent/assets/logs/risk.jsonl` by appending the new risk evaluation, this is use as system processing memory for future evaluations, following the ADR pattern.
- Use the `assets/risk_log_schema.json` as guidance to record and store risk information in `assets/logs/risk.jsonl`.
#### History Records Management
- Use the `assets/history_RF-ID_00.json` as example and generate a new history record for the current requirement, keeping the exact same `JSON` format as existing records to maintain historical consistency.
- Storage the new generated record in `agents/risk-evaluator-qa-strategy-agent/outputs/history-records/history_{RF_ID}_{timestamp}.json`.
#### Backup Payload
Besides the handoff to the next skill, the `risk-evaluator` must create a "Backup" payload containing the exact same internal structure as the official Handoff JSON, but with one crucial additional field:
- `artifact_status` is set to `BACKED_UP`.
This backup payload must be stored in `agents/risk-evaluator-qa-strategy-agent/outputs/risk-evaluator-backups/backup_{RF_ID}_{timestamp}.json`, ensuring that even if the pipeline fails before the final step, the complete risk evaluation is preserved in a machine-readable format.
### 5. Self-Validation (Quality Verification):**
Before handoff, you MUST review your own Risk Evaluation Report, following the next success criteria:
- [ ] Verify that all mandatory fields in the report are populated.
- [ ] Ensure the `technical_justification` field clearly explains the reasoning behind the assigned severity level and references the specific Manifesto rule or standard that supports the assessment.
- [ ] Double-check that the `Risk_Score` calculation is mathematically correct and falls within the appropriate threshold range for the assigned severity level.
- [ ] Confirm that any historical data referenced in the report is consistent with the current evaluation.
- [ ] Verify that the output format strictly adheres to the defined structure and that no critical information is missing.
- [ ] Verify the `history` file generated compliance the naming with `RF_ID` and `{timestamp}` in the file name: `history_{RF_ID}_{timestamp}.json`.
- [ ] Verify the `history` file generated is stored in the `outputs/history-records/` directory, and that the file path is correct.
- [ ] Verify the `assets/logs/risk.jsonl` file was updated with the new risk evaluation following the ADR pattern.
- [ ] Verify that the risk score and severity level are consistent with the NFRs extracted by Agent A and the risk standards.
- [ ] Verify if the payload handoff backup was generated and stored in the `outputs/risk-evaluator-backups/backup_{RF_ID}_{timestamp}.json` following the naming convention
---
## Constraints: Mandatory
| **Type** | **Rule** |
| --- | --- | --- |
| **Must** | Use cited justification, each assigned severity level must include a reference to a Manifesto rule or a standard in `/reference` |
| **Must** | Always apply as your main *truth processing source* the scenarios provided as **Acceptance Criteria** in the input artifact `bdd_validation_{RF_ID}_{timestamp}.md`and the context information from the orchestrator agent |
| **Must** | You MUST use and follow strictly the reference `reference/risk_standards.md` to perform the risk evaluation process. |
| **Must**| Execute the python script `scripts/risk_calculator.py` to compute the risk score according to the defined algorithm. Any deviation from this script is a critical failure.
| **Must**| Always apply **input validation policy**, stop the evaluation process if a mandatory input is missing (`Business_Priorities` or `bdd_validation_{RF_ID}.md`), register `"validation_status: "Failed"`, indicate the specific reason, and refrain from inferring missing information. |
|**Must**| Never overwrite or delete existing risk logs information in `risk.jsonl`. It must append exactly ONE single-line, minified JSON object to the end of the file. Do NOT wrap the file in an array `[]` and do not format it with line breaks.
| **Must** | Keep updated the `risk.jsonl` file with the new risk evaluation, maintaining sorted order by RF_ID. |
| **Must**| Apply historical risk records from `risk.jsonl` and `history_RF-ID_00.json` to ensure consistency in risk scoring for similar requirements. |
| **Could** | Include suggestion of risk control methodolog base on industries best practices, but not to exceed only 2 sentence with the reference to the control methodology, e.g: **`"risk_control_methodology": "static code analysis (SAST), dynamic code analysis (DAST)" `** |
| **Could** | In case you detect a risk pattern in the `risk.jsonl` , e.g: repetitive high risk exposure in specific areas, it is recommended to share a brief summary of your findings |
|**Won't**| **Overwriting Policy** Overwrite or delete existing files or information within this agent scope or provided by `bdd-validation-analysis-agent` or `orchestrator`.|
| **Won't** | **CRITICAL**Generate, suggest, or include any test types or QA strategy recommendations in the output Markdown or history JSON. Its only output is the risk diagnosis. |
| **Won't** |Assign risks based on vague language (e.g., " Seems risky to me"). It must use metrics.|
| **Won't** | **Prohibited Context Hallucination** Create or generate any of tyhe manadatory input artifacts, not even to extend the information context provided by the Orchestrator Agent|
| **Won't** | **Overwriting Policy** Overwrite or delete existing files. It must create new files with unique names.
| **Won't** | **Log Format Policy** The agent cannot overwrite or delete existing risk logs information. It must append the new risk evaluation to the file, maintaining sorted order by RF_ID. |
## Output Object
### Artifacts and ADRs updates
- You must output the final risk assessment in the file: `history_{RF_ID}_{timestamp}.json` and store in the specific directory `outputs/history-records/`
- You must update the ``assets/logs/risk.jsonl` file append the new risk evaluation.
### Internal Handoff:
You must provide the risk evaluation analysis and result to **Skill 2** `qa-strategy`, with:
- all the data and metrics according to the `reference/risk_standards.md` and `scripts/risk_calculator.py`.
- it is very important not missing information, because this will be used as main input processing for the next skill.
- the `justification{}` property can be expanded, with specific key:values pairs within the `standard_reference` key. This means that it can contain more key:values pairs than the ones defined in the schema example, depending on the evaluation result example:
```json
`standard_reference`: ["ShopSwift_Risk_Std_v1.2 - Risk ID: A08 - Software & Data Integrity Failures","Risk ID: A04 Insecure Design"],
```
Upon completion, the skill transfers control using the following structured handoff JSON object.
```json
{
"risk_metadata": {
"rf_id": "{RF_ID}",
"raw_score": 8.5,
"severity_level": "High",
"probability_of_failure": "Medium-High"
},
"justification": {
"business_impact": "Affects data persistence in the cart (Critical Flow).",
"technical_debt_risk": "High complexity due to Redis cache integration.",
"standard_reference": "ShopSwift_Risk_Std_v1.2 - Risk ID: A08 - Software & Data Integrity Failures",
"technical_justification": "Note: Historical deviation - similar APIs were rated Medium, but this modifies the Redis core cache."
},
"risk_evaluator_artifacts_generated":{
"history_json_payload": "agents/risk-evaluator-qa-strategy-agent/outputs/history-records/history_{RF_ID}_{timestamp}.json",
"handoff_json_payload_backup": "agents/risk-evaluator-qa-strategy-agent/outputs/risk-evaluator-backups/backup_{RF_ID}_{timestamp}.json",
"risk_jsonl_updated": "agents/risk-evaluator-qa-strategy-agent/skills/risk-evaluator/assets/logs/risk.jsonl"
}
}
```
### JSON Clarification NOTE
The agent must create two distinct `JSON` payloads and must not confuse them because they have different purposes and formats:
* `JSON` for the historical record saved to the file `outputs/history-records/history_{RF_ID}_{timestamp}.json`.
* Handoff `JSON` (schema above) to create the backup and to output information to next skill and continue the workflow.