Architectural Project Deck

Lead a design review through the spatial decision it needs to resolve. Architectural Project Deck organizes approved site information, drawings, massing and material evidence around one major artifact per page. Sheet-like annotations, units and revisions make the reasoning traceable, while visible preliminary-use boundaries keep a presentation distinct from professional approval.

What you get

  • A review sequence covering the premise, site forces, massing, plans/sections, material roles, program, phasing or option comparison as the brief requires. Each slide centers one dominant artifact; a deliberate plan/section pair may share a datum, rather than becoming a crowded sheet of unrelated drawings.
  • Visible units, sources, revision information, assumptions and preliminary/professional-review notes, ending in one decision request and unresolved questions. Known dimensions and inferred values remain distinguishable. The handoff includes a source ledger and a record of what was actually checked.
  • Three material palettes—Tracing Paper, Oxide Survey and Blue Datum—with generous space, insight-led headlines, technical drawing cues and readable labels at least 16px on the 1280×720 frame. Avoid rounded UI cards and more than two dark hinge pages in a typical deck; vary background roles rather than repeat three identical pages.
  • Six installed recipes for project premise, site forces, courtyard massing, material register, phased delivery and review request. Nine documented archetypes also discuss plan/section, program and decision-matrix compositions; those require adapting the editable model rather than selecting three additional ready-made recipes. The fictional North Quay scheme and its dimensions are not site evidence.
  • A standalone editable HTML deck with notes, viewing and presentation modes, plus requested PPTX/PDF. Text and notes remain editable in PowerPoint; drawings/SVG/backgrounds render as layers and supplied pictures stay separate. The installation includes the shared runtime and Python build/check tools, not CAD/BIM authoring or native drawing-object reconstruction.

Before you choose

Read the final decision alongside the drawing revision and assumptions. If the requested approval depends on an unverified dimension or a superseded plan, fix that dependency before improving the slide. A clear review deck makes the open question easier to see.

Good fit

  • An architect or interior designer needs a concept, design-development or client review to explain spatial choices through approved drawings.
  • A feasibility, development or competition proposal relies on site logic, massing, plan/section relationships and material evidence.
  • A project lead wants to compare options against a small set of criteria and close the review on a specific decision.

Not for

  • Confirming code, zoning, structure, cost, constructability or professional approval. The deck is preliminary communication and keeps that status visible.
  • Inventing site facts, geometry, dimensions or material performance. Work from cleared evidence and label assumptions.
  • Pages packed with unrelated drawings or a presentation that hides uncertainty behind attractive architectural imagery.
  • A native CAD/BIM deliverable or a PowerPoint in which every drawing primitive remains a separately editable technical object.

How to use

You say/architectural-project-deck Turn this fictional courtyard-housing brief into a six-slide architectural review deck.
  1. Provide the project brief, phase, review audience, decision goal and count. Supply rights-cleared site facts, plans, sections, program/material data and photography, with known assumptions, revision information and the exact disclaimer/professional-review wording.

  2. Normalize units, dates and drawing revisions before composing. Distinguish verified and assumed dimensions, identify the question the review must answer and record evidence in a source ledger. Do not reuse North Quay’s sample dwelling count, area or courtyard dimension as project data.

  3. Plan one major artifact per page and select Tracing Paper, Oxide Survey or Blue Datum during generation. Use generous whitespace, readable technical annotations and concise insight-led titles. Keep no more than two dark hinge pages in a typical deck and avoid three successive pages with the same background role.

  4. Compose using the six installed recipes, adapting nodes for a plan/section pair, proportional program stack or two-option/four-criteria decision matrix if needed. Keep drawings as editable SVG/CSS where appropriate and use approved locally embedded rasters otherwise. Image generation is optional; essential geometry and evidence must come from the brief rather than an invented rendering.

  5. Preserve visible units, source, revision, preliminary status and review note. Sheet codes are editable content, not a documented dedicated show/hide switch in the shared editor. If a code is omitted for a presentation version, keep essential provenance elsewhere and record the change. Labeled inline SVG cues support the drawings without decorative brands or glyph arrows.

  6. Compose/build/check with Python 3 and the agreed count/style kit, resolving sample leftovers and unfilled slots. Keep the shared editor unchanged and final fonts/media embedded; the core build does not need Node packages. Interface language can differ from slide language, with English copy the default unless requested otherwise.

  7. Open over local HTTP and inspect dimensions, labels, datums, crops, source notes, contrast and bounds on every page. Test Edit/E, picture replacement, drawing/text changes, notes, slide order, undo/redo, Save and reopening. The three palettes are generation choices; individual colors are editable but no preset picker is supplied.

  8. Export requested PPTX/PDF, run the PPTX check and inspect text/notes, drawing layers and font substitutions in PowerPoint, Keynote or WPS. Deliver the source ledger, assumptions, unresolved questions and exact QA findings with the HTML. A successful export does not establish design or professional approval.

Requirements and costs

You bring
Project brief, phase, review audience, and decision goal · Rights-cleared site facts, plans, sections, program, or material data · Known assumptions, revision information, and professional disclaimer
Dependencies
Modern browser — required · Node.js 20 or newer — required for validation · Chrome, Chromium or Edge plus Node.js 20 or newer — required only for PowerPoint export
Outside costs
Not collected yet
Publisher testing
v1.0.5 — Claude Code / Claude Desktop / Cowork / Codex / ChatGPT

FAQ

User reviews

—0 reviews

Select a star to share your experience.

No reviews yet. Ratings appear once readers share real experiences.

Similar Skills

View all skills