# Source Code Management

> Create, review, or revise tested repository commit messages and commit-message files. Use when summarizing a tested change for version control, selecting a subsystem indicator, validating the required subject and Before/After/Tests/More info structure, or creating a message file for a user-reviewed commit.

- Skill: `greenpau/source-code-management-2` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add greenpau/source-code-management-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/greenpau/source-code-management-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools, Security
- Author: greenpau (https://skillmd.com/u/greenpau)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/greenpau/source-code-management-2

---


# Source Code Management

## Inspect the intended change

Read `git status --short`, the staged diff, the unstaged diff, and relevant
untracked files before drafting a message. Inspect recent subjects when they
provide useful repository precedent. Base claims on the actual intended commit
scope and observed verification.

Do not stage, unstage, commit, amend, tag, or push unless the user explicitly
requests that separate action. A request for a commit message authorizes only
the message artifact.

## Write the required subject

Use this form:

```text
indicator: concise imperative outcome
```

Apply every subject rule:

- use exactly one lowercase indicator and no parenthesized scope;
- keep the complete line shorter than 87 characters;
- use imperative present tense;
- describe the resulting change rather than the work session;
- omit the trailing period;
- select the narrowest owner of the primary behavior.

## Select a tested indicator

Prefer a product-owner indicator:

- `app`: orchestration, run/report lifecycle, and exit precedence;
- `cli`: command grammar, flags, help, version, and Go-argument separation;
- `runner`: child execution, raw capture, cancellation, and process trees;
- `protocol`: bounded framing and `TestEvent`/`BuildEvent` decoding;
- `result`: occurrence aggregation, state, timing, and summaries;
- `coverage`: profile parsing, weighted totals, thresholds, and cover HTML;
- `report`: console, HTML, JSON, JUnit, index, escaping, and redaction;
- `artifact`: managed paths, permissions, atomic publication, and manifests.

Use a maintenance indicator when it is the honest center:

- `fix`: correct tested behavior without a known shipped regression;
- `breakfix`: repair a reported shipped regression, panic, or data-loss issue;
- `feat`: add user-visible capability with no narrower product owner;
- `tests`: primarily add or revise tests, fixtures, or golden evidence;
- `docs`: change user-facing documentation only;
- `skills`: change `AGENTS.md`, repo-local skills, or agent metadata;
- `refactor`: restructure implementation without intentional behavior change;
- `security`: harden execution, paths, permissions, redaction, or disclosure;
- `build`: change Make, compilation, packaging, or local build behavior;
- `github`: change GitHub Actions, templates, or repository GitHub metadata;
- `ops`: change dependencies, toolchain, versioning, release, or maintenance
  configuration;
- `various`: intentionally combine unrelated work that cannot be split.

If several indicators fit, choose the user-visible or architectural center.
Prefer splitting unrelated changes over `various` when the user controls scope.

## Write the required body

Include these sections in this exact order:

1. `Before this commit:`
2. `After this commit:`
3. `Tests:`
4. `More info:`

Separate sections with one blank line. End each label with a colon. Keep lines
at or below 87 characters except unavoidable links and detailed `More info`
content.

- Describe the previous observable behavior or repository state under
  `Before this commit`.
- Describe the resulting behavior, contract, or state under
  `After this commit`.
- Name exact commands and results under `Tests`.
- Write `Tests: not run — <reason>` when verification did not run.
- Summarize important design decisions, compatibility, security, generated
  outputs, and caveats under `More info`.
- Never claim a command passed unless its result was observed or supplied by
  the user.

After the required sections, add only applicable optional sections in this
order:

1. `Resolves:` for issues completely resolved;
2. `Partial Resolution:` for issues partly addressed;
3. `See also:` for related references;
4. `Links:` for a bulleted reference list.

Use valid links in the first three optional sections and separate multiple
links with comma and space.

## Template

```text
indicator: concise imperative outcome

Before this commit: describe the previous behavior, limitation, or state.

After this commit: describe the resulting behavior, implementation, or state.

Tests: name each command and result, or say not run and why.

More info: summarize implementation decisions and material caveats.
```

## Apply tested-specific evidence

- Mention authoritative child-status preservation when execution or exit policy
  changes.
- Mention raw-before-parse evidence and secure modes when runner or artifact
  behavior changes.
- Mention weighted statements rather than a rounded percentage when coverage
  calculation changes.
- Mention exact compatibility artifacts when report or publication behavior
  changes.
- Mention bounded framing, explicit incomplete results, redaction, atomic
  publication, or determinism only when the diff actually implements or tests
  those claims.
- Describe a proposed Make, CI, or release workflow as intended rather than
  present when its files are not in the intended commit.

## Create a commit-message file

When asked to create a commit message for the change, write it below
`tmp/commits` with a `YYYYMMDD_HHMM_` prefix and a concise slug. Treat that file
as an uncommitted working artifact unless the user says otherwise.

After writing it, provide the copy-paste command:

```text
git commit -F tmp/commits/YYYYMMDD_HHMM_<short-slug>.txt
```

Re-read the file, check line lengths and required section order, and tell the
user which staged or unstaged scope it describes. Do not modify the index.