report-qa

name: report-qa description: > Use this skill after generating a daily report to review it for completeness, consistency, and accuracy against project intelligence. Catches missing inspections, unrecognized subs, weather threshold conflicts, and other gaps before the report is finalized. version: 1.0.0

Report QA

Overview

Review a generated daily report against project intelligence to catch gaps, inconsistencies, and missing information before the report is finalized. This skill runs automatically after report generation as a quality check.

When to Run

This skill is triggered after the daily-report-format skill generates the report content but before the final .docx is created. It reviews the structured report data and flags issues that should be addressed.

QA Mode Selection

This skill operates in one of two modes, determined by the calling command:

The calling command determines the mode. When called from /daily-report or /amend-report, run ONLY the daily checks (1–10). When called from /weekly-report, run ONLY the weekly checks (W1–W6). Never run both sets on the same report.

Amended reports: When called from /amend-report, run daily QA checks ONLY on the sections that were modified. Present results with the prefix "Amendment QA" and note which sections were re-checked.

QA Check Categories

1. Subcontractor Validation

Check: Every sub mentioned in the Crew section exists in the project sub directory.

2. Weather vs. Work Threshold Check

Check: Compare today's reported weather against weather thresholds for the work documented.

3. Inspection Awareness

Check: Based on the work documented today, were required inspections noted?

Conditional Hold Point Logic:

Some hold points are conditional — they only apply when certain thresholds are met:

• Concrete volume > X CY may trigger additional testing requirements
• Steel connections above certain heights may require special inspection
• Work in specific zones (healthcare, clean room) may require additional sign-offs

When checking hold points against reported work:

1. Load hold points for the work type from specs-quality.json
2. If the hold point has a condition field, evaluate it against the reported work details
3. Only flag missing inspections when the condition is met
4. If the condition can't be evaluated (missing data), flag as INFO rather than WARNING: "Hold point may apply — verify if [condition] is met"

4. Schedule Consistency

Check: Report's schedule section aligns with known project intelligence.

5. Photo Coverage

Check: Photos are present for major work activities.

6. Completeness Check

Check: All report sections have content or are intentionally blank.

Quantity Discrepancy Check:

When a daily report documents concrete placement, flooring installation, or any measurable work:

1. Look up the relevant quantities in plans-spatial.json for that element/location
2. Check the data_sources.discrepancies array for any flagged conflicts
3. If discrepancies exist for the work being documented, add a NOTE: "Quantity discrepancy flagged for [element] — [source A] shows [value] vs [source B] shows [value]. Verify actual field measurement."
4. If the reported quantity in the daily report differs from ALL extracted sources by >15%, flag: "Reported [quantity] for [element] differs significantly from plan quantities. Confirm measurement."

6.1 New Hold Point Detection

Check: After /process-docs adds new spec sections, verify if new hold points were added to specs-quality.json:

When running report-qa on any report following a spec update:

• Compare current hold_points in specs-quality.json against the report-qa's cached list
• If new hold points exist that weren't previously tracked, add a NOTE to the current report: "New hold point added from spec section [XX XX XX]: [description]. Future reports involving [work type] will be checked against this."
• Update the cached hold points list to include the newly discovered entries

7. SWPPP Check (if applicable)

Check: If project has a SWPPP and rain was reported, was an inspection documented?

8. Safety Check (if applicable)

Check: If work in safety-sensitive areas was documented, were safety measures noted?

9. Delay Documentation Completeness

If delay events are documented in today's report, verify they contain sufficient detail for the delay-tracker and (if applicable) claims-documentation skills.

10. Claims Mode Compliance

Only runs when claims_mode: true in project-config.json. When claims mode is inactive, skip this entire section.

Verify that claims-grade detail is captured where available. These are notes and flags, not hard requirements — the superintendent can dismiss any of them.

Output format: Claims compliance results appear in a separate "Claims Mode" tier after the standard flags/notes/passes:

CLAIMS MODE:
• Worker names missing for Smith Electric (3 workers). Recommended for claims documentation.
• Delivery ticket not captured for rebar delivery from Harris Steel.
✓ Delay events fully documented with timing and activities
✓ Equipment IDs captured for all equipment

Project Intelligence Integration

When running QA checks, automatically cross-reference the report against the full project intelligence store. These checks supplement the category-specific checks above by catching gaps that span multiple data sources.

Punch List Cross-Check

Read punch-list.json → If the daily report documents work in a location that has open punch items (status = "open" or "in_progress"), verify the report mentions punch item status. Flag if work is documented on punch items without an update: "Work documented at {location} where PUNCH-{id} is open. Was punch item addressed? Update punch status if so."

Cost Authorization Check

Read change-order-log.json → For any new scope of work described in the report, verify it traces to an approved change order or is within original contract scope. Flag if unapproved scope work is documented: "Work on '{description}' does not match any approved CO or original contract scope. Was this authorized? If owner-directed, document the directive for CO processing."

Procurement Verification

Read procurement-log.json → If the report documents materials as "installed" or "in place," verify that procurement-log.json shows delivery_status = "delivered" for those materials. Flag mismatch: "{material} documented as installed but procurement-log shows delivery_status = '{status}'. Verify material was actually received and update procurement log."

Quality Record Correlation

Read quality-data.json → If the report mentions inspection results (pass/fail), verify that matching records exist in quality-data.json inspections. Flag if daily report mentions an inspection result not yet recorded: "Report states {inspection_type} passed at {location}, but no matching record in quality-data.json. Ensure inspection is formally logged."

Safety Incident Cross-Check

Read safety-log.json → If the report documents any safety incident, near miss, or first aid event, verify a corresponding entry exists in safety-log.json. Flag if missing: "Safety incident '{description}' documented in daily report but not found in safety-log.json. Log the incident with safety-management to maintain OSHA records."

Schedule Milestone Validation

Read schedule.json → milestones[] → If the report documents a milestone as "complete" or "achieved," verify that schedule.json shows the milestone status updated. Flag mismatch: "Report states '{milestone}' is complete but schedule.json still shows status = '{status}'. Update schedule to reflect completion."

Weather Threshold Verification

Read specs-quality.json → weather_thresholds[] + daily report weather data → For each weather-sensitive work type documented in the report, cross-check the reported conditions against spec thresholds. Flag if weather-sensitive work was performed during conditions below/above thresholds and no mitigation is documented: "{work_type} performed at {temp}°F but spec threshold is {threshold}°F per {spec_reference}. No mitigation measures documented — was a protection plan in effect?"

User Response Handling

After presenting QA results:

• If user provides corrections: Apply them to the report data, regenerate affected sections, and re-run QA on those sections only.
• If user says "looks good" or "skip": Proceed to .docx generation with the report as-is.
• If user addresses some flags but not others: Apply the corrections provided, note the unaddressed flags, and proceed.

Weekly Report QA Checks

When called from the /weekly-report pipeline (after section narratives are drafted but before .docx generation), run these weekly-specific checks instead of the daily checks above.

W1. Schedule Narrative vs. Actual Milestone Movement

Check: Does the schedule section accurately reflect what happened to milestones this week?

W2. Crew Trend Consistency

Check: Does the headcount narrative match what the daily reports actually show?

W3. Open Items Accuracy

Check: Do the open items in the weekly match the actual log data?

W4. Weather Impact Reconciliation

Check: Does the weather summary accurately reflect daily conditions and their impact?

W5. Photo Coverage

Check: Are photos included and representative?

W6. Distribution List Verification

Check: Is the distribution list current?

Weekly QA Output Format

Same tiered format as daily QA (Flags / Notes / Passes), but prefix the output:

Weekly Report QA Complete — X flags, Y notes

FLAGS:
• [weekly-specific flags]

NOTES:
• [weekly-specific notes]

PASSES:
✓ Schedule narrative matches milestone data
✓ Headcount averages match daily reports
✓ Open items counts match log data
✓ Weather summary matches daily conditions

Extended reference: Detailed examples, templates, scoring rubrics, and best practices are in references/skill-detail.md.