rcs-report-generator

name: rcs-report-generator description: > Generate Safetysure RCS (respirable crystalline silica) dust survey reports with exact template fidelity. Use this skill when the user asks to "generate an RCS report", "write a dust monitoring report", "create an air monitoring report", "draft an RCS survey report", or provides monitoring data and asks for a compliance report. Also trigger on the /rcs-report command. Includes an HTML data capture intake form and produces reports section-by-section in markdown preview before final .docx assembly. Cross-references the safetysure-whs-legislation plugin for verified legislative provisions. version: 0.2.0 changelog: 0.2.0: Consolidated plugin — removed duplicate WHS checkers, now reference safetysure-whs-legislation plugin

RCS Dust Survey Report Generator

Purpose

Generate Safetysure respirable crystalline silica (RCS) dust survey reports faithful to the established template. Reports are produced section-by-section in markdown preview for review, then assembled into a formatted .docx document.

CRITICAL PRINCIPLE: Template language fidelity. The language, tone, sentence structure, and phrasing in the section templates represent the Safetysure house style. When generating report sections, reproduce this language exactly — do not paraphrase, simplify, reword, or "improve" the template text. Insert project-specific data only where placeholders indicate.

Dependencies

Cross-reference these companion skills in the safetysure-whs-legislation plugin:

• whs-regulation-checker-qld — Chapter 8A (Crystalline Silica), Chapter 3 (Risk Management), Chapter 7 (Hazardous Chemicals)
• whs-act-checker-qld — PCBU duties (s 19), officer duties (s 27), consultation obligations, incident notification

When citing legislative provisions or technical standards, always load and verify from the safetysure-whs-legislation plugin skills rather than citing from memory.

Data Capture

An interactive HTML intake form is bundled at references/RCS_Report_Intake_Form.html. The user fills this in with all project-specific data and exports as JSON. The JSON file contains all fields needed to populate the report. If the user provides data in another format (pasted text, spreadsheet, conversation), map it to the intake form fields before generating.

Complete Report Structure

The report follows this exact structure. Do not reorder, rename, or omit sections.

Front Matter: Cover Page → Document Control → List of Terms and Abbreviations → Limitations → Executive Summary → Table of Contents

Body: Section 1 Regulatory Framework → Section 2 Introduction → Section 3 Methodology (3.1 SEGs, 3.2 Equipment, 3.3 Analysis, 3.4 Approach to Assessment) → Section 4 Workplace Exposure Limits (4.1 Exposure Standards, 4.2 Shift Adjustment) → Section 5 Site Observations → Section 6 Results (6.1 RD, 6.2 RCS, 6.3 RCS:RD Ratio) → Section 7 Discussion → Section 8 Recommendations → Section 9 Conclusion → Section 10 References

Appendices: A Sampling Details → B Laboratory Certificates → C Site Photographs

Workflow

CRITICAL: Never generate the entire report in a single pass.

Step 1 — Information Gathering. Check the user has provided all essential data: client/site details, monitoring dates, consultant details, SEG definitions, sampling equipment, laboratory results (all sample IDs, durations, results), and shift lengths. Ask for missing essentials before proceeding. Use [INSERT: description] placeholders only as a last resort.

Step 2 — Section-by-Section Generation. Generate each section individually in markdown preview. Do NOT proceed to the next section until the user explicitly instructs. Wait for review and approval before moving on.

Generation order — substantive sections first, summary last:

Phase 1 (body sections, in order): Sections 1 → 2 → 3 → 4 → 5 → 6 → 7 → 8 → 9 → 10

Phase 2 (front matter, written last with full context): Executive Summary → Limitations → Terms/Abbreviations → Cover Page → Document Control → Table of Contents

Never generate more than one major section per turn.

Step 3 — Calculations. Before generating Section 6 (Results), perform and present all calculations for user verification:

• Shift-adjusted TWA: TWA₈ₕᵣ = (C × t) / 480
• Percentage of WEL: (Shift-adjusted TWA / WEL) × 100
• RCS:RD ratio: RCS result / RD result
• Compliance assessment per AIOH framework: <10% well below, 10–50% below, 50–100% approaching, ≥100% exceeds
• Results below LOR: report as "< [LOR]", use LOR/2 for statistical calculations

Step 4 — Assembly. After all sections approved, assemble into .docx using the docx skill. Apply Safetysure formatting: heading hierarchy, bordered tables with header shading, page numbers, landscape for wide tables.

Section Templates

Detailed template language for every section is in the references directory. Read the relevant template file before generating each section:

Language and Tone

1. Australian English — analyse, minimise, behaviour, programme
2. Conservative, neutral language — no "significant risk", "serious concern", "deterioration", "alarming". State measured values, applicable limits, and factual comparison.
3. Technical precision — correct units (mg/m³, L/min, µm), correct standard references (AS 2985:2009), correct regulation references (r 529F, not "Regulation 529F")
4. Template fidelity — reproduce template language verbatim. Insert project data only at placeholders.
5. Executive Summary headings — "What we did", "What we found", "What this means", "Key recommendations", "How Safetysure Can Help" must be used exactly as written.

Error Prevention

• Never fabricate monitoring data — all results from user or lab certificates
• Never cite a regulation without verifying via safetysure-whs-legislation plugin skills
• Never assume WEL values — verify against Schedule 14
• Never omit results exceeding the WEL — report all results transparently
• Never use "safe" — use "compliant with the WEL" or "below the WEL"
• Never invent references — only cite verifiably existing publications
• Flag anomalous data to the user rather than silently accepting