Draft RFI

Draft a formal Request for Information (RFI) following AIA G716 conventions. Output is a Word-compatible Markdown document ready for transmittal to the design team via the project's RFI workflow (Procore, Newforma, BIM 360, or email).

Input you need

Before drafting, gather:

• Project name and project number.
• RFI number — sequential within the project (e.g., RFI-042). If unknown, ask the user or check the RFI log.
• Date in Month DD, YYYY.
• From — Contractor name, individual, role.
• To — Architect of Record (AOR) firm + responsible individual.
• Cc — Owner, CM, MEP/Structural Engineer if relevant.
• Subject — short, specific (e.g., Slab depression at typical bathroom — A-301 / S-201).
• Reference documents — drawing numbers, spec section, ASI/bulletin numbers, prior RFI numbers.
• Question — the actual issue. Concrete, with dimensions and locations.
• Suggested resolution — the contractor's proposed answer (optional but expected per AIA A201 §3.2.2).
• Schedule impact — days of float remaining; whether work is currently held.
• Cost impact — none, TBD, or estimated $ if known.

If any of the above is missing or ambiguous, ask the user before drafting. Do not invent drawing numbers, dimensions, or AOR contact info.

Output structure

Produce this Markdown layout. Section headers must match an AIA G716 form so a contracting party can locate fields without re-reading.

# Request for Information — RFI-XXX

**Project:** [Name] (Project No. [######])
**Date:** [Month DD, YYYY]
**RFI No.:** RFI-XXX
**From:** [Name, Role, Firm]
**To:** [Name, Firm — AOR]
**Cc:** [list]
**Subject:** [short specific subject]

---

## References

| Doc type | Number / Section | Detail |
|----------|------------------|--------|
| Drawing | A-301 | Detail 4 — typical bathroom slab |
| Spec | 03 30 00 §2.04.B | Concrete topping |
| Prior RFI | RFI-038 | Related — slab levelness |

## Question

[Concrete description of the issue, with location, dimensions, and what the documents currently show vs. the field condition.]

## Suggested Resolution (per A201 §3.2.2)

[Contractor's proposed answer, or `None — awaiting AOR direction`.]

## Impact

**Schedule:** [days of float / work held / no impact]
**Cost:** [None / TBD / $X estimated]

---

## Architect Response — *to be completed by AOR*

**Response:**

**Date:** [Month DD, YYYY]
**Signed:** [AOR PIC]

NA AEC conventions

• English only. No Hangul anywhere.
• Imperial-first units (ft, in, sf, °F); metric in parens only when useful.
• Dates use Month DD, YYYY.
• Roles — Architect of Record (AOR), Owner, Construction Manager (CM), MEP Engineer, Structural Engineer (SE), General Contractor (GC). Never Director as a project role.
• Firms — full legal name on first reference, abbreviation thereafter.
• AIA references — AIA G716 (the form), AIA A201 §3.2.2 (contractor's review obligation), AIA B101 §3.6.5 (architect response).
• AHJs — name specifically (NYC DOB, LADBS, DSA, CA HCAI) when the question implicates a code interpretation.
• Floor labels — Level 3, L3, or 3rd floor. Never 3F.

Constraints

• Do not fabricate drawing numbers, dimensions, spec sections, or AOR contact info.
• The RFI question must be answerable — yes/no, choose-A-or-B, or specify-the-dimension. If the user's input is too vague to answer, surface the gap rather than padding the question.
• The "Suggested Resolution" section is required per A201 §3.2.2. If the contractor declines to suggest one, use the literal phrase None — awaiting AOR direction (do not omit the section).
• Word (.docx) output requires the aec-doc-gen companion skill. If aec-doc-gen is not installed, output Markdown and instruct the user to install via the catalog.
• Do not promise a response date. The architect's response time is governed by AIA B101 §3.6.5 / project-specific contract terms.

Workflow

1. Echo back: project, RFI number, subject, references count, schedule impact. One line.
2. If any required input is missing, list the gap and stop.
3. Otherwise, produce the full RFI Markdown.
4. If the user requested Word output, hand the Markdown to the aec-doc-gen skill and ask it for .docx. Surface the output path. If that skill is not installed, deliver the Markdown and say what is missing rather than producing nothing.
5. After the draft, list any items flagged for follow-up (TBD impacts, ambiguous references) so the user can resolve them before transmitting.