Before you wayfind, orient. Wayfinding charts a way from here to a destination, but you can't chart from here if you don't know where here is. Orienting reads the terrain the requirement lands on, so every subsequent plan is grounded in what already exists.

Read the terrain

The requirement is your compass — it points the direction. Survey the terrain between here and where it points, not the whole project.

Glossary. Read CONTEXT.md, or CONTEXT-MAP.md if the repo carries multiple contexts — follow it to the one the requirement touches. Extract the ubiquitous language: terms the project has already agreed on. A term in the requirement that the glossary defines is now precise; one it doesn't is a gap.
Decisions. Read docs/adr/ — the architectural decisions already locked. Each narrows what the plan can propose without re-opening a settled question. Extract those in the requirement's area.
Docs. Read the project's documentation — README.md, docs/, and any local knowledge base (knowledge_search, kb_read). Extract what's already written about the area.
Conventions. Read the project's development conventions — AGENTS.md, DEVELOPMENT.md, CONTRIBUTING.md, .claude/rules/, Makefile targets, pre-commit config. Extract the rules the work must follow: commit conventions, verification commands, lint policies, code-review patterns, must-read skills before modifying specific components.
Codebase. Survey the code the requirement will touch. Use codegraph for fast symbol search where available; otherwise read directory structure and key files. Map the seams — existing interfaces, modules, and patterns the work should follow rather than invent. While surveying, note landmarks — existing implementations whose semantics resemble what the requirement asks for. A landmark is not a seam to follow but a point to navigate by: its code encodes behavior, boundaries, and design decisions more precisely than prose, and the plan can migrate semantics from it rather than describing them from scratch.
Waymarks. Read test files in the requirement's area. Tests are waymarks — markers left by previous travelers on the terrain, indicating paths that pass and boundaries that hold. A test named test_old_user_compatibility tells you more about hidden constraints than any README. Extract the behaviors tests assert and the boundary conditions they guard.

A terrain layer that doesn't exist — no CONTEXT.md, no ADRs, no docs, no conventions — is itself a gap; note it. This skill is read-only; /skill:domain-modeling handles creation, reached when grilling resolves a term or decision.