chore(ai): align skill rules for commit and PR

Author: minusfive

.agents/skills/commit-guidelines/SKILL.md

@@ -7,8 +7,9 @@ description: Guidelines for analyzing changes and creating branches and commits
 
 - **MUST NOT** skip hooks execution under any circumstances
 
-## 1: Analyze Changes
+## Analyze Changes
 
+- Perform a comprehensive review of all the changes
 - Perform a full security analysis before committing (see `security` skill)
 - Validate documentation and reference integrity (e.g. documentation links, path references, hardcoded paths, test file references)
 - Analyze diffs and identify:
@@ -18,14 +19,17 @@ description: Guidelines for analyzing changes and creating branches and commits
   - Atomic operations across multiple files
   - Small related changes
   - Breaking changes
-- Determine commit message constraints before drafting messages:
-  - Check for commitlint configuration in this order: `commitlint.config.*`, `.commitlintrc*`, then `package.json` `commitlint` section
-  - If commitlint config exists, follow its rules (including inherited presets)
-  - If no commitlint config exists, use Conventional Commits (`<type>[(<scope>)][!]: <summary>`)
 
-## 2: Branch and Commit
+## Branch
 
 - Create a new branch using concise AND descriptive branch names from analysis. It is your job to generate the branch name, do not ask the user to provide it
+
+## Commit
+
+- **MUST** determine and follow commit title and message constraints before drafting messages:
+  - Check for commitlint configuration in this order: `commitlint.config.*`, `.commitlintrc*`, then `package.json` `commitlint` section
+  - If commitlint config exists, follow its rules (including inherited presets)
+  - If no commitlint config exists, use Conventional Commits (`<type>[(<scope>)][!]: <summary>`)
 - Create separate commits for:
   - Different functional areas or independent concerns
   - Different change types
@@ -37,4 +41,6 @@ description: Guidelines for analyzing changes and creating branches and commits
   - Breaking changes should be clearly marked and include details
 - Request explicit approval, never auto-commit without user confirmation
 
-> For pushing and opening a pull request, see `pr-guidelines` skill.
+## Pull Request
+
+- For pushing and opening a pull request, see `pr-guidelines` skill.

.agents/skills/github-cli/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: github-cli
+description: Rules for using gh CLI for all GitHub interactions.
+---
+
+# GitHub CLI Rules
+
+> [!IMPORTANT]
+> All rules and guidelines in this document are **MANDATORY**
+
+## Core Rule
+
+- Use `gh` CLI for all GitHub interactions when `gh` is available.
+- Do not use generic web fetching tools for GitHub URLs when the same operation can be done with `gh`.
+
+## Required Usage
+
+- Repository and file content: use `gh api`.
+- Pull requests: use `gh pr` and `gh api`.
+- Issues: use `gh issue` and `gh api`.
+- Checks, runs, and releases: use `gh run`, `gh release`, and `gh api`.
+- Authentication and context checks: use `gh auth status` and related `gh` commands.
+
+## Examples
+
+- List docs directory: `gh api repos/jdx/mise/contents/docs`
+- Read a file raw: `gh api repos/jdx/mise/contents/docs/tasks/file-tasks.md -H "Accept: application/vnd.github.raw+json"`
+- View PR comments: `gh api repos/<owner>/<repo>/pulls/<number>/comments`
+
+## Fallback
+
+- If `gh` is not installed or not authenticated, report the exact blocker and next command needed.
+- Do not silently switch to web fetch for GitHub operations.

.agents/skills/pr-guidelines/SKILL.md

@@ -15,10 +15,7 @@ description: Guidelines for pushing branches and creating pull requests with pro
 
 ## 2: Pull Request
 
-- Determine pull request title rules before drafting:
-  - Check for commitlint configuration in this order: `commitlint.config.*`, `.commitlintrc*`, then `package.json` `commitlint` section
-  - If commitlint config exists, align the pull request title format to those rules
-  - If no commitlint config exists, use Conventional Commits-compatible format (`<type>[(<scope>)][!]: <summary>`)
+- PR title and message formatting **MUST** follow the same guidelines as commits
 - The pull request body should include a brief summary of the changes and any relevant context or notes for the reviewer
 - **MUST NOT** include commit messages in the pull request body — these are clear from the PR's commit history and will quickly become stale
 - Reference any related issues or pull requests where relevant