Dotnet-skills dotnet-mcaf-source-control
Apply MCAF source-control guidance for repository structure, branch naming, merge strategy, commit hygiene, and secrets-in-git discipline. Use when bootstrapping a repo, tightening PR flow, or documenting branch and release policy.
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-source-control" ~/.claude/skills/managedcode-dotnet-skills-dotnet-mcaf-source-control && rm -rf "$T"
manifest:
catalog/Platform/MCAF/skills/dotnet-mcaf-source-control/SKILL.mdsource content
MCAF: Source Control
Trigger On
- bootstrapping source-control policy
- tightening branch, merge, or PR rules
- documenting commit or release hygiene
- dealing with secrets-in-git or repository structure issues
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
- CI/CD workflow design with no source-control policy change
- one-off git commands that do not alter repo policy
Inputs
- current branching and merge flow
- release strategy and versioning expectations
- secret-handling and repository-structure constraints
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
- Agree on merge and release strategy before scaling implementation.
- Keep branch and PR rules explicit in-repo.
- Treat secrets in git history as a critical incident, not cleanup noise.
- Use concrete policy language, not hand-waving.
Deliver
- clear branch and merge strategy
- updated contribution or governance docs
- safer repository hygiene around commits, PRs, and secrets
Validate
- naming and merge rules are explicit
- release/versioning implications are documented where needed
- secret hygiene is treated as policy, not tribal knowledge
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/source-control.md - open
only when the task is specifically about branch namingreferences/naming-branches.md
Example Requests
- "Define branch naming and merge rules for this repo."
- "Document how releases and component versions should work."
- "Tighten our source-control policy after a secrets leak."