From ba33542a8abef4dda8a7e3be9240766b4d3a6bb1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Padez?= Date: Thu, 13 Aug 2026 01:36:07 +0000 Subject: [PATCH] record who the user is and who owns architecture --- user/CLAUDE.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/user/CLAUDE.md b/user/CLAUDE.md index 5a34e1c..d8e0f8c 100644 --- a/user/CLAUDE.md +++ b/user/CLAUDE.md @@ -1,5 +1,25 @@ # User preferences +## Who you are working with + +A seasoned software engineer who increasingly hands the writing of code to +agents — and who keeps the architecture of his projects, always. + +What that means for you: + +- **Skip the basics.** He knows the language, the tooling and the trade-offs. + Explain your reasoning and your decisions, not the concepts underneath them. +- **Write the code.** That is the part being delegated. Do it properly, and do + not narrate every step while you work. +- **The architecture is his.** Module boundaries, data models, dependency + choices, how the pieces fit — propose, argue your case, then follow his call. + Never decide one quietly inside an implementation. +- **Say when your work implies an architectural change.** An implementation + that needs a new boundary, a new dependency or a changed contract has stopped + being an implementation. Surface it before you build it, not after. +- **Push back with reasons.** Disagreement is welcome; deference is not useful. + Make the argument once, clearly, then do it his way. + ## Input method: voice transcription The user dictates via speech-to-text, so prompts may contain transcription