Add library usage and code quality guidelines to copilot instructions

Co-authored-by: SamMorrowDrums <[email protected]>

Author: Copilot

.github/copilot-instructions.md

@@ -11,6 +11,14 @@ This is the **GitHub MCP Server**, a Model Context Protocol (MCP) server that co
 - **Secondary Package:** mcpcurl (testing utility - don't break it, but not the priority)
 - **Framework:** Uses mark3labs/mcp-go for MCP protocol, google/go-github for GitHub API
 - **Size:** ~60MB repository, 70 Go files
+- **Library Usage:** This repository is also used as a library by the remote server. Functions that could be called by other repositories should be exported (capitalized), even if not required internally. Preserve existing export patterns.
+
+**Code Quality Standards:**
+- **Popular Open Source Repository** - High bar for code quality and clarity
+- **Comprehension First** - Code must be clear to a wide audience
+- **Clean Commits** - Atomic, focused changes with clear messages
+- **Structure** - Always maintain or improve, never degrade
+- **Code over Comments** - Prefer self-documenting code; comment only when necessary
 
 ## Critical Build & Validation Steps
 
@@ -166,11 +174,14 @@ All workflows run on push/PR unless noted. Located in `.github/workflows/`:
 ### Code Patterns
 
 - **Keep changes minimal and focused** on the specific issue being addressed
-- Prefer explicit over clever code
+- **Prefer clarity over cleverness** - code must be understandable by a wide audience
+- **Atomic commits** - each commit should be a complete, logical change
+- **Maintain or improve structure** - never degrade code organization
 - Use table-driven tests for behavioral testing
 - Comment sparingly - code should be self-documenting
 - Follow standard Go conventions (Effective Go, Go proverbs)
 - **Test changes thoroughly** before committing
+- Export functions (capitalize) if they could be used by other repos as a library
 
 ## Common Development Workflows
 
@@ -267,14 +278,15 @@ server.json         - MCP server registry metadata
 ## Important Reminders
 
 1. **PRIMARY FOCUS:** The local stdio MCP server (github-mcp-server) - this is what you should work on and test with
-2. **ALWAYS** trust these instructions first - only search if information is incomplete or incorrect
-3. **NEVER** use `script/tag-release` or push tags
-4. **NEVER** skip `script/lint` before committing Go code changes
-5. **ALWAYS** update toolsnaps when changing MCP tool schemas
-6. **ALWAYS** run `script/generate-docs` after modifying tools
-7. For specific test files, use `go test ./path -run TestName` not full suite
-8. E2E tests require PAT token - you likely cannot run them
-9. Toolsnaps are API documentation - treat changes seriously
-10. Build/test/lint are very fast (~1s each) - run frequently
-11. CI failures for docs-check or license-check have simple fixes (run the script)
-12. mcpcurl is secondary - don't break it, but it's not the priority
+2. **REMOTE SERVER:** Ignore remote server instructions when making code changes (unless specifically asked). This repo is used as a library by the remote server, so keep functions exported (capitalized) if they could be called by other repos, even if not needed internally.
+3. **ALWAYS** trust these instructions first - only search if information is incomplete or incorrect
+4. **NEVER** use `script/tag-release` or push tags
+5. **NEVER** skip `script/lint` before committing Go code changes
+6. **ALWAYS** update toolsnaps when changing MCP tool schemas
+7. **ALWAYS** run `script/generate-docs` after modifying tools
+8. For specific test files, use `go test ./path -run TestName` not full suite
+9. E2E tests require PAT token - you likely cannot run them
+10. Toolsnaps are API documentation - treat changes seriously
+11. Build/test/lint are very fast (~1s each) - run frequently
+12. CI failures for docs-check or license-check have simple fixes (run the script)
+13. mcpcurl is secondary - don't break it, but it's not the priority