agentleFS
Microsoft AzureKnown publisherAzure/dacs/.github/copilot-instructions.md

dacs

Copilot instructions16 starsChanged 3 months agoApache-2.0View on GitHub

DACS (dacs) is a high-performance distributed caching system for Kubernetes. This repository contains storage cache layer components including CacheServer, CacheClient, and StorageInterception libraries. When writing C++ code: - Follow existing naming conventions in the codebase - Use the repository logging macros (e.g., LOG_ERROR, LOG_WARN, LOG_INFO, LOG_DEBUG) - Use fmt for formatting - Use nlohmann/json for JSON serialization - Use Google Test for unit tests - Prefer smart pointers over raw pointers - Use std::expected or error codes for error handling…

  • 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,336 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.

The file

Show its rules and text

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

20 rules. About 0 are common, 7 are distinctive, and 13 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 13

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When writing C++ code:

    line 15
  2. Distinctive:

    Follow existing naming conventions in the codebase

    line 16
  3. Very specific:

    Use the repository logging macros (e.g., LOG_ERROR, LOG_WARN, LOG_INFO, LOG_DEBUG)

    line 17
  4. Very specific:

    Use fmt for formatting

    line 18
  5. Very specific:

    Use nlohmann/json for JSON serialization

    line 19
  6. Distinctive:

    Use Google Test for unit tests

    line 20
  7. Distinctive:

    Prefer smart pointers over raw pointers

    line 21
  8. Very specific:

    Use std::expected or error codes for error handling (no exceptions in hot paths)

    line 22
  9. Distinctive:

    When writing Go code:

    line 30
  10. Very specific:

    Follow standard Go conventions and go fmt

    line 31
  11. Distinctive:

    Use controller-runtime patterns for Kubernetes resources

    line 32
  12. Very specific:

    Use Ginkgo Describe/It blocks for tests

    line 33
  13. Very specific:

    Use set -euo pipefail for error handling

    line 41
  14. Very specific:

    Use FOCUS=<pattern> to run specific tests

    line 149
  15. Very specific:

    Create directory under src/subsystems/storage/

    line 155
  16. Very specific:

    Add CMakeLists.txt with target definitions

    line 156
  17. Very specific:

    Add unit tests in .tests/ subdirectory

    line 158
  18. Distinctive:

    Add RBAC annotations as needed

    line 164
  19. Very specific:

    Update values.yaml for new parameters

    line 168
  20. Very specific:

    Test with helm template before deploying

    line 169

≈ “Common” is an estimate: at least 1 in 5 of the 3,779 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 DACS

Project Context

DACS (dacs) is a high-performance distributed caching system for Kubernetes. This repository contains storage cache layer components including CacheServer, CacheClient, and StorageInterception libraries.

Languages & Standards

C++ (Primary - Native Components)

  • Standard: C++23
  • Compiler: Clang with -Werror (warnings as errors)
  • Build System: CMake 3.19+ with Ninja backend
  • Location: src/subsystems/storage/

When writing C++ code:

  • Follow existing naming conventions in the codebase
  • Use the repository logging macros (e.g., LOG_ERROR, LOG_WARN, LOG_INFO, LOG_DEBUG)
  • Use fmt for formatting
  • Use nlohmann/json for JSON serialization
  • Use Google Test for unit tests
  • Prefer smart pointers over raw pointers
  • Use std::expected or error codes for error handling (no exceptions in hot paths)

Go (Kubernetes Controller & Tests)

  • Version: Go 1.24+
  • Framework: controller-runtime for Kubernetes controllers
  • Testing: Ginkgo/Gomega BDD framework
  • Location: src/subsystems/cache-controller/, test/

When writing Go code:

  • Follow standard Go conventions and go fmt
  • Use controller-runtime patterns for Kubernetes resources
  • Use Ginkgo Describe/It blocks for tests
  • Handle errors explicitly, don't ignore them

Python (Integration Tests)

  • Used for pytest-based integration tests
  • Location: Various test directories

Bash (Build & Deployment Scripts)

  • Use set -euo pipefail for error handling
  • Quote variables properly
  • Location: .pipelines/, deploy/scripts/

Key Dependencies

C++ Libraries

  • Boost: General utilities
  • fmt: Structured logging
  • nlohmann/json: JSON/BSON/CBOR serialization
  • Google Test (gtest): Unit testing
  • Prometheus C++: Metrics exposition
  • Azure Storage Lite: Azure Blob communication
  • protobuf: Protocol buffer serialization
  • xxHash: Fast hashing

Go Libraries

  • controller-runtime: Kubernetes controller SDK
  • client-go: Kubernetes client
  • Ginkgo/Gomega: BDD testing
  • Azure SDK for Go: Azure services

Infrastructure

  • Helm 3: Kubernetes deployments
  • Bicep: Azure infrastructure as code
  • Docker: Container images

Project Structure

src/subsystems/storage/     # C++ storage components
  cache_server/             # Main cache server
  cache_client/             # Client library
  cache_server_scheduler/   # Custom K8s scheduler
  storage_intercept/        # Storage interception
  common/                   # Shared code
  utils/                    # Utilities

src/subsystems/cache-controller/  # Go K8s controller

helm/cache-server/          # Helm deployment chart
deploy/                     # Infrastructure & scripts
test/                       # E2E and performance tests
Docker/                     # Dockerfiles

Build Commands

make build                      # Debug build (containerized)
make build BUILD_TYPE=Release   # Release build
make test                       # All unit tests
make test-native                # C++ tests only
make test-go                    # Go tests only
make images                     # Build Docker images
make deploy                     # Deploy to Kubernetes
make test-e2e                   # Run E2E tests

Code Patterns

C++ Cache Operations

// Use the established patterns for cache operations
#include "CacheClient.h"

// Error handling with status codes
Status status = cache_client->Get(key, &value);
if (!status.ok()) {
    LOG_ERROR("Cache get failed: {}", status.message());
    return status;
}

Go Kubernetes Controller

// Use controller-runtime reconciliation pattern
func (r *CacheReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    log := log.FromContext(ctx)
    
    // Fetch the resource
    var cache cachev1.Cache
    if err := r.Get(ctx, req.NamespacedName, &cache); err != nil {
        return ctrl.Result{}, client.IgnoreNotFound(err)
    }
    
    // Reconciliation logic here
    return ctrl.Result{}, nil
}

Ginkgo Tests

var _ = Describe("CacheServer", func() {
    Context("when deployed", func() {
        It("should become ready", func() {
            Eventually(func() bool {
                return isPodReady(podName)
            }).Should(BeTrue())
        })
    })
})

Testing Guidelines

  • Unit tests should be fast and not require external dependencies
  • E2E tests run against a real Kubernetes cluster
  • Use FOCUS=<pattern> to run specific tests
  • Performance tests use the perf label filter

Common Tasks

Adding a New C++ Component

  1. Create directory under src/subsystems/storage/
  2. Add CMakeLists.txt with target definitions
  3. Register in root CMakeLists.txt with add_subdirectory()
  4. Add unit tests in .tests/ subdirectory

Adding a Kubernetes CRD

  1. Define types in src/subsystems/cache-controller/api/
  2. Generate manifests: make manifests
  3. Implement controller in internal/controller/
  4. Add RBAC annotations as needed

Modifying Helm Charts

  1. Edit templates in helm/cache-server/templates/
  2. Update values.yaml for new parameters
  3. Test with helm template before deploying

Environment Variables

VariableDescription
BUILD_TYPEDebug or Release
BUILD_ARCHamd64 or arm64
USE_CONTAINER1 for containerized build, 0 for native
DOCKER_REGISTRYTarget container registry
BUILD_NUMBERImage tag for builds

Download now (ZIP)

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.