$npx -y skills add dleerdefi/claude-code-construction --skill rfi-drafterDraft RFIs and manage the ambient issue registry. Reviews issues surfaced by other skills, escalates to formal RFIs. Triggers: 'draft RFI', 'write RFI', 'drawing conflict', 'review issues', 'issue queue'.
| 1 | # RFI Drafter |
| 2 | |
| 3 | ## Purpose |
| 4 | |
| 5 | Two responsibilities: (1) draft formal RFIs from identified issues, and |
| 6 | (2) manage the issue detection registry where potential problems surface |
| 7 | during other skill workflows. Detection is ambient. Drafting is user- |
| 8 | triggered. No RFI is ever created without explicit user instruction. |
| 9 | |
| 10 | **Design**: RIGID output format and quality checks. GUIDED research |
| 11 | sequence before drafting. FLEXIBLE across any trade, CSI division, or |
| 12 | document conflict type. |
| 13 | |
| 14 | Does NOT: autonomously discover issues and write RFIs, send RFIs |
| 15 | without user review, or determine whether an issue is actually an |
| 16 | error vs. intentional design. |
| 17 | |
| 18 | ## Permitted Scripts |
| 19 | |
| 20 | | Script | Location | Purpose | |
| 21 | |--------|----------|---------| |
| 22 | | `rfi_export.py` | `${CLAUDE_SKILL_DIR}/scripts/rfi_export.py` | Populate firm's .docx template or generate generic RFI | |
| 23 | | `issue_manager.py` | `${CLAUDE_SKILL_DIR}/../../scripts/issue_manager.py` | CRUD for issue registry (.construction/issues/) | |
| 24 | | `generate_rfi_pdf.py` | `${CLAUDE_SKILL_DIR}/../../scripts/rfi/generate_rfi_pdf.py` | Generate PDF RFI (alternative format) | |
| 25 | | `rasterize_page.py` | `${CLAUDE_SKILL_DIR}/../../scripts/pdf/rasterize_page.py` | Rasterize drawing pages for vision reading | |
| 26 | | `crop_region.py` | `${CLAUDE_SKILL_DIR}/../../scripts/pdf/crop_region.py` | Crop regions for targeted reading | |
| 27 | |
| 28 | Do NOT create custom scripts during execution. All output goes through the scripts above. |
| 29 | |
| 30 | --- |
| 31 | |
| 32 | ## Mode 1: User-Initiated RFI Drafting |
| 33 | |
| 34 | The user identifies an issue and instructs Claude to draft an RFI. |
| 35 | This is the primary workflow — a 30-minute task compressed to minutes. |
| 36 | |
| 37 | ### Step 0: Gather RFI Template (first RFI per project) |
| 38 | |
| 39 | Before the first RFI, ask the user for their firm's RFI form template. |
| 40 | Construction teams have a branded template they use for all official |
| 41 | RFIs — the output MUST match their format exactly. |
| 42 | |
| 43 | **If .docx template provided:** |
| 44 | 1. Read with python-docx to identify field locations (table cells, |
| 45 | placeholders like `[PROJECT NAME]`, content controls) |
| 46 | 2. Build a field mapping JSON linking each RFI data field to its |
| 47 | location in the template |
| 48 | 3. Store mapping at `.construction/rfi_template_map.json` |
| 49 | 4. Store a SHA-256 hash of the template for change detection |
| 50 | |
| 51 | **If PDF template provided:** |
| 52 | 1. Rasterize each page at 200 DPI |
| 53 | 2. Read with vision to understand field layout and structure |
| 54 | 3. Build the mapping JSON from visual analysis |
| 55 | 4. Store at `.construction/rfi_template_map.json` |
| 56 | |
| 57 | **If no template available:** |
| 58 | Fall back to the generic format built into `rfi_export.py`. Inform |
| 59 | the user that providing their template is recommended for production |
| 60 | RFIs. |
| 61 | |
| 62 | On subsequent RFIs, reuse the stored mapping. If the template file |
| 63 | hash differs from the stored hash, re-map. |
| 64 | |
| 65 | ### Step 1: Understand the Issue |
| 66 | |
| 67 | Gather from the user (or from an issue registry record if escalating): |
| 68 | - **What**: the conflict, ambiguity, or missing information |
| 69 | - **Where**: sheet number(s), grid location, room/area, detail ref |
| 70 | - **Between what**: which documents disagree (plan vs detail, arch vs |
| 71 | structural, drawing vs spec, etc.) |
| 72 | |
| 73 | If the user's description is vague, ask clarifying questions. Never |
| 74 | draft from ambiguous input — an RFI that doesn't clearly state the |
| 75 | problem wastes everyone's time. |
| 76 | |
| 77 | ### Step 2: Research Context |
| 78 | |
| 79 | Before drafting, systematically gather evidence. Read |
| 80 | `references/research-checklist.md` for the full checklist. |
| 81 | |
| 82 | **Minimum research before any RFI:** |
| 83 | 1. Read the specific area on the source sheet(s) |
| 84 | 2. Check related details/sections for the same condition |
| 85 | 3. Check the relevant spec section for requirements |
| 86 | 4. Check if general notes address the condition |
| 87 | 5. Check addenda and ASIs for superseding changes |
| 88 | 6. Check existing RFI log for duplicates (if available) |
| 89 | |
| 90 | If AgentCM data is available (`.construction/` exists), query the |
| 91 | database for cross-references to the affected area. See |
| 92 | `references/research-checklist.md` for concrete query examples. |
| 93 | |
| 94 | If research reveals the issue is already resolved (by addendum, ASI, |
| 95 | or existing RFI response), inform the user — no RFI needed. |
| 96 | |
| 97 | ### Step 3: Draft the RFI |
| 98 | |
| 99 | Use the format in `references/rfi-format.md`. Every RFI must include: |
| 100 | - Project identification (name, number, RFI number) |
| 101 | - Addressee (the design professional who owns the document) |
| 102 | - Specific drawing/spec references with grid locations |
| 103 | - Clear description of the issue |
| 104 | - Suggested resolution (always — accelerates response) |
| 105 | - Schedule impact statement |
| 106 | - Attachment list |
| 107 | |
| 108 | Read `references/rfi-format.md` for the full template, field-by-field |
| 109 | guidance, and an example RFI. |
| 110 | |
| 111 | ### Step 4: Quality Check |
| 112 | |
| 113 | Before presenting to user, verify against the checklist in |
| 114 | `references/quality-checks.md`. Key gates: |
| 115 | - Specific sheet numbers and grid locations cited (ne |