style: apply prettier formatting to various files

Author: castrojo

.github/agents/blog-poster.agent.md

@@ -1,8 +1,7 @@
 ---
-description: 'Converts GitHub issues and discussions into formatted Docusaurus blog posts with proper metadata, links, and author attribution'
-tools: ['github', 'edit', 'search', 'web_search']
-model: 'claude-sonnet-4.5'
-
+description: "Converts GitHub issues and discussions into formatted Docusaurus blog posts with proper metadata, links, and author attribution"
+tools: ["github", "edit", "search", "web_search"]
+model: "claude-sonnet-4.5"
 ---
 
 # Blog Poster Agent
@@ -12,6 +11,7 @@ You are a specialist in converting GitHub issues and discussions from @ublue-os/
 ## Core Responsibilities
 
 ### 1. Content Transformation
+
 - Fetch the GitHub discussion or issue URL provided in the task description
 - For cross-repo discussions (e.g., from ublue-os/bluefin), extract the full URL and use it to fetch content
 - If GitHub API fails, use the discussion URL directly and inform the user.
@@ -21,17 +21,20 @@ You are a specialist in converting GitHub issues and discussions from @ublue-os/
 - Add proper frontmatter metadata (title, authors, tags)
 
 ### 2. Link Enhancement
+
 - Link to the originating GitHub discussion so readers can participate
 - Convert repository mentions to proper `@projectname/repo` format with hyperlinks
 - Add hyperlinks to all major projects mentioned, linking to their upstream projects
 - Ensure all URLs are valid and properly formatted
 
 ### 3. Image Formatting
+
 - Reformat all images to use `![Description](https://github-url)` format
 - Ensure images display correctly in Docusaurus
 - Preserve alt text and add descriptive text if missing
 
 ### 4. Author Management
+
 - Check if the author exists in `blog/authors.yaml`
 - Auto-add new authors with their GitHub profile information:
   - name
@@ -42,14 +45,16 @@ You are a specialist in converting GitHub issues and discussions from @ublue-os/
   - socials (bluesky, mastodon, github, linkedin, youtube, blog if available)
 
 ### 5. Tag Management
+
 - Analyze existing blog posts to understand tag patterns
 - Apply relevant tags that match the repository's tagging conventions
 - Common tags include: announcements, artwork, beta, lts, homebrew, development
-- Map the post to use the labels defined in @projectbluefin/common as blog post tags. 
+- Map the post to use the labels defined in @projectbluefin/common as blog post tags.
 
 ## Strict Guidelines
 
 ### DO:
+
 - Extract discussion URLs from the task description (e.g., "Turn https://github.com/ublue-os/bluefin/discussions/3960 into a blogpost")
 - Use GitHub API for all tasks (issues, discussions, user profiles)
 - If API access fails for cross-repo content, report the error and ask for manual content
@@ -60,6 +65,7 @@ You are a specialist in converting GitHub issues and discussions from @ublue-os/
 - Follow existing blog post patterns for consistency
 
 ### DO NOT:
+
 - Modify the author's original content or add your own opinions, copy the text exactly
 - Touch any files other than the blog post file and `blog/authors.yaml`
 - Change the author's writing style or tone
@@ -69,6 +75,7 @@ You are a specialist in converting GitHub issues and discussions from @ublue-os/
 ## Error Handling
 
 If you cannot fetch a discussion:
+
 1. Report the specific error (API permission, network, etc.)
 2. Provide the discussion URL you attempted to fetch
 3. Ask the user to either grant permissions or provide the content manually
@@ -77,6 +84,7 @@ If you cannot fetch a discussion:
 ## File Handling
 
 Only modify these files:
+
 - New blog post: `blog/YYYY-MM-DD-slug.md`
 - Author info: `blog/authors.yaml` (only if author is new)
 

.github/prompts/conventional-commit.prompt.md

@@ -1,7 +1,7 @@
 ---
-agent: 'agent'
-description: 'Generate conventional commit messages following the Conventional Commits specification with proper formatting, validation, and automatic git commit execution.'
-tools: ['runCommands', 'changes', 'think']
+agent: "agent"
+description: "Generate conventional commit messages following the Conventional Commits specification with proper formatting, validation, and automatic git commit execution."
+tools: ["runCommands", "changes", "think"]
 ---
 
 ### Instructions

.github/skills/blog-poster.yaml

@@ -2,7 +2,6 @@
 name: blog poster
 description: Post a blog post
 ---
-
 - Use the github API to do all tasks instead os scraping the web
 - Under no circumstance do you touch any files other than the blog file and the authors.yaml (optional) - do NOT touch anything else
 - Take a github issue or github discussion that is assigned to you and post it as a @docusaurus blog post.

.nvidia-drivers-cache.json

@@ -7,4 +7,4 @@
   "304.137": "https://www.nvidia.com/en-us/drivers/details/123710/",
   "173.14.39": "https://www.nvidia.com/en-us/drivers/details/71304/",
   "470.256.02": "https://www.nvidia.com/en-us/drivers/details/226761/"
-}
+}

.planning/phases/03-documentation-refinement/03-02-PLAN.md

@@ -415,9 +415,9 @@ Read both AGENTS.md section and docs/reports.md completely:
 - [ ] Examples are clear
 - [ ] Troubleshooting scenarios are realistic
 - [ ] Ready for production use
-    </how-to-verify>
-  <resume-signal>
-Type "approved" if Phase 3 deliverables meet quality standards and documentation is production-ready.
+      </how-to-verify>
+      <resume-signal>
+      Type "approved" if Phase 3 deliverables meet quality standards and documentation is production-ready.
 
 If issues found, describe them and they will be addressed before proceeding.
 </resume-signal>

.planning/quick/005-label-unlabeled-prs-in-monthly-reports-t/005-SUMMARY.md

@@ -13,12 +13,14 @@ Reduce the January 2026 monthly report's "Other" section (100+ items) by applyin
 ## Tasks Completed
 
 ### Task 1: Identify Obvious Labeling Patterns ✅
+
 - Analyzed lines 186-295 of January 2026 report
 - Identified 34 PRs with obvious labeling patterns
 - Categorized by: CI/automation, upstream, testing, hardware, documentation, ISO
 - Created categorized list with PR URLs and proposed labels
 
 ### Task 2: Apply Labels via GitHub CLI ✅
+
 - Successfully labeled **34 PRs** across multiple repositories:
   - 11 CI/automation PRs → `kind/automation` or `github_actions`
   - 5 upstream/logos PRs → `area/upstream`
@@ -37,6 +39,7 @@ Reduce the January 2026 monthly report's "Other" section (100+ items) by applyin
   - `projectbluefin/branding` (1 PR)
 
 ### Task 3: Validate Impact via Report Regeneration ✅
+
 - Regenerated January 2026 report with labeled PRs
 - Measured impact:
   - **Before:** 110 items in "Other" section
@@ -54,12 +57,14 @@ Reduce the January 2026 monthly report's "Other" section (100+ items) by applyin
 ## Impact Analysis
 
 ### What Worked
+
 - ✅ Process validated: labeling → regeneration → categorization works as expected
 - ✅ 34 PRs now properly categorized and discoverable
 - ✅ Automation, Upstream, Testing, Hardware categories significantly improved
 - ✅ Clear labeling patterns established for future use
 
 ### What Didn't Work
+
 - ❌ Permission barriers prevented labeling majority of unlabeled PRs
 - ❌ Aurora and Dakota repos account for ~54 unlabeled PRs
 - ❌ Limited to 16% reduction vs. target 50% due to access limitations
@@ -68,28 +73,30 @@ Reduce the January 2026 monthly report's "Other" section (100+ items) by applyin
 ## Recommendations
 
 ### Short-term
+
 1. **Request maintainer labeling** for aurora/dakota repositories
 2. **Focus labeling efforts** on repos with write access (bluefin, bluefin-lts, common, documentation, iso)
 3. **Label at PR creation time** rather than retroactive labeling
 
 ### Long-term
-1. **Standardize labels** across all projectbluefin/* repositories
+
+1. **Standardize labels** across all projectbluefin/\* repositories
 2. **Add PR templates** with label requirements
 3. **Implement auto-labeling** based on conventional commits or file paths
 4. **Consider repository consolidation** to reduce unlabeled PR sprawl
 
 ## Files Modified
 
-| File                            | Status   | Description                  |
-| ------------------------------- | -------- | ---------------------------- |
-| `reports/2026-01-31-report.mdx` | Modified | Regenerated with new labels  |
-| `005-PLAN.md`                   | Created  | Task plan                    |
-| `005-SUMMARY.md`                | Created  | This summary                 |
+| File                            | Status   | Description                 |
+| ------------------------------- | -------- | --------------------------- |
+| `reports/2026-01-31-report.mdx` | Modified | Regenerated with new labels |
+| `005-PLAN.md`                   | Created  | Task plan                   |
+| `005-SUMMARY.md`                | Created  | This summary                |
 
 ## Commits
 
-| Hash    | Message                                                     |
-| ------- | ----------------------------------------------------------- |
+| Hash    | Message                                                         |
+| ------- | --------------------------------------------------------------- |
 | 1cb5e57 | chore(reports): reduce 'Other' section via retroactive labeling |
 
 ## External Changes
@@ -115,6 +122,7 @@ Reduce the January 2026 monthly report's "Other" section (100+ items) by applyin
 ## Notes
 
 This task demonstrates the value of consistent labeling practices. While we successfully labeled 34 PRs, the majority of "Other" items stem from repositories where we lack permissions. Achieving the target 50% reduction would require:
+
 1. Maintainer cooperation for aurora/dakota labeling
 2. Label standardization across all repos
 3. Enforcement mechanisms (PR templates, GitHub Actions, etc.)

.planning/research/automerge-workflow-research.md

@@ -5,6 +5,7 @@
 **Recommended Approach:** Use `gh pr merge --auto` with enhanced workflow permissions
 
 **Rationale:**
+
 - Works with existing repository ruleset (merge queue + PR requirements)
 - Requires minimal changes to current workflow
 - Maintains security and quality gates
@@ -19,6 +20,7 @@
 ### Repository Protection Configuration
 
 **Ruleset:** `main` (active)
+
 - **Merge Queue:** Enabled
   - Strategy: `ALLGREEN` (all status checks must pass)
   - Max entries to merge: 5
@@ -37,11 +39,12 @@
 
 ```yaml
 permissions:
-  contents: write     # For git commits
+  contents: write # For git commits
   pull-requests: read # For GraphQL queries
 ```
 
 **Missing for auto-merge:**
+
 - No PR creation permission
 - No permission to enable auto-merge on PRs
 - Workflow pushes directly to main (bypasses PR flow)
@@ -50,12 +53,12 @@ permissions:
 
 ## Options Comparison
 
-| Approach | Pros | Cons | Security | Implementation |
-|----------|------|------|----------|----------------|
-| **1. `gh pr merge --auto` with GITHUB_TOKEN** | ✅ Native GitHub feature<br>✅ Works with rulesets<br>✅ No extra tokens needed<br>✅ Respects status checks | ❌ Requires PR creation first<br>❌ Needs permission changes | 🟢 High - respects all rules | Easy - 10 lines |
-| **2. GitHub App Token** | ✅ Can bypass restrictions<br>✅ Fine-grained permissions<br>✅ Audit trail | ❌ Requires app setup<br>❌ Complex token generation<br>❌ Can bypass needed checks | 🟡 Medium - depends on config | Hard - 30+ lines |
-| **3. Personal Access Token (PAT)** | ✅ Simple to set up | ❌ Tied to user account<br>❌ Security risk<br>❌ Breaks on user removal | 🔴 Low - poor practice | Easy - 5 lines |
-| **4. Direct push to main** | ✅ Simplest | ❌ Bypasses all protection<br>❌ No review possible<br>❌ Violates governance | 🔴 Very Low - dangerous | Current state |
+| Approach                                      | Pros                                                                                                         | Cons                                                                                | Security                      | Implementation   |
+| --------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------- | ----------------------------- | ---------------- |
+| **1. `gh pr merge --auto` with GITHUB_TOKEN** | ✅ Native GitHub feature<br>✅ Works with rulesets<br>✅ No extra tokens needed<br>✅ Respects status checks | ❌ Requires PR creation first<br>❌ Needs permission changes                        | 🟢 High - respects all rules  | Easy - 10 lines  |
+| **2. GitHub App Token**                       | ✅ Can bypass restrictions<br>✅ Fine-grained permissions<br>✅ Audit trail                                  | ❌ Requires app setup<br>❌ Complex token generation<br>❌ Can bypass needed checks | 🟡 Medium - depends on config | Hard - 30+ lines |
+| **3. Personal Access Token (PAT)**            | ✅ Simple to set up                                                                                          | ❌ Tied to user account<br>❌ Security risk<br>❌ Breaks on user removal            | 🔴 Low - poor practice        | Easy - 5 lines   |
+| **4. Direct push to main**                    | ✅ Simplest                                                                                                  | ❌ Bypasses all protection<br>❌ No review possible<br>❌ Violates governance       | 🔴 Very Low - dangerous       | Current state    |
 
 **Recommendation:** Option 1 (gh pr merge --auto)
 
@@ -69,8 +72,8 @@ permissions:
 
 ```yaml
 permissions:
-  contents: write        # For git commits
-  pull-requests: write   # To create and enable auto-merge on PRs
+  contents: write # For git commits
+  pull-requests: write # To create and enable auto-merge on PRs
 ```
 
 **2. Create PR Instead of Direct Push**
@@ -154,12 +157,14 @@ Ensure build passes before merge:
 5. **Merge** → PR automatically merges when queue clears
 
 **Merge Queue Behavior:**
+
 - Groups PRs together (up to 5 at once)
 - Tests them in merge queue branch
 - Merges if all checks pass
 - Prevents "merge race" conditions
 
 **Required Conditions:**
+
 - ✅ No required reviews (already configured: `required_approving_review_count: 0`)
 - ✅ Auto-merge enabled (already configured: `autoMergeAllowed: true`)
 - ✅ Status checks pass (enforced by merge queue `ALLGREEN`)
@@ -185,18 +190,19 @@ Ensure build passes before merge:
 
 ### What Changes vs Current Workflow
 
-| Aspect | Current (Direct Push) | With Auto-Merge PR |
-|--------|----------------------|-------------------|
-| Protection bypassed? | ✅ Yes (pushes to main) | ❌ No (uses PR) |
-| Reviewable? | ❌ No audit trail | ✅ Yes (PR history) |
-| Can be blocked? | ❌ No way to stop | ✅ Yes (close PR) |
-| Status checks? | ❌ Skipped | ✅ Required |
+| Aspect               | Current (Direct Push)   | With Auto-Merge PR  |
+| -------------------- | ----------------------- | ------------------- |
+| Protection bypassed? | ✅ Yes (pushes to main) | ❌ No (uses PR)     |
+| Reviewable?          | ❌ No audit trail       | ✅ Yes (PR history) |
+| Can be blocked?      | ❌ No way to stop       | ✅ Yes (close PR)   |
+| Status checks?       | ❌ Skipped              | ✅ Required         |
 
 **Security Improvement:** Moving to PR-based flow is MORE secure than current direct push.
 
 ### Bot Security
 
 **github-actions[bot]** is a special system account:
+
 - Tied to GitHub Actions service (not a user)
 - Cannot be compromised like PAT
 - Permissions limited by workflow file
@@ -211,6 +217,7 @@ Ensure build passes before merge:
 **When to use:** Need to bypass branch protection completely
 
 **Setup:**
+
 ```yaml
 - name: Generate GitHub App Token
   id: generate-token
@@ -226,6 +233,7 @@ Ensure build passes before merge:
 ```
 
 **Why not recommended here:**
+
 - Requires creating GitHub App
 - More complex setup
 - Overkill for this use case (no bypass needed)
@@ -235,6 +243,7 @@ Ensure build passes before merge:
 **When to use:** Never (bad practice)
 
 **Why avoid:**
+
 - Tied to user account (security risk)
 - Breaks if user leaves
 - Violates principle of least privilege
@@ -247,6 +256,7 @@ Ensure build passes before merge:
 **Before merging changes:**
 
 1. **Test PR creation in feature branch:**
+
    ```bash
    git checkout -b test-monthly-reports-automerge
    # Make workflow changes
@@ -255,16 +265,19 @@ Ensure build passes before merge:
    ```
 
 2. **Verify PR created:**
+
    ```bash
    gh pr list --author "github-actions[bot]"
    ```
 
 3. **Check auto-merge enabled:**
+
    ```bash
    gh pr view <PR-NUMBER> --json autoMergeRequest
    ```
 
 4. **Monitor merge queue:**
+
    ```bash
    gh api repos/projectbluefin/documentation/branches/main/protection --jq '.merge_queue'
    ```
@@ -275,6 +288,7 @@ Ensure build passes before merge:
 
 **Rollback Plan:**
 If auto-merge fails, PR remains open and can be:
+
 - Manually merged via GitHub UI
 - Closed and workflow re-run
 - Edited to fix issues before merge
@@ -297,7 +311,7 @@ on:
 
 permissions:
   contents: write
-  pull-requests: write  # ← ADD THIS
+  pull-requests: write # ← ADD THIS
 
 jobs:
   generate-report:
@@ -320,7 +334,7 @@ jobs:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         run: npm run generate-report
 
-      - name: Create PR with auto-merge  # ← REPLACE "Commit and push" step
+      - name: Create PR with auto-merge # ← REPLACE "Commit and push" step
         run: |
           BRANCH="monthly-report/$(date +%Y-%m)"
           git config user.name "github-actions[bot]"