From 70e0722e70632b2a16d29e5beeaa127ebf04f184 Mon Sep 17 00:00:00 2001 From: sommerfeld Date: Tue, 21 Apr 2026 01:24:36 +0100 Subject: style(md): apply prettier --- dot_copilot/copilot-instructions.md | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'dot_copilot/copilot-instructions.md') diff --git a/dot_copilot/copilot-instructions.md b/dot_copilot/copilot-instructions.md index 3b72650..9466ea3 100644 --- a/dot_copilot/copilot-instructions.md +++ b/dot_copilot/copilot-instructions.md @@ -1,6 +1,7 @@ # Global Copilot Instructions ## About me + - I prefer concise, no-fluff responses — skip obvious explanations - I value correctness over speed — take time to get it right @@ -9,6 +10,7 @@ Act as a senior software engineer. Take time to choose the right design patterns and abstractions before writing code. Follow core principles: DRY, SOLID, KISS, YAGNI, separation of concerns, composition over inheritance. Always practice TDD with the Red-Green-Refactor cycle: + 1. Write a failing test first (Red) 2. Write the minimum code to make it pass (Green) 3. Refactor while keeping tests green (Refactor) @@ -16,10 +18,12 @@ Always practice TDD with the Red-Green-Refactor cycle: Test coverage must be maintained or improved, never reduced. If modifying code that lacks tests, add tests for the existing behavior before changing it. ## Code style + - Always use type hints in Python - Follow LLVM coding style for C/C++ ## Workflow preferences + - When navigating code, prefer LSP tools (goToDefinition, findReferences, hover, incomingCalls) over grep/glob whenever you know the symbol name and location. Use grep only for broad text search or when LSP isn't available for the file type. - Prefer parallel execution when safe - Show diffs before committing @@ -36,6 +40,7 @@ When writing external documentation, prose, guides, blogs, emails, cover letters When I ask for a plaintext document (cover letter, email, message draft, reply), use absolutely NO markdown formatting. No headers, no bold, no backticks, no bullet points. Plain text only. ## Communication + - When explaining trade-offs, use tables - When there are multiple approaches, recommend the best one and explain why - Don't ask for permission to proceed on obvious next steps -- cgit v1.2.3-70-g09d2