ck-architectlisted

# CK Architect Sketch the caller's experience before the machinery behind it. Derive types, function signatures, data contracts, and module boundaries from that usage, with `not implemented` bodies and pseudocode. Compare structurally different designs, then implement the chosen shape when implementation is in scope. If the work reveals that shape is wrong, redesign around the new evidence. ## Dependencies and scope Read **ck-how** for existing-system grounding, **ck-why** when changing ownership or layering requires historical rationale, and **ck-arena** for candidate design and synthesis. Resolve each by name in the available skill catalog, or read its `SKILL.md` in the sibling skill folder. Read the resolved instructions before using them; a skill name is not a tool call. If a required skill is unavailable, identify the missing dependency and pause that phase while continuing useful independent work. Use the host's available tools and agents. Honor the user's task scope, settled constraints, and decisions already reached through deposition or other planning. A design-only request ends with a concrete design package. An implementation request authorizes continuing through implementation; an explicit checkpoint pauses before it. Record the applicable phases in the working plan: 1. Ground 2. Sketch 3. Agree 4. Implement, when requested 5. Scrap and redesign, when evidence calls for it ## Phase A: Ground the problem Build a traced model of the systems the change touches