[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BYWDM0MJHP042M7YA17RZX":3,"skill-same:01M6BYWDM0MJHP042M7YA17RZX":70},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":24,"linkOnly":25,"markdownContent":26,"markdownBody":27,"frontMatter":28,"refName":29,"commitSha":30,"skillDirectory":31,"forksCount":32,"repositoryHtmlUrl":33,"repositoryHomepageUrl":6,"ownerHtmlUrl":34,"ownerBlogUrl":6,"ownerDescription":35,"updatedAt":36,"install":37,"resources":50},"01M6BYWDM0MJHP042M7YA17RZX","oma-scm",null,"SCM (software configuration management) and Git: branching, merges, conflicts, worktrees, baselines, audit readiness, plus Conventional Commits and safe staging.","mrmarbury\u002FPalmSync4Mac","mrmarbury","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F114311?v=4","01M6BYSN920J8AMQ0W6HGSBH60","Stefan Marbury","01M6BYSNDEACDBNBPNRNCVYAPJ",2,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmrmarbury\u002FPalmSync4Mac\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Foma-scm\u002FSKILL.md",[],[19,20,21,22,23],"oma scm","safe","git","audit","commits","2026-11-10 10:12:30",false,"---\nname: oma-scm\ndescription: \"SCM (software configuration management) and Git: branching, merges, conflicts, worktrees, baselines, audit readiness, plus Conventional Commits and safe staging.\"\n---\n\n# Software configuration management: SCM (`oma-scm`)\n\n## Scheduling\n\n### Goal\nManage Git and software configuration management safely: commits, branches, merges, worktrees, releases, baselines, audit posture, CODEOWNERS, and Conventional Commits.\n\n### Intent signature\n- User asks to commit, stage, branch, merge, rebase, cherry-pick, tag, release, resolve conflicts, manage worktrees, inspect SCM posture, or apply Conventional Commits.\n- User needs safe Git operations with explicit file staging, secret awareness, and CM governance.\n\nThis skill is the **single** place for **configuration management (CM)** on a software repo and for **Conventional Commits** \u002F safe staging.\n\n### When to use\n\n- **Commits:** “commit this”, `\u002Fscm`, message type\u002Fscope, splitting staged changes into multiple commits.\n- **CM \u002F Git:** branching (gitflow, GitHub Flow, GitLab Flow, trunk-based), protected branches, merge queue, merge conflicts, rebase, cherry-pick, worktrees, submodules\u002Fsubtrees, tags and releases.\n- **Governance:** issue\u002FADR links, breaking-change footers, changelog or release-tool alignment.\n- **Audit posture:** signed commits, CI before merge, secret-sensitive paths.\n\n### When NOT to use\n\n- Implementing product or application code -> use the relevant domain skill\n- Debugging runtime failures without a Git or CM operation -> use `oma-debug`\n- Security, performance, or accessibility review -> use `oma-qa`\n- Planning feature requirements or decomposing work -> use `oma-pm`\n\n### Expected inputs\n- Git task, desired branch\u002Fcommit\u002Frelease operation, and affected files\n- Current worktree status, staged diff, branch tracking, config files, and governance constraints\n- Optional issue\u002FADR\u002FPR\u002Frelease context\n\n### Expected outputs\n- Safe commit, branch, merge\u002Frebase guidance, conflict plan, status accounting, or CM audit findings\n- Conventional Commit message and explicit staged paths when committing\n- Risk notes for shared history, secrets, CODEOWNERS, CI, and release evidence\n\n### Dependencies\n- Git CLI and repository metadata\n- `.agents\u002Foma-config.yaml`, Conventional Commit references, onboarding-risk and CODEOWNERS playbooks\n\n### Control-flow features\n- Branches by quick commit path versus full CM\u002Fgovernance path\n- Reads Git state and diffs; may write commits, branches, tags, or conflict resolutions\n- Requires explicit approval for broad staging, shared-history rewrite, production-destructive operations, or secret-risk paths\n\n## Structural Flow\n\n### Entry\n1. Inspect Git status, branch, staged\u002Funstaged changes, and user intent.\n2. Choose Quick Path for ordinary commits or Full CM Path for governance\u002Frisky history work.\n3. Read commit and CM config before enforcing project-specific rules.\n\n### Scenes\n1. **PREPARE**: Determine operation type, risk, and affected files.\n2. **ACQUIRE**: Read status, diff, logs, config, ownership, and release context.\n3. **REASON**: Split changes, choose message\u002Fscope, identify CM controls and risks.\n4. **ACT**: Stage explicit paths, commit, branch, resolve, or provide CM action plan.\n5. **VERIFY**: Check status, staged diff, CI expectations, signatures, secrets, and audit evidence.\n6. **FINALIZE**: Report operation result and remaining SCM tasks.\n\n### Transitions\n- If user intent is commit-only, follow Quick Path and stop after safe commit.\n- If branching\u002Fhistory\u002Frelease\u002Fgovernance is involved, run Full CM Path.\n- If shared history rewrite is requested, require maintainer approval.\n- If changes span independent features, split commits unless user requests one commit.\n\n### Failure and recovery\n- If worktree is dirty in unrelated files, avoid touching unrelated changes.\n- If conflicts exist, resolve markers, test, and preserve target-branch context.\n- If secrets are detected or suspected, stop before staging\u002Fcommitting.\n\n### Exit\n- Success: requested SCM operation is complete or a safe, auditable plan is delivered.\n- Partial success: blockers such as conflicts, missing approval, CI, or secret risk are explicit.\n\n## Logical Operations\n\n### Actions\n| Action | SSL primitive | Evidence |\n|--------|---------------|----------|\n| Read Git state | `READ` | `git status`, diff, log, config |\n| Select SCM path | `SELECT` | Quick Path vs Full CM Path |\n| Compare change scopes | `COMPARE` | Split by type\u002Fscope\u002Ffeature |\n| Validate commit\u002Fgovernance rules | `VALIDATE` | Config and CM controls |\n| Stage explicit files | `CALL_TOOL` | `git add \u003Cspecific-files>` |\n| Commit or manage refs | `CALL_TOOL` | Git commit\u002Fbranch\u002Fmerge\u002Frebase\u002Ftag |\n| Write audit notes | `WRITE` | Commit message or CM report |\n| Report result | `NOTIFY` | Final SCM summary |\n\n### Tools and instruments\n- Git CLI and repository metadata\n- Commit\u002FCM config, Conventional Commit guide, CODEOWNERS playbook, onboarding-risk signals\n\n### Canonical command path\n```bash\ngit status -sb\ngit diff --staged\ngit log --oneline -5\n```\n\nStage and commit only explicit paths:\n```bash\ngit add \u003Cspecific-files>\ngit commit -m \"$(cat \u003C\u003C'EOF'\n\u003Ctype>(\u003Cscope>): \u003Cdescription>\n\n[optional body]\n\nCo-Authored-By: First Fluke \u003Cour.first.fluke@gmail.com>\nEOF\n)\"\n```\n\n### Resource scope\n| Scope | Resource target |\n|-------|-----------------|\n| `CODEBASE` | Tracked files, diffs, conflicts, CODEOWNERS |\n| `LOCAL_FS` | Git metadata, config files, commit message temp files |\n| `PROCESS` | Git commands and verification commands |\n| `CREDENTIALS` | Secret-sensitive files must not be staged or committed |\n\n### Preconditions\n- Repository and Git intent are identifiable.\n- User has authorized the requested SCM operation.\n\n### Effects and side effects\n- May stage files, create commits, branches, tags, worktrees, or history operations.\n- Can affect shared repository history if unsafe commands are used, so approvals matter.\n\n### Guardrails\n\n0. **Explicit user override (highest priority).** When the user gives an explicit, unambiguous instruction on how to perform a Git\u002FSCM operation, follow it exactly and do not argue, re-litigate, or block on the conditions below. This overrides every default and guardrail in this skill — including \"no direct push to `main`\u002Fprotected branches\", broad staging, the commit-split rules, single vs. multiple commits, message type\u002Fscope\u002Flength, and shared-history rewrite. State briefly what you are doing and proceed; do not ask for re-confirmation of an instruction the user already gave. Only confirm if the instruction is genuinely ambiguous (multiple plausible interpretations) — never as a way to push back on a clear directive.\n   - **Single hard exception:** likely-secret material (`.env`, keys, raw tokens). If the user's instruction would stage\u002Fcommit such material, surface it once before proceeding; everything else proceeds without challenge.\n1. Choose Quick Path for ordinary commits and Full CM Path for branching, history, release, or governance work.\n2. Read `.agents\u002Foma-config.yaml` before applying project-specific commit or CM rules.\n3. Stage only explicit files; never use broad staging unless the user explicitly approves it.\n4. Do not rewrite shared history without maintainer approval.\n5. Never stage or commit likely-secret material.\n6. **Response language follows `oma-config.yaml` `language`**: user-facing SCM output (status summaries, conflict explanations, CM audit notes, action plans) is localized. Per `i18n-guide.md`, commit messages, PR titles\u002Fbody, branch names, and status keywords stay in English regardless of the setting.\n\n### Configuration\n\n| File | Role |\n|------|------|\n| `.agents\u002Foma-config.yaml` | Conventional Commit types, branch prefixes, message rules, and CM pointers |\n\n### Operating mode (choose first)\n\n### Quick Path (commit-focused, default)\n\nUse this when the user intent is mainly \"commit this safely.\"\n\n1. Follow **Conventional Commits** section only\n2. Stage explicit files only\n3. Validate message type\u002Fscope\u002Flength from `commit-config.yaml`\n4. Stop after safe commit unless user asks CM\u002Fgovernance operations\n\n### Full CM Path (repo governance \u002F risky history operations)\n\nUse this when the user asks about branching strategy, merges, rebase\u002Fcherry-pick, worktrees, release refs, CODEOWNERS, or audit posture.\n\n1. Run CM workflows in order (Planning -> Identification -> Control -> Status accounting -> Verification)\n2. Add onboarding risk scan when inheriting or auditing a repository\n3. Include commit governance from Conventional Commits when creating commits\n4. For large-scope merge operations, use risk scoring and Ask Gate criteria from `..\u002F..\u002Fworkflows\u002Fscm.md`\n\n### CM process map (software)\n\n| CM function | Intent | Typical artefacts \u002F actions |\n|-------------|--------|------------------------------|\n| **Management & planning** | Agreed rules | `CONTRIBUTING.md`, `SECURITY.md`, `commit-config.yaml` |\n| **Configuration identification** | What is managed, naming | Branch\u002Ftag rules, version files, `.gitattributes`, LFS |\n| **Configuration control** | Reviewed change | PRs, checks, issue links, `BREAKING CHANGE` footers |\n| **Status accounting** | As-built truth | `main` \u002F release refs, `CHANGELOG`, tags, CI status |\n| **Verification & audit** | Evidence | CI logs, signed commits, lockfiles \u002F SBOM policy |\n\n### CM workflows (use before risky history operations)\n\n### 1) Planning\n\n1. Read `commit-config.yaml` and files listed under `documented_process`.\n2. If missing, infer from `CONTRIBUTING.md` \u002F `README`; state assumptions.\n3. Confirm **branching model** and whether **force-push** on shared branches is allowed (default: not without explicit approval).\n\n### 2) Identification\n\n1. Canonical refs: default branch, release branches\u002Ftags, version sources (`package.json`, etc.).\n2. `.gitattributes` \u002F LFS for binaries and generated assets.\n3. Branch names vs `commit-config.yaml` `branch_prefixes` when the project uses them.\n\n### 3) Control\n\n1. Small, reviewable units; align commits with PR \u002F issue intent.\n2. **Conflicts:** `merge-base`, `git status`, resolve markers, tests; suggest `rerere` when conflicts repeat.\n3. **Worktrees:** `git worktree add`; merge\u002Frebase from the **target branch’s** checkout; all worktrees share one object database.\n4. Do not rewrite **shared** history without maintainer approval; prefer `--force-with-lease` if force-push is unavoidable.\n\n### 4) Status accounting\n\n1. `git status -sb`: branch, remote tracking, ahead\u002Fbehind, merge state.\n2. Relate last tag \u002F release branch to `CHANGELOG` or tooling (semantic-release, release-please, changesets) if present.\n\n### 5) Verification & audit\n\n1. Required CI and `merge_group` when merge queue applies.\n2. Never stage\u002Fcommit secrets (`.env`, keys, raw tokens). Filename patterns from `commit-config.yaml` `forbidden_patterns` are enforced mechanically by the `scm-guard` PreToolUse hook; for content-level leaks (tokens hardcoded in ordinary source files), run a scanner when available (`gitleaks protect --staged`, `trufflehog git`) before large or unfamiliar commits.\n3. Call out signed-commit expectations when the org cares about verification badges.\n\n#### CODEOWNERS maintenance checklist\n\n1. Validate CODEOWNERS file exists (prefer `.github\u002FCODEOWNERS`).\n2. Ensure critical paths are explicitly owned (not only fallback `*`).\n3. Ensure owners are active and mapped to current teams.\n4. Confirm branch protection requires CODEOWNERS review where needed.\n5. Flag overlapping\u002Fambiguous rules that can hide intended owners.\n\nRead `change_governance.require_codeowners` and `ownership.*` in `commit-config.yaml` when present.\n\n### 6) Onboarding risk scan (optional, recommended)\n\nUse this quick scan when joining or inheriting a repository to identify risky areas before major changes.\n\n1. High churn files in `lookback` window.\n2. Ownership concentration \u002F bus-factor signals.\n3. Bug hotspot files from fix-related history.\n4. Velocity trend by month.\n5. Revert\u002Fhotfix\u002Femergency frequency.\n\nRead thresholds from `commit-config.yaml` `onboarding_metrics` when present and cite caveats:\n- squash merge teams can distort ownership metrics,\n- weak commit labeling reduces hotspot accuracy,\n- monorepo commit counts can bias subsystem interpretation.\n\n---\n\n### Conventional Commits\n\n### Commit types\n\n| Type | Description | Branch Prefix |\n|------|-------------|---------------|\n| feat | New feature | feature\u002F |\n| fix | Bug fix | fix\u002F |\n| refactor | Code improvement | refactor\u002F |\n| docs | Documentation changes | docs\u002F |\n| test | Test additions\u002Fmodifications | test\u002F |\n| chore | Build, configuration, etc. | chore\u002F |\n| style | Code style changes | style\u002F |\n| perf | Performance improvements | perf\u002F |\n| build | Build system \u002F external dependencies | build\u002F |\n| ci | CI configuration and scripts | ci\u002F |\n| revert | Revert a previous commit | (none) |\n\n### Commit format\n\n```\n\u003Ctype>(\u003Cscope>): \u003Cdescription>\n\n[optional body]\n\nCo-Authored-By: First Fluke \u003Cour.first.fluke@gmail.com>\n```\n\n### Commit workflow\n\n#### Step 1: Analyze changes\n\n```bash\ngit status\ngit diff --staged\ngit log --oneline -5\n```\n\n#### Step 1.5: Split by feature (if needed)\n\nIf changes span multiple features\u002Fdomains, **split commits by feature**.\n\n**Split when:** the changes are logically independent (different features, unrelated fixes).\n\n**Do not split when:** one logical change (even if it touches code + tests + docs together), or the user asked for a single commit.\n\n**Precedence for edge cases** (when both readings are defensible):\n1. Logical independence decides first — one logical change is one commit regardless of how many types\u002Fscopes it touches.\n2. File count is only a tiebreaker: ≤5 files lean single commit; >5 files spanning multiple scopes\u002Ftypes lean split.\n3. An explicit user instruction (single commit or split) overrides both.\n\n#### Step 2: Determine type\n\n- New capability → `feat` · Bug fix → `fix` · Structure-only → `refactor` · Docs only → `docs` · Tests → `test` · Build\u002Fconfig → `chore`\n\n#### Step 3: Scope\n\nUse module\u002Fcomponent: `feat(auth):`, `fix(api):`, or omit: `chore: update dependencies`\n\n#### Step 4: Description\n\n≤72 chars (per `commit-config.yaml`), imperative mood, lowercase start, no trailing period.\n\n#### Step 5: Execute commit\n\nShow the message, then commit with explicit paths:\n\n```bash\ngit add \u003Cspecific-files>\ngit commit -m \"$(cat \u003C\u003C'EOF'\n\u003Ctype>(\u003Cscope>): \u003Cdescription>\n\n[optional body]\n\nCo-Authored-By: First Fluke \u003Cour.first.fluke@gmail.com>\nEOF\n)\"\n```\n\nIf HEREDOC is unstable in your shell (or body is long), use file-based commit input:\n\n```bash\ngit add \u003Cspecific-files>\nmsgfile=\"$(mktemp)\"\ncat > \"$msgfile\" \u003C\u003C'EOF'\n\u003Ctype>(\u003Cscope>): \u003Cdescription>\n\n[optional body]\n\nCo-Authored-By: First Fluke \u003Cour.first.fluke@gmail.com>\nEOF\ngit commit -F \"$msgfile\"\nrm -f \"$msgfile\"\n```\n\nUse HEREDOC by default, and switch to `-F` for long or flaky terminal sessions.\n\n### Push and PR safety (only when requested)\n\nPush only when the user asks or a workflow requires it. Before pushing:\n\n1. `git status -sb` — confirm branch, remote tracking, ahead\u002Fbehind.\n2. Protected-branch check: if the target is the default\u002Fprotected branch and `commit-config.yaml` sets `require_pr_for_default_branch: true`, push a topic branch and open a PR (`gh pr create`) instead of pushing directly — unless the user explicitly instructed a direct push (Guardrail 0).\n3. Never plain `--force`; after an approved history rewrite use `git push --force-with-lease`.\n4. If push is rejected (non-fast-forward), fetch and rebase\u002Fmerge locally; do not retry with force.\n\n### Amend, fixup, autosquash\n\nFirst determine whether the target commits are shared:\n\n```bash\ngit status -sb                 # ahead\u002Fbehind vs upstream\ngit log --oneline @{u}..HEAD   # commits not yet pushed (errors when no upstream — treat all as unpushed)\n```\n\n- **Unpushed commits:** `git commit --amend`, `git commit --fixup \u003Csha>` + `git rebase -i --autosquash`, and interactive rebase are safe — proceed.\n- **Pushed\u002Fshared commits:** this is a shared-history rewrite — require maintainer approval (Guardrail 4) and use `--force-with-lease` when pushing the result.\n- Before `--amend`, check `git diff --staged`: the amend must not silently absorb unrelated staged changes.\n\n## References\n\n- `.agents\u002Foma-config.yaml`\n- `resources\u002Fconventional-commits.md`\n- `resources\u002Fonboarding-risk-signals.md`\n- `resources\u002Fcodeowners-playbook.md`\n- Observability handoff: `..\u002Foma-observability\u002FSKILL.md` §Integrations — release markers (`service.version`), revert baseline diff\n\n### Important notes\n\n- **Explicit user instruction wins.** A clear user directive on how to commit\u002Fpush\u002Fbranch overrides every rule below (and every other guardrail). Follow it without arguing; the only thing that still warrants a heads-up is likely-secret material.\n- **NEVER** `git add -A` or `git add .` without explicit user permission.\n- **NEVER** commit likely-secret material.\n- **ALWAYS** stage by explicit paths; tie non-trivial CM work to the five CM rows above, even briefly.\n","# Software configuration management: SCM (`oma-scm`)\n\n## Scheduling\n\n### Goal\nManage Git and software configuration management safely: commits, branches, merges, worktrees, releases, baselines, audit posture, CODEOWNERS, and Conventional Commits.\n\n### Intent signature\n- User asks to commit, stage, branch, merge, rebase, cherry-pick, tag, release, resolve conflicts, manage worktrees, inspect SCM posture, or apply Conventional Commits.\n- User needs safe Git operations with explicit file staging, secret awareness, and CM governance.\n\nThis skill is the **single** place for **configuration management (CM)** on a software repo and for **Conventional Commits** \u002F safe staging.\n\n### When to use\n\n- **Commits:** “commit this”, `\u002Fscm`, message type\u002Fscope, splitting staged changes into multiple commits.\n- **CM \u002F Git:** branching (gitflow, GitHub Flow, GitLab Flow, trunk-based), protected branches, merge queue, merge conflicts, rebase, cherry-pick, worktrees, submodules\u002Fsubtrees, tags and releases.\n- **Governance:** issue\u002FADR links, breaking-change footers, changelog or release-tool alignment.\n- **Audit posture:** signed commits, CI before merge, secret-sensitive paths.\n\n### When NOT to use\n\n- Implementing product or application code -> use the relevant domain skill\n- Debugging runtime failures without a Git or CM operation -> use `oma-debug`\n- Security, performance, or accessibility review -> use `oma-qa`\n- Planning feature requirements or decomposing work -> use `oma-pm`\n\n### Expected inputs\n- Git task, desired branch\u002Fcommit\u002Frelease operation, and affected files\n- Current worktree status, staged diff, branch tracking, config files, and governance constraints\n- Optional issue\u002FADR\u002FPR\u002Frelease context\n\n### Expected outputs\n- Safe commit, branch, merge\u002Frebase guidance, conflict plan, status accounting, or CM audit findings\n- Conventional Commit message and explicit staged paths when committing\n- Risk notes for shared history, secrets, CODEOWNERS, CI, and release evidence\n\n### Dependencies\n- Git CLI and repository metadata\n- `.agents\u002Foma-config.yaml`, Conventional Commit references, onboarding-risk and CODEOWNERS playbooks\n\n### Control-flow features\n- Branches by quick commit path versus full CM\u002Fgovernance path\n- Reads Git state and diffs; may write commits, branches, tags, or conflict resolutions\n- Requires explicit approval for broad staging, shared-history rewrite, production-destructive operations, or secret-risk paths\n\n## Structural Flow\n\n### Entry\n1. Inspect Git status, branch, staged\u002Funstaged changes, and user intent.\n2. Choose Quick Path for ordinary commits or Full CM Path for governance\u002Frisky history work.\n3. Read commit and CM config before enforcing project-specific rules.\n\n### Scenes\n1. **PREPARE**: Determine operation type, risk, and affected files.\n2. **ACQUIRE**: Read status, diff, logs, config, ownership, and release context.\n3. **REASON**: Split changes, choose message\u002Fscope, identify CM controls and risks.\n4. **ACT**: Stage explicit paths, commit, branch, resolve, or provide CM action plan.\n5. **VERIFY**: Check status, staged diff, CI expectations, signatures, secrets, and audit evidence.\n6. **FINALIZE**: Report operation result and remaining SCM tasks.\n\n### Transitions\n- If user intent is commit-only, follow Quick Path and stop after safe commit.\n- If branching\u002Fhistory\u002Frelease\u002Fgovernance is involved, run Full CM Path.\n- If shared history rewrite is requested, require maintainer approval.\n- If changes span independent features, split commits unless user requests one commit.\n\n### Failure and recovery\n- If worktree is dirty in unrelated files, avoid touching unrelated changes.\n- If conflicts exist, resolve markers, test, and preserve target-branch context.\n- If secrets are detected or suspected, stop before staging\u002Fcommitting.\n\n### Exit\n- Success: requested SCM operation is complete or a safe, auditable plan is delivered.\n- Partial success: blockers such as conflicts, missing approval, CI, or secret risk are explicit.\n\n## Logical Operations\n\n### Actions\n| Action | SSL primitive | Evidence |\n|--------|---------------|----------|\n| Read Git state | `READ` | `git status`, diff, log, config |\n| Select SCM path | `SELECT` | Quick Path vs Full CM Path |\n| Compare change scopes | `COMPARE` | Split by type\u002Fscope\u002Ffeature |\n| Validate commit\u002Fgovernance rules | `VALIDATE` | Config and CM controls |\n| Stage explicit files | `CALL_TOOL` | `git add \u003Cspecific-files>` |\n| Commit or manage refs | `CALL_TOOL` | Git commit\u002Fbranch\u002Fmerge\u002Frebase\u002Ftag |\n| Write audit notes | `WRITE` | Commit message or CM report |\n| Report result | `NOTIFY` | Final SCM summary |\n\n### Tools and instruments\n- Git CLI and repository metadata\n- Commit\u002FCM config, Conventional Commit guide, CODEOWNERS playbook, onboarding-risk signals\n\n### Canonical command path\n```bash\ngit status -sb\ngit diff --staged\ngit log --oneline -5\n```\n\nStage and commit only explicit paths:\n```bash\ngit add \u003Cspecific-files>\ngit commit -m \"$(cat \u003C\u003C'EOF'\n\u003Ctype>(\u003Cscope>): \u003Cdescription>\n\n[optional body]\n\nCo-Authored-By: First Fluke \u003Cour.first.fluke@gmail.com>\nEOF\n)\"\n```\n\n### Resource scope\n| Scope | Resource target |\n|-------|-----------------|\n| `CODEBASE` | Tracked files, diffs, conflicts, CODEOWNERS |\n| `LOCAL_FS` | Git metadata, config files, commit message temp files |\n| `PROCESS` | Git commands and verification commands |\n| `CREDENTIALS` | Secret-sensitive files must not be staged or committed |\n\n### Preconditions\n- Repository and Git intent are identifiable.\n- User has authorized the requested SCM operation.\n\n### Effects and side effects\n- May stage files, create commits, branches, tags, worktrees, or history operations.\n- Can affect shared repository history if unsafe commands are used, so approvals matter.\n\n### Guardrails\n\n0. **Explicit user override (highest priority).** When the user gives an explicit, unambiguous instruction on how to perform a Git\u002FSCM operation, follow it exactly and do not argue, re-litigate, or block on the conditions below. This overrides every default and guardrail in this skill — including \"no direct push to `main`\u002Fprotected branches\", broad staging, the commit-split rules, single vs. multiple commits, message type\u002Fscope\u002Flength, and shared-history rewrite. State briefly what you are doing and proceed; do not ask for re-confirmation of an instruction the user already gave. Only confirm if the instruction is genuinely ambiguous (multiple plausible interpretations) — never as a way to push back on a clear directive.\n   - **Single hard exception:** likely-secret material (`.env`, keys, raw tokens). If the user's instruction would stage\u002Fcommit such material, surface it once before proceeding; everything else proceeds without challenge.\n1. Choose Quick Path for ordinary commits and Full CM Path for branching, history, release, or governance work.\n2. Read `.agents\u002Foma-config.yaml` before applying project-specific commit or CM rules.\n3. Stage only explicit files; never use broad staging unless the user explicitly approves it.\n4. Do not rewrite shared history without maintainer approval.\n5. Never stage or commit likely-secret material.\n6. **Response language follows `oma-config.yaml` `language`**: user-facing SCM output (status summaries, conflict explanations, CM audit notes, action plans) is localized. Per `i18n-guide.md`, commit messages, PR titles\u002Fbody, branch names, and status keywords stay in English regardless of the setting.\n\n### Configuration\n\n| File | Role |\n|------|------|\n| `.agents\u002Foma-config.yaml` | Conventional Commit types, branch prefixes, message rules, and CM pointers |\n\n### Operating mode (choose first)\n\n### Quick Path (commit-focused, default)\n\nUse this when the user intent is mainly \"commit this safely.\"\n\n1. Follow **Conventional Commits** section only\n2. Stage explicit files only\n3. Validate message type\u002Fscope\u002Flength from `commit-config.yaml`\n4. Stop after safe commit unless user asks CM\u002Fgovernance operations\n\n### Full CM Path (repo governance \u002F risky history operations)\n\nUse this when the user asks about branching strategy, merges, rebase\u002Fcherry-pick, worktrees, release refs, CODEOWNERS, or audit posture.\n\n1. Run CM workflows in order (Planning -> Identification -> Control -> Status accounting -> Verification)\n2. Add onboarding risk scan when inheriting or auditing a repository\n3. Include commit governance from Conventional Commits when creating commits\n4. For large-scope merge operations, use risk scoring and Ask Gate criteria from `..\u002F..\u002Fworkflows\u002Fscm.md`\n\n### CM process map (software)\n\n| CM function | Intent | Typical artefacts \u002F actions |\n|-------------|--------|------------------------------|\n| **Management & planning** | Agreed rules | `CONTRIBUTING.md`, `SECURITY.md`, `commit-config.yaml` |\n| **Configuration identification** | What is managed, naming | Branch\u002Ftag rules, version files, `.gitattributes`, LFS |\n| **Configuration control** | Reviewed change | PRs, checks, issue links, `BREAKING CHANGE` footers |\n| **Status accounting** | As-built truth | `main` \u002F release refs, `CHANGELOG`, tags, CI status |\n| **Verification & audit** | Evidence | CI logs, signed commits, lockfiles \u002F SBOM policy |\n\n### CM workflows (use before risky history operations)\n\n### 1) Planning\n\n1. Read `commit-config.yaml` and files listed under `documented_process`.\n2. If missing, infer from `CONTRIBUTING.md` \u002F `README`; state assumptions.\n3. Confirm **branching model** and whether **force-push** on shared branches is allowed (default: not without explicit approval).\n\n### 2) Identification\n\n1. Canonical refs: default branch, release branches\u002Ftags, version sources (`package.json`, etc.).\n2. `.gitattributes` \u002F LFS for binaries and generated assets.\n3. Branch names vs `commit-config.yaml` `branch_prefixes` when the project uses them.\n\n### 3) Control\n\n1. Small, reviewable units; align commits with PR \u002F issue intent.\n2. **Conflicts:** `merge-base`, `git status`, resolve markers, tests; suggest `rerere` when conflicts repeat.\n3. **Worktrees:** `git worktree add`; merge\u002Frebase from the **target branch’s** checkout; all worktrees share one object database.\n4. Do not rewrite **shared** history without maintainer approval; prefer `--force-with-lease` if force-push is unavoidable.\n\n### 4) Status accounting\n\n1. `git status -sb`: branch, remote tracking, ahead\u002Fbehind, merge state.\n2. Relate last tag \u002F release branch to `CHANGELOG` or tooling (semantic-release, release-please, changesets) if present.\n\n### 5) Verification & audit\n\n1. Required CI and `merge_group` when merge queue applies.\n2. Never stage\u002Fcommit secrets (`.env`, keys, raw tokens). Filename patterns from `commit-config.yaml` `forbidden_patterns` are enforced mechanically by the `scm-guard` PreToolUse hook; for content-level leaks (tokens hardcoded in ordinary source files), run a scanner when available (`gitleaks protect --staged`, `trufflehog git`) before large or unfamiliar commits.\n3. Call out signed-commit expectations when the org cares about verification badges.\n\n#### CODEOWNERS maintenance checklist\n\n1. Validate CODEOWNERS file exists (prefer `.github\u002FCODEOWNERS`).\n2. Ensure critical paths are explicitly owned (not only fallback `*`).\n3. Ensure owners are active and mapped to current teams.\n4. Confirm branch protection requires CODEOWNERS review where needed.\n5. Flag overlapping\u002Fambiguous rules that can hide intended owners.\n\nRead `change_governance.require_codeowners` and `ownership.*` in `commit-config.yaml` when present.\n\n### 6) Onboarding risk scan (optional, recommended)\n\nUse this quick scan when joining or inheriting a repository to identify risky areas before major changes.\n\n1. High churn files in `lookback` window.\n2. Ownership concentration \u002F bus-factor signals.\n3. Bug hotspot files from fix-related history.\n4. Velocity trend by month.\n5. Revert\u002Fhotfix\u002Femergency frequency.\n\nRead thresholds from `commit-config.yaml` `onboarding_metrics` when present and cite caveats:\n- squash merge teams can distort ownership metrics,\n- weak commit labeling reduces hotspot accuracy,\n- monorepo commit counts can bias subsystem interpretation.\n\n---\n\n### Conventional Commits\n\n### Commit types\n\n| Type | Description | Branch Prefix |\n|------|-------------|---------------|\n| feat | New feature | feature\u002F |\n| fix | Bug fix | fix\u002F |\n| refactor | Code improvement | refactor\u002F |\n| docs | Documentation changes | docs\u002F |\n| test | Test additions\u002Fmodifications | test\u002F |\n| chore | Build, configuration, etc. | chore\u002F |\n| style | Code style changes | style\u002F |\n| perf | Performance improvements | perf\u002F |\n| build | Build system \u002F external dependencies | build\u002F |\n| ci | CI configuration and scripts | ci\u002F |\n| revert | Revert a previous commit | (none) |\n\n### Commit format\n\n```\n\u003Ctype>(\u003Cscope>): \u003Cdescription>\n\n[optional body]\n\nCo-Authored-By: First Fluke \u003Cour.first.fluke@gmail.com>\n```\n\n### Commit workflow\n\n#### Step 1: Analyze changes\n\n```bash\ngit status\ngit diff --staged\ngit log --oneline -5\n```\n\n#### Step 1.5: Split by feature (if needed)\n\nIf changes span multiple features\u002Fdomains, **split commits by feature**.\n\n**Split when:** the changes are logically independent (different features, unrelated fixes).\n\n**Do not split when:** one logical change (even if it touches code + tests + docs together), or the user asked for a single commit.\n\n**Precedence for edge cases** (when both readings are defensible):\n1. Logical independence decides first — one logical change is one commit regardless of how many types\u002Fscopes it touches.\n2. File count is only a tiebreaker: ≤5 files lean single commit; >5 files spanning multiple scopes\u002Ftypes lean split.\n3. An explicit user instruction (single commit or split) overrides both.\n\n#### Step 2: Determine type\n\n- New capability → `feat` · Bug fix → `fix` · Structure-only → `refactor` · Docs only → `docs` · Tests → `test` · Build\u002Fconfig → `chore`\n\n#### Step 3: Scope\n\nUse module\u002Fcomponent: `feat(auth):`, `fix(api):`, or omit: `chore: update dependencies`\n\n#### Step 4: Description\n\n≤72 chars (per `commit-config.yaml`), imperative mood, lowercase start, no trailing period.\n\n#### Step 5: Execute commit\n\nShow the message, then commit with explicit paths:\n\n```bash\ngit add \u003Cspecific-files>\ngit commit -m \"$(cat \u003C\u003C'EOF'\n\u003Ctype>(\u003Cscope>): \u003Cdescription>\n\n[optional body]\n\nCo-Authored-By: First Fluke \u003Cour.first.fluke@gmail.com>\nEOF\n)\"\n```\n\nIf HEREDOC is unstable in your shell (or body is long), use file-based commit input:\n\n```bash\ngit add \u003Cspecific-files>\nmsgfile=\"$(mktemp)\"\ncat > \"$msgfile\" \u003C\u003C'EOF'\n\u003Ctype>(\u003Cscope>): \u003Cdescription>\n\n[optional body]\n\nCo-Authored-By: First Fluke \u003Cour.first.fluke@gmail.com>\nEOF\ngit commit -F \"$msgfile\"\nrm -f \"$msgfile\"\n```\n\nUse HEREDOC by default, and switch to `-F` for long or flaky terminal sessions.\n\n### Push and PR safety (only when requested)\n\nPush only when the user asks or a workflow requires it. Before pushing:\n\n1. `git status -sb` — confirm branch, remote tracking, ahead\u002Fbehind.\n2. Protected-branch check: if the target is the default\u002Fprotected branch and `commit-config.yaml` sets `require_pr_for_default_branch: true`, push a topic branch and open a PR (`gh pr create`) instead of pushing directly — unless the user explicitly instructed a direct push (Guardrail 0).\n3. Never plain `--force`; after an approved history rewrite use `git push --force-with-lease`.\n4. If push is rejected (non-fast-forward), fetch and rebase\u002Fmerge locally; do not retry with force.\n\n### Amend, fixup, autosquash\n\nFirst determine whether the target commits are shared:\n\n```bash\ngit status -sb                 # ahead\u002Fbehind vs upstream\ngit log --oneline @{u}..HEAD   # commits not yet pushed (errors when no upstream — treat all as unpushed)\n```\n\n- **Unpushed commits:** `git commit --amend`, `git commit --fixup \u003Csha>` + `git rebase -i --autosquash`, and interactive rebase are safe — proceed.\n- **Pushed\u002Fshared commits:** this is a shared-history rewrite — require maintainer approval (Guardrail 4) and use `--force-with-lease` when pushing the result.\n- Before `--amend`, check `git diff --staged`: the amend must not silently absorb unrelated staged changes.\n\n## References\n\n- `.agents\u002Foma-config.yaml`\n- `resources\u002Fconventional-commits.md`\n- `resources\u002Fonboarding-risk-signals.md`\n- `resources\u002Fcodeowners-playbook.md`\n- Observability handoff: `..\u002Foma-observability\u002FSKILL.md` §Integrations — release markers (`service.version`), revert baseline diff\n\n### Important notes\n\n- **Explicit user instruction wins.** A clear user directive on how to commit\u002Fpush\u002Fbranch overrides every rule below (and every other guardrail). Follow it without arguing; the only thing that still warrants a heads-up is likely-secret material.\n- **NEVER** `git add -A` or `git add .` without explicit user permission.\n- **NEVER** commit likely-secret material.\n- **ALWAYS** stage by explicit paths; tie non-trivial CM work to the five CM rows above, even briefly.\n",{"name":5,"description":7},"main","0debaec9469b8a9289d77b8ce5c3143c4a656b16",".agents\u002Fskills\u002Foma-scm",0,"https:\u002F\u002Fgithub.com\u002Fmrmarbury\u002FPalmSync4Mac","https:\u002F\u002Fgithub.com\u002Fmrmarbury","FreeBSD admin, Elixir & Erlang Dev, Rubyist, Skateboarder, Musician","2026-11-07 06:23:43",{"source":8,"skillName":5,"commands":38,"prompt":48,"zipAvailable":49},[39,42,45],{"tool":40,"command":41},"npx","npx skills add mrmarbury\u002FPalmSync4Mac --skill oma-scm",{"tool":43,"command":44},"bunx","bunx skills add mrmarbury\u002FPalmSync4Mac --skill oma-scm",{"tool":46,"command":47},"pnpm","pnpm dlx skills add mrmarbury\u002FPalmSync4Mac --skill oma-scm","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmrmarbury\u002FPalmSync4Mac\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Foma-scm\u002FSKILL.md",true,[51,56,62,66],{"path":52,"resourceType":52,"resourceTypeDesc":53,"sizeBytes":54,"sourceHtmlUrl":55},"LICENSE","许可证",1066,"https:\u002F\u002Fgithub.com\u002FTrollz1004\u002FANTIGRAVITY\u002Fblob\u002Fmain\u002Fhermes\u002Fdesign-ui\u002Fhumanizer\u002FLICENSE",{"path":57,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":60,"sourceHtmlUrl":61},"resources\u002Fcodeowners-playbook.md","REFERENCE","参考文档",1230,"https:\u002F\u002Fgithub.com\u002Fmrmarbury\u002FPalmSync4Mac\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Foma-scm\u002Fresources\u002Fcodeowners-playbook.md",{"path":63,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":64,"sourceHtmlUrl":65},"resources\u002Fconventional-commits.md",4206,"https:\u002F\u002Fgithub.com\u002Fmrmarbury\u002FPalmSync4Mac\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Foma-scm\u002Fresources\u002Fconventional-commits.md",{"path":67,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":68,"sourceHtmlUrl":69},"resources\u002Fonboarding-risk-signals.md",2067,"https:\u002F\u002Fgithub.com\u002Fmrmarbury\u002FPalmSync4Mac\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Foma-scm\u002Fresources\u002Fonboarding-risk-signals.md",[71,98,128,154,182,210],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":24},"01M6WJZMN4HV76T0Y2PYDAAD7Q","oma-translator","Context-aware translation that preserves tone, style, and natural word order. Use when translating UI strings, documentation, marketing copy, or any multilingual content. Infers register, domain, and style from the source text and surrounding codebase context.","https:\u002F\u002Fgithub.com\u002Fmrmarbury\u002FPalmSync4Mac\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Foma-translation\u002FSKILL.md",[],[78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97],"translator","oma translator","documentation","ui","marketing","Word","text","context","use","multilingual","translation","domain","tone","style","register","copy","strings","source","codebase","when",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":109,"publishedAt":24},"01M6WJZ5W60XSDDE72AW5E85GT","oma-skill-creator","Create or update OMA skills in the SSL-lite human-readable format. Use when adding a new `.agents\u002Fskills\u002F{skill-name}\u002FSKILL.md`, converting an existing skill to the standardized Scheduling \u002F Structural Flow \u002F Logical Operations \u002F References structure, or validating whether a skill has enough routing, execution, resource, and safety detail.","https:\u002F\u002Fgithub.com\u002Fmrmarbury\u002FPalmSync4Mac\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Foma-skill-creation\u002FSKILL.md",[104],{"categoryNo":105,"categoryName":106,"taxonomyType":107,"taxonomyTypeDesc":108},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[110,111,112,113,114,115,116,117,118,119,86,120,121,122,123,124,125,126,127,97],"skill creator","oma skill creator","creator","create","update","routing","ssl","flow","execution","Safety","scheduling","references","existing skill","structure","human","structural","detail","Existing",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":135,"publishedAt":24},"01M6WJYHKKTDG9RT9A6ZWCT29A","oma-orchestrator","Automated multi-agent orchestrator that spawns CLI subagents in parallel, coordinates via MCP Memory, and monitors progress. Use for orchestration, parallel execution, and automated multi-agent workflows.","https:\u002F\u002Fgithub.com\u002Fmrmarbury\u002FPalmSync4Mac\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Foma-orchestration\u002FSKILL.md",[134],{"categoryNo":105,"categoryName":106,"taxonomyType":107,"taxonomyTypeDesc":108},[136,137,138,139,140,141,142,118,143,144,145,86,146,147,148,149,150,151,152,153],"oma orchestrator","orchestrator","MCP","cli","memory","orchestration","workflows","multi-agent","parallel","subagents","agent orchestrator","parallel execution","coordinates","agent workflows","progress","via","multi","for",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":163,"publishedAt":24},"01M6WJXXDQ99RCQ3S4GW5D42Q4","oma-explainer","Turn a code change (diff, PR, branch, commit range) into a rich, self-contained interactive HTML explainer with Background \u002F Intuition \u002F Code \u002F Quiz sections. Use for explain, walkthrough, code-change explanation, diff\u002FPR\u002Fbranch explainer requests — 설명서, 해설, コード解説, 代码讲解. Produces a single offline-capable HTML file with diagrams, callouts, and an accessible quiz.","https:\u002F\u002Fgithub.com\u002Fmrmarbury\u002FPalmSync4Mac\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Foma-explanation\u002FSKILL.md",[160],{"categoryNo":161,"categoryName":162,"taxonomyType":107,"taxonomyTypeDesc":108},"01JBSEEDCAT000000000000009","前端开发",[164,165,166,167,168,169,170,171,172,173,174,86,175,176,177,178,179,153,180,181],"explainer","oma explainer","change","commit","pr","code","offline","file","walkthrough","branch","interactive","html","diff","diagrams","self","quiz","rich","single",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":191,"publishedAt":24},"01M6WJWQC0CTFQWQKQ2EZYXVGJ","oma-academic-writer","Academic writing specialist for publication-grade English prose. Drafts, revises, and audits essays, reports, analysis sections, executive summaries, conclusions, and literature reviews while enforcing sentence-structure variation, high-frequency academic verbs, calibrated hedging, and anti-AI stylistic compliance. USE for academic writing, essay polish, paragraph rewrite, prose revision against any rubric tier (HD\u002FD\u002FC, A\u002FB\u002FC, top-band\u002Fmid-band, etc.), anti-AI audit, reverse outlining, claim-evidence mapping, and rubric enforcement on assignments.","https:\u002F\u002Fgithub.com\u002Fmrmarbury\u002FPalmSync4Mac\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Foma-academic-writing\u002FSKILL.md",[188],{"categoryNo":189,"categoryName":190,"taxonomyType":107,"taxonomyTypeDesc":108},"01JBSEEDCAT000000000000018","写作与文案",[192,193,194,195,196,22,197,198,199,200,201,123,202,203,204,205,206,207,208,209],"oma academic writer","writer","Academic","academic writer","writing","analysis","polish","reports","ai audit","claim","Anti-AI","english","literature","essays","essay","reviews","drafts","top",{"skillNo":211,"name":212,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":215,"publishedAt":24},"01M6BYY6K38NQSE2BXHWM0ZGRC","work","https:\u002F\u002Fgithub.com\u002Fmrmarbury\u002FPalmSync4Mac\u002Fblob\u002Fmain\u002F.opencode\u002Fskills\u002Fwork\u002FSKILL.md",[],[212]]