custom-framework-arch

Define a multi-library .NET framework repository layout with package boundaries.

3|Updated Mar 18, 2024
One-click install
npx skills add https://github.com/deveel/deveel.events --skill custom-framework-arch
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: custom-framework-arch
Source: https://github.com/deveel/deveel.events/tree/main/.agents/skills/custom-framework-arch
Command: npx skills add https://github.com/deveel/deveel.events --skill custom-framework-arch

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill helps teams design and organize a multi-library .NET framework repository with clear package boundaries, consistent layout, and public distribution readiness.

Core Features & Use Cases

  • Package taxonomy and boundaries: split into focused packages such as Abstractions (optional) and a main Core or Framework package, with feature modules to follow.
  • Standardized repository layout: adopt a consistent src/, test/, samples/, and docs/ structure with one project per package and clear directory ownership.
  • API layering and packaging rules: enforce stable public contracts, inward dependencies, and dedicated extensions to support clean consumption.
  • Centralized build and packaging configuration: consolidate settings in Directory.Build.props and Directory.Packages.props, and include repository metadata and symbol publishing.
  • Governance and documentation: establish quality gates, changelogs, migration notes, and post-change documentation routines.
  • Real-world usage: scaffold a multi-library solution for a new framework and prepare it for NuGet publishing with versioning and SourceLink.

Quick Start

Define the target framework name, choose main package naming, and scaffold a multi-library solution layout with consistent package boundaries and packaging rules.

Frequently Asked Questions about custom-framework-arch

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure a multi-library .NET framework for NuGet distribution?

Structure a multi-library .NET framework by splitting packages into Abstractions and Core, adopting a consistent src/ and test/ layout, and enforcing API layering with centralized build configuration for NuGet distribution readiness.

What is the best way to organize package boundaries in a large .NET solution?

Organize package boundaries in a large .NET solution by defining a taxonomy of focused packages, maintaining one project per package with clear directory ownership, and enforcing inward dependencies to ensure stable public contracts.

How do I centralize build configuration for a .NET multi-library repository?

Centralize build configuration for a .NET multi-library repository by consolidating settings in Directory.Build.props and Directory.Packages.props, including repository metadata, symbol publishing, and SourceLink for consistent automated builds.

Does this .NET framework architecture approach support automated governance checks in CI?

This .NET framework architecture approach supports automated governance checks in CI by establishing quality gates, enforcing packaging rules, and including post-change documentation routines such as changelogs and migration notes.

When do I need to split Abstractions and Core into separate NuGet packages?

Split Abstractions and Core into separate NuGet packages when building a multi-library framework intended for public distribution, ensuring stable public contracts, dedicated extensions, and clean consumption for downstream applications.

Why use Directory.Packages.props in a multi-library .NET framework?

Use Directory.Packages.props in a multi-library .NET framework to centralize package versioning across all projects, consolidate metadata, and streamline automated validation and symbol publishing within your build pipelines.