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
- Distinctive: line 24
Run a single test using dotnet (Makefile has no helper):
- Very specific: line 51
License header: every .cs file starts with // Copyright (c) Microsoft Corporation.
≈ “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.
Files
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.GenerateMetadataResponsedescribe-key→Key.GenerateKeyResponsegenerate-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 coverageRun 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-arm64build.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.csprojplus global<Using>entries in the test.csproj(so tests referencePluginConstants,ErrorCodes, model types withoutusingstatements). - Error handling: throw
NotationException(message, ErrorCodes.*)for any expected/validation failure.Program.Maincatches it and emits a JSONErrorResponseto stderr with exit 1. Anything else becomes aGenericError. Do not write to stderr directly — only the serializedErrorResponsebelongs there. - Validation pattern:
Utilities/Validator.csusesbool TryValidateXxx(request, out string errorMessage)with[NotNullWhen(true)]so callers can dereferencerequestafter a successful check. Add new validation as private helpers chained insideValidateXxxRequest. - JSON I/O: requests come from a single line on stdin via
InputProvider.ReadJsonRequest; serialization usesJsonNamingPolicy.CamelCase(set inProgram.Main). New request/response models go underModels/RequestsorModels/Responsesand rely on this camelCase policy — do not add[JsonPropertyName]unless the wire name diverges. - Auth: signing uses
DefaultAzureCredentialfromAzure.Identity.PluginConfig.ExcludeCredentialsis a comma-separated list validated againstCredentialOptions.SupportedTypes; extending supported credentials means updating both that set and theDefaultAzureCredentialOptionsmapping inSignatureRequest.GetAzureCredential. - Crypto: actual signing is delegated to
ISignContextfrom theAzure.Developer.ArtifactSigning.CryptoProviderpackage. Tests mock it viaMocks/MockSignContext.cs; production code constructs anAzSignContextinSignatureRequest.GetAzSignContext(madevirtualspecifically so tests can override it). - Version string:
PluginConstants.ClientVersionStringis"<assemblyName>::<major.minor.build>", computed via reflection. The assembly name is rewritten at publish time, soVersioningTestsvalidates this format end-to-end — be careful changingGetClientVersionStringor theVersionDelimiter. - Tests: xUnit + Moq. Inherit from
TestBasefor canned valid request JSON/objects (ValidKeyRequest,GetDefaultSignatureRequest, etc.). Console-redirection helpers live inPluginUsageTestsfor end-to-endProgram.Maintests. - License header: every
.csfile starts with// Copyright (c) Microsoft Corporation./// Licensed under the MIT License.— keep it on new files.
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
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.

