build-parallelism — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited build-parallelism (Agent Skill) and scored it 45/100 (orange). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 7 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 7 flagged
A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Work this checklist in order — it targets the usual root cause (a serial dependency chain that no number of cores can parallelize):
binlog with dotnet build /bl:{} (PowerShell: dotnet build '-bl:{}') and inspect the node timeline to see whether more than one node ran. Every dotnet CLI command built on the SDK's MSBuild-forwarding path (build, msbuild, test, pack, publish, etc.) enables /maxcpucount (multiple nodes) by default; -m:1 forces a single node. A direct MSBuild.exe invocation is sequential by default, so pass -m explicitly to enable parallel worker nodes there.
node timeline. If total build time ≈ the sum of the projects on one dependency chain, that chain — not CPU count — is the bottleneck.
Core → Api → Web → Tests. A long serialchain stays serial no matter how large -m is, because each project waits on its predecessor.
reference that only needs build order (not the output assembly), or one that could be a PackageReference, forces serialization it doesn't need.
build concurrently, and consider /graph for better scheduling.
/maxcpucount (or -m): number of worker nodes (processes)dotnet CLI command (build, msbuild, test, pack, publish,etc.) passes /maxcpucount by default via the SDK's shared MSBuild-forwarding path; -m:1 overrides it with one node
MSBuild.exe invocation is sequential by default and requires anexplicit -m
-m without a number = use all logical processorsperformancesummary and check Project Performance Summary — shows per-project time; grep for node.*assigned to check scheduling/graph)dotnet build /graph or msbuild /graph<ProjectReference> (no programmatic MSBuild task references)<ProjectReference> only after proving it is unnecessary; a slow butvalid dependency must stay in the graph
<ProjectReference ... SkipGetTargetFrameworkProperties="true"> to avoid extra evaluations<ProjectReference ... ReferenceOutputAssembly="false"> for build-order-only dependenciessolution filters (.slnf) to build subsets of the solution<MSBuild Projects="@(ProjectsToBuild)" BuildInParallel="true" /> in custom targetsBuildInParallel="true", MSBuild task batches projects sequentially/maxcpucount > 1 for this to have effectIMultiThreadableTask can run on multiple threads[MSBuildMultiThreadableTask]Use the binlog MCP server (Microsoft.AITools.BinlogMcp, exposed under the binlog MCP namespace):
Step-by-step:
dotnet msbuild build.binlog -noconlog -fl "-flp:v=diag;logfile=full.log;performancesummary"full.loggrep 'Target Performance Summary' -A 30 full.log → find the bottleneck targets-m in CI (many CI runners have multiple cores)dotnet build /graph works well with structured CI pipelines~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.