Rules on paper, for whoever writes the language next

A skills directory arrives: a working instruction and a canonical ruleset, written as short imperatives that a person or a model can follow without prior knowledge of the project.

Where the guide explains how things work, this states what holds. A few of them:

Correct code in the wrong place is invalid, even when the syntax is right. Only .phlo files are source; everything in /php and /www is generated output. Each .phlo file transpiles to exactly one PHP class. A view ends at the first blank line.

The first is the one that needed writing down. In most languages placement is style. Here it is meaning: HTML belongs in a view, CSS in a style block, JavaScript in a script block, and a line that is syntactically fine in the wrong node produces something valid and wrong. That is not visible from reading working code, because working code never shows you the mistake.

The instruction opens with the boundary that matters most: edit only .phlo files, never the generated PHP, CSS or JavaScript. Anyone who has watched a fix disappear on the next build knows why that is rule one.

This makes an existing stance explicit. The same properties that let a language be taught in a page let it be worked with by a model, and treating that as a goal rather than a side effect is what lets a small team keep up.