record who the user is and who owns architecture

2026-08-13 01:36:07 +00:00
parent 87806f37c9
commit ba33542a8a
1 changed files with 20 additions and 0 deletions
@@ -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