erp-developer

name: erp-developer description: > Primary orchestrator for developing site-specific Emergency Response Plans (ERPs) aligned with AS 3745:2010 (Planning for emergencies in facilities). Guides section-by-section ERP development with template fidelity, multi-jurisdiction support (QLD, NSW, VIC, TAS, WA), variable ECO structures, shift-specific coverage models, and .docx output. Use this skill whenever developing a new ERP, building an emergency response plan, creating emergency procedures, or setting up emergency management documentation for an Australian facility. Also triggers on mentions of AS 3745 ERP development, emergency planning documents, ECO action cards, or evacuation procedures for a specific site.

ERP Developer — Orchestrator Skill

You are developing a site-specific Emergency Response Plan aligned with the methodology of AS 3745:2010. Work through the plan one phase at a time, confirming with the user before moving to the next phase. Never attempt to generate the entire ERP in a single pass — the template contains carefully crafted language that is lost when rushing.

Before You Start

1. Load the as-3745 reference skill — you will need it throughout for clause references.
2. Load the docx skill — the final output is a Word document.
3. Identify the jurisdiction — this determines which WHS/OHS legislation skills to load:

Victoria uses different terminology throughout: "employer" not "PCBU", "OHS" not "WHS", "WorkSafe Victoria" as regulator.

Document Structure Overview

The ERP follows this section structure (24 template reference files in references/):

For each section, read the corresponding template file before generating content. Reproduce boilerplate text verbatim — only insert site-specific data where placeholders indicate.

Phase 0 — Project Initialisation

Goal: Establish project parameters and gather all site data before writing any content.

Inputs Required

1. Jurisdiction — QLD (default), NSW, VIC, TAS, or WA
2. Facility/site type — Industry classification (e.g., cardboard recycling, warehousing, commercial office)
3. Client name and site address
4. Site data source — One of:
   • JSON file exported from ERP-Intake-Form.html
   • Existing site tool data in the Cowork working folder
   • If neither exists, present the HTML intake form or guide the user conversationally

Actions

• Set jurisdiction and load the correct legislation skills
• Load the erp-emergency-library skill
• If intake JSON exists, parse it and summarise key data back to the user
• If no intake data, walk the user through the essential information needed (see intake form sections in references/ERP-Intake-Form.html)
• Confirm all project parameters with the user before proceeding

Checkpoint

Present a summary: "Here is what I have for this project: [Client], [Site], [Jurisdiction], [Industry type], [Key details]. Shall I proceed to Phase 1?"

Phase 1 — Site Profile and Facility Description

AS 3745 alignment: Clause 3.3 (Key Considerations)

Template Files to Load

Read these template reference files before generating content:

• references/template-s02-key-contacts.md
• references/template-s04-facility-description.md
• references/template-s06-emergency-features.md
• references/template-s07-communications.md
• references/template-s08-assembly-areas.md

Data Required

• Facility name, address, description, BCA classification
• Number of floors, zones/areas
• Hours of operation and shift patterns
• Occupant numbers (workers, visitors, contractors)
• Fire safety features and emergency installations
• Communication and alarm systems
• Assembly area locations

Output

Draft these sections using template boilerplate with site-specific data inserted:

• Section 02 — Key Site Contacts
• Section 04 — Facility Description
• Section 06 — Emergency Features / Fire Installations
• Section 07 — Communications and Alarm System
• Section 08 — Assembly Areas

Present each section to the user for review. Use [INSERT: description] for any missing data.

Checkpoint

"Phase 1 complete — site profile sections drafted. Ready for Phase 2 (ECO structure and shift management)?"

Phase 2 — ECO Structure and Shift Management

AS 3745 alignment: Clauses 5.1–5.3, Appendix F

This phase has two steps that must be completed together because the shift model directly affects the ECO structure.

Step 2a — ECO Role Selection

Read references/eco-role-matrix.md for the full role pool and duty descriptions. Read references/template-s09-eco.md and references/template-s10-roles.md.

Present ECO preset models as starting points, then allow full customisation:

Presets:

• Minimum (small, single tenancy): Chief Warden only
• Standard (medium facility): Chief Warden + Wardens + First Aid Officer(s)
• Extended (multi-area/multi-floor): Chief Warden + Deputy CW + Communications Officer + Area/Floor Wardens + Wardens + First Aid Officer(s)
• Full (large/complex): All above + Emergency Response Team

After selecting a preset (or starting from scratch), the user can add or remove roles. Custom roles beyond AS 3745's standard set are supported — for each custom role, capture: role title, pre-emergency duties, emergency duties, post-emergency duties, and identification colour.

The role selection drives:

• Section 09 (ECO structure and zoning)
• Section 10 (roles and responsibilities — duty tables for each role)
• Section 17 (action card columns — one column per ECO role tier present)
• Appendix B (ECO Register)

Step 2b — Shift Pattern and ECO Coverage

If the facility operates shifts (captured in Phase 0/1), define the ECO coverage model for each shift:

Key principle: A night shift with 5 workers does not attempt the same response as a day shift with 50. For reduced-staffing shifts, the strategy may be "all personnel evacuate immediately to assembly area; senior person calls 000; no first-attack firefighting attempted."

Shift-specific strategy is documented in Section 14 (Emergency Management Principles). Action cards in Section 17 use a single format based on the full-staffing ECO — they do not repeat shift variations. Section 14 provides the overarching shift-specific protocol that the reader refers to.

Output

Draft these sections:

• Section 09 — ECO Structure and Zoning (with shift coverage table)
• Section 10 — Roles and Responsibilities (duty tables per role, with shift-specific notes)
• Section 14 (partial) — After-hours / reduced-shift strategy paragraph
• Appendix B structure — ECO Register per shift

Checkpoint

"Phase 2 complete — ECO structure and shift management defined. Ready for Phase 3 (emergency identification and assessment)?"

Phase 3 — Emergency Identification and Assessment

AS 3745 alignment: Clause 3.2 (Emergency Identification and Analysis)

This phase is handled by the erp-emergency-assessment skill. Invoke it with the facility data gathered in Phases 0–1. If the user has already run /erp-assess independently, use those results instead of re-running.

What the Assessment Skill Produces

1. Appendix G — Full itemised emergency identification register (every individual risk listed separately)
2. Section 16 summary table — Grouped emergency types for the ERP
3. Grouping map — Cross-reference linking each Appendix G item to its Section 17 procedure group

Your Role as Orchestrator

• Pass the facility address, industry type, and intake data to the assessment skill
• Receive the outputs and present them to the user for confirmation
• If the user wants adjustments to groupings or risk items, relay these back
• Once confirmed, store the grouping map — you will need it in Phase 4

Output

• Appendix G drafted (within Section 22 — Appendices)
• Section 16 — Types of Emergencies table drafted

Checkpoint

"Phase 3 complete — [X] individual risks identified, grouped into [Y] procedure categories. Ready for Phase 4 (procedure development)?"

Phase 4 — Emergency Response Procedure Development

AS 3745 alignment: Clauses 4.1, 4.2

Read references/template-s17-procedures.md for the action card format and base procedure content.

For Each Grouped Emergency Type

Generate a procedure with:

1. Title and colour code per AS 3745 Table 4.1:

   • Red = Fire
   • Purple = Bomb threat / suspicious object
   • Blue = Medical emergency
   • Black = Personal threat / armed intrusion
   • Yellow = Internal emergency (hazmat, infrastructure, plant)
   • Brown = External emergency (weather, flood, external hazmat)
   • Orange = Evacuation

2. Action card table — Columns determined by the ECO roles from Phase 2. Example column structures:

   Minimum ECO: Chief Warden | All Occupants Standard ECO: Chief Warden | Wardens | All Occupants | First Aid Officer Extended ECO: Chief Warden | Area/Floor Wardens | Wardens | All Occupants | First Aid Officer

3. Row structure per column:

   • Immediate actions (discovery/notification)
   • Response actions (containment/evacuation)
   • Post-incident actions (recovery/debrief)

Evacuation Options

Select the appropriate option for each procedure (per AS 3745 Clause 4.2.6.3):

• Full evacuation — fire, explosion, major structural failure
• Partial evacuation — localised incidents in multi-area facilities
• Shelter in place — external threats (bushfire, storm, external toxic release)
• Escape, Hide, Tell — armed intrusion / active threat
• Lockdown — imminent external threat requiring facility securing

Working Method

Generate procedures one at a time, presenting each to the user for review before proceeding to the next. The template file contains base procedure text — adapt it to the facility's specific hazards, equipment, and ECO structure. Do not invent generic content where the template provides specific language.

Output

Section 17 — All emergency response procedures with action cards.

Checkpoint

"Phase 4 complete — [Y] emergency procedures drafted. Ready for Phase 5 (supporting sections)?"

Phase 5 — Supporting Sections

Generate the remaining sections using template boilerplate with site-specific data. Read each template file before generating the corresponding section.

Working Method

Work through these in document order (Section 01 first, then 03, 05, etc.). For sections with mostly boilerplate, you can draft several at once and present them as a batch. For sections requiring significant customisation (01, 13, 14, 22), present individually.

Checkpoint

"Phase 5 complete — all supporting sections drafted. Ready for Phase 6 (assembly and review)?"

Phase 6 — Assembly and Review

Step 6a — Compile Document

Read references/template-cover-and-toc.md for the cover page and table of contents format.

Compile all sections into a single Word document (.docx) using the docx skill. The document order is:

1. Cover page (with client name, site name, version, date)
2. Table of contents
3. Sections 01 through 23 in sequence
4. Back page

Step 6b — Completeness Check

Review the assembled document against this checklist:

• All 23 sections present and numbered sequentially
• All AS 3745 required elements addressed (Clause 3.4 structure)
• Every Appendix G risk has a corresponding procedure group in Section 17
• ECO roles consistent across Sections 09, 10, 15, 17, and Appendix B
• Shift-specific strategy clearly stated in Section 14
• Legislative references correct for the selected jurisdiction
• All [INSERT] placeholders flagged for user attention
• Emergency colour codes consistent throughout (Table 4.1)
• Assembly area locations consistent across Sections 08, 14, 17
• Cross-references between sections are accurate

Step 6c — Present to User

Present the completeness summary. List any [INSERT] placeholders that still need user input. Save the document to the working folder.

Final Output

"Your Emergency Response Plan has been saved as [filename].docx. There are [N] placeholder fields that still need site-specific information — I have listed these above. The document is ready for transfer to InDesign for final formatting."

Language Requirements

These apply throughout all phases:

• Australian English spelling: analyse, minimise, behaviour, organisation, defence, licence (noun)
• Conservative, neutral language — describe findings factually without emotive terms
• Preserve template boilerplate verbatim where indicated in template files
• All legislative and standards references verified from companion skills — never fabricate citations
• Distinguish "shall" from "should" in AS 3745 references — mandatory vs recommended
• Use [INSERT: description of required information] for any data not yet provided

Error Handling

• If the user has not provided enough data for a section, do not guess — use [INSERT] placeholders and flag them
• If the erp-emergency-assessment skill is not available, guide the user through a simplified manual hazard identification using the erp-emergency-library scenarios as prompts
• If a legislation skill is not available for the selected jurisdiction, note this and use the QLD skill as a fallback with a warning to the user
• If the template reference file for a section is missing, note this and generate content based on the AS 3745 standard requirements with a warning that template fidelity could not be verified