A prompt I use to make help keep my development consistent

development-context-prompt.txt

Review any planning documents in the .plan folder to get context. If find any ambiguity in execution, you must ask for my clarification

  A few biases you need to follow for python development:
  - you must follow red/green/refactor
  - structure the code in a way that dependencies are injectable.
  - YAGNI
  - 12 factor app principals
  - Extreme programming principals
  - test class when testing a class and when testing a global method it should just be a test method
  - pytest fixtures should be defined in the class when needed
  - use pytest fixtures for creating mocks
  - if we use a dependency injection framework, we should have a test container fixture.
  - if we have a test class we should have a subject fixture
  - if we have a subject fixture and that fixture has dependencies that are injectable we should do any overriding of those dependencies there
  - patching should be used only where absolutely needed (e.g. patching os.env, or a global function)
  - never ever mock or patch third party party dependencies or system dependencies. You should lean on abstraction and encapsulation. An analogy: the code structure is
  the a circle, anything we cannot test should continue to be pushed to the outer part of the circle. The inner part of the circle is what we can mock, unit test, etc.
  The outer part should be covered by e2e or integration tests. We don't do this because this can lead to instability in the code (e.g. you mock something to behavior a
  specific way that it doesn't actually behave like)
  - If creating mocks always use spec. All mocks should be directly modelled from the class they are mocking and should not be allowed respond to any random method
  reference (e.g. mock_instance.does_not_exist.return_value =... should result in an error)
  - test assertions should be strong (e.g. asserting on return structure, type, mocks called with, etc)
  - you can use mock.assert_called... to give a hook into the code so that internal inputs and outputs can validated
  - the implementation should always use typing
  - when starting a new feature we should have a failing integration test that confirms the overall contract (e.g. the inputs and outputs of all "units" together). Once
  this is defined we can go into red/green/refactor iterations at the unit test level. The idea being once all the iterations are done and the unit tests pass the
  integration test should pass.
  - you must follow red/green/refactor # duplicated intentionally
  - imports must always be at the top
  - if you define a mock like this: `mock_class = MagicMock(spec=Class)`, do not do this: `mock_class.method = AsyncMock(side_effect=fake_maethod_side_effect)` if the functions is defined it will already setup to be a mock. If's not defined it will fail which is what is expected (we can define it later)
  - imports always go at the top of the file
  - if addressing a bug, you must a write a fao;omg test to prove the bug is reproducible and that you understand what the actual issue is
  - any commit being made should be a single-lined conventional commit. No self promotion (e.g. Generated with [Claude..., Co-authored-by: Claude... ). The same goes for gemini or any other LLM that is using this.
  - It's okay to say you don't know something or need to get more information on it. 
  - Adopt an 'outside-in' methodology: Develop from the external interface inward to solidify the contract. Examples: Full Stack: Build the frontend first to finalize the API requirements before backend implementation. API Design: Map out routes and schemas before coding internal business logic.