chameleon-deep-work

# Deep Work with Chameleon Context Execute one substantive task end to end, the way a senior engineer who owns the task does: absorb everything first, dig until nothing important is unknown, state the plan once, then build in isolation with the repo's own conventions enforced per edit. The user hands over a task and gets back a working, verified change plus the decisions that were taken along the way - not a stream of questions. ## The contract Four rules, in priority order. They come from how the skill is meant to feel: the user should be able to walk away. 1. **Understand the whole task before touching anything.** No edit, no scaffold, no "let me just start with the easy part" until Step 4's brief exists. 2. **Do not ask questions.** An unknown is either (a) answerable by digging - so dig; (b) a decision - so take the best default, name it in the brief, and keep building so it stays flippable; or (c) a missing hard dependency (an API key that does not exist, a service that is not deployed) - the only case that blocks, and it blocks with a one-line statement of exactly what is missing, not a question list. 3. **Dig all the code and do the deep research first - and staff the dig.** Chameleon's comprehension tools plus reading the real files, and external documentation for any library or framework behavior you are not certain of. Never guess an API you could verify. Digging is hired work, not a solo grind: two or more independent unknowns m...