writing-csharp

Name: writing-csharp
Author: alexei-led

35stars5forks

How to install writing-csharp?

alexei-led/cc-thingz/writing-csharp

$npx -y skills add alexei-led/cc-thingz --skill writing-csharp

Installs into the current project.

Summary

Use only for C# and .NET code. Follow the project's SDK, target frameworks, nullable settings, analyzer config, test stack, and local conventions.

Files · 1

View on GitHub

SKILL.md

1	# C# /.NET Development
2
3	Use only for C# and .NET code. Follow the project's SDK, target frameworks,
4	nullable settings, analyzer config, test stack, and local conventions.
5
6	## Read First
7
8	Read [principles.md](references/principles.md) before writing, changing, or reviewing C# code. Read conditional references only when the change touches that area.
9
10	## Conditional References
11
12	- [patterns.md](references/patterns.md) — solution layout, ASP.NET Core boundaries, DI, EF access, config, and worker patterns.
13	- [testing.md](references/testing.md) — adding or reshaping xUnit, NUnit, or MSTest coverage; keep the local `dotnet test` loop fast.
14	- [linting.md](references/linting.md) — changing `dotnet format`, analyzers, warning policy, or slow verification flow.
15	- [cli.md](references/cli.md) — writing or changing .NET CLIs.
16
17	## Project Baseline
18
19	- Inspect the nearest `*.csproj`, `Directory.Build.props`, `global.json`, solution file, CI, and nearby code before using SDK- or framework-specific APIs.
20	- Keep nullable reference types enabled. Fix the warning or model, not the warning level.
21	- Prefer the BCL and existing NuGet packages before adding a dependency.
22	- Use the existing app style: ASP.NET Core controllers vs minimal APIs, records vs classes, MediatR or no mediator, EF or raw SQL, and the configured test framework.
23
24	## Comments and XML Docs
25
26	- Use XML documentation comments for public APIs when the project emits API docs or enforces CS1591.
27	- Summarize contracts, invariants, edge cases, and effects. Do not restate member names or signatures.
28	- Use `//` for brief implementation notes; avoid long `/* */` explanations.
29	- Keep comments short. Move longer rationale to docs, issue links, or design notes.
30	- Do not comment obvious code.
31	- Keep tests readable without comments; add one only for unobvious fixtures, timing, concurrency, external services, or regression context.
32
33	## Verification
34
35	Run focused `dotnet` checks while editing, then the project-configured build,
36	tests, analyzers, and formatting checks before final output. Prefer the
37	narrowest useful project or solution target for the hot loop, then the broader
38	configured command before final output.
39
40	If a check is unavailable, state that and run the closest configured gate. If a
41	check fails, quote the failure, diagnose the cause, fix one issue, and rerun the
42	relevant check.
43
44	## Failure Cases
45
46	- No clear .NET root: locate the nearest `.csproj` or containing `.sln` before choosing files or commands.
47	- Unknown SDK or language level: inspect `TargetFramework`, `TargetFrameworks`, `LangVersion`, `global.json`, CI, and lockfiles before using newer APIs or syntax.
48	- New package requested: confirm the BCL or existing packages cannot meet the requirement.
49	- Broad or risky edit: state the risk and ask before acting. Do not run destructive commands.
50
51	## Final Response
52
53	Include:
54
55	- changed files
56	- checks run and results
57	- checks skipped with reasons
58	- remaining risks or follow-ups

People who liked this also viewed

6 picks

Type

hyperframes-cliUse the HyperFrames CLI development loop: init, add, catalog, capture, lint, check, snapshot, compare, grade-compare, preview, play, present, beats, keyframes, single or batch render, publish, cloud, SkillsJul 2026262k37k
request-refactor-planSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026165k181k
analyze-projectRigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrSkillsMay 2026161k507
explore-codeRigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated braSkillsMay 2026161k507
ubiquitous-languageSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026160k181k
scaffold-exercisesSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026149k181k

writing-csharp

35stars5forks

View on GitHub

How to install writing-csharp?

alexei-led/cc-thingz/writing-csharp

$npx -y skills add alexei-led/cc-thingz --skill writing-csharp

Installs into the current project.

Summary

Use only for C# and .NET code. Follow the project's SDK, target frameworks, nullable settings, analyzer config, test stack, and local conventions.

Files · 1

View on GitHub

SKILL.md

1	# C# /.NET Development
2
3	Use only for C# and .NET code. Follow the project's SDK, target frameworks,
4	nullable settings, analyzer config, test stack, and local conventions.
5
6	## Read First
7
8	Read [principles.md](references/principles.md) before writing, changing, or reviewing C# code. Read conditional references only when the change touches that area.
9
10	## Conditional References
11
12	- [patterns.md](references/patterns.md) — solution layout, ASP.NET Core boundaries, DI, EF access, config, and worker patterns.
13	- [testing.md](references/testing.md) — adding or reshaping xUnit, NUnit, or MSTest coverage; keep the local `dotnet test` loop fast.
14	- [linting.md](references/linting.md) — changing `dotnet format`, analyzers, warning policy, or slow verification flow.
15	- [cli.md](references/cli.md) — writing or changing .NET CLIs.
16
17	## Project Baseline
18
19	- Inspect the nearest `*.csproj`, `Directory.Build.props`, `global.json`, solution file, CI, and nearby code before using SDK- or framework-specific APIs.
20	- Keep nullable reference types enabled. Fix the warning or model, not the warning level.
21	- Prefer the BCL and existing NuGet packages before adding a dependency.
22	- Use the existing app style: ASP.NET Core controllers vs minimal APIs, records vs classes, MediatR or no mediator, EF or raw SQL, and the configured test framework.
23
24	## Comments and XML Docs
25
26	- Use XML documentation comments for public APIs when the project emits API docs or enforces CS1591.
27	- Summarize contracts, invariants, edge cases, and effects. Do not restate member names or signatures.
28	- Use `//` for brief implementation notes; avoid long `/* */` explanations.
29	- Keep comments short. Move longer rationale to docs, issue links, or design notes.
30	- Do not comment obvious code.
31	- Keep tests readable without comments; add one only for unobvious fixtures, timing, concurrency, external services, or regression context.
32
33	## Verification
34
35	Run focused `dotnet` checks while editing, then the project-configured build,
36	tests, analyzers, and formatting checks before final output. Prefer the
37	narrowest useful project or solution target for the hot loop, then the broader
38	configured command before final output.
39
40	If a check is unavailable, state that and run the closest configured gate. If a
41	check fails, quote the failure, diagnose the cause, fix one issue, and rerun the
42	relevant check.
43
44	## Failure Cases
45
46	- No clear .NET root: locate the nearest `.csproj` or containing `.sln` before choosing files or commands.
47	- Unknown SDK or language level: inspect `TargetFramework`, `TargetFrameworks`, `LangVersion`, `global.json`, CI, and lockfiles before using newer APIs or syntax.
48	- New package requested: confirm the BCL or existing packages cannot meet the requirement.
49	- Broad or risky edit: state the risk and ask before acting. Do not run destructive commands.
50
51	## Final Response
52
53	Include:
54
55	- changed files
56	- checks run and results
57	- checks skipped with reasons
58	- remaining risks or follow-ups

People who liked this also viewed

6 picks

Type