agentleFS
dougcunhadougcunha/TokenHound/.agents/skills/architectural-analysis/SKILL.md

architectural-analysis

Skill3 starsChanged 35 days agoMITView on GitHub

Read-only architectural audit of a .NET/C# codebase — dead code, duplication, anti-patterns, nullability and type safety, code smells — written to a report, never edited. Use when a whole solution or a large module needs an architecture-level health check; it detects the stack first and offers a derived strategy when that stack is not .NET/C#. Don't use for style/formatting, performance profiling, security audits, or feature-level code review.

4 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 6 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read-only audit of a whole .NET/C# codebase.

    line 12
  2. Distinctive:

    Start from the build manifests: one sweep both names the stack and lists the projects.

    line 22
  3. Very specific:

    Run both sweeps: C# symbols are reached from markup, configuration binding, and DI by name, so a .cs-only search reports live code as dead.

    line 41
  4. Distinctive:

    Done when: every todo file's declared members are usage-checked and categorized.

    line 44
  5. Distinctive:

    Done when: every candidate group is read and classified.

    line 53
  6. Very specific:

    Read the largest files for mixed responsibilities.

    line 62
  7. Very specific:

    Start from each project's nullable posture: <Nullable> absent or disable strips null tracking from the whole project and raises the …

    line 66
  8. Distinctive:

    Done when: every project's nullable posture is recorded and every hit is judged.

    line 73
  9. Distinctive:

    Done when: every smell category in that section has been swept.

    line 81
  10. Distinctive:

    Done when: every placeholder is replaced and every section is present.

    line 85

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Architectural Analysis

Read-only audit of a whole .NET/C# codebase. Report findings only — make no edits. Classification depth for every dimension lives in references/detection-catalog.md; each step below names its section — read that section in full before classifying findings in that dimension.

Commands are PowerShell driven by ripgrep, run from the repository root. Set the exclusion set once per session and splat it into every sweep, improvised ones included — without it the sweeps report compiler output and generated code as source.

$src = @('-g','!**/bin/**','-g','!**/obj/**','-g','!**/*.g.cs','-g','!**/*.Designer.cs')

Steps

1. Map the codebase

Start from the build manifests: one sweep both names the stack and lists the projects.

rtk rg --files -g '*.sln' -g '*.slnx' -g '*.csproj' -g 'Directory.Build.props' -g 'global.json' -g '*.dproj' -g 'package.json' -g 'pyproject.toml' -g 'go.mod' -g 'Cargo.toml' -g 'pom.xml' -g 'build.gradle*' -g 'Gemfile' -g 'composer.json'

A .sln, .slnx, or .csproj alongside .cs sources means .NET/C# — carry on below. Any other stack — or .NET on a non-C# language such as F# or VB.NET — falls outside this skill's calibration: name the stack you found, name the mismatch, and ask the user whether to continue anyway. On a yes, read references/foreign-stack-adaptation.md in full and follow it; it rebuilds the sweeps in steps 1–6 around the detected stack and ends by offering to save that strategy as architectural-analysis-<stack>.

On .NET/C#, count the compilable sources and build a todo with one item per .cs file. Note the entry points that anchor usage tracing: Program/Startup, DI registration extensions, controllers and minimal-API endpoint maps, BackgroundService/IHostedService, each class library's public surface, CLI verbs, test projects.

(rtk rg --files -g '*.cs' @src | Measure-Object).Count
rtk rg -n --type cs @src 'class Program|static.*Main\(|MapGet|MapPost|MapControllers|ControllerBase|BackgroundService|IHostedService|AddScoped|AddSingleton|AddTransient'

Done when the stack is named and either it is .NET/C# or the user has answered the continue question, every source file has a todo entry, and the entry-point list is recorded.

2. Detect dead code

For each file in the todo: list the types and members it declares, then search each name for references elsewhere.

rtk rg -n --type cs @src '\bSymbolName\b'
rtk rg -n -g '*.razor' -g '*.cshtml' -g '*.xaml' -g '*.axaml' -g '*.json' -g '*.xml' 'SymbolName'

Run both sweeps: C# symbols are reached from markup, configuration binding, and DI by name, so a .cs-only search reports live code as dead.

Before recording anything as dead, clear it against the "Not dead" list in references/detection-catalog.md → Dead code — DI registration, reflection, serialization, markup binding, interface implementation, attribute-driven entry points, and EF Core wiring all count as USED. Record each finding as file:line, category, and confidence per that section, then mark the todo item complete. Done when every todo file's declared members are usage-checked and categorized.

3. Detect duplication

Surface candidates by similar names, repeated blocks, and competing implementations of one concept — C# scatters these across extension-method classes, helpers, mappers, and a Utils per project.

rtk rg -n --type cs @src 'static .*(Validate|Parse|Format|Map|Convert|Normalize|Sanitize)\w*\('
rtk rg -n --type cs @src '(record|class|struct|interface|enum) \w*(Dto|Request|Response|Options|Settings|Result)\b'

Confirm each candidate group by reading the implementations, then classify and rank it using references/detection-catalog.md → Duplication. Done when every candidate group is read and classified.

4. Detect anti-patterns

rtk rg -c '^' --type cs @src | Sort-Object { [int]($_ -split ':')[-1] } -Descending | Select-Object -First 20
rtk rg -n -g '*.csproj' 'ProjectReference'
rtk rg -n --type cs @src -g '**/*Controller.cs' -g '**/Pages/**' -g '**/Components/**' -g '**/*.razor.cs' 'DbContext|IDbConnection|SqlConnection|SaveChanges'
rtk rg -n --type cs @src 'async void|\.Result\b|\.Wait\(\)|GetAwaiter\(\)\.GetResult\(\)|GetRequiredService<|GetService<|ServiceLocator'

Read the largest files for mixed responsibilities; trace the ProjectReference graph for assembly-level cycles and the namespace graph for type-level ones; judge each layer and lifetime hit. Check findings against the full set in references/detection-catalog.md → Anti-patterns. Done when each of the largest files is judged, the ProjectReference graph is traced, and every hit from the layer and async/lifetime sweeps is classified.

5. Detect type and nullability issues

Start from each project's nullable posture: <Nullable> absent or disable strips null tracking from the whole project and raises the severity of every other finding here.

rtk rg -n -g '*.csproj' -g 'Directory.Build.props' '<Nullable>|<TreatWarningsAsErrors>|<WarningsAsErrors>|<LangVersion>'
rtk rg -n --type cs @src '#nullable disable|#pragma warning disable|SuppressMessage|\bdynamic\b|\(object |, object '
rtk rg -n --type cs @src '!\.|!\)|!;|!,| as [A-Z]\w*'

For each hit decide whether a precise type, a generic, or a real null check is possible, or whether a genuine error is being suppressed; classify per references/detection-catalog.md → Type and nullability issues. Done when every project's nullable posture is recorded and every hit is judged.

6. Detect code smells

rtk rg -n --type cs @src '^\s*//\s*(public|private|internal|protected|var|if|foreach|return|await|using)'
rtk rg -n --type cs @src '#region|catch\s*\{|catch \(Exception\w*\)\s*\{\s*\}|throw new Exception\('

Sweep for long methods, long parameter lists, complex conditionals, magic numbers and string keys, commented-out code, swallowed exceptions, #region hiding bulk, and naming that fights C# convention. Thresholds for each smell are in references/detection-catalog.md → Code smells. Done when every smell category in that section has been swept.

7. Write the report

Populate assets/report-template.md and write it to .audits/architectural-analysis-[timestamp].md, filling every placeholder from steps 2–6. Keep every section present; where a count is zero, write "None found" rather than deleting the heading. Done when every placeholder is replaced and every section is present.

8. Summarize for the user

Populate assets/summary-template.md and emit it inline in chat, linking to the full report at the end. Done when the summary is in chat and carries the report path.

Bundled files

  • references/detection-catalog.md — .NET/C# classification depth for the five detection dimensions; each of steps 2–6 names its section.
  • references/foreign-stack-adaptation.md — the non-.NET branch: build a stack-specific strategy, run it, and offer to save it as a derived skill. Reached only from the stack gate in step 1.
  • assets/report-template.md — the full report written in step 7.
  • assets/summary-template.md — the chat summary emitted in step 8.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.