dotnet-open-source-first-governance
Skill4 starsChanged 10 months agoMITView on GitHub
Use when selecting or reviewing .NET dependencies - enforce open-source-first choices with live license revalidation and review-time gating.
In this repository67 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- agents-onboardingSkill
- agent-workitem-automationSkill
- architecture-testingSkill
- aspire-integration-testingSkill
- automated-standards-enforcementSkill
- best-practice-introductionSkill
- branching-strategy-and-conventionsSkill
- broken-windowSkill
- change-risk-rollbackSkill
- ci-cd-conformanceSkill
- component-boundary-ownershipSkill
- contract-consistency-validationSkill
- csharp-best-practicesSkill
- deployment-provenanceSkill
- documentation-as-codeSkill
- documentation-scaffoldSkill
- dotnet-bespoke-code-minimisationSkill
- dotnet-best-practicesSkill
- dotnet-domain-primitivesSkill
- dotnet-efcore-practicesSkill
- dotnet-healthchecksSkill
- dotnet-logging-serilogSkill
- dotnet-mapping-standardSkill
- dotnet-source-generation-firstSkill
- dotnet-specification-patternSkill
- dotnet-testing-assertionsSkill
- environment-traceabilitySkill
- finishing-a-development-branch-iddSkill
- greenfield-baselineSkill
- impacted-scope-enforcementSkill
- incremental-change-impactSkill
- incremental-deploymentSkill
- innersource-governance-bootstrapSkill
- issue-driven-deliverySkill
- library-extraction-stabilisationSkill
- local-dev-experienceSkill
- markdown-authorSkill
- modern-csharp-coding-standardsSkill
- monorepo-orchestration-setupSkill
- observability-logging-baselineSkill
- pair-programmingSkill
- persona-switchingSkill
- process-skill-routerSkill
- quality-gate-enforcementSkill
- release-tagging-planSkill
- repo-best-practices-bootstrapSkill
- repository-foundation-bootstrapSkill
- requirements-gatheringSkill
- runtime-tooling-validationSkill
- safe-brownfield-refactorSkill
- scoped-colocationSkill
- security-processesSkill
- selective-build-testSkill
- semantic-version-impactSkill
- session-awareSkill
- skills-first-workflowSkill
- static-analysis-securitySkill
- structured-review-workflowSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 10 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 25
Prefer open-source: Default to OSS libraries over proprietary or source-available alternatives
- Distinctive: line 26
Perform live web search: Search for current licensing status (not cached/historical data)
- Distinctive: line 27
Verify authoritative sources: Check project homepage, LICENSE file, release notes, issue tracker
- Distinctive: line 28
Confirm exact version license: Verify licensing for the specific version being adopted
- Distinctive: line 39
Prefer established OSS libraries over bespoke scripts/frameworks.
- Distinctive: line 50
no recent licensing change introduces:
- Distinctive: line 67
Verify licensing for the exact version being adopted.
- Distinctive: line 68
If pinning to an older OSS version, document:
- Distinctive: line 87
Default outcome if missing: reject or defer.
- Distinctive: line 91
When encountering a new library, an upgrade, or a dependency review, the agent must:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill 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
Overview
Enforce open-source-first dependency selection with mandatory live license revalidation at review time. Historical OSS status is insufficient; verify current licensing via web search for every dependency selection, upgrade, or review to catch recent licensing changes.
When to Use
- Selecting a new library or tool dependency
- Upgrading any dependency (minor or major version)
- Performing PR, architecture, security, or dependency reviews
- Evaluating alternatives for an existing proprietary or source-available component
- Auditing existing dependencies for license compliance
Core Workflow
- Prefer open-source: Default to OSS libraries over proprietary or source-available alternatives
- Perform live web search: Search for current licensing status (not cached/historical data)
- Verify authoritative sources: Check project homepage, LICENSE file, release notes, issue tracker
- Confirm exact version license: Verify licensing for the specific version being adopted
- Check transitive dependencies: Spot-check critical transitives for license changes
- Document verification: Record license name, verification source(s), and verification date (UTC)
- Gate on missing verification: Reject or defer proposals without complete license documentation
- Flag ambiguity: Mark dependency unapproved if licensing cannot be verified confidently
Core
Policy (non-negotiable)
- Strongly prefer open-source tooling and libraries.
- Prefer established OSS libraries over bespoke scripts/frameworks.
- OSS status is time-sensitive and must be revalidated.
Load: checklists
Mandatory: live license verification (web search)
For every dependency selection/upgrade/review, perform a live web search to confirm:
- the component is still open source today,
- the current license (and any dual-license terms) is acceptable,
- no recent licensing change introduces:
- source-available restrictions,
- field-of-use or non-commercial limitations,
- delayed-open clauses,
- copyleft obligations conflicting with the intended distribution model.
Historical OSS status is insufficient.
Authoritative sources to check (minimum)
- Project homepage / official docs
- Source repository
LICENSEfile (and recent commits) - Release notes / official announcements
- Issue tracker discussions relating to licensing changes
Version-specific licensing
- Verify licensing for the exact version being adopted.
- If pinning to an older OSS version, document:
- rationale,
- maintenance plan,
- security posture and upgrade strategy.
Transitive dependencies
- Spot-check critical transitive dependencies for license changes (especially build-time tools and generators).
Load: enforcement
Hard gate (required)
A dependency proposal/PR/ADR is incomplete without:
- License name
- Verification source(s)
- Verification date (UTC)
Default outcome if missing: reject or defer.
Agent rule: automatic revalidation trigger
When encountering a new library, an upgrade, or a dependency review, the agent must:
- perform a live web search for current licensing,
- flag ambiguity or recent changes,
- mark the dependency unapproved if licensing cannot be verified confidently.
Red Flags - STOP
These statements indicate license governance bypass:
| Thought | Reality |
| "It was open source last time" | Licenses change; revalidate with every upgrade |
| "The package name sounds open source" | Verify the LICENSE file directly; names mislead |
| "Transitive deps don't matter" | Critical transitives need license checks too |
| "We'll check licensing before release" | Check at PR time; late discovery is costly |
| "Source-available is the same" | Source-available often has restrictions; verify terms |
| "Copyleft is fine for internal tools" | Distribution models matter; understand obligations |
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.