dev-docslisted

# dev-docs ## Establish context before making changes 1. Read the applicable project instructions. When available, locate the documentation index, canonical policy, layer registry, and affected cards/decisions. In an empty project, the absence of these files, established layers, and code does not block init or discover. 2. Determine the action and request boundaries. Installing or invoking the skill does not by itself authorize restructuring the project. If the goal is undefined, propose an option or perform a read-only audit; do not begin a broad migration. 3. Determine the actual rule source according to the [adoption requirements](references/adoption.md): either a complete project-local copy or a pinned public link. Do not look for a separate mode/profile. Until an adoption method has been selected and verified, the existing rules remain in effect. If there is a conflict, propose resolving it; do not silently switch the rule source. 4. Do not invent requirements, owners, accepted decisions, deadlines, a stack, or constraints. Record unknowns as open questions. Do not create sample tasks from templates. Justify every new product or technical choice and explicitly agree it with the user according to the policy's "Decision approval" section. Applying already approved rules does not require renewed agreement; do not treat your own proposal as an accepted decision. Determine the permitted write mode first. ## Selective loading Read only the refe