Daylight Study

Give it each room's depth, its window head height, and its glazing area, and it tells you how much of the room daylight actually reaches. The depth convention and the obstruction geometry are worked out and shown step by step. Everything about your rooms, and everything the code demands, is yours to supply.

Workflow

Step 1. Collect the rooms

Ask, in one message:

1. Which rooms, and for each: the depth from the window wall, and the floor area.
2. The window head height in each room, measured from the floor.
3. The glazing area per room, and what you counted as glazing.
4. Is there a code minimum to check against? If so, quote it and name where it is from. Without one I report ratios, not verdicts.
5. Does anything face the windows? If so, its height and the distance from the window to it, and the sill or working-plane height you care about.

Confirm the units back before computing. Everything comes back in the units given, and a study run with a metric head height against imperial depths is wrong everywhere and looks fine.

Step 2. Compute the daylit depth

State the convention before the arithmetic, every time:

convention      daylit depth ~ 2.0 x window head height for a sidelit room,
                ~ 2.5 x with a high transom or light shelf
                (a rule-of-thumb convention, not a code value; name your own
                multiplier and I will use it instead)
daylit depth    <multiplier x head height, arithmetic shown>
room depth      <as given>
remainder       <room depth - daylit depth, or "fully daylit">

Per room. A room deeper than its daylit depth is not a failure; it is a fact about the plan, and the report says how much of the room is past the light.

Step 3. Compute the glazing ratio

glazing area    <as given>
floor area      <as given>
ratio           <glazing / floor, arithmetic shown>
minimum         <quoted from the user, with their source, or "none supplied">

If a minimum was quoted, state each room against it in the user's own words. If none was, report the ratio bare and say the rule to hold it against is theirs to bring.

Step 4. Compute the no-sky line, where something faces the window

Only for rooms where the user gave an obstruction. From the working plane, sky is visible through the window head until the line of sight from a point in the room, through the head, drops below the top of what faces it. Set the two sight lines equal and solve for the depth, showing the triangles:

head above working plane         <arithmetic>
obstruction above working plane  <arithmetic>
distance to obstruction          <as given>
no-sky depth                     <similar triangles, arithmetic shown>

If the obstruction top sits below the window head as seen from the window, the sky is clear and the row says so. If the geometry gets past one facing plane, a court, a reveal, a sloped tower, say so and stop rather than approximating silently.

Step 5. Report

One table, rooms as rows, options side by side if there is more than one layout:

Room	Depth	Head height	Daylit depth	Past the light	Glazing : floor	No-sky depth

Then, in prose: which rooms sit deepest past their daylight, and what moves each one, since there are only three levers: raise the head, pull the depth, or borrow light through the plan. If a code minimum was quoted, each room stands against it, quoted as given. If layouts are being compared, say where the options actually differ, not just what each scores.

Close every run with: sidelight only, glass properties not modeled, and anything filed for a credit or a code alternative comes from a simulation, not from this table.

Step 6. Save, if asked

Ask whether to write the study to a file and where. Write it directly, including the convention and arithmetic lines. There is no template and no script.

Rules

• The depth convention and the obstruction geometry are the only things this skill knows. Every dimension, area, and minimum comes from the user, and each carries its source in the output.
• Name the convention as a convention, with its multiplier, before using it. The user's own multiplier always replaces it.
• No verdict against a code without the code text quoted by the user, source named. Without it, ratios are measurements, not findings.
• Print the arithmetic per room. A daylit depth nobody can re-derive is not checkable.
• Never convert the user's units. Confirm them once, then keep them.
• Say on every run that this is plan-stage arithmetic, not a simulation.

Anti-patterns

• Quoting a light-and-ventilation minimum from memory ("code wants glazing at 8% of floor area") instead of asking for the text. Percentages and what counts toward them are code text and go stale; the user brings them.
• Reporting a daylight factor or an illuminance. That is a simulation's answer wearing arithmetic's clothes, and it will be wrong.
• Treating the 2-times-head-height convention as a limit a room passes or fails, or presenting it without saying it is a convention.
• Skipping a facing building the user mentioned because they left out its height. Ask; the no-sky line is often the whole answer.
• Calling a room compliant. A room meets the minimum the user quoted, in their words, or the question stays open.

Resources

None. This skill is one file. Output is written directly at the path you choose.