Skill Name

Credit GoldenKey Path Extraction Skill v2 (JIRA2 ASCII Renderer)

Skill One-Sentence Definition

A deterministic skill that extracts Credit-relevant return paths and conditional existence-gating paths from a Rosetta reporting rule (and its sub-functions), producing JIRA2-ready ASCII-only wiki output for Golden Key and testing coverage workflows.

Applicable Scenarios

• •DRR / MAS Credit product field analysis
• •Golden Key identification support for Credit reporting fields
• •Testing queue preparation (sheet/JIRA path filling)
• •Rule-to-CDM traceability documentation for Credit scope
• •Consistent downstream handoff to Coverage teams (IR/FX overlap review)

Non-Applicable Scenarios

• •Regulatory correctness decisions (expected vs bug)
• •Product payoff or economic interpretation
• •Selecting the final population branch among multiple candidates
• •Runtime data validation or execution testing
• •Refactoring or optimization recommendations

Inputs

• •A complete reporting rule definition (Rosetta DSL)
• •Access to all referenced sub-function definitions
• •Credit scope keywords or payoff anchors (e.g. creditDefaultPayout, referenceObligation)
• •Optional: br.md index for Reference BR Jira lookup
• •Optional: file/line mapping source (best-effort)

Out of Scope

• •Determining which candidate path is ultimately populated (human decision)
• •Cross-asset coverage decisions (IR/FX ownership)
• •Any business/regime interpretation beyond Credit-only scoping
• •Inferring missing dependencies not explicitly present in code

Workflow

1. •

   Rule Entry Identification -> Identify rule name, dataElement, regime, and optionality metadata.

2. •

   Rule-Level Path Scan (Credit Scope Only) -> Extract CDM model paths directly referenced in the reporting rule body. -> Retain only Credit-relevant paths.

3. •

   Sub-Function Enumeration -> List all functions invoked by the rule.

4. •

   Recursive Function Expansion (Single-Visit) -> Expand each function once. -> Extract all referenced CDM paths. -> Track source function name and best-effort line span.

5. •

   Path Classification -> Classify each extracted path into exactly one category:

   • •Return Paths (output-driving)
   • •Exists Paths (conditional gating via "X exists")
   • •Candidate Paths (fallback branches requiring human review)
6. •

   Alias Resolution (Canonical Expansion) -> Replace aliases with full explicit CDM paths wherever possible.

7. •

   Path Normalization and Cleanup -> Deduplicate paths. -> Keep paths minimal, canonical, and sheet-friendly. -> No non-Credit noise.

8. •

   JIRA2 ASCII Renderer Output -> Render final output using ONLY:

   • •{panel}
   • •{code} -> ASCII characters only ("->", no Unicode arrows/icons).

Outputs

Intermediate Artifacts

• •Function call list (rule -> sub-functions)
• •Per-function extracted CDM path set
• •Alias expansion mapping (alias -> canonical path)
• •Classification tags: [Return], [Exists], [Candidate]

Final Output (JIRA2 Wiki Markup, ASCII-only)

The skill produces a paste-ready JIRA2 ticket body with fixed sections:

• •Rule Overview panel
• •Extraction Logic panel
• •Paths - Return Paths panel
• •Paths - Conditional Exists Paths panel
• •Paths - Candidate/Fallback Paths panel
• •Coverage Notes panel (human-owned)

Each path entry includes:

• •Canonical CDM path (ASCII "->")
• •Category tag
• •Source function name
• •Best-effort line range or anchor

Failure Modes

• •Reporting rule is incomplete or truncated
• •Sub-function definitions are missing or inaccessible
• •Alias expansion cannot be resolved (cross-file or generator logic)
• •Line numbers cannot be reliably mapped (drift across versions)
• •Over-filtering removes relevant Credit gating paths

Failure Handling

• •Output unresolved paths with function-only attribution
• •Do not guess or infer missing dependencies
• •Explicitly mark limitations as human review required

Output Constraints (Hard Requirements)

• •JIRA2 wiki markup only: {panel} and {code}
• •ASCII-only characters (no Unicode arrows, no icons, no emoji)
• •Use "->" for path traversal
• •Always separate paths into:
  • •Return
  • •Exists
  • •Candidate
• •Never perform branch selection or business correctness judgment

JIRA2 Output Template (ASCII-safe)

h2. DRR Dependency Analysis - <FieldName>

{panel:title=Rule Overview}
Field: dataElement <N> - <FieldName>
Regime: MAS DRR
Optionality: Conditional (per Cirrus mapping)
Purpose: <One-line purpose statement>
Reference BR Jira: <Auto-filled from br.md if available>
{panel}

{panel:title=Extraction Logic}
{code}
<Reporting rule snippet>
{code}
{panel}

{panel:title=Paths - Return Paths (Output Driving)}
{code}
<CanonicalPath>
  [Return] @<SourceFunction> (Lxx-Lyy)
{code}
{panel}

{panel:title=Paths - Conditional Exists Paths (Gating Conditions)}
{code}
<CanonicalPath> (Exists)
  [Exists] @<SourceFunction> (Lxx-Lyy)
{code}
{panel}

{panel:title=Paths - Candidate / Fallback Paths (Human Review Needed)}
{code}
NOTE: Multiple branches exist. Final population path selection is a downstream decision.

<CanonicalPath>
  [Candidate] @<SourceFunction> (Lxx-Lyy)
{code}
{panel}

{panel:title=Coverage Notes (Out of Skill Scope)}
{code}
- Some paths may already be covered under IR or FX analysis.
- Coverage confirmation must be performed by Golden Key / Regime owners.
{code}
{panel}