qa-skills 3.0.0 → 3.1.0

package/skills/qa-test-doc-compiler/SKILL.md

@@ -1,114 +0,0 @@
----
-name: qa-test-doc-compiler
-description: Compile formal test documentation per ISO/IEC/IEEE 29119-3 including test policies, plans, specifications, execution logs, incident reports, and completion reports.
-output_dir: docs/compiled
-dependencies:
-  recommended:
-    - qa-test-reporter
----
-
-# QA Test Doc Compiler
-
-## Purpose
-
-Compile formal test documentation per ISO/IEC/IEEE 29119-3. Collect inputs from other QA skills, organize content per ISO structure, format documents, and validate completeness. Supports tailoring for Agile, Scrum, and DevOps contexts.
-
-## Document Types
-
-| Category | Document Types |
-| -------- | -------------- |
-| **Governance** | Test Policy, Organizational Test Practices |
-| **Planning** | Project Test Plan, Level Test Plans (unit/integration/system/acceptance), Type Test Plans (functional/performance/security) |
-| **Specification** | Test Model Specification, Test Case Specification, Test Procedure Specification |
-| **Execution** | Test Execution Log, Test Incident Report |
-| **Reporting** | Test Status Report, Test Completion Report |
-| **Readiness** | Test Data Requirements, Test Environment Requirements, Test Data Readiness Report, Test Environment Readiness Report |
-
-See `references/iso-29119-3-documents.md` for required sections per document type.
-
-## Document Compilation Workflow
-
-1. **Collect inputs** — Gather content from other skills:
-   - `qa-requirements-generator` → requirements, acceptance criteria
-   - `qa-plan-creator` → test plans, sprint plans, release plans
-   - `qa-spec-writer` → specifications, acceptance criteria
-   - `qa-testcase-from-docs` → test cases, RTM
-   - `qa-nfr-analyst` → NFR criteria for performance/security plans
-   - Manual inputs: execution logs, incident reports, status updates
-
-2. **Organize per ISO structure** — Map content to ISO 29119-3 document templates. Use `references/iso-29119-3-documents.md` for mandatory/recommended sections.
-
-3. **Format** — Apply consistent formatting (Markdown, tables, traceability IDs). Call `qa-diagram-generator` for Gantt charts, flowcharts, or RTM visualizations when needed.
-
-4. **Validate completeness** — Check:
-   - All mandatory sections present
-   - Traceability links preserved (requirement → test model → test case → procedure)
-   - IDs follow project conventions
-   - No orphaned references
-
-5. **Tailor for context** — If Agile/DevOps, apply `references/agile-tailoring.md` to reduce ceremony and merge documents where appropriate.
-
-## Trigger Phrases
-
-- "Compile test documentation per ISO 29119-3"
-- "Create test policy / organizational test practices"
-- "Assemble test plan from [sources]"
-- "Format test execution log / incident report"
-- "Generate test completion report"
-- "Tailor ISO 29119-3 for Agile/DevOps"
-
-## Scope
-
-**Can do (autonomous):**
-- Compile any ISO 29119-3 document type from provided inputs
-- Organize content into ISO structure
-- Merge outputs from multiple QA skills into coherent documents
-- Apply Agile/DevOps tailoring per reference guide
-- Call qa-diagram-generator for timelines, RTM, flowcharts
-- Validate mandatory sections and traceability
-
-**Cannot do (requires confirmation):**
-- Create content from scratch without inputs (policy, practices, plans need stakeholder input)
-- Override organizational test policy or practices
-- Change scope or priorities set by stakeholders
-
-**Will not do (out of scope):**
-- Execute tests or automation
-- Modify production code or environments
-- Approve documents (approval is stakeholder responsibility)
-- Generate test code
-
-## Embedding: Diagram Generator
-
-When visualization is needed, reference qa-diagram-generator:
-- **Timelines** → `references/gantt.md`
-- **Traceability** → `references/flowchart.md` or mindmap
-- **Test flow** → `references/sequence.md`
-
-## Quality Checklist
-
-- [ ] Document type matches ISO 29119-3 definition
-- [ ] All mandatory sections present per `references/iso-29119-3-documents.md`
-- [ ] Traceability links preserved (REQ → model → case → procedure)
-- [ ] IDs follow project conventions (e.g., TC-001, TIR-001)
-- [ ] Agile tailoring applied when context is Agile/DevOps
-- [ ] No hardcoded secrets or sensitive data
-- [ ] Format consistent (Markdown, tables, headings)
-
-## Troubleshooting
-
-| Symptom | Likely Cause | Fix |
-| ------- | ------------ | --- |
-| Missing mandatory sections | Inputs incomplete or wrong document type | Check `references/iso-29119-3-documents.md`; request missing inputs |
-| Broken traceability links | IDs changed or content merged incorrectly | Re-map requirement → test case links; validate RTM |
-| Document too heavy for Agile | Full ISO structure applied | Apply `references/agile-tailoring.md`; merge/omit non-essential sections |
-| Inconsistent formatting | Multiple sources with different styles | Normalize to single template; use consistent ID prefixes |
-| Orphaned references | Deleted or renamed items | Audit references; update or remove broken links |
-| Policy conflicts with plan | Stakeholder input contradicts | Flag for resolution; do not override policy |
-
-## Reference Files
-
-| Topic | File |
-| ----- | ---- |
-| ISO 29119-3 document types & sections | `references/iso-29119-3-documents.md` |
-| Agile/Scrum/DevOps tailoring | `references/agile-tailoring.md` |

package/skills/qa-test-doc-compiler/references/agile-tailoring.md

@@ -1,220 +0,0 @@
-# Agile/Scrum/DevOps Tailoring Guide for ISO 29119-3
-
-*How to adapt ISO/IEC/IEEE 29119-3 test documentation for Agile, Scrum, and DevOps contexts while preserving traceability and compliance.*
-
-## Principles
-
-1. **Reduce ceremony, not traceability** — Merge documents, shorten cycles, but keep requirement → test case links.
-2. **Living documents** — Confluence pages, wiki, or repo Markdown instead of static PDFs.
-3. **Automation-friendly** — Structure for tool integration (Jira, Zephyr, TestRail, Allure).
-4. **Just enough** — Include only what adds value for the team and stakeholders.
-
----
-
-## Document Merging Strategies
-
-### Option A: Minimal Set (Sprint-based)
-
-| ISO Document | Agile Equivalent |
-|--------------|------------------|
-| Test Policy | Org-level; rarely changes; 1-page summary |
-| Organizational Test Practices | Definition of Done, DoD for testing; wiki page |
-| Project Test Plan | Release/sprint 0 doc; high-level only |
-| Level/Type Test Plans | Merged into single "Test Approach" section |
-| Test Model Specification | Inline in test case or BDD feature file |
-| Test Case Specification | Jira/Zephyr/TestRail; or Markdown in repo |
-| Test Procedure Specification | Steps in test case; or automated (code = procedure) |
-| Test Execution Log | CI/CD results; JUnit/Allure/TestRail |
-| Test Incident Report | Bug ticket (Jira, GitHub Issues) |
-| Test Status Report | Sprint burndown, dashboard, standup notes |
-| Test Completion Report | Release retrospective; 1-page summary |
-| Test Data/Environment Requirements | README or runbook; as-needed |
-| Readiness Reports | Checklist in Confluence; or omitted if self-evident |
-
-### Option B: Hybrid (Regulated / Contract)
-
-Keep formal documents for audit, but:
-- Use templates; auto-populate from tools where possible
-- Generate Test Completion Report from CI + bug tracker
-- Keep Test Policy and Organizational Test Practices as living docs, reviewed quarterly
-
-### Option C: DevOps / Continuous Delivery
-
-- **Test Plan** → Pipeline config, quality gates, deployment criteria
-- **Test Case** → Automated test code + BDD scenarios
-- **Execution Log** → CI logs, Allure/JUnit XML
-- **Incident Report** → Bug ticket linked to failing test
-- **Status/Completion** → Dashboard (Grafana, custom); no separate report unless requested
-
----
-
-## Tailoring by Document Type
-
-### Test Policy
-
-| Full ISO | Agile Tailoring |
-|----------|------------------|
-| Multi-page policy | 1-page summary: objectives, principles, governance |
-| Formal approval cycle | Living doc; reviewed at org retro |
-| Detailed roles | Link to RACI; keep high-level only |
-
-### Organizational Test Practices
-
-| Full ISO | Agile Tailoring |
-|----------|------------------|
-| Separate document | Merge into "Testing" section of team wiki |
-| Detailed process | Definition of Done for testing; Definition of Ready |
-| Tool strategy | Tool section; link to pipeline docs |
-
-### Project Test Plan
-
-| Full ISO | Agile Tailoring |
-|----------|------------------|
-| Full 13-section plan | Release/sprint 0: scope, approach, entry/exit, risks |
-| Level + Type plans | Single "Test Approach" table: level × type × tools |
-| Formal approvals | Async sign-off; or Product Owner acceptance |
-
-### Test Model Specification
-
-| Full ISO | Agile Tailoring |
-|----------|------------------|
-| Standalone document | Inline in BDD feature (Given/When/Then) or test case |
-| Formal traceability | Link in test case to requirement ID |
-| Diagrams | Use qa-diagram-generator; embed in Confluence |
-
-### Test Case Specification
-
-| Full ISO | Agile Tailoring |
-|----------|------------------|
-| Formal document | Test management tool (Zephyr, TestRail) or Markdown table |
-| Full preconditions | Condensed; link to setup docs |
-| Traceability | Requirement ID in test case; RTM auto-generated |
-
-### Test Procedure Specification
-
-| Full ISO | Agile Tailoring |
-|----------|------------------|
-| Separate procedure doc | Steps in test case; or automated test = procedure |
-| Manual procedures | Keep for manual/exploratory; automate where possible |
-
-### Test Execution Log
-
-| Full ISO | Agile Tailoring |
-|----------|------------------|
-| Manual log | CI/CD results; JUnit XML, Allure, TestRail |
-| Per-execution record | Pipeline run = execution; link build to test results |
-| Manual tests | Log in tool; or lightweight spreadsheet |
-
-### Test Incident Report
-
-| Full ISO | Agile Tailoring |
-|----------|------------------|
-| Formal TIR template | Bug ticket (Jira, GitHub Issues) with: expected, actual, steps, severity |
-| Separate numbering | Use ticket ID (e.g., PROJ-123) |
-| Traceability | Link bug to test case ID |
-
-### Test Status Report
-
-| Full ISO | Agile Tailoring |
-|----------|------------------|
-| Periodic report | Sprint burndown, dashboard, standup summary |
-| Formal document | Omit; or 1-page sprint test summary if stakeholder needs |
-| Metrics | Coverage %, pass rate, open bugs; auto from tools |
-
-### Test Completion Report
-
-| Full ISO | Agile Tailoring |
-|----------|------------------|
-| Formal report | Release retrospective; 1-page: summary, exit criteria met, recommendations |
-| Full metrics | Link to dashboard; summarize key numbers |
-| Lessons learned | Part of retro; optional section |
-
-### Test Data / Environment Requirements
-
-| Full ISO | Agile Tailoring |
-|----------|------------------|
-| Formal document | README, runbook, or Confluence page |
-| Readiness reports | Checklist; or omit if team self-manages |
-| Traceability | Link from test plan or wiki |
-
----
-
-## Scrum-Specific Patterns
-
-### Sprint Cycle
-
-| Phase | Documents |
-|-------|-----------|
-| **Sprint Planning** | Sprint Test Plan (lightweight) or Test Approach in sprint goal |
-| **Development** | Test cases in backlog; BDD scenarios in code |
-| **Daily** | No formal doc; standup covers blockers |
-| **Sprint Review** | Demo = informal execution; bugs logged |
-| **Sprint Retro** | Update Organizational Test Practices if needed |
-| **Release** | Test Completion Report (1-page) if release sign-off required |
-
-### Definition of Done (Testing)
-
-Include in DoD:
-- [ ] Test cases written for new/changed features
-- [ ] Automated tests in pipeline where applicable
-- [ ] No critical/high bugs open for release scope
-- [ ] Test execution logged (CI or manual log)
-- [ ] Traceability: requirement → test case
-
-### Definition of Ready (Testing)
-
-- [ ] Acceptance criteria defined
-- [ ] Test environment available
-- [ ] Test data identified
-- [ ] Dependencies known
-
----
-
-## DevOps-Specific Patterns
-
-### Pipeline as Documentation
-
-- **Test Plan** → Quality gates in pipeline (e.g., 80% pass, no critical failures)
-- **Test Procedure** → Test code
-- **Execution Log** → CI run logs, Allure report
-- **Incident Report** → Bug created from failed test; auto-link
-
-### Quality Gates
-
-Define in pipeline config:
-- Unit test pass rate
-- Integration test pass rate
-- Coverage threshold
-- Security scan (OWASP, Snyk)
-- Performance baseline (optional)
-
-### Dashboards
-
-Replace Test Status Report with:
-- Pass/fail trend
-- Coverage trend
-- Open bugs by severity
-- Deployment frequency
-- Mean time to recovery (MTTR)
-
----
-
-## Checklist: Applying Tailoring
-
-- [ ] Context identified: Agile / Scrum / DevOps / Hybrid
-- [ ] Document set chosen: Minimal / Hybrid / Full
-- [ ] Merged documents listed (e.g., "Test Plan + Level Plans → single doc")
-- [ ] Omitted sections documented (e.g., "Readiness reports omitted; checklist in Confluence")
-- [ ] Tool integration specified (Jira, Zephyr, CI, etc.)
-- [ ] Traceability preserved (requirement → test case → execution → incident)
-- [ ] Stakeholder sign-off approach defined (async, PO, formal)
-- [ ] Review cadence set (sprint, release, quarterly)
-
----
-
-## When NOT to Over-Tailor
-
-- **Regulated domains** (medical, finance, aviation): Keep formal documents; tailor format, not content.
-- **Contractual requirements**: Customer may require specific ISO documents; confirm before omitting.
-- **Audit trail**: If audits occur, ensure tool exports or generated reports satisfy auditors.
-- **Distributed teams**: Slightly more documentation helps remote collaboration.

package/skills/qa-test-doc-compiler/references/iso-29119-3-documents.md

@@ -1,302 +0,0 @@
-# ISO/IEC/IEEE 29119-3 Document Types Reference
-
-*Per ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentation*
-
-## Document Hierarchy
-
-```
-Test Policy
-    └── Organizational Test Practices
-            └── Project Test Plan
-                    ├── Level Test Plans (unit/integration/system/acceptance)
-                    ├── Type Test Plans (functional/performance/security)
-                    └── Test Specifications
-                            ├── Test Model Specification
-                            ├── Test Case Specification
-                            └── Test Procedure Specification
-```
-
----
-
-## Governance Documents
-
-### Test Policy
-
-**Purpose:** High-level organizational commitment to testing. Defines testing objectives, principles, and governance.
-
-| Section | Mandatory | Recommended | Description |
-|---------|-----------|-------------|-------------|
-| Purpose | ✓ | | Why the policy exists |
-| Scope | ✓ | | Organizational scope |
-| Testing objectives | ✓ | | High-level goals |
-| Testing principles | | ✓ | Guiding principles |
-| Roles and responsibilities | | ✓ | Who governs testing |
-| References | | ✓ | Related standards, policies |
-
----
-
-### Organizational Test Practices
-
-**Purpose:** Describes how the organization implements testing. Operationalizes the Test Policy.
-
-| Section | Mandatory | Recommended | Description |
-|---------|-----------|-------------|-------------|
-| Purpose | ✓ | | Purpose of the practices |
-| Scope | ✓ | | Applicability |
-| Test process description | ✓ | | How testing is performed |
-| Test documentation practices | ✓ | | Which documents are used |
-| Test environment management | | ✓ | Environment setup and control |
-| Test data management | | ✓ | Data creation, masking, retention |
-| Tools and automation | | ✓ | Tool strategy |
-| References | | ✓ | Test Policy, standards |
-
----
-
-## Planning Documents
-
-### Project Test Plan
-
-**Purpose:** Describes the testing approach for a specific project. May be decomposed into Level and Type Test Plans.
-
-| Section | Mandatory | Recommended | Description |
-|---------|-----------|-------------|-------------|
-| Introduction | ✓ | | Purpose, scope, definitions |
-| Test items | ✓ | | Features to test, features not to test |
-| Test approach | ✓ | | Strategy per level/type |
-| Pass/fail criteria | ✓ | | Measurable criteria |
-| Entry criteria | ✓ | | Conditions to start testing |
-| Exit criteria | ✓ | | Conditions to complete testing |
-| Suspension/resumption | ✓ | | When to halt/resume |
-| Deliverables | ✓ | | Expected artifacts |
-| Test environment | ✓ | | Environment requirements |
-| Schedule | ✓ | | Timeline, milestones |
-| Staffing | ✓ | | Roles, responsibilities |
-| Risks and contingencies | | ✓ | Risks and mitigations |
-| Approvals | | ✓ | Sign-off table |
-
----
-
-### Level Test Plans
-
-**Purpose:** Plans for a specific test level (unit, integration, system, acceptance).
-
-| Level | Description |
-|-------|-------------|
-| **Unit** | Component-level testing |
-| **Integration** | Interface and interaction testing |
-| **System** | End-to-end system testing |
-| **Acceptance** | User/business acceptance |
-
-**Sections:** Same structure as Project Test Plan, scoped to the level. May reference parent Project Test Plan for shared elements.
-
----
-
-### Type Test Plans
-
-**Purpose:** Plans for a specific test type (functional, performance, security, etc.).
-
-| Type | Description |
-|------|-------------|
-| **Functional** | Functional behavior verification |
-| **Performance** | Load, stress, scalability |
-| **Security** | Security vulnerabilities, OWASP |
-| **Usability** | UX, accessibility (WCAG) |
-| **Compatibility** | Browsers, devices, OS |
-
-**Sections:** Same structure as Project Test Plan, scoped to the type. May reference NFR criteria from qa-nfr-analyst.
-
----
-
-## Specification Documents
-
-### Test Model Specification
-
-**Purpose:** Describes test models used to derive test cases. Replaces "test conditions" in ISO 29119-3:2021. Models include state diagrams, decision tables, equivalence classes, boundary values.
-
-| Section | Mandatory | Recommended | Description |
-|---------|-----------|-------------|-------------|
-| Identifier | ✓ | | Unique ID (e.g., TMS-001) |
-| Purpose | ✓ | | Purpose of the model |
-| Scope | ✓ | | What the model covers |
-| Model description | ✓ | | Model content (diagram, table, etc.) |
-| Traceability | ✓ | | Links to requirements |
-| References | | ✓ | Source requirements, specs |
-
----
-
-### Test Case Specification
-
-**Purpose:** Defines individual test cases derived from test models.
-
-| Section | Mandatory | Recommended | Description |
-|---------|-----------|-------------|-------------|
-| Identifier | ✓ | | Unique ID (e.g., TC-001) |
-| Purpose | ✓ | | Purpose of the test case |
-| Preconditions | ✓ | | Prerequisites |
-| Input specifications | ✓ | | Test inputs |
-| Expected results | ✓ | | Expected outcomes |
-| Postconditions | | ✓ | State after execution |
-| Traceability | ✓ | | Links to test model, requirements |
-| Priority | | ✓ | Priority level |
-
----
-
-### Test Procedure Specification
-
-**Purpose:** Step-by-step instructions for executing test cases.
-
-| Section | Mandatory | Recommended | Description |
-|---------|-----------|-------------|-------------|
-| Identifier | ✓ | | Unique ID (e.g., TPS-001) |
-| Purpose | ✓ | | Purpose of the procedure |
-| Test cases covered | ✓ | | TC-001, TC-002, ... |
-| Prerequisites | ✓ | | Setup requirements |
-| Procedure steps | ✓ | | Numbered steps |
-| Expected results per step | | ✓ | Per-step expectations |
-| Traceability | ✓ | | Links to test cases |
-
----
-
-## Execution Documents
-
-### Test Execution Log
-
-**Purpose:** Records the execution of test procedures. Captures date, tester, result, actual vs expected.
-
-| Section | Mandatory | Recommended | Description |
-|---------|-----------|-------------|-------------|
-| Identifier | ✓ | | Log ID |
-| Test procedure | ✓ | | TPS reference |
-| Execution date/time | ✓ | | When executed |
-| Tester | ✓ | | Who executed |
-| Result | ✓ | | Pass/Fail/Blocked/Skipped |
-| Actual results | ✓ | | What was observed |
-| Environment/build | | ✓ | SUT version, build ID |
-| Evidence | | ✓ | Screenshots, logs |
-
----
-
-### Test Incident Report (Bug Report / Defect Report)
-
-**Purpose:** Records deviations between expected and actual results. Synonymous with bug report, defect report.
-
-| Section | Mandatory | Recommended | Description |
-|---------|-----------|-------------|-------------|
-| Identifier | ✓ | | Unique ID (e.g., TIR-001) |
-| Summary | ✓ | | Brief description |
-| Test case/procedure | ✓ | | Which test failed |
-| Expected result | ✓ | | What was expected |
-| Actual result | ✓ | | What occurred |
-| Steps to reproduce | ✓ | | How to reproduce |
-| Severity/priority | | ✓ | Impact and urgency |
-| Status | | ✓ | Open, fixed, deferred |
-| Environment | | ✓ | Build, OS, browser |
-| Evidence | | ✓ | Attachments |
-
----
-
-## Reporting Documents
-
-### Test Status Report
-
-**Purpose:** Periodic progress report during test execution.
-
-| Section | Mandatory | Recommended | Description |
-|---------|-----------|-------------|-------------|
-| Identifier | ✓ | | Report ID |
-| Reporting period | ✓ | | Date range |
-| Summary | ✓ | | Executive summary |
-| Test execution summary | ✓ | | Pass/fail/blocked counts |
-| Incidents | ✓ | | Open/closed incident summary |
-| Risks and issues | | ✓ | Blockers, risks |
-| Next period plan | | ✓ | Planned activities |
-| Metrics | | ✓ | Coverage, progress % |
-
----
-
-### Test Completion Report
-
-**Purpose:** Final report when testing is complete. Summarizes outcomes and recommendations.
-
-| Section | Mandatory | Recommended | Description |
-|---------|-----------|-------------|-------------|
-| Identifier | ✓ | | Report ID |
-| Summary | ✓ | | Executive summary |
-| Test execution summary | ✓ | | Final pass/fail/blocked counts |
-| Exit criteria met | ✓ | | Whether criteria were satisfied |
-| Incidents summary | ✓ | | Open, closed, deferred |
-| Recommendations | ✓ | | Release readiness, follow-up |
-| Lessons learned | | ✓ | Process improvements |
-| Metrics | | ✓ | Coverage, defect density |
-
----
-
-## Readiness Documents
-
-### Test Data Requirements
-
-**Purpose:** Specifies data needed for testing.
-
-| Section | Mandatory | Recommended | Description |
-|---------|-----------|-------------|-------------|
-| Identifier | ✓ | | Document ID |
-| Purpose | ✓ | | Purpose of the data |
-| Data requirements | ✓ | | Types, volumes, characteristics |
-| Data sources | | ✓ | Where data comes from |
-| Privacy/security | | ✓ | Masking, anonymization |
-| Traceability | | ✓ | Links to test cases |
-
----
-
-### Test Environment Requirements
-
-**Purpose:** Specifies environment needed for testing.
-
-| Section | Mandatory | Recommended | Description |
-|---------|-----------|-------------|-------------|
-| Identifier | ✓ | | Document ID |
-| Purpose | ✓ | | Purpose of the environment |
-| Hardware | ✓ | | Servers, devices |
-| Software | ✓ | | OS, middleware, tools |
-| Network | | ✓ | Connectivity requirements |
-| Access/credentials | | ✓ | Access requirements (no secrets) |
-| Traceability | | ✓ | Links to test plans |
-
----
-
-### Test Data Readiness Report
-
-**Purpose:** Confirms test data is ready for use.
-
-| Section | Mandatory | Recommended | Description |
-|---------|-----------|-------------|-------------|
-| Identifier | ✓ | | Report ID |
-| Status | ✓ | | Ready/Not ready |
-| Data sets | ✓ | | What was prepared |
-| Gaps | | ✓ | Missing or incomplete data |
-| Traceability | | ✓ | Links to Test Data Requirements |
-
----
-
-### Test Environment Readiness Report
-
-**Purpose:** Confirms test environment is ready for use.
-
-| Section | Mandatory | Recommended | Description |
-|---------|-----------|-------------|-------------|
-| Identifier | ✓ | | Report ID |
-| Status | ✓ | | Ready/Not ready |
-| Components | ✓ | | What was set up |
-| Gaps | | ✓ | Missing or incomplete components |
-| Traceability | | ✓ | Links to Test Environment Requirements |
-
----
-
-## Information Element Necessity
-
-ISO 29119-3 classifies each information element as:
-- **Mandatory** — Must be present
-- **Recommended** — Should be present unless tailored out
-- **Possible** — Optional, include when useful
-
-Tailoring is permitted; document which elements are omitted and why.