Dotnet-skills dotnet-mcaf-devex
Apply MCAF developer-experience guidance for onboarding, F5 contract, cross-platform tasks, local inner loop, and reproducible setup. Use when the repo is hard to run, debug, test, or onboard into.
install
source · Clone the upstream repo
git clone https://github.com/managedcode/dotnet-skills
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/managedcode/dotnet-skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/catalog/Platform/MCAF/skills/dotnet-mcaf-devex" ~/.claude/skills/managedcode-dotnet-skills-dotnet-mcaf-devex && rm -rf "$T"
manifest:
catalog/Platform/MCAF/skills/dotnet-mcaf-devex/SKILL.mdsource content
MCAF: Developer Experience
Trigger On
- the repo is hard to run, test, debug, or onboard into
- local setup differs too much across contributors
- the inner loop is slow or undocumented
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
- production deployment or pipeline policy
- pure documentation cleanup with no developer workflow impact
Inputs
- the current local setup and first-run path
- actual build, run, debug, and test commands
- pain points in onboarding or the inner loop
Quick Start
- Read the nearest
and confirm scope and constraints.AGENTS.md - Run this skill's
through theWorkflow
until outcomes are acceptable.Ralph Loop - Return the
with concrete artifacts and verification evidence.Required Result Format
Workflow
- Find the slowest or most fragile part of the inner loop:
- clone and setup
- build
- run and debug
- test
- Standardize tasks before optimizing them.
- Prefer one documented way to run the full solution locally.
- Pull only the references that match the local-dev problem you are fixing.
Deliver
- lower-friction local workflow
- better onboarding
- reproducible build, run, test, and debug paths
Validate
- a newcomer can follow the docs without hidden setup knowledge
- the inner loop is explicit and reproducible
- cross-platform or containerized guidance is used only where it helps
- local development uses real services, containers, or sandbox environments instead of fakes or stubs
Ralph Loop
Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.
- Brainstorm first (mandatory):
- analyze current state
- define the problem, target outcome, constraints, and risks
- generate options and think through trade-offs before committing
- capture the recommended direction and open questions
- Plan second (mandatory):
- write a detailed execution plan from the chosen direction
- list final validation skills to run at the end, with order and reason
- Execute one planned step and produce a concrete delta.
- Review the result and capture findings with actionable next fixes.
- Apply fixes in small batches and rerun the relevant checks or review steps.
- Update the plan after each iteration.
- Repeat until outcomes are acceptable or only explicit exceptions remain.
- If a dependency is missing, bootstrap it or return
with explicit reason and fallback path.status: not_applicable
Required Result Format
:status
|complete
|clean
|improved
|configured
|not_applicableblocked
: concise plan and current iteration stepplan
: concrete changes madeactions_taken
: final skills run, or skipped with reasonsvalidation_skills
: commands, checks, or review evidence summaryverification
: top unresolved items orremainingnone
For setup-only requests with no execution, return
status: configured and exact next commands.
Load References
- read
firstreferences/developer-experience.md - open
only when relevantreferences/onboarding-guide-template.md
Example Requests
- "Make this repo easier to onboard into."
- "Document a sane local run and debug loop."
- "Fix the dev setup drift across machines."