agentleFS
Microsoft AzureKnown publisherAzure/artifact-signing-notation-plugin/.github/copilot-instructions.md

artifact-signing-notation-plugin

Copilot instructions5 starsChanged 37 days agoMITView on GitHub

This repo builds notation-azure-artifactsigning, a Notation plugin (a single-file native executable) that signs OCI artifacts using Microsoft's Artifact Signing service. Notation invokes the binary as a subprocess, sends a JSON request on stdin, and expects a JSON response on stdout (or a JSON ErrorResponse on stderr with a non-zero exit code). Implements the Notation plugin contract. Three commands are dispatched from Program.ProcessCommand: Capability advertised: SIGNATURE_GENERATOR.RAW. Only RSA-3072 / SHA-384 / RSASSA-PSS-SHA-384 are supported (see Constants/PluginConstants.cs); validators reject anything else. Targets…

  • 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

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

2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run a single test using dotnet (Makefile has no helper):

    line 24
  2. Very specific:

    License header: every .cs file starts with // Copyright (c) Microsoft Corporation.

    line 51

≈ “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

Copilot Instructions

Project overview

This repo builds notation-azure-artifactsigning, a Notation plugin (a single-file native executable) that signs OCI artifacts using Microsoft's Artifact Signing service. Notation invokes the binary as a subprocess, sends a JSON request on stdin, and expects a JSON response on stdout (or a JSON ErrorResponse on stderr with a non-zero exit code).

Implements the Notation plugin contract. Three commands are dispatched from Program.ProcessCommand:

  • get-plugin-metadata → Metadata.GenerateMetadataResponse
  • describe-key → Key.GenerateKeyResponse
  • generate-signature → Sign.GenerateSignatureResponse

Capability advertised: SIGNATURE_GENERATOR.RAW. Only RSA-3072 / SHA-384 / RSASSA-PSS-SHA-384 are supported (see Constants/PluginConstants.cs); validators reject anything else.

Build, test, lint

Targets .NET 10 with central package management (Directory.Packages.props). Add new package versions there, then reference them without a Version attribute in the .csproj.

make build                # dotnet build -c Release, single-file self-contained
make test                 # Microsoft.Testing.Platform with TRX reports + Coverlet coverage

Run a single test using dotnet (Makefile has no helper):

dotnet test --project Azure.Developer.ArtifactSigning.NotationPlugin.UnitTests \
  --filter-method "*PluginUsageTests.MainMethod_OutputsSuccess_ForValidMetadataRequest"

Produce release artifacts (zip/tar.gz with renamed binary) using:

python3 ./scripts/build.py v<version> <runtime>   # runtimes: win-x64, win-arm64, linux-x64, linux-arm64, osx-x64, osx-arm64

build.py rewrites the assembly name to notation-azure-artifactsigning via -p:AssemblyName=... and stamps the version with -p:Version=.... Notation locates the plugin by binary name, so the assembly rename is required for produced artifacts.

CI (.github/workflows/test-build.yml) runs make test + build.py on Linux/macOS/Windows x64 and arm64.

Key conventions

  • Internal-by-default: nearly every type is internal. The test project gets access via <InternalsVisibleTo> in the main .csproj plus global <Using> entries in the test .csproj (so tests reference PluginConstants, ErrorCodes, model types without using statements).
  • Error handling: throw NotationException(message, ErrorCodes.*) for any expected/validation failure. Program.Main catches it and emits a JSON ErrorResponse to stderr with exit 1. Anything else becomes a GenericError. Do not write to stderr directly — only the serialized ErrorResponse belongs there.
  • Validation pattern: Utilities/Validator.cs uses bool TryValidateXxx(request, out string errorMessage) with [NotNullWhen(true)] so callers can dereference request after a successful check. Add new validation as private helpers chained inside ValidateXxxRequest.
  • JSON I/O: requests come from a single line on stdin via InputProvider.ReadJsonRequest; serialization uses JsonNamingPolicy.CamelCase (set in Program.Main). New request/response models go under Models/Requests or Models/Responses and rely on this camelCase policy — do not add [JsonPropertyName] unless the wire name diverges.
  • Auth: signing uses DefaultAzureCredential from Azure.Identity. PluginConfig.ExcludeCredentials is a comma-separated list validated against CredentialOptions.SupportedTypes; extending supported credentials means updating both that set and the DefaultAzureCredentialOptions mapping in SignatureRequest.GetAzureCredential.
  • Crypto: actual signing is delegated to ISignContext from the Azure.Developer.ArtifactSigning.CryptoProvider package. Tests mock it via Mocks/MockSignContext.cs; production code constructs an AzSignContext in SignatureRequest.GetAzSignContext (made virtual specifically so tests can override it).
  • Version string: PluginConstants.ClientVersionString is "<assemblyName>::<major.minor.build>", computed via reflection. The assembly name is rewritten at publish time, so VersioningTests validates this format end-to-end — be careful changing GetClientVersionString or the VersionDelimiter.
  • Tests: xUnit + Moq. Inherit from TestBase for canned valid request JSON/objects (ValidKeyRequest, GetDefaultSignatureRequest, etc.). Console-redirection helpers live in PluginUsageTests for end-to-end Program.Main tests.
  • License header: every .cs file starts with // Copyright (c) Microsoft Corporation. / // Licensed under the MIT License. — keep it on new files.

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.