agentleFS
voxslopulivoxslopuli/opilot/.github/copilot-instructions.md

opilot

Copilot instructions94 starsChanged 5 months agoMITView on GitHub

Welcome! This document guides you through the recommended workflows, conventions, and tooling when working on the Opilot VS Code extension project. Follow these instructions strictly to ensure consistency, quality, and smooth collaboration. You are working on the Opilot extension, which integrates Ollama models into GitHub Copilot Chat inside VS Code. This project uses Ultracite, a zero-config preset built on Biome that enforces strict code quality standards through automated formatting and linting. The project has migrated from oxlint/oxfmt to Biome via…

We split this copilot-instructions.md into the rules it gives an agent

48 rules. About 1 is common, 26 are distinctive, and 21 are very specific to this project.

  • ≈1

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈26

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 21

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Start Ollama app or run ollama serve

    line 44
  2. Distinctive:

    Write code that is accessible, performant, type-safe, and maintainable.

    line 65
  3. Distinctive:

    Use explicit types for function parameters and return values when they enhance clarity

    line 69
  4. Very specific:

    Prefer unknown over any when the type is genuinely unknown

    line 70
  5. Very specific:

    Use const assertions (as const) for immutable values and literal types

    line 71
  6. Distinctive:

    Use meaningful variable names instead of magic numbers - extract constants with descriptive names

    line 73
  7. Distinctive:

    Use arrow functions for callbacks and short functions

    line 77
  8. Very specific:

    Prefer for...of loops over .forEach() and indexed for loops

    line 78
  9. Very specific:

    Use optional chaining (?.) and nullish coalescing (??) for safer property access

    line 79
  10. Distinctive:

    Prefer template literals over string concatenation

    line 80
  11. Distinctive:

    Use destructuring for object and array assignments

    line 81
  12. Very specific:

    Use const by default, let only when reassignment is needed, never var

    line 82
  13. Very specific:

    Always await promises in async functions - don't forget to use the return value

    line 86
  14. Very specific:

    Use async/await syntax instead of promise chains for better readability

    line 87
  15. Distinctive:

    Don't use async functions as Promise executors

    line 89
  16. Distinctive:

    Use function components over class components

    line 93
  17. Distinctive:

    Call hooks at the top level only, never conditionally

    line 94
  18. Very specific:

    Use the key prop for elements in iterables (prefer unique IDs over array indices)

    line 96
  19. Distinctive:

    Don't define components inside other components

    line 98
  20. Distinctive:

    Use semantic HTML and ARIA attributes for accessibility:

    line 99
  21. Distinctive:

    Use proper heading hierarchy

    line 101
  22. Distinctive:

    Add labels for form inputs

    line 102
  23. Very specific:

    Use semantic elements (<button>, <nav>, etc.) instead of divs with roles

    line 104
  24. Very specific:

    Remove console.log, debugger, and alert statements from production code

    line 108
  25. Very specific:

    Use try-catch blocks meaningfully - don't catch errors just to rethrow them

    line 110
  26. Common:

    Prefer early returns over nested conditionals for error cases

    line 111
  27. Distinctive:

    Keep functions focused and under reasonable cognitive complexity limits

    line 115
  28. Distinctive:

    Use early returns to reduce nesting

    line 117
  29. Distinctive:

    Prefer simple conditionals over nested ternary operators

    line 118
  30. Very specific:

    Add rel="noopener" when using target="_blank" on links

    line 123
  31. Very specific:

    Avoid dangerouslySetInnerHTML unless absolutely necessary

    line 124
  32. Very specific:

    Don't use eval() or assign directly to document.cookie

    line 125
  33. Distinctive:

    Avoid spread syntax in accumulators within loops

    line 130
  34. Distinctive:

    Use top-level regex literals instead of creating them in loops

    line 131
  35. Distinctive:

    Prefer specific imports over namespace imports

    line 132
  36. Distinctive:

    Avoid barrel files (index files that re-export everything)

    line 133
  37. Very specific:

    Use proper image components (e.g., Next.js <Image>) over <img> tags

    line 134
  38. Very specific:

    Write assertions inside it() or test() blocks

    line 138
  39. Distinctive:

    Avoid done callbacks in async tests - use async/await instead

    line 139
  40. Very specific:

    Don't use .only or .skip in committed code

    line 140
  41. Very specific:

    Keep test suites reasonably flat - avoid excessive describe nesting

    line 141
  42. Distinctive:

    Meaningful naming: - Use descriptive names for functions, variables, and types

    line 148
  43. Distinctive:

    Documentation: - Add comments for complex logic, but prefer self-documenting code

    line 152
  44. Very specific:

    Use the provided Taskfile.yml to run common commands.

    line 158
  45. Distinctive:

    Use VS Code settings to configure Ollama host, models, and completions.

    line 209
  46. Distinctive:

    Use the Ollama sidebar for model lifecycle management (pull, run, stop, delete).

    line 211
  47. Very specific:

    Use the command palette commands like Ollama: Build Modelfile to build custom models.

    line 213
  48. Distinctive:

    Use the provided test suites:

    line 221

≈ “Common” is an estimate: at least 1 in 5 of the 3,669 Copilot instructions files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
copilot-instructions.md

GitHub Copilot Instructions for Agent: Visual Studio Code Extension Integrating Ollama into GitHub Copilot Chat

Welcome! This document guides you through the recommended workflows, conventions, and tooling when working on the Opilot VS Code extension project. Follow these instructions strictly to ensure consistency, quality, and smooth collaboration.


Before Starting Work

  • Create or switch to the correct branch before editing code.
  • Branch name format: [type]/[short-title] (e.g., feat/add-ollama-integration).

Project Overview

You are working on the Opilot extension, which integrates Ollama models into GitHub Copilot Chat inside VS Code.

Key Features to Keep in Mind

  • Local and cloud Ollama model usage inside Copilot Chat.
  • Custom Ollama sidebar for model management.
  • @ollama chat participant for dedicated conversations.
  • Inline code completions using local models.
  • Modelfile creation, editing, and building with syntax support.
  • Streaming responses and vision model support.
  • Local execution for privacy.
  • Configuration via VS Code settings.

Development Environment Setup

  • Prerequisites:

    • Node.js 20+
    • pnpm (version pinned in package.json)
    • VS Code 1.109.0 or higher
    • GitHub Copilot Chat extension installed
    • Ollama installed locally or remote access configured
  • Installing Ollama:

    • Download from https://ollama.ai/download
    • Start Ollama app or run ollama serve
    • Login to Ollama Cloud if using cloud models (ollama login)
  • Extension Installation:

    • Install from VS Code Marketplace or .vsix file

Code Quality Standards

This project uses Ultracite, a zero-config preset built on Biome that enforces strict code quality standards through automated formatting and linting. The project has migrated from oxlint/oxfmt to Biome via Ultracite, so check-formatting and format tasks are no longer needed — ultracite check and ultracite fix cover both linting and formatting in a single command.

Quick Reference

  • Lint and format code: pnpm dlx ultracite fix
  • Check for issues: pnpm dlx ultracite check
  • Diagnose setup: pnpm dlx ultracite doctor

Core Principles

Write code that is accessible, performant, type-safe, and maintainable. Focus on clarity and explicit intent over brevity.

Type Safety & Explicitness

  • Use explicit types for function parameters and return values when they enhance clarity
  • Prefer unknown over any when the type is genuinely unknown
  • Use const assertions (as const) for immutable values and literal types
  • Leverage TypeScript's type narrowing instead of type assertions
  • Use meaningful variable names instead of magic numbers - extract constants with descriptive names

Modern JavaScript/TypeScript

  • Use arrow functions for callbacks and short functions
  • Prefer for...of loops over .forEach() and indexed for loops
  • Use optional chaining (?.) and nullish coalescing (??) for safer property access
  • Prefer template literals over string concatenation
  • Use destructuring for object and array assignments
  • Use const by default, let only when reassignment is needed, never var

Async & Promises

  • Always await promises in async functions - don't forget to use the return value
  • Use async/await syntax instead of promise chains for better readability
  • Handle errors appropriately in async code with try-catch blocks
  • Don't use async functions as Promise executors

React & JSX

  • Use function components over class components
  • Call hooks at the top level only, never conditionally
  • Specify all dependencies in hook dependency arrays correctly
  • Use the key prop for elements in iterables (prefer unique IDs over array indices)
  • Nest children between opening and closing tags instead of passing as props
  • Don't define components inside other components
  • Use semantic HTML and ARIA attributes for accessibility:
    • Provide meaningful alt text for images
    • Use proper heading hierarchy
    • Add labels for form inputs
    • Include keyboard event handlers alongside mouse events
    • Use semantic elements (<button>, <nav>, etc.) instead of divs with roles

Error Handling & Debugging

  • Remove console.log, debugger, and alert statements from production code
  • Throw Error objects with descriptive messages, not strings or other values
  • Use try-catch blocks meaningfully - don't catch errors just to rethrow them
  • Prefer early returns over nested conditionals for error cases

Code Organization

  • Keep functions focused and under reasonable cognitive complexity limits
  • Extract complex conditions into well-named boolean variables
  • Use early returns to reduce nesting
  • Prefer simple conditionals over nested ternary operators
  • Group related code together and separate concerns

Security

  • Add rel="noopener" when using target="_blank" on links
  • Avoid dangerouslySetInnerHTML unless absolutely necessary
  • Don't use eval() or assign directly to document.cookie
  • Validate and sanitize user input

Performance

  • Avoid spread syntax in accumulators within loops
  • Use top-level regex literals instead of creating them in loops
  • Prefer specific imports over namespace imports
  • Avoid barrel files (index files that re-export everything)
  • Use proper image components (e.g., Next.js <Image>) over <img> tags

Testing

  • Write assertions inside it() or test() blocks
  • Avoid done callbacks in async tests - use async/await instead
  • Don't use .only or .skip in committed code
  • Keep test suites reasonably flat - avoid excessive describe nesting

When Biome Can't Help

Biome's linter will catch most issues automatically. Focus your attention on:

  1. Business logic correctness - Biome can't validate your algorithms
  2. Meaningful naming - Use descriptive names for functions, variables, and types
  3. Architecture decisions - Component structure, data flow, and API design
  4. Edge cases - Handle boundary conditions and error states
  5. User experience - Accessibility, performance, and usability considerations
  6. Documentation - Add comments for complex logic, but prefer self-documenting code

Task Execution Using Taskfile

Use the provided Taskfile.yml to run common commands. Run tasks with:

task <taskname>

Common tasks

Task NameDescriptionUsage Example
check-typesType checkingtask check-types
lintRun linter and formatting checktask lint
lint-fixAuto-fix lint and formatting issuestask lint-fix
compileCompile the extensiontask compile
unit-testsRun unit teststask unit-tests
unit-test-coverageUnit tests with coveragetask unit-test-coverage
extension-testsRun VS Code extension teststask extension-tests
integration-testsRun integration tests (pulls models first)task integration-tests
precommitRun pre-commit checkstask precommit
releaseRelease the extensiontask release
watchWatch source and recompiletask watch

Code Contribution Workflow

  1. Create or switch to the correct branch.
  2. Run pre-commit tasks before committing:

    task precommit
  3. Test your changes thoroughly:
    • Unit tests: task unit-tests
    • Extension tests: task extension-tests
    • Integration tests: task integration-tests
  4. Build the extension before release or PR:

    task compile
  5. Push your branch and create a pull request.

Extension-Specific Notes

  • The extension auto-detects Ollama at http://localhost:11434 by default.
  • Use VS Code settings to configure Ollama host, models, and completions.
  • For inline code completions, configure ollama.completionModel and toggle ollama.enableInlineCompletions.
  • Use the Ollama sidebar for model lifecycle management (pull, run, stop, delete).
  • Manage modelfiles with the dedicated Modelfile Manager sidebar.
  • Use the command palette commands like Ollama: Build Modelfile to build custom models.
  • Leverage streaming support for real-time response in chat.

Debugging and Testing

  • Launch the extension in VS Code Extension Development Host with F5.
  • Use the provided test suites:

    • Unit tests with Vitest
    • Extension integration tests
    • Integration tests with pulled models
  • Coverage target: 85% or higher.

Resources


Summary

  • Create or switch to a branch before coding.
  • Run tasks via the Taskfile for consistency.
  • Use Ultracite (Biome) for linting and formatting — ultracite check and ultracite fix handle both.
  • Test, lint, and build before pushing changes.
  • Follow branch naming conventions.
  • Use VS Code settings and extension UI for Ollama integration features.

Happy coding! 🚀

Download now (ZIP)

  • Other versions1 project uses a version of this.

    Word for word · 1

    1. selfagency/opilot★ 90100% same

    Edited · 0

    None found.

    Wrote their own version · 0

    None found.

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Where files are headingNew Copilot instructions files have more rules about branches and pull requests, and fewer about code style.

    Of the Copilot instructions files we read, the 2,297 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.

  • In this repositoryOne other file it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.