oma-scm

---

name: oma-scm description: SCM (software configuration management) and Git: branching, merges, conflicts, worktrees, baselines, audit readiness, plus Conventional Commits and safe staging.

Software configuration management: SCM (oma-scm)

Scheduling

Goal

Manage Git and software configuration management safely: commits, branches, merges, worktrees, releases, baselines, audit posture, CODEOWNERS, and Conventional Commits.

Intent signature

• User asks to commit, stage, branch, merge, rebase, cherry-pick, tag, release, resolve conflicts, manage worktrees, inspect SCM posture, or apply Conventional Commits.
• User needs safe Git operations with explicit file staging, secret awareness, and CM governance.

This skill is the single place for configuration management (CM) on a software repo and for Conventional Commits / safe staging.

When to use

• Commits: “commit this”, /scm, message type/scope, splitting staged changes into multiple commits.
• CM / Git: branching (gitflow, GitHub Flow, GitLab Flow, trunk-based), protected branches, merge queue, merge conflicts, rebase, cherry-pick, worktrees, submodules/subtrees, tags and releases.
• Governance: issue/ADR links, breaking-change footers, changelog or release-tool alignment.
• Audit posture: signed commits, CI before merge, secret-sensitive paths.

When NOT to use

• Implementing product or application code -> use the relevant domain skill
• Debugging runtime failures without a Git or CM operation -> use oma-debug
• Security, performance, or accessibility review -> use oma-qa
• Planning feature requirements or decomposing work -> use oma-pm

Expected inputs

• Git task, desired branch/commit/release operation, and affected files
• Current worktree status, staged diff, branch tracking, config files, and governance constraints
• Optional issue/ADR/PR/release context

Expected outputs

• Safe commit, branch, merge/rebase guidance, conflict plan, status accounting, or CM audit findings
• Conventional Commit message and explicit staged paths when committing
• Risk notes for shared history, secrets, CODEOWNERS, CI, and release evidence

Dependencies

• Git CLI and repository metadata
• config/commit-config.yaml, config/cm-config.yaml, Conventional Commit references, onboarding-risk and CODEOWNERS playbooks

Control-flow features

• Branches by quick commit path versus full CM/governance path
• Reads Git state and diffs; may write commits, branches, tags, or conflict resolutions
• Requires explicit approval for broad staging, shared-history rewrite, production-destructive operations, or secret-risk paths

Structural Flow

Entry

1. Inspect Git status, branch, staged/unstaged changes, and user intent.
2. Choose Quick Path for ordinary commits or Full CM Path for governance/risky history work.
3. Read commit and CM config before enforcing project-specific rules.

Scenes

1. PREPARE: Determine operation type, risk, and affected files.
2. ACQUIRE: Read status, diff, logs, config, ownership, and release context.
3. REASON: Split changes, choose message/scope, identify CM controls and risks.
4. ACT: Stage explicit paths, commit, branch, resolve, or provide CM action plan.
5. VERIFY: Check status, staged diff, CI expectations, signatures, secrets, and audit evidence.
6. FINALIZE: Report operation result and remaining SCM tasks.

Transitions

• If user intent is commit-only, follow Quick Path and stop after safe commit.
• If branching/history/release/governance is involved, run Full CM Path.
• If shared history rewrite is requested, require maintainer approval.
• If changes span independent features, split commits unless user requests one commit.

Failure and recovery

• If worktree is dirty in unrelated files, avoid touching unrelated changes.
• If conflicts exist, resolve markers, test, and preserve target-branch context.
• If secrets are detected or suspected, stop before staging/committing.

Exit

• Success: requested SCM operation is complete or a safe, auditable plan is delivered.
• Partial success: blockers such as conflicts, missing approval, CI, or secret risk are explicit.

Logical Operations

Actions

Action	SSL primitive	Evidence
Read Git state	READ	git status, diff, log, config
Select SCM path	SELECT	Quick Path vs Full CM Path
Compare change scopes	COMPARE	Split by type/scope/feature
Validate commit/governance rules	VALIDATE	Config and CM controls
Stage explicit files	CALL_TOOL	git add <specific-files>
Commit or manage refs	CALL_TOOL	Git commit/branch/merge/rebase/tag
Write audit notes	WRITE	Commit message or CM report
Report result	NOTIFY	Final SCM summary

Tools and instruments

• Git CLI and repository metadata
• Commit/CM config, Conventional Commit guide, CODEOWNERS playbook, onboarding-risk signals

Canonical command path

git status -sb
git diff --staged
git log --oneline -5

Stage and commit only explicit paths:

git add <specific-files>
git commit -m "$(cat <<'EOF'
<type>(<scope>): <description>

[optional body]
EOF
)"

Resource scope

Scope	Resource target
CODEBASE	Tracked files, diffs, conflicts, CODEOWNERS
LOCAL_FS	Git metadata, config files, commit message temp files
PROCESS	Git commands and verification commands
CREDENTIALS	Secret-sensitive files must not be staged or committed

Preconditions

• Repository and Git intent are identifiable.
• User has authorized the requested SCM operation.

Effects and side effects

• May stage files, create commits, branches, tags, worktrees, or history operations.
• Can affect shared repository history if unsafe commands are used, so approvals matter.

Guardrails

1. Choose Quick Path for ordinary commits and Full CM Path for branching, history, release, or governance work.
2. Read config/commit-config.yaml and config/cm-config.yaml before applying project-specific commit or CM rules.
3. Stage only explicit files; never use broad staging unless the user explicitly approves it.
4. Do not rewrite shared history without maintainer approval.
5. Never stage or commit likely-secret material.

Configuration

File	Role
config/commit-config.yaml	Conventional Commit types, branch prefixes, message rules
config/cm-config.yaml	CM pointers (documented process, branching model, baselines, changelog)

Operating mode (choose first)

Quick Path (commit-focused, default)

Use this when the user intent is mainly "commit this safely."

1. Follow Conventional Commits section only
2. Stage explicit files only
3. Validate message type/scope/length from commit-config.yaml
4. Stop after safe commit unless user asks CM/governance operations

Full CM Path (repo governance / risky history operations)

Use this when the user asks about branching strategy, merges, rebase/cherry-pick, worktrees, release refs, CODEOWNERS, or audit posture.

1. Run CM workflows in order (Planning -> Identification -> Control -> Status accounting -> Verification)
2. Add onboarding risk scan when inheriting or auditing a repository
3. Include commit governance from Conventional Commits when creating commits
4. For large-scope merge operations, use risk scoring and Ask Gate criteria from ../../workflows/scm.md

CM process map (software)

CM function	Intent	Typical artefacts / actions
Management & planning	Agreed rules	CONTRIBUTING.md, SECURITY.md, cm-config.yaml
Configuration identification	What is managed, naming	Branch/tag rules, version files, .gitattributes, LFS
Configuration control	Reviewed change	PRs, checks, issue links, BREAKING CHANGE footers
Status accounting	As-built truth	main / release refs, CHANGELOG, tags, CI status
Verification & audit	Evidence	CI logs, signed commits, lockfiles / SBOM policy

CM workflows (use before risky history operations)

1) Planning

1. Read cm-config.yaml and files listed under documented_process.
2. If missing, infer from CONTRIBUTING.md / README; state assumptions.
3. Confirm branching model and whether force-push on shared branches is allowed (default: not without explicit approval).

2) Identification

1. Canonical refs: default branch, release branches/tags, version sources (package.json, etc.).
2. .gitattributes / LFS for binaries and generated assets.
3. Branch names vs commit-config.yaml branch_prefixes when the project uses them.

3) Control

1. Small, reviewable units; align commits with PR / issue intent.
2. Conflicts: merge-base, git status, resolve markers, tests; suggest rerere when conflicts repeat.
3. Worktrees: git worktree add; merge/rebase from the target branch’s checkout; all worktrees share one object database.
4. Do not rewrite shared history without maintainer approval; prefer --force-with-lease if force-push is unavoidable.

4) Status accounting

1. git status -sb: branch, remote tracking, ahead/behind, merge state.
2. Relate last tag / release branch to CHANGELOG or tooling (semantic-release, release-please, changesets) if present.

5) Verification & audit

1. Required CI and merge_group when merge queue applies.
2. Never stage/commit secrets (.env, keys, raw tokens).
3. Call out signed-commit expectations when the org cares about verification badges.

CODEOWNERS maintenance checklist

1. Validate CODEOWNERS file exists (prefer .github/CODEOWNERS).
2. Ensure critical paths are explicitly owned (not only fallback *).
3. Ensure owners are active and mapped to current teams.
4. Confirm branch protection requires CODEOWNERS review where needed.
5. Flag overlapping/ambiguous rules that can hide intended owners.

Read change_governance.require_codeowners and ownership.* in cm-config.yaml when present.

6) Onboarding risk scan (optional, recommended)

Use this quick scan when joining or inheriting a repository to identify risky areas before major changes.

1. High churn files in lookback window.
2. Ownership concentration / bus-factor signals.
3. Bug hotspot files from fix-related history.
4. Velocity trend by month.
5. Revert/hotfix/emergency frequency.

Read thresholds from cm-config.yaml onboarding_metrics when present and cite caveats:

• squash merge teams can distort ownership metrics,
• weak commit labeling reduces hotspot accuracy,
• monorepo commit counts can bias subsystem interpretation.

---

Conventional Commits

Commit types

Type	Description	Branch Prefix
feat	New feature	feature/
fix	Bug fix	fix/
refactor	Code improvement	refactor/
docs	Documentation changes	docs/
test	Test additions/modifications	test/
chore	Build, configuration, etc.	chore/
style	Code style changes	style/
perf	Performance improvements	perf/

Commit format

<type>(<scope>): <description>

[optional body]

Co-Authored-By: First Fluke <[e-mail]>

Commit workflow

Step 1: Analyze changes

git status
git diff --staged
git log --oneline -5

Step 1.5: Split by feature (if needed)

If changes span multiple features/domains, split commits by feature.

Split when: different scopes, different types, logically independent work.

Do not split when: one feature, few files (≤5), or user asked for a single commit.

Step 2: Determine type

• New capability → feat · Bug fix → fix · Structure-only → refactor · Docs only → docs · Tests → test · Build/config → chore

Step 3: Scope

Use module/component: feat(auth):, fix(api):, or omit: chore: update dependencies

Step 4: Description

≤72 chars (per commit-config.yaml), imperative mood, lowercase start, no trailing period.

Step 5: Execute commit

Show the message, then commit with explicit paths:

git add <specific-files>
git commit -m "$(cat <<'EOF'
<type>(<scope>): <description>

[optional body]
EOF
)"

If HEREDOC is unstable in your shell (or body is long), use file-based commit input:

git add <specific-files>
cat > /tmp/oma-commit-msg.txt <<'EOF'
<type>(<scope>): <description>

[optional body]
EOF
git commit -F /tmp/oma-commit-msg.txt

Use HEREDOC by default, and switch to -F for long or flaky terminal sessions.

References

• config/commit-config.yaml
• config/cm-config.yaml
• resources/conventional-commits.md
• resources/onboarding-risk-signals.md
• resources/codeowners-playbook.md

Important notes

• NEVER git add -A or git add . without explicit user permission.
• NEVER commit likely-secret material.
• ALWAYS stage by explicit paths; tie non-trivial CM work to the five CM rows above, even briefly.