Construction Documentation Automation with Claude Code Skills for Architects

The Documentation Burden in Architecture

Construction documentation is the backbone of every architectural project, yet it remains one of the most labor-intensive phases of practice. A typical mid-size commercial project generates hundreds of pages of specifications organized across 50 or more CSI divisions. The drawing set might include 200 to 400 sheets with cross-references between plans, details, schedules, and specifications. Submittal logs track 300 to 800 line items, each with its own review cycle, deadlines, and responsible parties. Punch lists at project closeout routinely hit 500 to 1,000 items that need sorting by trade, location, and priority.

The documentation workload does not scale linearly with project size - it compounds. When you add a new exterior cladding system, you are not just updating Division 07 specifications. You need to verify that the drawing index reflects new detail sheets, that submittals are logged for each product, that the code compliance documentation addresses fire rating requirements, and that cross-references between architectural and structural drawings remain valid. A single product change can touch ten or more documents.

Most firms handle this complexity through meticulous manual tracking, spreadsheets, and years of institutional knowledge about what documents need to exist and how they connect to each other. Junior staff spend significant time on document maintenance tasks that follow clear, repeatable patterns - exactly the kind of work that benefits from automation.

Claude Code skills offer a practical path to automating these patterns. A skill is a markdown instruction file stored in your project’s .claude/skills/ directory. When you invoke a skill, Claude Code reads the instructions and executes a multi-step workflow against your project files - generating specification sections, updating submittal logs, checking cross-references, or processing punch lists. Because skills encode your firm’s specific conventions, CSI organization, and document formats, the output matches your standards every time.

Setting Up Construction Documentation for Claude Code

Before building skills, you need a folder structure that Claude Code can navigate reliably. The key is organizing your construction documentation data as plain text files - CSV exports, markdown tables, YAML configuration, and structured text. Here is the folder structure that works well for documentation projects:

project-root/
├── .claude/
│   └── skills/
│       ├── spec-generator/
│       │   └── SKILL.md
│       ├── submittal-tracker/
│       │   └── SKILL.md
│       ├── drawing-index-manager/
│       │   └── SKILL.md
│       ├── punch-list-processor/
│       │   └── SKILL.md
│       ├── addenda-generator/
│       │   └── SKILL.md
│       └── code-compliance-checker/
│           └── SKILL.md
├── specs/
│   ├── config/
│   │   ├── project-info.yaml
│   │   ├── product-selections.yaml
│   │   └── csi-divisions.yaml
│   ├── sections/
│   │   ├── 07-2100-thermal-insulation.md
│   │   ├── 08-1113-hollow-metal-doors.md
│   │   └── 09-2116-gypsum-board-assemblies.md
│   └── templates/
│       ├── section-template.md
│       └── three-part-format.md
├── submittals/
│   ├── submittal-log.csv
│   ├── reviewer-assignments.yaml
│   └── archives/
├── drawings/
│   ├── drawing-index.csv
│   ├── revision-log.csv
│   └── cross-reference-map.yaml
├── punch-lists/
│   ├── raw-items.csv
│   └── processed/
├── addenda/
│   ├── pending-changes.yaml
│   └── issued/
└── compliance/
    ├── required-docs-checklist.yaml
    ├── code-references.yaml
    └── completed/

The project-info.yaml file anchors everything. It defines the project name, number, location, applicable codes, and key dates that every skill references:

project:
  name: "Riverside Medical Office Building"
  number: "2026-042"
  location: "Portland, OR"
  building_type: "Medical Office (B Occupancy)"
  construction_type: "Type II-B"
  applicable_codes:
    - "2021 Oregon Structural Specialty Code"
    - "2021 Oregon Fire Code"
    - "2021 Oregon Mechanical Specialty Code"
    - "NFPA 101 Life Safety Code"
    - "ADA Standards for Accessible Design"
  phases:
    sd_complete: "2026-01-15"
    dd_complete: "2026-04-01"
    cd_50_percent: "2026-06-15"
    cd_100_percent: "2026-08-30"
    bid_date: "2026-09-30"

The product-selections.yaml file drives specification generation. Each entry maps a CSI section to specific products selected for the project:

products:
  - csi_section: "07 2100"
    csi_title: "Thermal Insulation"
    products:
      - manufacturer: "Owens Corning"
        product: "EcoTouch Insulation"
        basis_of_design: true
        fire_rating: "Class A"
      - manufacturer: "CertainTeed"
        product: "CertaPro Commercial Batts"
        basis_of_design: false
  - csi_section: "08 1113"
    csi_title: "Hollow Metal Doors and Frames"
    products:
      - manufacturer: "Ceco Door"
        product: "Commercial Steel Doors"
        basis_of_design: true
        fire_rating: "90-minute"

This structure lets every skill pull consistent project data without duplicating configuration across multiple files.

Skill: Specification Section Generator

Specification writing follows a predictable three-part format defined by CSI - General, Products, and Execution. Each section has standard article structures that vary by division but follow conventions that any experienced architect recognizes. This skill generates specification sections from your project data and product selections.

# Specification Section Generator

## Trigger
Use when the user asks to generate a specification section, create specs,
or write a CSI section.

## Instructions

### Step 1: Read Project Configuration
Read `specs/config/project-info.yaml` and `specs/config/product-selections.yaml`.
Extract the project name, number, applicable codes, and product data for the
requested CSI division.

### Step 2: Identify the Requested Section
Parse the user request for the CSI section number (e.g., "07 2100" or
"thermal insulation"). Match it against the product selections file.
If the section is not found in product selections, inform the user
and ask whether to generate a shell section with placeholder products.

### Step 3: Read the Section Template
Read `specs/templates/three-part-format.md` for the standard structure.
If a draft already exists in `specs/sections/`, read it and treat this
as an update rather than a fresh generation.

### Step 4: Generate the Specification Section
Create the section following CSI three-part format:

**PART 1 - GENERAL**
- Section Includes: List scope items based on the CSI division
- Related Sections: Cross-reference other relevant CSI sections
- References: List applicable ASTM, ANSI, UL standards for the products
- Submittals: List required submittals (product data, shop drawings,
  samples, test reports, certificates)
- Quality Assurance: Installer qualifications, manufacturer certifications
- Delivery, Storage, Handling: Standard requirements for the product type
- Project Conditions: Temperature, humidity, substrate requirements

**PART 2 - PRODUCTS**
- For each product in product-selections.yaml:
  - List the manufacturer and product name
  - Mark the basis of design product
  - Include "or approved equal" language for non-proprietary specs
  - List key performance requirements (R-value, fire rating, STC rating)
  - Include material properties from the product type standards

**PART 3 - EXECUTION**
- Examination: Substrate inspection requirements
- Preparation: Surface prep, priming, protection of adjacent work
- Installation: Method statements referencing manufacturer instructions
- Field Quality Control: Inspection, testing, certification requirements
- Cleaning: Post-installation cleanup requirements
- Protection: Temporary protection until substantial completion

### Step 5: Write the Output File
Save to `specs/sections/{section-number}-{title-slug}.md`.
Use the naming convention: `07-2100-thermal-insulation.md`.

### Step 6: Update Cross-References
Check `drawings/cross-reference-map.yaml` for any drawing sheets that
reference this specification section. Report which sheets may need
keynote or specification callout updates.

## Output Format
- Markdown with clear heading hierarchy
- Section number and title as H1
- Parts as H2, Articles as H3
- Product listings as bullet lists with bold manufacturer names
- Standards references in "ASTM C XXX - Standard Title" format

When you run /spec-generator 07 2100, Claude Code reads your project configuration, pulls the thermal insulation product selections, generates a complete three-part specification section with the correct standards references, and saves it to the right location. If the products include specific fire ratings, those get woven into the quality assurance and testing articles automatically.

Skill: Submittal Log Tracker

Submittal management is one of the most administratively demanding tasks during construction administration. Each submittal needs a unique number, a CSI section reference, a description, responsible contractor, reviewing consultant, due dates, and status tracking through multiple review cycles. This skill manages the entire submittal lifecycle from a single CSV file.

# Submittal Log Tracker

## Trigger
Use when the user asks to update submittals, check submittal status,
add new submittals, generate submittal reports, or identify overdue items.

## Instructions

### Step 1: Read Current State
Read `submittals/submittal-log.csv` and `submittals/reviewer-assignments.yaml`.
The CSV columns are:
submittal_no, csi_section, description, contractor, reviewer,
date_submitted, date_required, date_returned, status, review_cycle, notes

Valid status values: NOT_SUBMITTED, SUBMITTED, UNDER_REVIEW,
APPROVED, APPROVED_AS_NOTED, REVISE_AND_RESUBMIT, REJECTED

### Step 2: Determine the Action
Parse the user request to identify the action:

**Add Submittals**: When given new items (from a spec section or
product list), assign sequential submittal numbers following the
existing numbering pattern. Auto-assign reviewers based on
reviewer-assignments.yaml (maps CSI divisions to consultants).
Set status to NOT_SUBMITTED. Calculate due dates based on the
project schedule - submittals should be due 4 weeks before the
related work is scheduled to begin.

**Update Status**: When told a submittal was submitted, returned,
approved, or rejected, update the appropriate date and status fields.
If REVISE_AND_RESUBMIT, increment the review_cycle counter.

**Status Report**: Generate a summary showing:
- Total submittals by status (counts and percentages)
- Overdue items (date_required has passed, status not APPROVED)
- Items approaching deadline (within 2 weeks of date_required)
- Submittals pending by reviewer (workload distribution)
- Items on second or later review cycle (potential problems)

**Missing Submittals Audit**: Cross-reference the submittal log against
specs/sections/ to find specification sections that require submittals
(look for "Submittals" articles) but have no matching entries in the log.

### Step 3: Write Updates
Save the updated `submittals/submittal-log.csv`.
Preserve all existing data - only modify fields relevant to the action.

### Step 4: Generate Notifications
If any submittals changed to REVISE_AND_RESUBMIT or are overdue,
list them prominently in the output with contractor name and
description so the architect can follow up immediately.

## Output Format
- Updated CSV file
- Summary of changes made
- Status report as a markdown table when requested
- Flag any anomalies (duplicate entries, missing reviewers, impossible dates)

The real power of this skill shows up during weekly OAC meetings. You can run a quick status report before the meeting to see exactly which submittals are overdue, which consultants have review bottlenecks, and which specification sections still have no submittals logged. Instead of spending 30 minutes building this picture manually from a spreadsheet, you get it in seconds.

Skill: Drawing Index Manager

A well-maintained drawing index is essential for bid documents and permit submissions, but keeping it synchronized with the actual drawing set is tedious work. Every time a sheet is added, removed, or renumbered, the index needs updating. Cross-references between sheets need verification. Revision tracking needs to reflect which sheets were included in each addendum or bulletin. This skill handles all of it.

# Drawing Index Manager

## Trigger
Use when the user asks to update the drawing index, check cross-references,
add sheets, track revisions, or prepare a sheet index for a milestone.

## Instructions

### Step 1: Read Current Data
Read `drawings/drawing-index.csv` and `drawings/revision-log.csv`.
Drawing index columns: sheet_no, sheet_title, discipline, scale,
current_rev, last_rev_date, status
Revision log columns: sheet_no, rev_no, rev_date, description, addendum_no

### Step 2: Determine the Action

**Add Sheets**: When given new sheet numbers and titles, insert them
into the drawing index in proper sort order. Sheet numbering follows
AIA conventions: A (Architectural), S (Structural), M (Mechanical),
E (Electrical), P (Plumbing), L (Landscape), C (Civil).
Within each discipline, sort numerically. Assign revision "0" and
current date. Status is "IN_PROGRESS" until marked otherwise.

**Update Revisions**: When told sheets have been revised, increment
the revision number, update the date, and add an entry to the
revision log. If an addendum number is provided, tag the revision
log entry with that addendum.

**Cross-Reference Check**: Read `drawings/cross-reference-map.yaml`
which maps sheets to the other sheets they reference (e.g., A3.01
references detail on A5.12). Verify that all referenced sheets exist
in the drawing index. Report any broken references where a sheet
references a number that does not exist or has been removed.

**Milestone Index**: Generate a clean drawing index formatted for
a specific milestone (50% CD, 100% CD, Bid Set). Filter to sheets
with status "COMPLETE" or "IN_PROGRESS" (exclude "DELETED" or
"ON_HOLD"). Include revision information and total sheet count
by discipline.

**Gap Analysis**: Check for gaps in sheet numbering sequences.
If A2.01, A2.02, and A2.04 exist but A2.03 does not, flag it.
Also flag duplicate sheet numbers.

### Step 3: Write Updates
Save updated `drawings/drawing-index.csv` and `drawings/revision-log.csv`.

### Step 4: Report
Provide a summary of changes. For cross-reference checks, list all
broken references with the source sheet and the missing target.
For milestone indexes, provide sheet counts by discipline.

## Output Format
- Updated CSV files
- Markdown table for milestone indexes
- Broken reference report as a numbered list
- Discipline summary: "Architectural: 45 sheets, Structural: 22 sheets..."

The cross-reference check alone can save hours of manual verification before a permit submission. When you renumber sheets during design development, this skill immediately identifies every other sheet that referenced the old number, preventing the embarrassing situation of submitting documents with detail callouts pointing to non-existent sheets.

Skill: Punch List Processor

Punch list management at project closeout is a high-volume, fast-turnaround task. Field inspections generate hundreds of items that arrive as rough notes - often just a location, a description, and a trade. These need to be organized into actionable lists grouped by contractor, prioritized by severity, and tracked through resolution. This skill turns raw punch list data into organized, distributable documents.

# Punch List Processor

## Trigger
Use when the user asks to process punch lists, organize punch items,
generate contractor punch lists, or track punch list completion.

## Instructions

### Step 1: Read Raw Data
Read `punch-lists/raw-items.csv`.
Columns: item_no, date_observed, location, description, trade,
priority, status, assigned_to, resolved_date, photo_ref

Priority values: LIFE_SAFETY, HIGH, MEDIUM, LOW
Status values: OPEN, IN_PROGRESS, RESOLVED, VERIFIED, DISPUTED

### Step 2: Determine the Action

**Process New Items**: When given new punch list items (as text,
CSV, or pasted field notes), parse them and append to raw-items.csv.
Auto-assign sequential item numbers continuing from the highest
existing number. Infer the trade from the description when not
specified explicitly:
- Drywall, paint, ACT ceiling -> "Finishes"
- Door hardware, frames, closers -> "Doors/Hardware"
- Light fixtures, switches, outlets -> "Electrical"
- Diffusers, thermostats, ductwork -> "HVAC"
- Fixtures, faucets, drains -> "Plumbing"
- Casework, countertops -> "Millwork"
- Tile, carpet, VCT -> "Flooring"
- Fire extinguishers, strobes -> "Fire Protection"
- Signage, room numbers -> "Signage"

If priority is not specified, default to MEDIUM.

**Generate Contractor Lists**: Group all OPEN and IN_PROGRESS items
by trade/assigned_to. For each contractor, generate a separate
markdown file in `punch-lists/processed/` named
`punchlist-{trade-slug}-{date}.md`. Each file includes:
- Project name and punch list date
- Contractor name and trade
- Table of items with: item number, location, description, priority
- Sort by priority (LIFE_SAFETY first), then by location
- Total item count

**Status Report**: Generate a completion summary:
- Total items by status
- Items by trade with completion percentage
- Life safety items (must be listed individually regardless of status)
- Aging report: items open longer than 14 days
- Location heat map: which floors/areas have the most open items

**Update Status**: When told items are resolved, update status and
resolved_date. Do not delete items - the full record must be preserved
for project closeout documentation.

### Step 3: Write Updates
Save updated `punch-lists/raw-items.csv`.
Write contractor-specific lists to `punch-lists/processed/`.

### Step 4: Closeout Check
If all items are VERIFIED or RESOLVED, note that the punch list
is ready for substantial completion certification.
If LIFE_SAFETY items remain OPEN, flag this prominently.

## Output Format
- Updated CSV
- Individual contractor punch list files in markdown
- Status report as markdown with tables
- Life safety items always highlighted separately

The trade inference saves considerable time when processing field notes. An architect walking a building with a clipboard typically writes “Room 204 - ceiling tile damaged, north wall paint touch up needed, door closer not adjusting properly” without explicitly tagging trades. The skill parses these descriptions and routes them to the correct contractor automatically.

Skill: Addenda and ASI Generator

Changes during bidding and construction require formal documentation through addenda (pre-bid) and Architect’s Supplemental Instructions (post-bid). Each addendum needs a sequential number, a date, a list of affected documents, a description of each change, and clear language that the contractor can price or implement without ambiguity. This skill drafts these documents from a structured list of pending changes.

# Addenda and ASI Generator

## Trigger
Use when the user asks to create an addendum, draft an ASI,
compile pending changes, or prepare a change document.

## Instructions

### Step 1: Read Pending Changes
Read `addenda/pending-changes.yaml`.
Each change entry includes:
- change_id: unique identifier
- type: "addendum" or "asi"
- description: what changed and why
- affected_sheets: list of drawing sheet numbers
- affected_specs: list of CSI section numbers
- change_category: "design_change", "clarification",
  "code_correction", "owner_request", "substitution"
- priority: "required_for_bid" or "required_for_construction"

### Step 2: Read Project State
Read `specs/config/project-info.yaml` for project name and number.
Read `addenda/issued/` directory to determine the next sequential
addendum or ASI number.

### Step 3: Group and Organize
Group changes by type (addendum vs ASI). Within each group, sort by:
1. Priority (required_for_bid items first)
2. Change category
3. Affected discipline (Architectural, then consultants)

### Step 4: Generate the Document
For each addendum or ASI, create a markdown document with:

**Header:**
- Document title: "Addendum No. X" or "ASI No. X"
- Project name and number
- Date of issuance
- Number of pages

**Affected Documents List:**
- Drawing sheets being modified (sheet number and title from drawing index)
- Specification sections being modified (section number and title)

**Changes:**
For each change, write a clear item entry:
- Item number
- Description of the change in imperative language
  ("Delete Note 3 on Sheet A2.01 and replace with...")
- Reference to the specific sheet, detail, or specification article
- Reason for change (categorized)

**Acknowledgment Block:**
Standard language requiring contractor acknowledgment of receipt.

### Step 5: Update Related Files
After generating the addendum:
- Update `drawings/revision-log.csv` for affected sheets
- Update `drawings/drawing-index.csv` revision numbers
- Move processed changes from pending-changes.yaml to the issued
  addendum file
- Note which specification sections need to be regenerated

### Step 6: Save
Save to `addenda/issued/addendum-{number}-{date}.md` or
`addenda/issued/asi-{number}-{date}.md`.

## Output Format
- Formal document in markdown with clear heading structure
- Numbered change items with specific references
- Summary of all downstream files that were updated

The real value here is the downstream updates. When you issue Addendum No. 3 that modifies sheets A3.01, A5.04, and specification section 08 1113, the skill automatically bumps revision numbers in the drawing index and flags which specs need regeneration. Without this, firms routinely issue addenda that modify drawings but forget to update the drawing index, creating confusion at bid time.

Skill: Code Compliance Documentation Checker

Building departments require specific documentation to demonstrate code compliance, and the requirements vary by jurisdiction and project type. Missing a required item - an accessible route diagram, a fire-resistance rating schedule, or an energy compliance form - can delay permits by weeks. This skill audits your documentation set against a compliance checklist.

# Code Compliance Documentation Checker

## Trigger
Use when the user asks to check code compliance documentation,
audit permit documents, verify required code docs, or prepare
for permit submission.

## Instructions

### Step 1: Read Compliance Requirements
Read `compliance/required-docs-checklist.yaml` which lists every
required code compliance document for this project.
Each entry includes:
- doc_id: unique identifier
- title: document name
- category: "fire_safety", "accessibility", "energy", "structural",
  "zoning", "life_safety", "environmental"
- required_by: code or regulation reference
- responsible_party: who prepares it
- status: "complete", "in_progress", "not_started", "not_applicable"
- file_path: path to the completed document (if exists)
- notes: any special requirements

### Step 2: Read Code References
Read `compliance/code-references.yaml` for the applicable codes
and their specific documentation requirements for this building
type and construction classification.

### Step 3: Verify Document Existence
For each checklist item with status "complete":
- Verify the file_path actually exists on disk
- If the file does not exist, flag it as a discrepancy

For items with status "not_started" or "in_progress":
- Check if a file exists at the expected path anyway
  (someone may have completed it without updating the checklist)

### Step 4: Gap Analysis
Cross-reference the checklist against standard requirements for
the project's building type:

**Fire Safety Documents:**
- Fire-resistance rating schedule (wall types, floor assemblies)
- Fire barrier/fire partition plan
- Fire department access plan
- Sprinkler coverage confirmation
- Fire alarm riser diagram

**Accessibility Documents:**
- Accessible route plan (each floor)
- Accessible parking layout
- Restroom accessibility diagrams
- Elevator compliance data
- Signage plan (tactile, Braille)

**Energy Compliance:**
- Energy code compliance forms (COMcheck or equivalent)
- Envelope U-value calculations
- Mechanical efficiency documentation
- Lighting power density calculations

**Life Safety:**
- Occupancy load calculations
- Egress path diagrams (each floor)
- Egress width calculations
- Area of rescue assistance locations

Report any standard requirements that are not present in the
project's checklist (items that should have been added but were
missed entirely).

### Step 5: Generate Report
Create a compliance status report with:
- Overall completion percentage
- Category-by-category status
- List of missing or incomplete documents
- List of discrepancies (marked complete but file missing)
- Newly identified requirements not in the original checklist
- Recommended priority order for completing remaining items

### Step 6: Save Report
Save to `compliance/completed/compliance-audit-{date}.md`.
Update `compliance/required-docs-checklist.yaml` with any
corrections (file existence fixes, newly identified items).

## Output Format
- Audit report in markdown with tables
- Red/yellow/green status indicators using text labels
  (MISSING, INCOMPLETE, COMPLETE)
- Priority-ordered action items for the project team

Running this skill before a permit submission gives you a clear picture of what is ready and what is missing. The gap analysis catches requirements that the team might not have added to their checklist in the first place. For a medical office building, for example, the skill would flag that healthcare-specific ventilation documentation is a standard requirement even if nobody put it on the original list.

Chaining Documentation Skills for Milestone Submissions

Individual skills are useful, but the real productivity gains come from chaining them together at project milestones. A 50% CD submission, for instance, requires a coordinated set of documents that all need to be current and cross-referenced properly.

Here is how you might chain skills for a 50% CD milestone:

1. Run the Drawing Index Manager in milestone mode to generate the current sheet index and verify all cross-references are valid
2. Run the Specification Section Generator for any sections that have been modified since the last milestone
3. Run the Submittal Log Tracker with a missing submittals audit to identify specification sections that need submittal entries before construction starts
4. Run the Code Compliance Documentation Checker to verify that the documents required for 50% review are complete
5. Review the combined output and address any gaps before packaging the submission

You can even create a meta-skill that orchestrates this sequence:

# Milestone Submission Coordinator

## Trigger
Use when the user asks to prepare a milestone submission or
run a milestone check.

## Instructions

### Step 1: Identify the Milestone
Ask the user which milestone: 50% CD, 100% CD, Permit Set, or Bid Set.

### Step 2: Run Drawing Index Check
Invoke the drawing-index-manager skill in milestone mode.
Record the sheet count by discipline and any broken cross-references.

### Step 3: Run Specification Audit
Check which spec sections in specs/sections/ have been modified
since the last milestone date (from project-info.yaml).
List sections that need review or regeneration.

### Step 4: Run Submittal Gap Check
Invoke the submittal-tracker skill in missing submittals audit mode.
Record any spec sections without corresponding submittal entries.

### Step 5: Run Compliance Check
Invoke the code-compliance-checker skill.
Record overall completion percentage and missing items.

### Step 6: Generate Milestone Report
Create a comprehensive milestone readiness report combining
all findings. Save to `docs/milestone-{name}-{date}.md`.
Include a clear GO/NO-GO recommendation based on:
- All cross-references valid
- No missing spec sections for specified systems
- Compliance documentation at or above 80% for the milestone
- No outstanding life-safety compliance gaps

## Output Format
- Executive summary with GO/NO-GO recommendation
- Detailed findings by category
- Action items with responsible parties
- Estimated effort to close remaining gaps

This milestone coordinator turns what would be a full day of manual checking into a focused review session where the architect’s time is spent on judgment calls rather than clerical verification.

Tips for Construction Documentation Skill Development

Building effective documentation skills requires thinking carefully about how architects actually work with construction documents. Here are lessons learned from developing and refining these workflows.

Start with your firm’s actual templates. Generic specification language is a starting point, but the real value comes from encoding your firm’s specific boilerplate, standard details, and preferred product language. Copy your firm’s master specification template into the specs/templates/ directory and reference it in your skills. The closer the skill output matches your existing standards, the less editing you need after generation.

Use CSI MasterFormat numbering consistently. Every skill should reference specification sections by their six-digit CSI number (e.g., “07 2100” not “insulation”). This creates unambiguous links between specifications, submittals, drawing keynotes, and compliance documents. When the submittal tracker references “07 2100,” there is no confusion about which specification section it maps to.

Keep your YAML configuration files as the single source of truth. Product selections, reviewer assignments, and code requirements should each live in one file. When a product substitution is approved, update product-selections.yaml once, and every skill that references that product will use the updated information the next time it runs.

Version your documentation data with git. Because all the tracking files are plain text (CSV, YAML, markdown), they work naturally with version control. You get a complete history of every change to every submittal, every revision to the drawing index, and every update to the compliance checklist. This audit trail is invaluable during construction disputes or when you need to reconstruct the documentation timeline for a claim.

Build skills incrementally. Do not try to automate your entire documentation workflow at once. Start with the task that consumes the most time for the least value - for most firms, that is submittal log management or punch list processing. Get one skill working reliably, then add the next.

Common Mistakes and How to Avoid Them

Several pitfalls come up repeatedly when architects start automating construction documentation. Knowing them in advance saves significant debugging time.

Overcomplicating the data format. Some teams try to capture every possible field in their CSV files from the start. A submittal log with 30 columns is harder to maintain than one with 12 well-chosen columns. Start lean and add fields only when a specific skill needs them.

Ignoring the human review step. Automated specification generation produces good first drafts, not final documents. Every generated spec section needs review by a licensed professional who understands the project-specific requirements. Build your workflow so that generated documents land in a “review needed” state, not a “ready to issue” state.

Hardcoding project-specific data into skills. If your skill contains a line like “the fire rating for this assembly is 2 hours,” that skill breaks when you use it on a project with 1-hour assemblies. All project-specific data should live in configuration files (YAML, CSV) that the skill reads at runtime. The skill itself should contain only the logic and format instructions.

Neglecting to validate CSV structure. When multiple people edit a CSV file, columns can shift, commas can appear in descriptions, and encoding issues can corrupt data. Add a validation step at the beginning of each skill that checks for the expected column headers and flags any rows with unexpected formatting before processing.

Skipping the cross-reference updates. The biggest source of coordination errors in construction documents is not the content of individual documents but the references between them. When you update a specification section, the submittal log, drawing keynotes, and compliance checklist all may need corresponding updates. Build cross-reference checking into every skill, not just the drawing index manager.

Not testing with real project data. A skill that works perfectly on a 10-item punch list might struggle with 800 items. Test your skills with realistic data volumes before relying on them for production work. Export an actual submittal log from a recent project and run it through the skill to see how it performs.

Getting Started with Construction Documentation Skills

Construction documentation automation is not about replacing the architect’s judgment. It is about eliminating the hours spent on clerical tasks - copying submittal information between spreadsheets, manually cross-checking drawing references, counting punch list items by trade, and formatting specification boilerplate. These are tasks that follow clear rules and predictable patterns, which makes them ideal candidates for Claude Code skills.

The skills in this guide cover the core documentation workflows that consume the most time on a typical project. Start with the one that addresses your biggest pain point. For most firms, that is either the submittal tracker (because submittal management is relentless during CA) or the punch list processor (because closeout documentation is always rushed).

As you build confidence with individual skills, chain them together for milestone submissions. The milestone coordinator pattern, where one skill orchestrates several others to produce a comprehensive readiness report, is where the compound time savings become dramatic. Instead of spending a full day manually verifying that your 100% CD submission is complete and cross-referenced, you spend an hour reviewing the automated audit results and addressing the gaps.

The construction documentation tools and techniques covered here build directly on the Claude Code skills foundations. If you want to deepen your understanding of BIM workflows and the technical context that makes these automation skills possible, explore the courses at Archgyan Academy. The platform offers practical, project-focused training that connects directly to the kind of work we have covered here - turning repetitive documentation tasks into streamlined, automated workflows that let you focus on the design decisions that actually need your expertise.