chore(docs): format markdown

something changed

Author: khaneliman

CONTRIBUTING.md

@@ -57,16 +57,16 @@ provides guidelines for contributing to this Nix-based dotfiles configuration.
      signaling that the patch should be reviewed or removed.
 
 10. **External Code and Licensing**:
-   - Any code, configuration, documentation, script, asset, or other file
-     copied from an external/public repository must respect the upstream license.
-   - Include the upstream license file in-tree alongside the copied content
-     (typically `LICENSE`, `LICENSE.txt`, `COPYING`, `NOTICE`, etc.), unless
-     the original license is explicitly incompatible with this repository's
-     usage.
-   - If the upstream project requires attribution or additional notices, include
-     those notices as provided by the source alongside the copied files.
-   - Do not move or rename the original licensing files unless there is a clear
-     compatibility reason, and keep their contents unchanged.
+
+- Any code, configuration, documentation, script, asset, or other file copied
+  from an external/public repository must respect the upstream license.
+- Include the upstream license file in-tree alongside the copied content
+  (typically `LICENSE`, `LICENSE.txt`, `COPYING`, `NOTICE`, etc.), unless the
+  original license is explicitly incompatible with this repository's usage.
+- If the upstream project requires attribution or additional notices, include
+  those notices as provided by the source alongside the copied files.
+- Do not move or rename the original licensing files unless there is a clear
+  compatibility reason, and keep their contents unchanged.
 
 ### Module Organization
 

modules/common/ai-tools/base.md

@@ -20,8 +20,8 @@ easy to verify.
   the confusion, explain the tradeoff, and ask for resolution.
 - Push back when an approach has concrete downsides. Explain the risk, propose a
   simpler alternative, then accept the human's decision.
-- Prefer boring, direct solutions. Add abstractions only when they clearly reduce
-  real complexity.
+- Prefer boring, direct solutions. Add abstractions only when they clearly
+  reduce real complexity.
 - Keep scope tight. Do not clean up adjacent code, remove comments, refactor
   neighbors, or delete code you do not understand.
 - After refactors, identify newly unused code and ask before deleting it.

modules/common/ai-tools/skills/git-toolkit/SKILL.md

@@ -14,7 +14,8 @@ When invoked, route to one mode:
 1. **workflow** — branching strategy, conflict resolution, commit history, and
    basic Git operations.
 2. **commit-message** — conventional commit style, scope, and quality checks.
-3. **github-toolkit** — any GH PR review comments, check triage, or issue creation.
+3. **github-toolkit** — any GH PR review comments, check triage, or issue
+   creation.
 
 If intent is unclear, ask for the mode before applying changes.
 
@@ -23,25 +24,28 @@ If intent is unclear, ask for the mode before applying changes.
 Use for task planning, branch hygiene, rebase/merge decisions, conflict
 resolution, and `git` command guidance.
 
-- Check [git-reference.md](references/git-reference.md) for command/reference tables.
+- Check [git-reference.md](references/git-reference.md) for command/reference
+  tables.
 - Check [git-examples.md](references/git-examples.md) for workflow templates.
 
 ## 2) Commit Message Mode
 
 Use for commit message policy and drafting, including commit format choice and
 scope rules.
 
-- Check [commit-reference.md](references/commit-reference.md) for commit type tables
-  and rules.
-- Check [commit-examples.md](references/commit-examples.md) for good/bad examples.
+- Check [commit-reference.md](references/commit-reference.md) for commit type
+  tables and rules.
+- Check [commit-examples.md](references/commit-examples.md) for good/bad
+  examples.
 
 Core policy:
 
 - Match the repository history (`git log`) first.
 - Prefer imperative, short, scoped subjects.
 - Never emit literal `\n` escape sequences in commit message text.
   - Forbidden: `git commit -m "line1\nline2"`
-  - Correct pattern for multi-line bodies: repeat `-m` flags or use a heredoc/file input.
+  - Correct pattern for multi-line bodies: repeat `-m` flags or use a
+    heredoc/file input.
 
   ```bash
   # preferred
@@ -52,10 +56,12 @@ Commit strategy (must enforce):
 
 - Before committing, follow local history strategy first:
   - prefer `git commit --amend` for immediate HEAD corrections,
-  - prefer `fixup` + `--autosquash` for nearby regressions when history is local-only (unshared/unpushed).
-  - avoid adding tiny follow-up commits when a history edit is the better option.
-- If a change requires splitting, squashing, or reordering, state the target history
-  shape before running the command.
+  - prefer `fixup` + `--autosquash` for nearby regressions when history is
+    local-only (unshared/unpushed).
+  - avoid adding tiny follow-up commits when a history edit is the better
+    option.
+- If a change requires splitting, squashing, or reordering, state the target
+  history shape before running the command.
 
 ## 2a) Hunk-Level Git Strategy
 
@@ -66,7 +72,8 @@ Use `git-surgeon` for non-interactive, hunk-level git operations:
 - undoing or splitting commits by hunk IDs
 - reordering commits without broad interactive workflows
 
-Before using it, read [references/git-surgeon.md](references/git-surgeon.md) and follow its safety rules.
+Before using it, read [references/git-surgeon.md](references/git-surgeon.md) and
+follow its safety rules.
 
 ## 3) GitHub Extensions
 
@@ -82,12 +89,13 @@ This keeps Git logic and GitHub workflow logic separate.
 
 - For commands that touch shared history or remote state, call out destructive
   risk explicitly before running them.
-- If a recent commit introduced a breaking regression and the commit is local-only,
-  prefer `fixup` + `--autosquash` (via an interactive rebase) to fold the
-  correction into the originating commit, instead of stacking follow-up commits.
+- If a recent commit introduced a breaking regression and the commit is
+  local-only, prefer `fixup` + `--autosquash` (via an interactive rebase) to
+  fold the correction into the originating commit, instead of stacking follow-up
+  commits.
 - If the commit has been pushed/shared, avoid history rewrite; use conventional
   follow-up commits and/or coordinated PR update flow.
 - For multi-step changes, default to minimal safe steps and stop at user
   confirmation points.
-- Cross-skill references are intentionally non-duplicative: only `git` materials stay
-  in this toolkit.
+- Cross-skill references are intentionally non-duplicative: only `git` materials
+  stay in this toolkit.

modules/common/ai-tools/skills/git-toolkit/references/commit-reference.md

@@ -88,8 +88,8 @@ Use this when asked to group or create commits from an existing worktree.
 - Before committing, compare `git diff --cached` against the intended commit
   contents.
 
-For breaking regressions introduced in recent commits, use `fixup` + `autosquash`
-instead of tiny follow-up commits:
+For breaking regressions introduced in recent commits, use `fixup` +
+`autosquash` instead of tiny follow-up commits:
 
 - Commit the correction with `git commit --fixup=<bad-commit-sha>`.
 - Then run `git rebase -i --autosquash <parent-of-bad-commit>` and reorder if

modules/common/ai-tools/skills/git-toolkit/references/git-surgeon.md

@@ -126,16 +126,19 @@ git-surgeon split HEAD \
 2. Use `git-surgeon show <id>` to inspect a hunk (lines are numbered)
 3. Stage and commit in one step: `git-surgeon commit <id1> <id2> -m "message"`
 4. Or stage separately: `git-surgeon stage <id1> <id2>`, then `git commit`
-5. To commit only part of a hunk, use inline ranges: `git-surgeon commit <id>:5-30 -m "message"`
+5. To commit only part of a hunk, use inline ranges:
+   `git-surgeon commit <id>:5-30 -m "message"`
 
 ## Committing to another branch
 
 Use `commit-to` when working in a worktree and you need to commit changes to a
 branch checked out elsewhere (e.g., main):
 
 1. Run `git-surgeon hunks` to list hunks
-2. Commit to another branch: `git-surgeon commit-to main <id1> <id2> -m "message"`
-3. The hunks are applied to the target branch's tree and discarded from the working tree
+2. Commit to another branch:
+   `git-surgeon commit-to main <id1> <id2> -m "message"`
+3. The hunks are applied to the target branch's tree and discarded from the
+   working tree
 4. Fails if the patch cannot be applied cleanly to the target branch
 
 ## Folding fix commits into earlier commits
@@ -145,8 +148,10 @@ HEAD) are removed from history and their changes merge into the target.
 Intermediate commits stay untouched. Dirty working tree is autostashed.
 
 - `git-surgeon fixup <target>` -- fold HEAD into target (most common)
-- `git-surgeon fixup <target> --from <commit>` -- fold a specific non-HEAD commit
-- `git-surgeon fixup <target> --from <c1> <c2> <c3>` -- fold multiple commits in one pass
+- `git-surgeon fixup <target> --from <commit>` -- fold a specific non-HEAD
+  commit
+- `git-surgeon fixup <target> --from <c1> <c2> <c3>` -- fold multiple commits in
+  one pass
 - Fails if the range contains merge commits
 
 ### Using --blame to find the fixup target
@@ -158,6 +163,7 @@ git-surgeon hunks --blame
 ```
 
 Output shows commit hashes for each line:
+
 ```
 a1b2c3d src/auth.rs (+2 -0)
   8922b52  fn login(user: &str) {
@@ -189,12 +195,15 @@ Squash collapses ALL commits from the target through HEAD into a single commit.
 Every intermediate commit in the range is merged. To fold one commit into a
 non-adjacent earlier commit without collapsing the range, use `fixup` instead.
 
-1. Squash commits from a target commit through HEAD: `git-surgeon squash HEAD~2 -m "combined"`
-2. Use multiple `-m` flags for subject + body: `git-surgeon squash HEAD~1 -m "Subject" -m "Body paragraph"`
+1. Squash commits from a target commit through HEAD:
+   `git-surgeon squash HEAD~2 -m "combined"`
+2. Use multiple `-m` flags for subject + body:
+   `git-surgeon squash HEAD~1 -m "Subject" -m "Body paragraph"`
 3. Target commit must be an ancestor of HEAD
 4. Use `--force` to squash ranges containing merge commits
 5. Uncommitted changes are autostashed and restored
-6. Author from the oldest commit is preserved by default; use `--no-preserve-author` for current user
+6. Author from the oldest commit is preserved by default; use
+   `--no-preserve-author` for current user
 
 ## Undoing changes from commits
 
@@ -206,9 +215,12 @@ non-adjacent earlier commit without collapsing the range, use `fixup` instead.
 ## Splitting commits
 
 1. List hunks in the commit: `git-surgeon hunks --commit <sha>`
-   - For small commits, use `--full` to see all lines with line numbers in one call
-2. Split by picking hunks: `git-surgeon split <sha> --pick <id1> -m "first" --rest-message "second"`
-3. Use multiple `-m` flags for subject + body: `--pick <id> -m "Subject" -m "Body paragraph"`
+   - For small commits, use `--full` to see all lines with line numbers in one
+     call
+2. Split by picking hunks:
+   `git-surgeon split <sha> --pick <id1> -m "first" --rest-message "second"`
+3. Use multiple `-m` flags for subject + body:
+   `--pick <id> -m "Subject" -m "Body paragraph"`
 4. Use `id:range` syntax for partial hunks: `--pick <id>:5-20`
    - For non-contiguous lines, use commas: `--pick <id>:2-6,34-37`
 5. Works on HEAD (direct reset) or earlier commits (via rebase)

modules/common/ai-tools/skills/github-toolkit/SKILL.md

@@ -13,24 +13,25 @@ When invoked, choose one mode:
 
 1. **issue-creation** — convert messy inputs into a structured GitHub issue
    markdown file.
-2. **issue-triage** — find, filter, and summarize GitHub issues for selection
-   or contribution.
-3. **pr-review** — collect, prioritize, and address review comments on the PR for
-   the current branch.
+2. **issue-triage** — find, filter, and summarize GitHub issues for selection or
+   contribution.
+3. **pr-review** — collect, prioritize, and address review comments on the PR
+   for the current branch.
 4. **ci-fix** — inspect failing PR checks and summarize actionable fix context.
 
 If intent is unclear, ask for the mode before acting.
 
 ## 1) Issue Creation Mode
 
-Use when the user provides raw notes, logs, dictation, or screenshots and wants a
-ready-to-file GitHub issue.
+Use when the user provides raw notes, logs, dictation, or screenshots and wants
+a ready-to-file GitHub issue.
 
 - Follow the issue template below.
 - Keep every section concise and action-oriented.
-- Save output to `/issues/` as `YYYY-MM-DD-short-description.md` unless the
-  user requests another destination.
-- Match acceptance criteria in [acceptance-criteria.md](references/acceptance-criteria.md).
+- Save output to `/issues/` as `YYYY-MM-DD-short-description.md` unless the user
+  requests another destination.
+- Match acceptance criteria in
+  [acceptance-criteria.md](references/acceptance-criteria.md).
 
 ### Issue Template
 
@@ -56,9 +57,11 @@ ready-to-file GitHub issue.
 `[error text / logs if present]`
 
 ## Visual Evidence
+
 [attachment references]
 
 ## Impact
+
 [Critical/High/Medium/Low + short rationale]
 
 ## Additional Context
@@ -124,7 +127,8 @@ If no issues are found and commenting is requested, post:
 ```markdown
 ## Code review
 
-No issues found. Checked for bugs and repository instruction/contribution compliance.
+No issues found. Checked for bugs and repository instruction/contribution
+compliance.
 ```
 
 ## 4) CI Fix Mode
@@ -155,5 +159,5 @@ If `gh pr checks` field shape changes, rerun with reported accepted fields.
 - Prefer minimal, safe edits first.
 - Ask for explicit approval before touching files from issue summaries or CI
   recommendations.
-- For destructive git operations (hard reset, force push, branch deletion), call out
-  risk before running them.
+- For destructive git operations (hard reset, force push, branch deletion), call
+  out risk before running them.

modules/common/ai-tools/skills/github-toolkit/references/acceptance-criteria.md

@@ -1,8 +1,8 @@
 # GitHub Issue Creator Acceptance Criteria
 
-**Skill**: `github-toolkit` **Purpose**: Transform raw notes, error logs,
-voice dictation, or screenshots into structured GitHub issues **Focus**: Issue
-format, structured sections, appropriate severity classification
+**Skill**: `github-toolkit` **Purpose**: Transform raw notes, error logs, voice
+dictation, or screenshots into structured GitHub issues **Focus**: Issue format,
+structured sections, appropriate severity classification
 
 ---
 

modules/common/ai-tools/skills/jj-toolkit/SKILL.md

@@ -21,4 +21,5 @@ That file includes:
 - revset and workspace reference tables
 
 Keep MIT license attribution in-tree with:
+
 - [references/LICENSE-jj-hunk-tool](references/LICENSE-jj-hunk-tool)

modules/common/ai-tools/skills/jj-toolkit/references/conflict-resolution.md

@@ -9,6 +9,7 @@ log it, diff it, and even rebase it further. But the working copy will contain
 conflict markers and the code won't compile until resolved.
 
 Common triggers:
+
 - `jj edit <rev>` then modifying code → descendants that touched the same code
   get conflicts on rebase
 - `jj squash --from A --into B` where descendants of B overlap with A's changes
@@ -26,6 +27,7 @@ jj resolve --list -r <rev>          # list conflicted files in specific revision
 ```
 
 When you `jj edit` a conflicted commit, the warning is printed immediately:
+
 ```
 Warning: There are unresolved conflicts at these paths:
 src/main.rs    2-sided conflict
@@ -115,6 +117,7 @@ Use when one side is clearly correct and the other should be discarded.
 ### Strategy 3: Re-apply your changes
 
 If the conflict is from your own edits to an ancestor:
+
 1. Note what you changed (the diff in the `%%%%%%%` section)
 2. Take the `+++++++` side (the descendant's content)
 3. Re-apply your changes on top of it
@@ -163,5 +166,5 @@ untangle.
   all are resolved, the commit drops its "(conflict)" marker automatically.
 
 - **If resolution goes wrong**, `jj undo` reverts your last operation.
-  Alternatively, the conflict markers are still valid data — you can re-read
-  and try again.
+  Alternatively, the conflict markers are still valid data — you can re-read and
+  try again.

modules/common/ai-tools/skills/jj-toolkit/references/git-interop.md

@@ -2,9 +2,9 @@
 
 ## Colocated repos
 
-When `.git/` is sibling of `.jj/`, the repo is "colocated". Git and jj share
-the same commits. Imports/exports happen automatically. You can use `git log`
-to see the same history, but always use `jj` commands to make changes.
+When `.git/` is sibling of `.jj/`, the repo is "colocated". Git and jj share the
+same commits. Imports/exports happen automatically. You can use `git log` to see
+the same history, but always use `jj` commands to make changes.
 
 ## Bookmarks