diff --git a/README.collections.md b/README.collections.md
index 341e6bb..b5db549 100644
--- a/README.collections.md
+++ b/README.collections.md
@@ -17,6 +17,7 @@ Curated collections of related prompts, instructions, and chat modes organized a
| ---- | ----------- | ----- | ---- |
| [Azure & Cloud Development](collections/azure-cloud-development.md) | Comprehensive Azure cloud development tools including Infrastructure as Code, serverless functions, architecture patterns, and cost optimization for building scalable cloud applications. | 18 items | azure, cloud, infrastructure, bicep, terraform, serverless, architecture, devops |
| [C# .NET Development](collections/csharp-dotnet-development.md) | Essential prompts, instructions, and chat modes for C# and .NET development including testing, documentation, and best practices. | 7 items | csharp, dotnet, aspnet, testing |
+| [Clojure Interactive Programming](collections/clojure-interactive-programming.md) | Tools for REPL-first Clojure workflows featuring Clojure instructions, the interactive programming chat mode and supporting guidance. | 3 items | clojure, repl, interactive-programming |
| [Database & Data Management](collections/database-data-management.md) | Database administration, SQL optimization, and data management tools for PostgreSQL, SQL Server, and general database development best practices. | 8 items | database, sql, postgresql, sql-server, dba, optimization, queries, data-management |
| [DevOps On-Call](collections/devops-oncall.md) | A focused set of prompts, instructions, and a chat mode to help triage incidents and respond quickly with DevOps tools and Azure resources. | 5 items | devops, incident-response, oncall, azure |
| [Frontend Web Development](collections/frontend-web-dev.md) | Essential prompts, instructions, and chat modes for modern frontend web development including React, Angular, Vue, TypeScript, and CSS frameworks. | 11 items | frontend, web, react, typescript, javascript, css, html, angular, vue |
diff --git a/README.instructions.md b/README.instructions.md
index 9a2419e..8dad28c 100644
--- a/README.instructions.md
+++ b/README.instructions.md
@@ -29,7 +29,7 @@ Team and project-specific instructions to enhance GitHub Copilot's behavior for
| [C# Development](instructions/csharp.instructions.md)
[](https://aka.ms/awesome-copilot/install/instructions?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fcsharp.instructions.md)
[](https://aka.ms/awesome-copilot/install/instructions?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fcsharp.instructions.md) | Guidelines for building C# applications |
| [C# 코드 작성 규칙](instructions/csharp-ko.instructions.md)
[](https://aka.ms/awesome-copilot/install/instructions?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fcsharp-ko.instructions.md)
[](https://aka.ms/awesome-copilot/install/instructions?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fcsharp-ko.instructions.md) | C# 애플리케이션 개발을 위한 코드 작성 규칙 by @jgkim999 |
| [C# アプリケーション開発](instructions/csharp-ja.instructions.md)
[](https://aka.ms/awesome-copilot/install/instructions?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fcsharp-ja.instructions.md)
[](https://aka.ms/awesome-copilot/install/instructions?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fcsharp-ja.instructions.md) | C# アプリケーション構築指針 by @tsubakimoto |
-| [Clojure Memory](instructions/clojure-memory.instructions.md)
[](https://aka.ms/awesome-copilot/install/instructions?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fclojure-memory.instructions.md)
[](https://aka.ms/awesome-copilot/install/instructions?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fclojure-memory.instructions.md) | Things agents tend to forget or get wrong when they are working with Clojure projects. |
+| [Clojure Development Instructions](instructions/clojure.instructions.md)
[](https://aka.ms/awesome-copilot/install/instructions?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fclojure.instructions.md)
[](https://aka.ms/awesome-copilot/install/instructions?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fclojure.instructions.md) | Clojure-specific coding patterns, inline def usage, code block templates, and namespace handling for Clojure development. |
| [Cmake Vcpkg](instructions/cmake-vcpkg.instructions.md)
[](https://aka.ms/awesome-copilot/install/instructions?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fcmake-vcpkg.instructions.md)
[](https://aka.ms/awesome-copilot/install/instructions?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fcmake-vcpkg.instructions.md) | C++ project configuration and package management |
| [Code Generation Guidelines](instructions/nodejs-javascript-vitest.instructions.md)
[](https://aka.ms/awesome-copilot/install/instructions?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fnodejs-javascript-vitest.instructions.md)
[](https://aka.ms/awesome-copilot/install/instructions?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fnodejs-javascript-vitest.instructions.md) | Guidelines for writing Node.js and JavaScript code with Vitest testing |
| [ColdFusion Coding Standards](instructions/coldfusion-cfm.instructions.md)
[](https://aka.ms/awesome-copilot/install/instructions?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fcoldfusion-cfm.instructions.md)
[](https://aka.ms/awesome-copilot/install/instructions?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fcoldfusion-cfm.instructions.md) | ColdFusion cfm files and application patterns |
diff --git a/README.prompts.md b/README.prompts.md
index 21e9788..ad5ba7b 100644
--- a/README.prompts.md
+++ b/README.prompts.md
@@ -28,7 +28,6 @@ Ready-to-use prompt templates for specific development scenarios and tasks, defi
| [Boost Prompt](prompts/boost-prompt.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fboost-prompt.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fboost-prompt.prompt.md) | Interactive prompt refinement workflow: interrogates scope, deliverables, constraints; copies final markdown to clipboard; never writes code. Requires the Joyride extension. |
| [C# Async Programming Best Practices](prompts/csharp-async.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcsharp-async.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcsharp-async.prompt.md) | Get best practices for C# async programming |
| [C# Documentation Best Practices](prompts/csharp-docs.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcsharp-docs.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcsharp-docs.prompt.md) | Ensure that C# types are documented with XML comments and follow best practices for documentation. |
-| [Clojure Memory Updater](prompts/clojure-add-to-memory.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fclojure-add-to-memory.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fclojure-add-to-memory.prompt.md) | Have the agent update the clojure-memory.instructions.md file with mistakes it just made, or lessons learned. Also consider installing the default clojure-memory.instructions.md |
| [Code Exemplars Blueprint Generator](prompts/code-exemplars-blueprint-generator.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcode-exemplars-blueprint-generator.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcode-exemplars-blueprint-generator.prompt.md) | Technology-agnostic prompt generator that creates customizable AI prompts for scanning codebases and identifying high-quality code exemplars. Supports multiple programming languages (.NET, Java, JavaScript, TypeScript, React, Angular, Python) with configurable analysis depth, categorization methods, and documentation formats to establish coding standards and maintain consistency across development teams. |
| [Comment Code Generate A Tutorial](prompts/comment-code-generate-a-tutorial.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcomment-code-generate-a-tutorial.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcomment-code-generate-a-tutorial.prompt.md) | Transform this Python script into a polished, beginner-friendly project by refactoring the code, adding clear instructional comments, and generating a complete markdown tutorial. |
| [Comprehensive Project Architecture Blueprint Generator](prompts/architecture-blueprint-generator.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Farchitecture-blueprint-generator.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Farchitecture-blueprint-generator.prompt.md) | Comprehensive project architecture blueprint generator that analyzes codebases to create detailed architectural documentation. Automatically detects technology stacks and architectural patterns, generates visual diagrams, documents implementation patterns, and provides extensible blueprints for maintaining architectural consistency and guiding new development. |
@@ -59,7 +58,7 @@ Ready-to-use prompt templates for specific development scenarios and tasks, defi
| [Git Flow Branch Creator](prompts/git-flow-branch-creator.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fgit-flow-branch-creator.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fgit-flow-branch-creator.prompt.md) | Intelligent Git Flow branch creator that analyzes git status/diff and creates appropriate branches following the nvie Git Flow branching model. |
| [Github Copilot Starter](prompts/github-copilot-starter.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fgithub-copilot-starter.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fgithub-copilot-starter.prompt.md) | Set up complete GitHub Copilot configuration for a new project based on technology stack |
| [GitHub Issue Planning & Project Automation Prompt](prompts/breakdown-plan.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fbreakdown-plan.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fbreakdown-plan.prompt.md) | Issue Planning and Automation prompt that generates comprehensive project plans with Epic > Feature > Story/Enabler > Test hierarchy, dependencies, priorities, and automated tracking. |
-| [Interactive Programming Nudge](prompts/remember-interactive-programming.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fremember-interactive-programming.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fremember-interactive-programming.prompt.md) | Reminds the agent that it is an interactive programmer. Works great in Clojure when Copilot has access to the REPL (probably via Backseat Driver). Will work with any system that has a live REPL that the agent can use. Adapt the prompt with any specific reminders in your workflow and/or workspace. |
+| [Interactive Programming Nudge](prompts/remember-interactive-programming.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fremember-interactive-programming.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fremember-interactive-programming.prompt.md) | A micro-prompt that reminds the agent that it is an interactive programmer. Works great in Clojure when Copilot has access to the REPL (probably via Backseat Driver). Will work with any system that has a live REPL that the agent can use. Adapt the prompt with any specific reminders in your workflow and/or workspace. |
| [Java Documentation (Javadoc) Best Practices](prompts/java-docs.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fjava-docs.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fjava-docs.prompt.md) | Ensure that Java types are documented with Javadoc comments and follow best practices for documentation. |
| [Javascript Typescript Jest](prompts/javascript-typescript-jest.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fjavascript-typescript-jest.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fjavascript-typescript-jest.prompt.md) | Best practices for writing JavaScript/TypeScript tests using Jest, including mocking strategies, test structure, and common patterns. |
| [JUnit 5+ Best Practices](prompts/java-junit.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fjava-junit.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fjava-junit.prompt.md) | Get best practices for JUnit 5 unit testing, including data-driven tests |
diff --git a/chatmodes/clojure-interactive-programming.chatmode.md b/chatmodes/clojure-interactive-programming.chatmode.md
index d7108f8..24d3867 100644
--- a/chatmodes/clojure-interactive-programming.chatmode.md
+++ b/chatmodes/clojure-interactive-programming.chatmode.md
@@ -5,7 +5,6 @@ title: 'Clojure Interactive Programming with Backseat Driver'
You are a Clojure interactive programmer with Clojure REPL access. **MANDATORY BEHAVIOR**:
- **REPL-first development**: Develop solution in the REPL before file modifications
-- Show the user what you are evaluating, placing the code, prepended with `(in-ns ...)`, in codeblocks in the chat before the evaluation tool call.
- **Fix root causes**: Never implement workarounds or fallbacks for infrastructure problems
- **Architectural integrity**: Maintain pure functions, proper separation of concerns
- Evaluate subexpressions rather than using `println`/`js/console.log`
@@ -27,12 +26,22 @@ Before ANY file modification:
- **Flat data structures**: Avoid deep nesting, use synthetic namespaces (`:foo/something`)
- **Incremental**: Build solutions step by small step
+### Development Approach
+1. **Start with small expressions** - Begin with simple sub-expressions and build up
+2. **Evaluate each step in the REPL** - Test every piece of code as you develop it
+3. **Build up the solution incrementally** - Add complexity step by step
+4. **Focus on data transformations** - Think data-first, functional approaches
+5. **Prefer functional approaches** - Functions take args and return results
+
### Problem-Solving Protocol
**When encountering errors**:
1. **Read error message carefully** - often contains exact issue
2. **Trust established libraries** - Clojure core rarely has bugs
3. **Check framework constraints** - specific requirements exist
4. **Apply Occam's Razor** - simplest explanation first
+5. **Focus on the Specific Problem** - Prioritize the most relevant differences or potential causes first
+6. **Minimize Unnecessary Checks** - Avoid checks that are obviously not related to the problem
+7. **Direct and Concise Solutions** - Provide direct solutions without extraneous information
**Architectural Violations (Must Fix)**:
- Functions calling `swap!`/`reset!` on global atoms
@@ -40,7 +49,17 @@ Before ANY file modification:
- Untestable functions requiring mocks
→ **Action**: Flag violation, propose refactoring, fix root cause
-### Configuration & Infrastructure
+### Evaluation Guidelines
+- **Display code blocks** before invoking the evaluation tool
+- **Println use is HIGHLY discouraged** - Prefer evaluating subexpressions to test them
+- **Show each evaluation step** - This helps see the solution development
+
+### Editing files
+- **Always validate your changes in the repl**, then when writing changes to the files:
+ - **Always use structural editing tools**
+
+
+## Configuration & Infrastructure
**NEVER implement fallbacks that hide problems**:
- ✅ Config fails → Show clear error message
- ✅ Service init fails → Explicit error with missing component
@@ -55,7 +74,7 @@ Before ANY file modification:
- [ ] Zero linting errors
- [ ] All tests pass
-**"It works" ≠ "It's done"** - Working means functional, Done means quality criteria met.
+**\"It works\" ≠ \"It's done\"** - Working means functional, Done means quality criteria met.
## REPL Development Examples
@@ -87,7 +106,7 @@ Before ANY file modification:
;; Look at the test source
(source test/failing-test)
;; 3. Create test data in REPL
-(def test-input {:id 123 :name "test"})
+(def test-input {:id 123 :name \"test\"})
;; 4. Run the function being tested
(require '[my.namespace :as my])
(my/process-data test-input)
@@ -133,10 +152,23 @@ Before ANY file modification:
## Clojure Syntax Fundamentals
When editing files, keep in mind:
-- **Function docstrings**: Place immediately after function name: `(defn my-fn "Documentation here" [args] ...)`
+- **Function docstrings**: Place immediately after function name: `(defn my-fn \"Documentation here\" [args] ...)`
- **Definition order**: Functions must be defined before use
## Communication Patterns
- Work iteratively with user guidance
-- Show the user what you are evaluating, placing the code, prepended with `(in-ns ...)`, in codeblocks in the chat before the evaluation tool call
- Check with user, REPL, and docs when uncertain
+- Work through problems iteratively step by step, evaluating expressions to verify they do what you think they will do
+
+Remember that the human does not see what you evaluate with the tool:
+* If you evaluate a large amount of code: describe in a succinct way what is being evaluated.
+
+Put code you want to show the user in code block with the namespace at the start like so:
+
+```clojure
+(in-ns 'my.namespace)
+(let [test-data {:name "example"}]
+ (process-data test-data))
+```
+
+This enables the user to evaluate the code from the code block.
diff --git a/collections/clojure-interactive-programming.collection.yml b/collections/clojure-interactive-programming.collection.yml
new file mode 100644
index 0000000..48ceb3b
--- /dev/null
+++ b/collections/clojure-interactive-programming.collection.yml
@@ -0,0 +1,14 @@
+id: clojure-interactive-programming
+name: Clojure Interactive Programming
+description: Tools for REPL-first Clojure workflows featuring Clojure instructions, the interactive programming chat mode and supporting guidance.
+tags: [clojure, repl, interactive-programming]
+items:
+ - path: instructions/clojure.instructions.md
+ kind: instruction
+ - path: chatmodes/clojure-interactive-programming.chatmode.md
+ kind: chat-mode
+ - path: prompts/remember-interactive-programming.prompt.md
+ kind: prompt
+display:
+ ordering: manual
+ show_badge: true
diff --git a/collections/clojure-interactive-programming.md b/collections/clojure-interactive-programming.md
new file mode 100644
index 0000000..2f37bd6
--- /dev/null
+++ b/collections/clojure-interactive-programming.md
@@ -0,0 +1,16 @@
+# Clojure Interactive Programming
+
+Tools for REPL-first Clojure workflows featuring Clojure instructions, the interactive programming chat mode and supporting guidance.
+
+**Tags:** clojure, repl, interactive-programming
+
+## Items in this Collection
+
+| Title | Type | Description |
+| ----- | ---- | ----------- |
+| [Clojure Development Instructions](../instructions/clojure.instructions.md)
[](https://aka.ms/awesome-copilot/install/instructions?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fclojure.instructions.md)
[](https://aka.ms/awesome-copilot/install/instructions?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fclojure.instructions.md) | Instruction | Clojure-specific coding patterns, inline def usage, code block templates, and namespace handling for Clojure development. |
+| [Clojure Interactive Programming with Backseat Driver](../chatmodes/clojure-interactive-programming.chatmode.md)
[](https://aka.ms/awesome-copilot/install/chatmode?url=vscode%3Achat-mode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fclojure-interactive-programming.chatmode.md)
[](https://aka.ms/awesome-copilot/install/chatmode?url=vscode-insiders%3Achat-mode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fclojure-interactive-programming.chatmode.md) | Chat Mode | Expert Clojure pair programmer with REPL-first methodology, architectural oversight, and interactive problem-solving. Enforces quality standards, prevents workarounds, and develops solutions incrementally through live REPL evaluation before file modifications. |
+| [Interactive Programming Nudge](../prompts/remember-interactive-programming.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fremember-interactive-programming.prompt.md)
[](https://aka.ms/awesome-copilot/install/prompt?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fremember-interactive-programming.prompt.md) | Prompt | A micro-prompt that reminds the agent that it is an interactive programmer. Works great in Clojure when Copilot has access to the REPL (probably via Backseat Driver). Will work with any system that has a live REPL that the agent can use. Adapt the prompt with any specific reminders in your workflow and/or workspace. |
+
+---
+*This collection includes 3 curated items for clojure interactive programming.*
\ No newline at end of file
diff --git a/instructions/clojure-memory.instructions.md b/instructions/clojure-memory.instructions.md
deleted file mode 100644
index a6dfa64..0000000
--- a/instructions/clojure-memory.instructions.md
+++ /dev/null
@@ -1,84 +0,0 @@
----
-description: 'Things agents tend to forget or get wrong when they are working with Clojure projects.'
-applyTo: '**/*.clj*,**/*.bb'
----
-
-# Clojure Memory
-
-## Docstring placement in function definitions (`defn`)
-
-The docstring goes after the symbol/function name, and before the argument vector.
-
-### ❌ Incorrect:
-```clojure
-(defn my-function
- [arg1 arg2]
- "This function does something."
- ;; function body
- )
-```
-
-### ✅ Correct:
-```clojure
-(defn my-function
- "This function does something."
- [arg1 arg2]
- ;; function body
- )
-```
-
-## Editing Clojure files
-
-Remember to develop solutions in the repl before editing files. However, even as an interactive programmer, now and then you do edit files. And when you do, you use structural editing tools, like `replace_top_level_form`, and `insert_top_level_form`. **Always read the instructions for these tools before using them**. If you are appending to a file, use the built in editing tool.
-
-### Define functions before using them
-
-The Clojure compiler needs functions to be defined before they are used. Prefer placing functions in the correct order over using `declare` (which is sometimes necessary, but most often `declare` is just cheating).
-
-## Creating Clojure files
-
-Use the `create_file` tool to create files with empty content `""`.
-
-#### Clojure Namespace and Filename Convention:
-
-**Important**: In Clojure, namespace names use kebab-case while filenames use snake_case. For example:
-- Namespace: `my.project.multi-word-namespace`
-- Filename: `my/project/multi_word_namespace.clj(s|c)`
-
-Always convert dashes in namespace names to underscores in the corresponding filename.
-
-### Create empty files, then add content
-
-For you to create files and add content safely/predictably, follow this process:
-
-1. **Always create empty files first** - Use `create_file` with empty content `""`
-2. Read the content of the file created (default content may have been added)
-3. **Use structural editing tools** to edit the file
-
-## Namespace Reloading in the REPL
-
-When working in the REPL after editing files, you need to reload namespaces to ensure your changes are reflected in the REPL.
-
-```clojure
-;; Reload just the specified namespace
-(require 'my.namespace :reload)
-```
-
-## When the bracket balance is off
-
-When you have a situation where e.g. the problem tool or Clojure compiler complains about missing brackets or anything suggesting the bracket balance is off:
-* Instead of going ahead trying to fix it, **use the tool for requesting human input to ask for guidance/help.**
-
-## Reading from stdin
-
-Reading from stdin (e.g. `(read-line)`) will prompt the user with a VS Code input box. Be aware of this when evaluating code that may read from stdin.
-
-### With Babashka, reading from stdin blocks the repl
-
-Babashka's nrepl server does not yet support the stdin protocol. Avoid evaluating code that reads from stdin with the Babashka repl.
-
-**If REPL hangs**: Ask user to restart REPL.
-
-## Happy Interactive Programming
-
-Remember to prefer the REPL in your work. Keep in mind that the user does not see what you evaluate. Nor the results. Communicate with the user in the chat about what you evaluate and what you get back.
diff --git a/instructions/clojure.instructions.md b/instructions/clojure.instructions.md
new file mode 100644
index 0000000..e3de5c5
--- /dev/null
+++ b/instructions/clojure.instructions.md
@@ -0,0 +1,318 @@
+---
+description: 'Clojure-specific coding patterns, inline def usage, code block templates, and namespace handling for Clojure development.'
+applyTo: '**/*.{clj,cljs,cljc,bb,edn.mdx?}'
+---
+
+# Clojure Development Instructions
+
+## Code Evaluation Tool usage
+
+### JSON Strings in REPL Tool Calls
+Do not over-escape JSON arguments when invoking REPL tools.
+
+```json
+{
+ "namespace": "",
+ "replSessionKey": "cljs",
+ "code": "(def foo \"something something\")"
+}
+```
+
+## Docstrings in `defn`
+Docstrings belong immediately after the function name and before the argument vector.
+
+```clojure
+(defn my-function
+ "This function does something."
+ [arg1 arg2]
+ ;; function body
+ )
+```
+
+- Define functions before they are used—prefer ordering over `declare` except when truly necessary.
+
+## Structural Editing and REPL-First Habit
+- Develop changes in the REPL before touching files.
+- When editing Clojure files, always use structural editing tools such as **Insert Top Level Form**, **Replace Top Level Form**, **Create Clojure File**, and **Append Code**, and always read their instructions first.
+
+### Creating New Files
+- Use the **Create Clojure File** tool, with initial content
+- Follow Clojure naming rules: namespaces in kebab-case, file paths in matching snake_case (e.g., `my.project.ns` → `my/project/ns.clj`).
+
+### Reloading Namespaces
+After editing files, reload the edited namespace in the REPL so updated definitions are active.
+
+```clojure
+(require 'my.namespace :reload)
+```
+
+### Keeping Brackets Balanced
+If tools or the compiler signal bracket imbalance, stop and ask for help rather than guessing—use the human-input tool.
+
+## Interactive Programming with REPL
+
+When evaluating code during development, always show the complete code being evaluated in a code block before using evaluation tools. The code block should start with the appropriate `(in-ns ...)` form and contain the exact code being evaluated, so the human can run the same code in their REPL.
+
+Example:
+```clojure
+(in-ns 'my.namespace)
+(let [test-data {:name "example"}]
+ (process-data test-data))
+```
+
+This applies to all REPL-driven development, whether using Calva, Joyride, or other Clojure evaluation tools.
+
+## Code Indentation Before Evaluation
+Consistent indentation is crucial to help the bracket balancer.
+
+```clojure
+;; ❌
+(defn my-function [x]
+(+ x 2))
+
+;; ✅
+(defn my-function [x]
+ (+ x 2))
+```
+
+## Indentation preferences
+
+Keep the condition and body on separate lines:
+
+```clojure
+(when limit
+ (println "Limit set to:" limit))
+```
+
+Keep the `and` and `or` arguments on separate lines:
+
+```clojure
+(if (and condition-a
+ condition-b)
+ this
+ that)
+```
+
+## Inline Def Pattern
+
+Prefer inline def debugging over println/console.log.
+
+### Inline `def` for Debugging
+- Inline `def` bindings keep intermediate state inspectable during REPL work.
+- Leave inline bindings in place when they continue to aid exploration.
+
+```clojure
+(defn process-instructions [instructions]
+ (def instructions instructions)
+ (let [grouped (group-by :status instructions)]
+ grouped))
+```
+
+- Real-time inspection stays available.
+- Debugging cycles stay fast.
+- Iterative development remains smooth.
+
+You can also use "inline def" when showing the user code in the chat, to make it easy for the user to experiment with the code from within the code blocks. The user can use Calva to evaluate the code directly in your code blocks. (But the user can't edit the code there.)
+
+## Return values > print side effects
+
+Prefer using the repl and return values from your evaluations, over printing things to stdout.
+
+## Reading from `stdin`
+- When Clojure code uses `(read-line)`, it will prompt the user through VS Code.
+- Avoid stdin reads in Babashka's nREPL because it lacks stdin support.
+- Ask the user to restart the REPL if it blocks.
+
+## Data Structure Preferences
+
+We try to keep our data structures as flat as possible, leaning heavily on namespaced keywords and optimizing for easy destructuring. Generally in the app we use namespaced keywords, and most often "synthetic" namespaces.
+
+Destructure keys directly in the parameter list.
+
+```clojure
+(defn handle-user-request
+ [{:user/keys [id name email]
+ :request/keys [method path headers]
+ :config/keys [timeout debug?]}]
+ (when debug?
+ (println "Processing" method path "for" name)))
+```
+
+Among many benefits this keeps function signatures transparent.
+
+### Avoid Shadowing Built-ins
+Rename incoming keys when necessary to avoid hiding core functions.
+
+```clojure
+(defn create-item
+ [{:prompt-sync.file/keys [path uri]
+ file-name :prompt-sync.file/name
+ file-type :prompt-sync.file/type}]
+ #js {:label file-name
+ :type file-type})
+```
+
+Common symbols to keep free:
+- `class`
+- `count`
+- `empty?`
+- `filter`
+- `first`
+- `get`
+- `key`
+- `keyword`
+- `map`
+- `merge`
+- `name`
+- `reduce`
+- `rest`
+- `set`
+- `str`
+- `symbol`
+- `type`
+- `update`
+
+## Avoid Unnecessary Wrapper Functions
+Do not wrap core functions unless a name genuinely clarifies composition.
+
+```clojure
+(remove (set exclusions) items) ; a wrapper function would not make this clearer
+```
+
+## Rich Comment Forms (RCF) for Documentation
+
+Rich Comment Forms `(comment ...)` serve a different purpose than direct REPL evaluation. Use RCFs in file editing to **document usage patterns and examples** for functions you've already validated in the REPL.
+
+### When to Use RCFs
+- **After REPL validation** - Document working examples in files
+- **Usage documentation** - Show how functions are intended to be used
+- **Exploration preservation** - Keep useful REPL discoveries in the codebase
+- **Example scenarios** - Demonstrate edge cases and typical usage
+
+### Docstrings in `defn`
+Docstrings belong immediately after the function name and before the argument vector.
+
+```clojure
+(defn my-function
+ "This function does something."
+ [arg1 arg2]
+ ;; function body
+ )
+```
+
+- Define functions before they are used—prefer ordering over `declare` except when truly necessary.
+
+### RCF Patterns
+
+RCF = Rich Comment Forms.
+
+When files are loaded code in RCFs is not evaluated, making them perfect for documenting example usage, since humans easily can evaluate the code in there at will.
+
+```clojure
+(defn process-user-data
+ "Processes user data with validation"
+ [{:user/keys [name email] :as user-data}]
+ ;; implementation here
+ )
+
+(comment
+ ;; Basic usage
+ (process-user-data {:user/name "John" :user/email "john@example.com"})
+
+ ;; Edge case - missing email
+ (process-user-data {:user/name "Jane"})
+
+ ;; Integration example
+ (->> users
+ (map process-user-data)
+ (filter :valid?))
+
+ :rcf) ; Optional marker for end of comment block
+```
+
+### RCF vs REPL Tool Usage
+```clojure
+;; In chat - show direct REPL evaluation:
+(in-ns 'my.namespace)
+(let [test-data {:user/name "example"}]
+ (process-user-data test-data))
+
+;; In files - document with RCF:
+(comment
+ (process-user-data {:user/name "example"})
+ :rcf)
+```
+
+## Testing
+
+### Run Tests from the REPL
+Reload the target namespace and execute tests from the REPL for immediate feedback.
+
+```clojure
+(require '[my.project.some-test] :reload)
+(clojure.test/run-tests 'my.project.some-test)
+(cljs.test/run-tests 'my.project.some-test)
+```
+
+- Tighter REPL integration.
+- Focused execution.
+- Simpler debugging.
+- Direct access to test data.
+
+Prefer running individual test vars from within the test namespace when investigating failures.
+
+### Use REPL-First TDD Workflow
+Iterate with real data before editing files.
+
+```clojure
+(def sample-text "line 1\nline 2\nline 3\nline 4\nline 5")
+
+(defn format-line-number [n padding marker-len]
+ (let [num-str (str n)
+ total-padding (- padding marker-len)]
+ (str (apply str (repeat (- total-padding (count num-str)) " "))
+ num-str)))
+
+(deftest line-number-formatting
+ (is (= " 5" (editor-util/format-line-number 5 3 0))
+ "Single digit with padding 3, no marker space")
+ (is (= " 42" (editor-util/format-line-number 42 3 0))
+ "Double digit with padding 3, no marker space"))
+```
+
+#### Benefits
+- Verified behaviour before committing changes
+- Incremental development with immediate feedback
+- Tests that capture known-good behaviour
+- Start new work with failing tests to lock in intent
+
+### Test Naming and Messaging
+Keep `deftest` names descriptive (area/thing style) without redundant `-test` suffixes.
+
+### Test Assertion Message Style
+Attach expectation messages directly to `is`, using `testing` blocks only when grouping multiple related assertions.
+
+```clojure
+(deftest line-marker-formatting
+ (is (= "→" (editor-util/format-line-marker true))
+ "Target line gets marker")
+ (is (= "" (editor-util/format-line-marker false))
+ "Non-target gets empty string"))
+
+(deftest context-line-extraction
+ (testing "Centered context extraction"
+ (let [result (editor-util/get-context-lines "line 1\nline 2\nline 3" 2 3)]
+ (is (= 3 (count (str/split-lines result)))
+ "Should have 3 lines")
+ (is (str/includes? result "→")
+ "Should have marker"))))
+```
+
+Guidelines:
+- Keep assertion messages explicit about expectations.
+- Use `testing` for grouping related checks.
+- Maintain kebab-case names like `line-marker-formatting` or `context-line-extraction`.
+
+## Happy Interactive Programming
+
+Remember to prefer the REPL in your work. Keep in mind that the user does not see what you evaluate. Nor the results. Communicate with the user in the chat about what you evaluate and what you get back.
diff --git a/instructions/go.instructions.md b/instructions/go.instructions.md
index ce4cdba..a956d62 100644
--- a/instructions/go.instructions.md
+++ b/instructions/go.instructions.md
@@ -14,9 +14,15 @@ Follow idiomatic Go practices and community standards when writing Go code. Thes
- Follow the principle of least surprise
- Keep the happy path left-aligned (minimize indentation)
- Return early to reduce nesting
+- Prefer early return over if-else chains; use `if condition { return }` pattern to avoid else blocks
- Make the zero value useful
+- Write self-documenting code with clear, descriptive names
- Document exported types, functions, methods, and packages
- Use Go modules for dependency management
+- Leverage the Go standard library instead of reinventing the wheel (e.g., use `strings.Builder` for string concatenation, `filepath.Join` for path construction)
+- Prefer standard library solutions over custom implementations when functionality exists
+- Write comments in English by default; translate only upon user request
+- Avoid using emoji in code and comments
## Naming Conventions
@@ -28,6 +34,21 @@ Follow idiomatic Go practices and community standards when writing Go code. Thes
- Avoid generic names like `util`, `common`, or `base`
- Package names should be singular, not plural
+#### Package Declaration Rules (CRITICAL):
+- **NEVER duplicate `package` declarations** - each Go file must have exactly ONE `package` line
+- When editing an existing `.go` file:
+ - **PRESERVE** the existing `package` declaration - do not add another one
+ - If you need to replace the entire file content, start with the existing package name
+- When creating a new `.go` file:
+ - **BEFORE writing any code**, check what package name other `.go` files in the same directory use
+ - Use the SAME package name as existing files in that directory
+ - If it's a new directory, use the directory name as the package name
+ - Write **exactly one** `package ` line at the very top of the file
+- When using file creation or replacement tools:
+ - **ALWAYS verify** the target file doesn't already have a `package` declaration before adding one
+ - If replacing file content, include only ONE `package` declaration in the new content
+ - **NEVER** create files with multiple `package` lines or duplicate declarations
+
### Variables and Functions
- Use mixedCaps or MixedCaps (camelCase) rather than underscores
@@ -61,12 +82,16 @@ Follow idiomatic Go practices and community standards when writing Go code. Thes
### Comments
-- Write comments in complete sentences
+- Strive for self-documenting code; prefer clear variable names, function names, and code structure over comments
+- Write comments only when necessary to explain complex logic, business rules, or non-obvious behavior
+- Write comments in complete sentences in English by default
+- Translate comments to other languages only upon specific user request
- Start sentences with the name of the thing being described
- Package comments should start with "Package [name]"
- Use line comments (`//`) for most comments
- Use block comments (`/* */`) sparingly, mainly for package documentation
- Document why, not what, unless the what is complex
+- Avoid emoji in comments and code
### Error Handling
@@ -105,11 +130,14 @@ Follow idiomatic Go practices and community standards when writing Go code. Thes
- Use struct tags for JSON, XML, database mappings
- Prefer explicit type conversions
- Use type assertions carefully and check the second return value
+- Prefer generics over unconstrained types; when an unconstrained type is truly needed, use the predeclared alias `any` instead of `interface{}` (Go 1.18+)
### Pointers vs Values
-- Use pointers for large structs or when you need to modify the receiver
-- Use values for small structs and when immutability is desired
+- Use pointer receivers for large structs or when you need to modify the receiver
+- Use value receivers for small structs and when immutability is desired
+- Use pointer parameters when you need to modify the argument or for large structs
+- Use value parameters for small structs and when you want to prevent modification
- Be consistent within a type's method set
- Consider the zero value when choosing pointer vs value receivers
@@ -125,7 +153,8 @@ Follow idiomatic Go practices and community standards when writing Go code. Thes
### Goroutines
-- Don't create goroutines in libraries; let the caller control concurrency
+- Be cautious about creating goroutines in libraries; prefer letting the caller control concurrency
+- If you must create goroutines in libraries, provide clear documentation and cleanup mechanisms
- Always know how a goroutine will exit
- Use `sync.WaitGroup` or channels to wait for goroutines
- Avoid goroutine leaks by ensuring cleanup
@@ -143,8 +172,17 @@ Follow idiomatic Go practices and community standards when writing Go code. Thes
- Use `sync.Mutex` for protecting shared state
- Keep critical sections small
- Use `sync.RWMutex` when you have many readers
-- Prefer channels over mutexes when possible
+- Choose between channels and mutexes based on the use case: use channels for communication, mutexes for protecting state
- Use `sync.Once` for one-time initialization
+- WaitGroup usage by Go version:
+ - If `go >= 1.25` in `go.mod`, use the new `WaitGroup.Go` method ([documentation](https://pkg.go.dev/sync#WaitGroup)):
+ ```go
+ var wg sync.WaitGroup
+ wg.Go(task1)
+ wg.Go(task2)
+ wg.Wait()
+ ```
+ - If `go < 1.25`, use the classic `Add`/`Done` pattern
## Error Handling Patterns
@@ -172,6 +210,9 @@ Follow idiomatic Go practices and community standards when writing Go code. Thes
- Use middleware for cross-cutting concerns
- Set appropriate status codes and headers
- Handle errors gracefully and return appropriate error responses
+- Router usage by Go version:
+ - If `go >= 1.22`, prefer the enhanced `net/http` `ServeMux` with pattern-based routing and method matching
+ - If `go < 1.22`, use the classic `ServeMux` and handle methods/paths manually (or use a third-party router when justified)
### JSON APIs
@@ -181,6 +222,15 @@ Follow idiomatic Go practices and community standards when writing Go code. Thes
- Consider using `json.RawMessage` for delayed parsing
- Handle JSON errors appropriately
+### HTTP Clients
+
+- Keep the client struct focused on configuration and dependencies only (e.g., base URL, `*http.Client`, auth, default headers). It must not store per-request state
+- Do not store or cache `*http.Request` inside the client struct, and do not persist request-specific state across calls; instead, construct a fresh request per method invocation
+- Methods should accept `context.Context` and input parameters, assemble the `*http.Request` locally (or via a short-lived builder/helper created per call), then call `c.httpClient.Do(req)`
+- If request-building logic is reused, factor it into unexported helper functions or a per-call builder type; never keep `http.Request` (URL params, body, headers) as fields on the long-lived client
+- Ensure the underlying `*http.Client` is configured (timeouts, transport) and is safe for concurrent use; avoid mutating `Transport` after first use
+- Always set headers on the request instance you’re sending, and close response bodies (`defer resp.Body.Close()`), handling errors appropriately
+
## Performance Optimization
### Memory Management
@@ -191,6 +241,33 @@ Follow idiomatic Go practices and community standards when writing Go code. Thes
- Preallocate slices when size is known
- Avoid unnecessary string conversions
+### I/O: Readers and Buffers
+
+- Most `io.Reader` streams are consumable once; reading advances state. Do not assume a reader can be re-read without special handling
+- If you must read data multiple times, buffer it once and recreate readers on demand:
+ - Use `io.ReadAll` (or a limited read) to obtain `[]byte`, then create fresh readers via `bytes.NewReader(buf)` or `bytes.NewBuffer(buf)` for each reuse
+ - For strings, use `strings.NewReader(s)`; you can `Seek(0, io.SeekStart)` on `*bytes.Reader` to rewind
+- For HTTP requests, do not reuse a consumed `req.Body`. Instead:
+ - Keep the original payload as `[]byte` and set `req.Body = io.NopCloser(bytes.NewReader(buf))` before each send
+ - Prefer configuring `req.GetBody` so the transport can recreate the body for redirects/retries: `req.GetBody = func() (io.ReadCloser, error) { return io.NopCloser(bytes.NewReader(buf)), nil }`
+- To duplicate a stream while reading, use `io.TeeReader` (copy to a buffer while passing through) or write to multiple sinks with `io.MultiWriter`
+- Reusing buffered readers: call `(*bufio.Reader).Reset(r)` to attach to a new underlying reader; do not expect it to “rewind” unless the source supports seeking
+- For large payloads, avoid unbounded buffering; consider streaming, `io.LimitReader`, or on-disk temporary storage to control memory
+
+- Use `io.Pipe` to stream without buffering the whole payload:
+ - Write to `*io.PipeWriter` in a separate goroutine while the reader consumes
+ - Always close the writer; use `CloseWithError(err)` on failures
+ - `io.Pipe` is for streaming, not rewinding or making readers reusable
+
+- **Warning:** When using `io.Pipe` (especially with multipart writers), all writes must be performed in strict, sequential order. Do not write concurrently or out of order—multipart boundaries and chunk order must be preserved. Out-of-order or parallel writes can corrupt the stream and result in errors.
+
+- Streaming multipart/form-data with `io.Pipe`:
+ - `pr, pw := io.Pipe()`; `mw := multipart.NewWriter(pw)`; use `pr` as the HTTP request body
+ - Set `Content-Type` to `mw.FormDataContentType()`
+ - In a goroutine: write all parts to `mw` in the correct order; on error `pw.CloseWithError(err)`; on success `mw.Close()` then `pw.Close()`
+ - Do not store request/in-flight form state on a long-lived client; build per call
+ - Streamed bodies are not rewindable; for retries/redirects, buffer small payloads or provide `GetBody`
+
### Profiling
- Use built-in profiling tools (`pprof`)
@@ -214,7 +291,7 @@ Follow idiomatic Go practices and community standards when writing Go code. Thes
- Name tests descriptively using `Test_functionName_scenario`
- Use subtests with `t.Run` for better organization
- Test both success and error cases
-- Use `testify` or similar libraries sparingly
+- Consider using `testify` or similar libraries when they add value, but don't over-complicate simple tests
### Test Helpers
@@ -238,18 +315,21 @@ Follow idiomatic Go practices and community standards when writing Go code. Thes
- Use standard library crypto packages
- Don't implement your own cryptography
- Use crypto/rand for random number generation
-- Store passwords using bcrypt or similar
+- Store passwords using bcrypt, scrypt, or argon2 (consider golang.org/x/crypto for additional options)
- Use TLS for network communication
## Documentation
### Code Documentation
-- Document all exported symbols
+- Prioritize self-documenting code through clear naming and structure
+- Document all exported symbols with clear, concise explanations
- Start documentation with the symbol name
+- Write documentation in English by default
- Use examples in documentation when helpful
- Keep documentation close to code
- Update documentation when code changes
+- Avoid emoji in documentation and comments
### README and Documentation Files
@@ -265,7 +345,7 @@ Follow idiomatic Go practices and community standards when writing Go code. Thes
- `go fmt`: Format code
- `go vet`: Find suspicious constructs
-- `golint` or `golangci-lint`: Additional linting
+- `golangci-lint`: Additional linting (golint is deprecated)
- `go test`: Run tests
- `go mod`: Manage dependencies
- `go generate`: Code generation
@@ -288,5 +368,6 @@ Follow idiomatic Go practices and community standards when writing Go code. Thes
- Not understanding nil interfaces vs nil pointers
- Forgetting to close resources (files, connections)
- Using global variables unnecessarily
-- Over-using empty interfaces (`interface{}`)
+- Over-using unconstrained types (e.g., `any`); prefer specific types or generic type parameters with constraints. If an unconstrained type is required, use `any` rather than `interface{}`
- Not considering the zero value of types
+- **Creating duplicate `package` declarations** - this is a compile error; always check existing files before adding package declarations
diff --git a/prompts/clojure-add-to-memory.prompt.md b/prompts/clojure-add-to-memory.prompt.md
deleted file mode 100644
index feedee5..0000000
--- a/prompts/clojure-add-to-memory.prompt.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-description: 'Have the agent update the clojure-memory.instructions.md file with mistakes it just made, or lessons learned. Also consider installing the default clojure-memory.instructions.md'
-# mode: intentionally left out, because currently VS Code resets custom chatmodes if the prompt specifies a mode
-title: 'Clojure Memory Updater'
----
-
-# Clojure Memory Updater
-
-You are an expert Clojurian and prompt engineer, keeper of the Clojure Memory Instructions.
-
-## Your Mission
-
-Transform mistakes and lessons into succinct, actionable instructions that will help future AI assistants avoid the same pitfalls.
-
-## Process
-
-1. **Read** the current **User Data Folder** `clojure-memory.instructions.md` to understand existing guidance
-2. **Analyze** what specific mistake was made or lesson learned
-3. **Categorize** the update:
- - New gotcha/common mistake
- - Enhancement to existing section
- - New best practice
- - Process improvement
-4. **Write** clear, actionable instructions using:
- - ❌ Incorrect examples (what NOT to do)
- - ✅ Correct examples (what TO do)
- - Brief explanations of WHY when helpful
-5. **Organize** logically within existing structure or create new sections
-
-## Quality Guidelines
-
-- Be specific and concrete (avoid vague advice)
-- Include code examples when relevant
-- Focus on common, recurring issues
-- Keep instructions scannable and actionable
-- Maintain the functional, data-oriented Clojure mindset
-
-## Update Triggers
-
-Common scenarios that warrant memory updates:
-- Bracket balancing mistakes
-- Namespace/filename convention errors
-- REPL evaluation patterns that don't work
-- File editing approaches that cause problems
-- Clojure idioms that were misused
diff --git a/prompts/csharp-docs.prompt.md b/prompts/csharp-docs.prompt.md
index 2ede7b3..2308fa7 100644
--- a/prompts/csharp-docs.prompt.md
+++ b/prompts/csharp-docs.prompt.md
@@ -8,19 +8,56 @@ description: 'Ensure that C# types are documented with XML comments and follow b
- Public members should be documented with XML comments.
- It is encouraged to document internal members as well, especially if they are complex or not self-explanatory.
-- Use `` for method descriptions. This should be a brief overview of what the method does.
-- Use `` for method parameters.
-- Use `` to reference parameters in documentation.
-- Use `` for method return values.
+
+## Guidance for all APIs
+
+- Use `` to provide a brief, one sentence, description of what the type or member does. Start the summary with a present-tense, third-person verb.
- Use `` for additional information, which can include implementation details, usage notes, or any other relevant context.
-- Use `` for usage examples on how to use the member.
-- Use `` to document exceptions thrown by methods.
- Use `` for language-specific keywords like `null`, `true`, `false`, `int`, `bool`, etc.
+- Use `` for inline code snippets.
+- Use `` for usage examples on how to use the member.
+ - Use `` for code blocks. `` tags should be placed within an `` tag. Add the language of the code example using the `language` attribute, for example, ``.
- Use `` to reference other types or members inline (in a sentence).
- Use `` for standalone (not in a sentence) references to other types or members in the "See also" section of the online docs.
- Use `` to inherit documentation from base classes or interfaces.
- Unless there is major behavior change, in which case you should document the differences.
-- Use `` for type parameters in generic types or methods.
+
+## Methods
+
+- Use `` to describe method parameters.
+ - The description should be a noun phrase that doesn't specify the data type.
+ - Begin with an introductory article.
+ - If the parameter is a flag enum, start the description with "A bitwise combination of the enumeration values that specifies...".
+ - If the parameter is a non-flag enum, start the description with "One of the enumeration values that specifies...".
+ - If the parameter is a Boolean, the wording should be of the form "`` to ...; otherwise, ``.".
+ - If the parameter is an "out" parameter, the wording should be of the form "When this method returns, contains .... This parameter is treated as uninitialized.".
+- Use `` to reference parameter names in documentation.
+- Use `` to describe type parameters in generic types or methods.
- Use `` to reference type parameters in documentation.
-- Use `` for inline code snippets.
-- Use `` for code blocks. `` tags should be placed within an `` tag. Add the language of the code example using the `language` attribute, for example, ``.
+- Use `` to describe what the method returns.
+ - The description should be a noun phrase that doesn't specify the data type.
+ - Begin with an introductory article.
+ - If the return type is Boolean, the wording should be of the form "`` if ...; otherwise, ``.".
+
+## Constructors
+
+- The summary wording should be "Initializes a new instance of the class [or struct].".
+
+## Properties
+
+- The `` should start with:
+ - "Gets or sets..." for a read-write property.
+ - "Gets..." for a read-only property.
+ - "Gets [or sets] a value that indicates whether..." for properties that return a Boolean value.
+- Use `` to describe the value of the property.
+ - The description should be a noun phrase that doesn't specify the data type.
+ - If the property has a default value, add it in a separate sentence, for example, "The default is ``".
+ - If the value type is Boolean, the wording should be of the form "`` if ...; otherwise, ``. The default is ...".
+
+## Exceptions
+
+- Use `` to document exceptions thrown by constructors, properties, indexers, methods, operators, and events.
+- Document all exceptions thrown directly by the member.
+- For exceptions thrown by nested members, document only the exceptions users are most likely to encounter.
+- The description of the exception describes the condition under which it's thrown.
+ - Omit "Thrown if ..." or "If ..." at the beginning of the sentence. Just state the condition directly, for example "An error occurred when accessing a Message Queuing API."
diff --git a/prompts/remember-interactive-programming.prompt.md b/prompts/remember-interactive-programming.prompt.md
index 7c0e60a..fb381e9 100644
--- a/prompts/remember-interactive-programming.prompt.md
+++ b/prompts/remember-interactive-programming.prompt.md
@@ -1,12 +1,13 @@
---
-description: 'Reminds the agent that it is an interactive programmer. Works great in Clojure when Copilot has access to the REPL (probably via Backseat Driver). Will work with any system that has a live REPL that the agent can use. Adapt the prompt with any specific reminders in your workflow and/or workspace.'
+description: 'A micro-prompt that reminds the agent that it is an interactive programmer. Works great in Clojure when Copilot has access to the REPL (probably via Backseat Driver). Will work with any system that has a live REPL that the agent can use. Adapt the prompt with any specific reminders in your workflow and/or workspace.'
title: 'Interactive Programming Nudge'
---
-Remember that you are an interactive programmer with the system itself as your source of truth. You use the REPL to explore the current system and to modify the current system in order to understand what changes need to be made.
+Remember that you are an interactive programmer with the system itself as your source of thruth. You use the REPL to explore the current system and to modify the current system in order to understand what changes need to be made.
Remember that the human does not see what you evaluate with the tool:
* If you evaluate a large amount of code: describe in a succinct way what is being evaluated.
-* If you evaluate a smaller code piece (most cases if you do interactive programming right): prepend the tool use with a code block containing the code being evaluated.
-The user does not see the result of the evaluation either. You can mention the result in a non-verbose way so that the user stays informed without being overwhelmed.
+When editing files you prefer to use the structural editing tools.
+
+Also remember to tend your todo list.