mcaf-dotnet-cloc

name	mcaf-dotnet-cloc
description	Use the open-source free `cloc` tool for line-count, language-mix, and diff statistics in .NET repositories. Use when a repo needs C# and solution footprint metrics, branch-to-branch LOC comparison, or repeatable code-size reporting in local workflows and CI.
compatibility	Requires a repository with .NET source files or a Git checkout; respects the repo's `AGENTS.md` commands first.

MCAF: .NET cloc

Trigger On

• the repo wants cloc
• the team needs repeatable LOC, language, or branch diff statistics for a .NET repo
• the user asks about C# codebase size, solution composition, or code-count deltas between refs

Value

• produce a concrete project delta: code, docs, config, tests, CI, or review artifact
• reduce ambiguity through explicit planning, verification, and final validation skills
• leave reusable project context so future tasks are faster and safer

Do Not Use For

• judging developer productivity from raw LOC
• replacing behavioral verification, architecture review, or complexity analysis
• counting generated or vendored files without an explicit reason

Inputs

• the nearest AGENTS.md
• target repository, solution, project, or subtree
• the question being answered: footprint, composition, diff, or trend

Quick Start

1. Read the nearest AGENTS.md and confirm scope and constraints.
2. Run this skill's Workflow through the Ralph Loop until outcomes are acceptable.
3. Return the Required Result Format with concrete artifacts and verification evidence.

Workflow

1. Choose the counting mode deliberately:
   • --vcs=git for repo-respecting counts
   • path-based counting for bounded folders
   • --git --diff BASE HEAD for change deltas
2. Prefer .NET-relevant views first:
   • C# footprint
   • test versus production footprint
   • solution language mix such as C#, Razor, XML, JSON, YAML, and MSBuild files
3. Exclude noise before trusting the numbers:
   • bin
   • obj
   • .git
   • vendored or generated folders when they are not part of the decision
4. Use machine-readable output when the numbers feed docs, CI, or follow-up automation:
   • --json
   • --csv
   • --yaml
   • --md
5. Treat cloc as a sizing and comparison tool, not as evidence that the design is good.
6. When using diff mode, compare named refs that match the review question:
   • origin/main..HEAD
   • release branch versus main
   • before and after a refactor
7. After any code cleanup based on cloc findings, run the repo's normal quality pass.

Bootstrap When Missing

If cloc is not available yet:

1. Detect current state:
   • command -v cloc
   • cloc --version
   • perl --version
2. Choose the install path deliberately:
   • macOS with Homebrew: brew install cloc
   • Debian or Ubuntu: sudo apt install cloc
   • Red Hat or older Fedora family: sudo yum install cloc
   • Fedora or newer Red Hat family: sudo dnf install cloc
   • npm fallback: npm install -g cloc
   • Windows with Chocolatey: choco install cloc
   • Windows with Scoop: scoop install cloc
   • Docker fallback: docker run --rm -v $PWD:/tmp aldanial/cloc .
3. If package-manager builds are not acceptable, install from the latest upstream release or source and verify with cloc --version.
4. Record exact counting commands in AGENTS.md, for example:
   • cloc --vcs=git --include-lang="C#,MSBuild,JSON,XML,YAML"
   • cloc --by-file --vcs=git --include-lang="C#"
   • cloc --git --diff origin/main HEAD --include-lang="C#"
5. Run one bounded command and return status: configured or status: improved.
6. If the repo intentionally uses another code-count tool and does not want cloc, return status: not_applicable.

Deliver

• repeatable LOC and language-mix reporting for .NET repos
• explicit include and exclude rules
• branch-diff or bounded-scope commands that answer a concrete engineering question

Validate

• counts match the intended source boundary instead of including build output noise
• command choice matches the reporting question
• any automation or docs that consume the numbers can rerun the same command
• cloc is used as context, not as a substitute for tests or design review

Ralph Loop

Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.

1. Plan first (mandatory):
   • analyze current state
   • define target outcome, constraints, and risks
   • write a detailed execution plan
   • list final validation skills to run at the end, with order and reason
2. Execute one planned step and produce a concrete delta.
3. Review the result and capture findings with actionable next fixes.
4. Apply fixes in small batches and rerun the relevant checks or review steps.
5. Update the plan after each iteration.
6. Repeat until outcomes are acceptable or only explicit exceptions remain.
7. If a dependency is missing, bootstrap it or return status: not_applicable with explicit reason and fallback path.

Required Result Format

• status: complete | clean | improved | configured | not_applicable | blocked
• plan: concise plan and current iteration step
• actions_taken: concrete changes made
• validation_skills: final skills run, or skipped with reasons
• verification: commands, checks, or review evidence summary
• remaining: top unresolved items or none

For setup-only requests with no execution, return status: configured and exact next commands.

Load References

• read references/cloc.md first

Example Requests

• "Add cloc reporting to this .NET repo."
• "Compare code size between main and this branch."
• "Count C# versus test footprint in this solution."
• "Give me a machine-readable line-count report for CI."