write-page-objectlisted

# Skill: write-page-object Add one class that owns the locators for a screen and exposes what a user can *do* there. The point of this layer is not encapsulation for its own sake. It is that when a screen changes, the number of files that must change is one. Every design decision below follows from that, and any decision that does not serve it is ceremony. ## Preconditions 1. `.claude/test-profile.md` exists and records a model layer. If the profile says `none`, this repo has no such layer — do not unilaterally introduce one. Ask; adding an architectural layer is the user's call. 2. You know which screen, and which interactions the calling spec needs. Build for the caller in front of you, not for imagined future callers. ## Procedure ### 1. Read the nearest existing model, and the base class From the neighbour, record: the export style, the constructor signature, where locators are declared and initialised, the visibility modifiers used, and the method naming pattern. From the base class, record every member subclasses are obliged to implement and every helper they are expected to use instead of raw calls. Then check the model does not already exist under a different name. Two models for one screen is worse than none, because a locator fix lands in only one of them. ### 2. Write the class ``` class <Screen> extends <the repo's base, if it has one> { // every locator declared here, with the repo's visibility modifier // every locator resolved in the cons