nfr-capture

name	nfr-capture
skill	nfr-capture
description	Generate pre-populated NFR table for a system's HLD based on tier and project type
context	fork
arguments	[{"name":"system","description":"System name (e.g., \"ERPSystem\", \"DataPlatform\", \"AlertHub\")","required":true},{"name":"tier","description":"CS tier (CS1-CS4) — if omitted, skill will ask or run scoping questionnaire","required":false},{"name":"types","description":"Comma-separated project types (all,pci,gdpr,caa_nis) — if omitted, skill will ask","required":false},{"name":"output","description":"Output format — \"markdown\" (default), \"confluence\" (wiki markup), \"jira\" (for epic creation)","required":false},{"name":"flags","description":"Comma-separated flags — \"with-evidence-prompts\" (include AI draft prompts per NFR), \"from-hld:<page-id>\" (pre-fill evidence from existing HLD)","required":false}]
model	opus

/nfr-capture

Generate a pre-populated NFR requirements table for a system's HLD, filtered by classification tier and project type. Reads from the NFR-as-Code YAML single source of truth.

Usage

/nfr-capture ERPSystem
/nfr-capture ERPSystem CS2
/nfr-capture "AlertHub" CS1 all,gdpr
/nfr-capture DataPlatform CS2 all,pci,gdpr confluence
/nfr-capture ERPSystem CS2 all,gdpr markdown with-evidence-prompts
/nfr-capture ERPSystem CS2 all,gdpr markdown from-hld:664765269

Data Source

All NFR data is read from .claude/data/nfr-reference.yaml — the single source of truth for all 66 NFRs. Do NOT hard-code NFR content; always read from the YAML.

Instructions

Phase 1: Read NFR Data

1. Read .claude/data/nfr-reference.yaml
2. Parse the YAML to extract all sections, NFRs, scoping questions, and archetypes
3. Note the classification tiers from classification_tiers

Phase 2: Determine System Classification

Option A: Direct arguments — If tier and types are provided, use them.

Option B: Scoping questionnaire — If arguments are omitted, offer the user a choice:

1. Quick scoping — ask the 6 plain-English questions from scoping_questions in the YAML. Map answers to tier and types using the maps_to fields.
2. Archetype selection — show the archetypes from archetypes in the YAML and let the user pick one.
3. Manual selection — show the tier/type selection tables (original behaviour).

If only tier is omitted, show the tier selection table:

What is the Criticality / Service Level tier for [system]?

| Tier | Criticality | Availability | RTO | RPO |
|------|-------------|-------------|-----|-----|
| CS1/SL1 | Critical | 99.95% | 4 hours | Zero data loss |
| CS2/SL2 | High | 99.50% | 8 hours | 1 hour |
| CS3/SL3 | Medium | 99.00% | 5 working days | 1 day |
| CS4/SL4 | Low | 98.50% | 10 working days | 5 days |

If only types is omitted, show the type selection:

Which project types apply to [system]? (select all that apply)

- [ ] All Projects (mandatory baseline)
- [ ] PCI — system handles payment card data
- [ ] GDPR — system processes personal data of UK/EEA subjects
- [ ] CAA/NIS — system supports essential aviation services

Note: "All Projects" should always be selected as it is the mandatory baseline.

Phase 3: Filter NFRs

Using the selected tier and project types:

1. Include sections where the section's applicability overlaps with the selected project types:

   • Sections with applicability: [all] are always included
   • Sections with applicability: [pci] only included if PCI is selected
   • Sections with applicability: [gdpr] only included if GDPR is selected
   • Sections with applicability: [caa_nis] only included if CAA/NIS is selected
   • Some sections have multiple applicability values (e.g., [all, pci, gdpr, caa_nis]) — include if ANY match

2. Map CS tier to SL tier: CS1→SL1, CS2→SL2, CS3→SL3, CS4→SL4

3. Pre-fill tier values for tiered NFRs using the selected SL tier's tier_values

Phase 3b: Pre-fill from HLD (if from-hld:<page-id> flag)

If the from-hld flag is present:

1. Fetch the HLD page from Confluence using Atlassian MCP getConfluencePage with the given page ID
2. Parse the HLD content to identify sections that map to NFR requirements
3. For each applicable NFR, search the HLD content for evidence that addresses the requirement:
   • Look for mentions of: encryption configuration, IAM/RBAC setup, backup policies, monitoring stack, VPC/network design, scaling approach, DR strategy, data handling, compliance controls
   • Use keyword matching against the NFR's requirement, guidance, and aws_services fields
4. Pre-populate the evidence column with extracted content and source attribution:
   • Format: "Pre-filled from HLD page [ID], section [name]: [extracted evidence]"
5. Mark remaining empty cells for manual completion

Phase 4: Generate Output

Generate the NFR table in the requested format (default: markdown).

Markdown Output

For each applicable section, generate:

### [Section Name]

> **Purpose:** [section.purpose]
>
> **Compliance:** [section.compliance_frameworks joined]
>
> **Applicability:** [section.applicability_notes]

**Tier Targets ([CS tier] / [SL tier]):**

[If section has tier_guidance, render the selected tier's values as a summary table]

| NFR ID | Requirement | Target ([SL tier]) | Verification / Evidence | Status |
|--------|------------|---------------------|------------------------|--------|
| [nfr.id] | [nfr.title]: [nfr.requirement] | [tier_values for SL tier if tiered, else "See guidance"] | _[nfr.evidence_guidance]_ | |

Important formatting rules:

• Tier-specific values in the "Target" column should show the actual value for the selected tier, not all tiers
• Evidence guidance should be in italics as prompts for the team to fill in
• Status column is empty — teams fill this in (Met / Partial / Not Met / N/A)
• Include section intro boxes (purpose, compliance, applicability) as blockquotes
• If a section has tier_guidance at the section level, include a summary of the selected tier's values

With Evidence Prompts (with-evidence-prompts flag)

When this flag is present, add an additional column or section per NFR with an AI Evidence Prompt — a structured template the team can use to draft their evidence statement.

For each NFR, generate a prompt block after the table row:

<details>
<summary>AI Evidence Prompt for [NFR-ID]</summary>

**To draft evidence for this NFR, describe:**
- [Specific questions based on evidence_guidance field]
- [For automated evidence_type]: Which AWS Config rules or CLI commands can verify this? (See nfr-evidence-rules.yaml)
- [For manual evidence_type]: What documents, diagrams, or procedures demonstrate compliance?

**Example evidence statement:**
> [Generate a realistic example based on the NFR's requirement and evidence_guidance, using the system name and tier context]

</details>

For NFRs with evidence_type: automated, also include the specific AWS checks from .claude/data/nfr-evidence-rules.yaml:

**Automated checks available:**
- [check description]: `[command or config rule]`

Confluence Output

If output is confluence, generate Confluence wiki markup instead of markdown:

• Use || for header rows and | for data rows
• Use {info} macros for section intro boxes
• Use {status} macros for the Status column placeholders
• Include {page-properties} block at the top (see Phase 4b)

Confluence Page Properties (always included in Confluence output)

Add a {page-properties} block at the top of Confluence output:

{page-properties}
| NFR Status | Draft |
| NFR Tier | [CS tier] |
| NFR Sections Applicable | [included] of 13 |
| NFR Completion | 0/[total] (0%) |
| NFR Last Reviewed | [today's date] |
{page-properties}

This enables estate-wide dashboards via Confluence {page-properties-report}.

Jira Output

If output is jira, generate a structured list suitable for creating a Jira Epic:

• Epic: "NFR Compliance — [System Name] ([CS tier])"
• One story per NFR with:
  • Summary: "[NFR ID] — [NFR title]"
  • Description: requirement text + guidance + evidence guidance
  • Labels: nfr, [section-id lowercase]
  • Priority mapped from tier (CS1→Critical, CS2→High, CS3→Medium, CS4→Low)

Phase 5: Write Output

1. Console output (default): Print the generated table to the terminal
2. If the user requests, write to a vault note:
   • Location: Root directory
   • Filename: Concept - NFR Capture - [System Name].md
   • Include proper frontmatter:

---
type: Concept
title: "NFR Capture - [System Name]"
created: [today]
modified: [today]
tags:
  - activity/governance
  - activity/architecture
  - domain/engineering
confidence: high
freshness: current
source: synthesis
verified: false
reviewed: [today]
keywords: [nfr, nfr-capture, [system-name lowercase]]
relatedTo:
  - "[[Pattern - NFR Standards and Governance]]"
---

3. Optionally push to Confluence using Atlassian MCP tools:
   • Use createConfluencePage to create as child of system's HLD page
   • Only if user explicitly requests Confluence push

Output Summary

After generating the table, print a summary:

NFR Capture Summary for [System Name] ([CS tier]/[SL tier])
- Sections included: [count] of 13
- NFRs included: [count] of 66
- Sections excluded: [list excluded section names with reason]
- Tiered NFRs: [count] with [SL tier] values pre-filled
- Evidence types: [count automated] automated, [count manual] manual
- Pre-filled from HLD: [count] NFRs (if from-hld flag used)
- Evidence prompts: included (if with-evidence-prompts flag used)

Related

• .claude/data/nfr-reference.yaml — NFR single source of truth
• .claude/data/nfr-evidence-rules.yaml — Automated AWS evidence checks for 37 NFRs
• .claude/skills/nfr-review/SKILL.md — Gap analysis against existing HLDs
• .claude/skills/nfr-jira-epic/SKILL.md — Create Jira Epic with stories per NFR
• Pattern - NFR Standards and Governance — Tiered framework context
• Pattern - NFR Compliance Evidence Best Practices — Evidence patterns