From b992a6376832e7c2de6af861b61c9c16e392dd28 Mon Sep 17 00:00:00 2001
From: Amolith <amolith@secluded.site>
Date: Mon, 25 May 2026 15:44:50 -0600
Subject: [PATCH] format

---
 skills/authoring-skills/SKILL.md              |  4 +-
 skills/backing-up-with-keld/SKILL.md          | 10 +--
 skills/frontend-accessibility/SKILL.md        | 72 ++++++++++++-------
 skills/handling-customer-data/SKILL.md        |  8 +++
 skills/humanize/SKILL.md                      | 39 +++++++---
 skills/rebasing-with-git/SKILL.md             |  7 ++
 skills/scripting-with-go/SKILL.md             |  3 +
 .../updating-llm-client-model-lists/SKILL.md  | 16 ++---
 skills/writing-git-tags/SKILL.md              | 32 +++++----
 skills/writing-rust/SKILL.md                  | 20 +++---
 10 files changed, 137 insertions(+), 74 deletions(-)

diff --git a/skills/authoring-skills/SKILL.md b/skills/authoring-skills/SKILL.md
index bd8aca298873458f00b397c6c367889a9316d49a..c878549d4f149393f0e40f301eef37d8d2d3429c 100644
--- a/skills/authoring-skills/SKILL.md
+++ b/skills/authoring-skills/SKILL.md
@@ -49,7 +49,7 @@ description: Extracts text and tables from PDF files. Use when working with PDFs
 - Include trigger keywords for discovery
 - No markdown formatting
 
-The description is the primary trigger mechanism. The body only loads *after* activation, so "When to Use" sections in the body don't help agents discover the skill.
+The description is the primary trigger mechanism. The body only loads _after_ activation, so "When to Use" sections in the body don't help agents discover the skill.
 
 Agents tend to undertrigger — they won't load a skill unless the description clearly matches the user's request. Be generous with trigger contexts. Include the obvious keywords, but also phrases the user might use when they need the skill without naming it directly. A description that triggers a few times when it isn't needed costs less than one that misses the cases where it would help.
 
@@ -98,9 +98,11 @@ These add clutter without helping agents perform tasks.
 
 ```markdown
 # Quick start
+
 [Essential instructions here]
 
 ## Advanced features
+
 **Form filling**: See [FORMS.md](references/FORMS.md)
 **API reference**: See [REFERENCE.md](references/REFERENCE.md)
 ```
diff --git a/skills/backing-up-with-keld/SKILL.md b/skills/backing-up-with-keld/SKILL.md
index 813f8d5e25e6b0ebc35c331aba34bf76a0418245..57711e63774e743fe7fc805336ec3f890e4343e6 100644
--- a/skills/backing-up-with-keld/SKILL.md
+++ b/skills/backing-up-with-keld/SKILL.md
@@ -65,12 +65,12 @@ This lets you mix and match: `home@cloud`, `home@nas`, `media@cloud` all reuse t
 
 ### Special keys
 
-| Key          | Purpose                                                            |
-| ------------ | ------------------------------------------------------------------ |
+| Key          | Purpose                                                                     |
+| ------------ | --------------------------------------------------------------------------- |
 | `_arguments` | Positional args for restic (prefer arrays; string form is whitespace-split) |
-| `_workdir`   | Directory to chdir before exec                                     |
-| `_command`   | Restic subcommand (allows aliasing)                                |
-| `*.environ`  | Section suffix for environment variables                           |
+| `_workdir`   | Directory to chdir before exec                                              |
+| `_command`   | Restic subcommand (allows aliasing)                                         |
+| `*.environ`  | Section suffix for environment variables                                    |
 
 ### Interpolation
 
diff --git a/skills/frontend-accessibility/SKILL.md b/skills/frontend-accessibility/SKILL.md
index 8e6711a35ab03f85ee322ba063941f952fb488e8..04e62bc0f77a9101c9d8c031c57ffde10cb1f7d8 100644
--- a/skills/frontend-accessibility/SKILL.md
+++ b/skills/frontend-accessibility/SKILL.md
@@ -14,23 +14,28 @@ Write accessible frontend code by default. Semantic HTML covers most needs; ARIA
 1. **Semantic HTML first**: Use `<button>`, `<nav>`, `<main>`, `<form>` - not divs with roles
 2. **Keyboard accessible**: Everything clickable must be focusable and operable with Enter/Space
 3. **Screen reader context**: Labels, alt text, and heading hierarchy convey structure without vision
-4. **No ARIA is better than bad ARIA**: ARIA overrides native semantics and can make things *worse*
+4. **No ARIA is better than bad ARIA**: ARIA overrides native semantics and can make things _worse_
 
 ## Quick reference
 
 ### Images
+
 ```html
 <!-- Informative: describe content -->
-<img src="chart.png" alt="Sales increased 25% from Q1 to Q2">
+<img src="chart.png" alt="Sales increased 25% from Q1 to Q2" />
 
 <!-- Decorative: empty alt -->
-<img src="divider.png" alt="">
+<img src="divider.png" alt="" />
 
 <!-- Complex: summarize + link to details -->
-<img src="flowchart.png" alt="User registration flow. Details in following section.">
+<img
+	src="flowchart.png"
+	alt="User registration flow. Details in following section."
+/>
 ```
 
 ### Interactive elements
+
 ```html
 <!-- Correct: semantic button -->
 <button onclick="save()">Save</button>
@@ -38,26 +43,40 @@ Write accessible frontend code by default. Semantic HTML covers most needs; ARIA
 <!-- Wrong: div cosplaying as button -->
 <div onclick="save()" role="button" tabindex="0">Save</div>
 ```
+
 The div requires `role`, `tabindex`, `onkeydown` for Enter/Space, focus styles, and still won't work with voice control. Use `<button>`.
 
 ### Forms
+
 ```html
 <label for="email">Email address</label>
-<input type="email" id="email" name="email" required aria-describedby="email-hint">
+<input
+	type="email"
+	id="email"
+	name="email"
+	required
+	aria-describedby="email-hint"
+/>
 <span id="email-hint">We'll never share your email</span>
 ```
+
 Every input needs a visible `<label>` with matching `for`/`id`. Use `aria-describedby` for hints, `aria-invalid` for errors.
 
 ### Headings
+
 ```html
-<h1>Page title</h1>           <!-- One per page -->
-  <h2>Section</h2>            <!-- Don't skip levels -->
-    <h3>Subsection</h3>
-  <h2>Another section</h2>
+<!-- One per page -->
+<h1>Page title</h1>
+<!-- Don't skip levels -->
+<h2>Section</h2>
+<h3>Subsection</h3>
+<h2>Another section</h2>
 ```
+
 Headings create navigable structure. Screen reader users jump by heading level.
 
 ### Links
+
 ```html
 <!-- Good: describes destination -->
 <a href="/pricing">View pricing plans</a>
@@ -70,14 +89,14 @@ Headings create navigable structure. Screen reader users jump by heading level.
 
 Use ARIA only when HTML has no semantic equivalent:
 
-| Need | Solution |
-|------|----------|
-| Button | `<button>` not `role="button"` |
-| Navigation | `<nav>` not `role="navigation"` |
-| Live updates | `aria-live="polite"` (no HTML equivalent) |
-| Current page | `aria-current="page"` (no HTML equivalent) |
+| Need           | Solution                                    |
+| -------------- | ------------------------------------------- |
+| Button         | `<button>` not `role="button"`              |
+| Navigation     | `<nav>` not `role="navigation"`             |
+| Live updates   | `aria-live="polite"` (no HTML equivalent)   |
+| Current page   | `aria-current="page"` (no HTML equivalent)  |
 | Expanded state | `aria-expanded="true"` (no HTML equivalent) |
-| Custom widget | ARIA + keyboard handling (last resort) |
+| Custom widget  | ARIA + keyboard handling (last resort)      |
 
 ## Common violations to avoid
 
@@ -98,29 +117,30 @@ Respect user preferences for reduced motion:
 ```css
 /* Default: full animation */
 .animated {
-  transition: transform 0.3s ease;
+	transition: transform 0.3s ease;
 }
 
 /* Reduce or remove for users who prefer it */
 @media (prefers-reduced-motion: reduce) {
-  .animated {
-    transition: none;
-  }
+	.animated {
+		transition: none;
+	}
 }
 ```
 
 Or start safe and enhance:
+
 ```css
 /* Safe default */
 .animated {
-  transition: none;
+	transition: none;
 }
 
 /* Only animate if user hasn't requested reduced motion */
 @media (prefers-reduced-motion: no-preference) {
-  .animated {
-    transition: transform 0.3s ease;
-  }
+	.animated {
+		transition: transform 0.3s ease;
+	}
 }
 ```
 
@@ -129,17 +149,20 @@ Applies to: transitions, transforms, parallax, auto-playing video, animated illu
 ## Framework-specific notes
 
 ### React/JSX
+
 - `htmlFor` instead of `for`
 - `className` instead of `class`
 - Fragments (`<>`) don't affect accessibility tree
 - Manage focus with refs when content changes dynamically
 
 ### Component libraries
+
 If using Radix, Headless UI, or similar - they handle ARIA. Don't add redundant attributes.
 
 ## Validation
 
 Generated code should pass:
+
 - **axe-core**: Catches ~57% of WCAG issues automatically
 - **Manual keyboard test**: Tab through everything, operate with Enter/Space
 - **Screen reader spot check**: VoiceOver (Mac), NVDA (Windows), Orca (Linux)
@@ -149,6 +172,7 @@ Automated tools miss context-dependent issues (alt text quality, heading hierarc
 ## Detailed patterns
 
 See [patterns.md](references/patterns.md) for:
+
 - Modal dialogs and focus management
 - Custom select/combobox
 - Tabs and tab panels
diff --git a/skills/handling-customer-data/SKILL.md b/skills/handling-customer-data/SKILL.md
index 0e6023126897d94e9fff507603f0068362edc0db..e8d0aebfe941c45cfc953c5a0897d7edae384ca4 100644
--- a/skills/handling-customer-data/SKILL.md
+++ b/skills/handling-customer-data/SKILL.md
@@ -84,31 +84,39 @@ grep "error" /var/log/app.log  # if log contains customer data
 **User**: "Are there any uppercase JIDs in Redis?"
 
 **Good**:
+
 ```bash
 redis-cli KEYS "jmp_customer_id-*" | grep -qE "[A-Z]" && echo TRUE || echo FALSE
 ```
+
 Response: "TRUE - there are uppercase characters in some JID keys."
 
 **User**: "How many?"
 
 **Good**:
+
 ```bash
 redis-cli KEYS "jmp_customer_id-*" | grep -cE "[A-Z]"
 ```
+
 Response: "52 keys contain uppercase characters."
 
 **User**: "Which ones?"
 
 **Good**:
+
 ```bash
 redis-cli KEYS "jmp_customer_id-*" | grep -E "[A-Z]" > uppercase_jids.txt
 ```
+
 Response: "Saved to `uppercase_jids.txt`. You can review the file directly."
 
 **Bad** (never do this):
+
 ```bash
 redis-cli KEYS "jmp_customer_id-*" | grep -E "[A-Z]"
 ```
+
 This would print customer JIDs into the response.
 
 ## When in doubt
diff --git a/skills/humanize/SKILL.md b/skills/humanize/SKILL.md
index a06d6a4e92a3bca54bc53549d21d829299bb4795..11add34d06cd73fbf5e73e182fa70a0a76d1a2cf 100644
--- a/skills/humanize/SKILL.md
+++ b/skills/humanize/SKILL.md
@@ -9,13 +9,14 @@ metadata:
 
 # Humanizing Text: Quick Start
 
-The goal is not to make text "worse" but to make it *believably human*. Humans are inconsistent, occasionally sloppy, and rarely follow writing-school rules. LLMs are the opposite. Invert LLM defaults.
+The goal is not to make text "worse" but to make it _believably human_. Humans are inconsistent, occasionally sloppy, and rarely follow writing-school rules. LLMs are the opposite. Invert LLM defaults.
 
 ## Step 1: Strip the AI polish
 
 Remove or replace these dead giveaways before anything else:
 
 **Overwrought significance phrases:**
+
 - "stands as a testament to" → "is" or "shows" or just delete
 - "a pivotal moment in" → "when" or "this was"
 - "marking a shift toward" → "then" or "after that"
@@ -24,12 +25,14 @@ Remove or replace these dead giveaways before anything else:
 - "in the broader landscape of" → delete
 
 **Canned analysis phrases:**
+
 - "highlighting..." / "emphasizing..." / "underscoring..." (as sentence-ending participles) → delete or recast as a standalone sentence
 - "reflecting broader trends in" → delete
 - "contributing to the ongoing dialogue" → delete
 - "valuable insights into" → "ideas about" or delete
 
 **Promotional fluff:**
+
 - "boasts a vibrant" → "has"
 - "nestled in the heart of" → "in"
 - "rich tapestry of" → delete, describe the thing directly
@@ -37,11 +40,13 @@ Remove or replace these dead giveaways before anything else:
 - "renowned" → "known for [specific thing]" or just name-drop
 
 **Media-coverage chest-beating:**
+
 - "has been featured in" / "profiled in" → "was covered in" or just name the publication inline
 - "independent coverage in notable outlets" → name the outlets or skip
 - "maintains an active social media presence" → "posts on X" or delete
 
 **Avoidance of simple verbs:**
+
 - "serves as" → "is"
 - "stands as" → "is"
 - "marks a" → "is"
@@ -50,22 +55,27 @@ Remove or replace these dead giveaways before anything else:
 - "features a diverse array of" → "has"
 
 **Negative parallelisms / unearned grandiosity:**
+
 - "not just X, but also Y" → "X and Y" or say what you mean directly
 - "It is not ..., it is ..." → one direct clause
 - "no ..., no ..., just ..." → one direct clause
 - "More than just [category]" → describe the thing directly without the elevation pitch
 
 **Rule-of-three lists:**
+
 - "adjective, adjective, and adjective" → trim to one or two, or vary the structure
 - "short phrase, short phrase, and short phrase" → break the rhythm: make one longer, merge two, drop one
 
 **AI vocabulary (high-density red flags):**
+
 - Delete or replace: additionally, delve, crucial, pivotal, robust, intricate, interplay, tapestry, testament, underscore, vibrant, meticulous, fostering, enhancing, enduring, bolster, garner, align with, resonate with, exemplify, showcase
 
 **Em dashes:**
+
 - Replace with commas, parentheses, or just separate sentences. If you keep them, use `--` (two hyphens) instead of `—`, and use them sparingly.
 
 **Bulky structure:**
+
 - Kill rigid "Challenges and Future Directions" / "Future Outlook" sections unless the user explicitly asked for them
 - Kill the formulaic "Despite [positive], [subject] faces challenges..." paragraph structure
 - Kill the "In conclusion" / "In summary" wrapper
@@ -73,15 +83,17 @@ Remove or replace these dead giveaways before anything else:
 
 ## Step 2: Add human irregularities
 
-Vary technique by desired register. Use *lightly* — one or two touches per paragraph, not every sentence.
+Vary technique by desired register. Use _lightly_ — one or two touches per paragraph, not every sentence.
 
 ### Sentence rhythm
+
 - **Vary sentence length dramatically.** Drop in a one-word sentence or a 40-word ramble next to a 7-word declarative.
 - **Start sentences with "And" or "But"** occasionally.
 - **Use sentence fragments.** "Anyway." "Not really." "The usual."
 - **Break a long sentence with an aside** that could have been a footnote: "the thing — and this was back in 2019, before everything changed — happened."
 
 ### Informal punctuation
+
 - Replace some em dashes with double hyphens `--`
 - Use en-dashes where a human might (sloppily) use hyphens
 - Let a comma splice slip through if the tone is casual enough
@@ -90,17 +102,20 @@ Vary technique by desired register. Use *lightly* — one or two touches per par
 - End an occasional sentence with a preposition if that's how people actually talk
 
 ### Contractions and compression
+
 - Expand contractions for formality. Contract them for informality. Most AI output under-uses contractions.
 - Use "can't," "won't," "it's," "that's," "there's" in casual text.
 - Drop auxiliary verbs in casual speech patterns: "Guess so," "Makes sense."
 
 ### Imperfections
+
 - **Occasional typos or misspellings** in very informal contexts (not for anything important): "recieve," "definately," "seperate" — no more than one per few hundred words
 - **Minor grammar slips** that don't impede readability: "me and Jake went," "should of," "less people" — only when the register is extremely casual
 - **Inconsistent capitalization** of words-for-emphasis in informal writing: "it was Bad"
 - **Elision:** "wanna," "gonna," "kinda," "sorta," "dunno" — appropriate for dialogue, social posts, very casual blogging
 
 ### Vocabulary shifts
+
 - Replace Latinate abstractions with Anglo-Saxon specifics.
 - Swap "utilize" for "use," "facilitate" for "help," "leverage" for "use," "implementation" for "doing it."
 - Swap "individuals" for "people," "purchased" for "bought," "located" for "in."
@@ -109,12 +124,14 @@ Vary technique by desired register. Use *lightly* — one or two touches per par
 - Drop a colloquialism: "whatever," "I mean," "honestly," "to be fair," "look," "like" (as filler)
 
 ### First-person and opinion
+
 - AI defaults to third-person neutrality. Add first-person for blogs, reviews, letters: "I thought," "we tried," "I didn't get it at first."
 - Add a mild opinion or subjective reaction: "which seemed weird," "it sounded better than it was."
 - **Take a stand instead of hedging.** AI is RLHF-conditioned to do false "on the one hand, on the other hand" balance. Humans pick a side (unless they genuinely feel ambivalent). State what you think. Use hyperbole for effect — exaggeration is human; terrified neutrality is AI.
 - **If you don't know, say so.** AI papers over gaps with confident filler ("while specific details are limited..."). Humans say "I don't know" or "nobody's sure" or just skip it.
 
 ### Specificity over abstraction
+
 - AI replaces specific facts with generic praise. Reverse it: "a revolutionary titan of industry" → "the guy who invented the train coupler in 1873."
 - Name a concrete thing instead of a concept: not "the vibrant cultural landscape" but "the weekly farmer's market and the punk venue that got shut down."
 
@@ -122,22 +139,22 @@ Vary technique by desired register. Use *lightly* — one or two touches per par
 
 The degree of humanization depends on context:
 
-| Context | Techniques |
-|---|---|
-| Blog post / newsletter | Contractions, first person, asides, varied sentence length |
-| Social media comment | Fragments, elisions, lowercase, occasional typos, emoji |
-| Business email (casual) | Contractions, lighter structure, drop promotional phrasing, one conversational aside |
-| Fiction dialogue | Elisions, interruptions, trailing thoughts, imperfect grammar |
+| Context                 | Techniques                                                                                            |
+| ----------------------- | ----------------------------------------------------------------------------------------------------- |
+| Blog post / newsletter  | Contractions, first person, asides, varied sentence length                                            |
+| Social media comment    | Fragments, elisions, lowercase, occasional typos, emoji                                               |
+| Business email (casual) | Contractions, lighter structure, drop promotional phrasing, one conversational aside                  |
+| Fiction dialogue        | Elisions, interruptions, trailing thoughts, imperfect grammar                                         |
 | Academic-adjacent essay | Kill AI vocabulary, replace vague analysis with specific claims, vary structure, keep grammar correct |
-| Forum post | All of the above, plus lowercase aggression, sarcasm, or enthusiasm as appropriate |
+| Forum post              | All of the above, plus lowercase aggression, sarcasm, or enthusiasm as appropriate                    |
 
 ## What NOT to do
 
 - Don't make every sentence sloppy. Irregularity only works next to regularity.
 - Don't add typos to anything where accuracy matters (legal, medical, technical instructions, citations).
 - Don't overdo the "uh" and "like" verbal filler — it reads as parody.
-- Don't strip all structure. Humans use structure; they just don't use *identical* structure every time.
-- Don't make the text *harder to read*. Make it *more natural to read*.
+- Don't strip all structure. Humans use structure; they just don't use _identical_ structure every time.
+- Don't make the text _harder to read_. Make it _more natural to read_.
 
 ## Reference
 
diff --git a/skills/rebasing-with-git/SKILL.md b/skills/rebasing-with-git/SKILL.md
index 4f729445ec3233961165e1eb2c1caebc84ffd144..fbcfce4691f21d139678a42aa10785ae0f1841ea 100644
--- a/skills/rebasing-with-git/SKILL.md
+++ b/skills/rebasing-with-git/SKILL.md
@@ -170,6 +170,7 @@ Preserve the order the feature-branch commits originally appeared in the persona
 The rebase todo must be structured as: **drop → break → pick**. The drops remove stale feature-branch commits, the break pauses the rebase so fresh cherry-picks can be inserted, and the remaining picks replay personal-only commits on top.
 
 Build a sed command that:
+
 1. Changes `pick` to `drop` for each identified commit
 2. Inserts a `break` line after the last `drop`, before the first remaining `pick`
 
@@ -195,16 +196,19 @@ The rebase is paused. Cherry-pick feature branches back in now, before the perso
 For each feature branch, in the order confirmed in step 4:
 
 1. Get commits oldest-first:
+
    ```sh
    git log --oneline --reverse upstream/<canonical>..<branch>
    ```
 
 2. **If the branch has a single commit**, cherry-pick it:
+
    ```sh
    git cherry-pick <hash>
    ```
 
 3. **If the branch has multiple commits**, cherry-pick the first, then fixup the rest:
+
    ```sh
    git cherry-pick <first-hash>
    git cherry-pick --no-commit <second-hash>
@@ -212,6 +216,7 @@ For each feature branch, in the order confirmed in step 4:
    git cherry-pick --no-commit <third-hash>
    git commit --amend --no-edit
    ```
+
    Continue for all remaining commits.
 
 4. **If `cherry-pick --no-commit` hits a conflict**: resolve per [Handling conflicts](#handling-conflicts), `git add` resolved files, then `git cherry-pick --quit` to clear the cherry-pick state while preserving staged changes, then `git commit --amend --no-edit`.
@@ -231,9 +236,11 @@ This replays the personal-only commits on top of the freshly cherry-picked featu
 ### Step 8: Final verification
 
 1. Review the log:
+
    ```sh
    git log --oneline upstream/<canonical>..HEAD
    ```
+
    Confirm the expected structure: personal-only commits and one squashed commit per re-picked feature branch, in the expected order.
 
 2. Run the full test suite.
diff --git a/skills/scripting-with-go/SKILL.md b/skills/scripting-with-go/SKILL.md
index 724237841b145b1741196337404bdbc1cf3fb624..0e51cfefd21d7365df04051d5ed6b21c33f79c42 100644
--- a/skills/scripting-with-go/SKILL.md
+++ b/skills/scripting-with-go/SKILL.md
@@ -24,6 +24,7 @@ First line of any Go script (choose based on your shell):
 Then `chmod +x script.go` and run `./script.go args`.
 
 **Shell compatibility:**
+
 - `/**/` syntax works in bash/zsh but NOT in dash
 - `//` syntax works in dash but gopls will complain about formatting
 - Check your `/bin/sh`: `ls -l /bin/sh`
@@ -63,6 +64,7 @@ func main() {
 ## When to use
 
 **Good for:**
+
 - Long-lived automation needing stability (Go 1.x compatibility guarantee)
 - Cross-platform scripts
 - Corporate environments
@@ -70,6 +72,7 @@ func main() {
 - Avoiding dependency management hell
 
 **Avoid for:**
+
 - Simple one-liners
 - Systems without Go
 - Throwaway scripts
diff --git a/skills/updating-llm-client-model-lists/SKILL.md b/skills/updating-llm-client-model-lists/SKILL.md
index 6f9e4832b0f7104b4dae2d17d2294d6bd2363f4e..565c5a6dde527d8e34b6b436e999fd83f38076fd 100644
--- a/skills/updating-llm-client-model-lists/SKILL.md
+++ b/skills/updating-llm-client-model-lists/SKILL.md
@@ -129,14 +129,14 @@ Update `providers.plexus`. ECA custom providers use an OpenAI-compatible provide
 
 ```json
 {
-  "api": "openai-chat",
-  "url": "http://100.77.116.78:4000/v1",
-  "key": "${cmd:fnox get PLEXUS_API_KEY}",
-  "reasoningHistory": "all",
-  "fetchModels": false,
-  "models": {
-    "<id>": {}
-  }
+	"api": "openai-chat",
+	"url": "http://100.77.116.78:4000/v1",
+	"key": "${cmd:fnox get PLEXUS_API_KEY}",
+	"reasoningHistory": "all",
+	"fetchModels": false,
+	"models": {
+		"<id>": {}
+	}
 }
 ```
 
diff --git a/skills/writing-git-tags/SKILL.md b/skills/writing-git-tags/SKILL.md
index e1693ec769297b846a862d0129d3b360dd97cc05..6ed7c5667a07030f27b3708fdaabdd0e351879ae 100644
--- a/skills/writing-git-tags/SKILL.md
+++ b/skills/writing-git-tags/SKILL.md
@@ -71,25 +71,26 @@ git formatted-tag v1.2.0 -m "Add user authentication" -b "$(cat <<'EOF'
 - [api]: add login and logout endpoints
 
 🐛 Bug Fixes
+
 - [login]: correct password validation error
-EOF
-)"
-</git-formatted-tag-example>
+  EOF
+  )"
+  </git-formatted-tag-example>
 
 ## Commit type mapping
 
-| Type | Section |
-|------|---------|
-| feat | ✨ Features |
-| fix | 🐛 Bug Fixes |
-| perf | ⚡ Performance Improvements |
-| docs | 📚 Documentation |
-| style | 🎨 Styling |
-| refactor | ♻️ Code Refactoring |
-| test | 🧪 Tests |
-| build, ci | 🔧 Build System |
-| chore | 🔧 Build System (or omit if trivial) |
-| revert | Include in relevant section with "(revert)" |
+| Type      | Section                                     |
+| --------- | ------------------------------------------- |
+| feat      | ✨ Features                                 |
+| fix       | 🐛 Bug Fixes                                |
+| perf      | ⚡ Performance Improvements                 |
+| docs      | 📚 Documentation                            |
+| style     | 🎨 Styling                                  |
+| refactor  | ♻️ Code Refactoring                         |
+| test      | 🧪 Tests                                    |
+| build, ci | 🔧 Build System                             |
+| chore     | 🔧 Build System (or omit if trivial)        |
+| revert    | Include in relevant section with "(revert)" |
 
 ## Subject line constraints
 
@@ -104,6 +105,7 @@ EOF
 Tag: `v1.2.0`
 
 Annotation:
+
 ```
 Add user authentication and session management
 
diff --git a/skills/writing-rust/SKILL.md b/skills/writing-rust/SKILL.md
index 552bca10c86bb93a5ed2cf492e5cf273a03809fd..2300d155a3fd49cae22aa34fbee960ec3b41794b 100644
--- a/skills/writing-rust/SKILL.md
+++ b/skills/writing-rust/SKILL.md
@@ -39,16 +39,16 @@ project-root/
 
 ## Naming conventions
 
-| Item             | Convention        | Example                    |
-|------------------|-------------------|----------------------------|
-| Crates           | `snake_case`      | `my_crate`                 |
-| Modules          | `snake_case`      | `my_module`                |
-| Types / Traits   | `PascalCase`      | `MyStruct`, `MyTrait`      |
-| Functions        | `snake_case`      | `do_something()`           |
-| Constants        | `SCREAMING_SNAKE` | `MAX_RETRIES`              |
-| Local variables  | `snake_case`      | `item_count`               |
-| Type parameters  | Single uppercase  | `T`, `E`, `K`, `V`        |
-| Lifetimes        | Short lowercase   | `'a`, `'de`                |
+| Item            | Convention        | Example               |
+| --------------- | ----------------- | --------------------- |
+| Crates          | `snake_case`      | `my_crate`            |
+| Modules         | `snake_case`      | `my_module`           |
+| Types / Traits  | `PascalCase`      | `MyStruct`, `MyTrait` |
+| Functions       | `snake_case`      | `do_something()`      |
+| Constants       | `SCREAMING_SNAKE` | `MAX_RETRIES`         |
+| Local variables | `snake_case`      | `item_count`          |
+| Type parameters | Single uppercase  | `T`, `E`, `K`, `V`    |
+| Lifetimes       | Short lowercase   | `'a`, `'de`           |
 
 ## Error handling