# Site Context > Turn supplied site facts (orientation, topography, access, climate, neighbours, views, constraints) into a design-relevant reading — opportunities and constraints, and how each should shape the concept. Use at RIBA Stage 0–1 / AIA Pre-Design for a "site analysis", "site appraisal write-up", "read this site", or "what does this site want to be". Works only from facts you provide; it never invents… - **Type:** Skill - **Install:** `agentstack add skill-gaia-computer-technologies-architecture-skills-site-context` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [gaia-computer-technologies](https://agentstack.voostack.com/s/gaia-computer-technologies) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [gaia-computer-technologies](https://github.com/gaia-computer-technologies) - **Source:** https://github.com/gaia-computer-technologies/architecture-skills/tree/main/plugins/concept-design/skills/site-context - **Website:** https://www.gaia.computer/skills ## Install ```sh agentstack add skill-gaia-computer-technologies-architecture-skills-site-context ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Site Context Read a site the way an architect does on the first visit: not as a list of facts, but as a set of forces the design will answer to. Turn what is known about the site into design implications — where to open, where to close, where the building wants to sit, what to protect against. ## When to use - Early in a project (RIBA Stage 0–1 / AIA Pre-Design), once site information exists. - To write the site-appraisal section of a brief or a Design & Access Statement. - To move from raw site data (a survey, a planning portal printout, a walk-round note) to design consequences. ## The one rule that matters **You work only from site facts the user supplies (or that can be genuinely retrieved).** You do not know this site. Orientation, flood zone, conservation-area status, rights of light, ground conditions, microclimate, sun path, wind, noise — these are *specific and checkable*, and a confident guess is worse than a flagged gap. If a fact isn't given, put it in "To confirm," never invent it. The value here is turning facts into design moves, not sourcing the facts. ## Input Any of — and note what's missing: - Location / address / coordinates, and orientation (which way does the frontage face?) - Topography and levels; access points; existing structures/trees to keep - Neighbours — heights, uses, overlooking, party walls - Views to frame and views to screen - Climate and sun path (heat, prevailing wind, rainfall) — as supplied or from a named source - Constraints — planning designations, easements, flood, noise, contamination — as supplied - The brief or intended use, if known ## Process 1. **Inventory what you were given, and what you weren't.** Separate stated facts from unknowns immediately. The unknowns become "To confirm." 2. **For each fact, ask "so what for the design?"** A north-facing frontage is not an observation; it's an instruction about where living space and glazing want to go. Orientation → daylight and heat strategy. Slope → section and entry level. A bad view → where the building turns its back. This translation is the whole job. 3. **Separate opportunities from constraints,** but treat constraints as design generators — the overlooking neighbour sets up the courtyard; the slope gives you the split section. 4. **Name the site's defining move** — the one condition the design should organise around (the view, the slope, the sun, the one good tree). Most sites have one. 5. **Flag everything unverifiable.** Anything regulatory (flood, conservation, rights of light, zoning) gets a "verify with [authority/survey]" note and the disclaimer block if you've asserted a regulated fact. ## Domain knowledge (how facts become moves) - **Orientation** — In the northern hemisphere, south light is the prize (control it); north light is even and calm (studios, kitchens); east is morning; west is low, warm, and hard to shade. Invert for the southern hemisphere. Put habitable rooms and glazing where the good light is; put service and circulation where it isn't. - **Slope** — A section problem before a plan problem. Cut-and-fill, split levels, entry at mid-level, and the chance for a raumplan. Work with the contours, not against them. - **Approach and threshold** — How you arrive sets the whole experience. Where the eye lands, where the level changes, where compression precedes release. - **Neighbours and overlooking** — Drive the inward/outward logic: courtyards, clerestories, high-level glazing, the blank elevation that becomes a strength. - **Prospect and shelter** — Frame the view worth having; brace against the wind and the worst weather. The two often pull in opposite directions — resolving that tension is design. - **Microclimate** — Thermal mass suits hot-arid and high-diurnal-swing climates; lightweight suits humid; wet climates punish detailing that traps water. Take actual figures as input; don't recall climate data from memory. ## Output format ``` ## Site Reading **The site in one line:** [the defining condition the design should organise around] **Opportunities** - [fact] → [design move it invites] **Constraints (as design generators)** - [fact] → [how the design turns it to advantage or answers it] **Orientation & light strategy** [Where habitable space and glazing want to go, and why — from the given orientation.] **Organising response** [2–3 sentences: given all of the above, where the building wants to sit and how it opens and closes.] **To confirm (do not design around until verified)** - [unknown or regulated fact] → [who confirms it: survey / planning authority / arborist / etc.] ``` ## What you don't do - Don't invent site facts. No assumed orientation, flood status, planning designation, ground condition, or climate figure. If it wasn't given, it's "To confirm." - Don't give planning or regulatory rulings. Flag conservation, flood, rights-of-light, and zoning as items to verify with the authority; append the disclaimer block if you've named a regulated fact. - Don't produce a generic "site analysis" that could describe anywhere. If your reading doesn't depend on *this* site's specifics, you're padding. - Don't stop at observation. Every fact must earn a design consequence, or leave it out. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [gaia-computer-technologies](https://github.com/gaia-computer-technologies) - **Source:** [gaia-computer-technologies/architecture-skills](https://github.com/gaia-computer-technologies/architecture-skills) - **License:** MIT - **Homepage:** https://www.gaia.computer/skills Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-gaia-computer-technologies-architecture-skills-site-context - Seller: https://agentstack.voostack.com/s/gaia-computer-technologies - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.