@mesrai/cli 0.4.21

package/skills/hunk-review/SKILL.md

@@ -0,0 +1,154 @@
+---
+name: hunk-review
+description: Interacts with live Hunk diff review sessions via CLI. Inspects review focus, navigates files and hunks, reloads session contents, and adds inline review comments. Use when the user has a Hunk session running or wants to review diffs interactively.
+---
+
+# Hunk Review
+
+Hunk is an interactive terminal diff viewer. The TUI is for the user -- do NOT run `hunk diff`, `hunk show`, or other interactive commands directly. Use `hunk session *` CLI commands to inspect and control live sessions through the local daemon.
+
+If no session exists, ask the user to launch Hunk in their terminal first.
+
+## Workflow
+
+```text
+1. hunk session list                                    # find live sessions
+2. hunk session get --repo .                            # inspect path / repo / source
+3. hunk session review --repo . --json                  # inspect file/hunk structure first
+4. hunk session review --repo . --include-patch --json  # opt into raw diff text only when needed
+5. hunk session context --repo .                        # check current focus when needed
+6. hunk session navigate ...                            # move to the right place
+7. hunk session reload -- <command>                     # swap contents if needed
+8. hunk session comment add ...                         # leave one review note
+9. hunk session comment apply ...                       # apply many agent notes in one stdin batch
+```
+
+## Session selection
+
+Most session commands accept:
+
+- `--repo <path>` -- match the live session by its current loaded repo root (most common)
+- `<session-id>` -- match by exact ID (use when multiple sessions share a repo)
+- If only one session exists, it auto-resolves
+
+`reload` also supports:
+
+- `--session-path <path>` -- match the live Hunk window by its current working directory
+- `--source <path>` -- load the replacement `diff` / `show` command from a different directory
+
+Use `--source` only for advanced reloads where the live session you want to control is not already associated with the checkout you want to load next. For a normal worktree session, prefer selecting it directly with `--repo /path/to/worktree`.
+
+## Commands
+
+### Inspect
+
+```bash
+hunk session list [--json]
+hunk session get (--repo . | <id>) [--json]
+hunk session context (--repo . | <id>) [--json]
+hunk session review (--repo . | <id>) [--json] [--include-patch]
+```
+
+- `get` shows the session `Path`, `Repo`, and `Source`, which helps when choosing between `--repo` and `--session-path`
+- `Repo` is what `--repo` matches; `Path` is what `--session-path` matches
+- `review --json` returns file and hunk structure by default; add `--include-patch` only when a caller truly needs raw unified diff text
+
+### Navigate
+
+Absolute navigation requires `--file` and exactly one of `--hunk`, `--new-line`, or `--old-line`:
+
+```bash
+hunk session navigate --repo . --file src/App.tsx --hunk 2
+hunk session navigate --repo . --file src/App.tsx --new-line 372
+hunk session navigate --repo . --file src/App.tsx --old-line 355
+```
+
+Relative comment navigation jumps between annotated hunks and does not require `--file`:
+
+```bash
+hunk session navigate --repo . --next-comment
+hunk session navigate --repo . --prev-comment
+```
+
+- `--hunk <n>` is 1-based
+- `--new-line` / `--old-line` are 1-based line numbers on that diff side
+- Use either `--next-comment` or `--prev-comment`, not both
+
+### Reload
+
+Swaps the live session's contents. Pass a Hunk review command after `--`:
+
+```bash
+hunk session reload --repo . -- diff
+hunk session reload --repo . -- diff main...feature -- src/ui
+hunk session reload --repo . -- show HEAD~1
+hunk session reload --repo . -- show HEAD~1 -- README.md
+hunk session reload --repo /path/to/worktree -- diff
+hunk session reload --session-path /path/to/live-window --source /path/to/other-checkout -- diff
+```
+
+- Always include `--` before the nested Hunk command
+- `--repo` or `<session-id>` usually selects the session you want
+- `--source` is advanced: it does not select the session; it only changes where the replacement review command runs
+- If the live session is already showing the target worktree, prefer `hunk session reload --repo /path/to/worktree -- diff`
+- `--session-path` targets the live window when you need to keep session selection separate from reload source
+
+### Comments
+
+```bash
+hunk session comment add --repo . --file README.md --new-line 103 --summary "Tighten this wording" [--rationale "..."] [--author "agent"] [--focus]
+printf '%s\n' '{"comments":[{"filePath":"README.md","newLine":103,"summary":"Tighten this wording"}]}' | hunk session comment apply --repo . --stdin [--focus]
+hunk session comment list --repo . [--file README.md]
+hunk session comment rm --repo . <comment-id>
+hunk session comment clear --repo . --yes [--file README.md]
+```
+
+- `comment add` is best for one note; `comment apply` is best when an agent already has several notes ready
+- `comment add` requires `--file`, `--summary`, and exactly one of `--old-line` or `--new-line`
+- `comment apply` payload items require `filePath`, `summary`, and exactly one target such as `hunk`, `hunkNumber`, `oldLine`, or `newLine`
+- `comment apply` reads a JSON batch from stdin and validates the full batch before mutating the live session
+- Pass `--focus` when you want to jump to the new note or the first note in a batch
+- `comment list` and `comment clear` accept optional `--file`
+- Quote `--summary` and `--rationale` defensively in the shell
+
+## New files in working-tree reviews
+
+`hunk diff` includes untracked files by default. If the user wants tracked changes only, reload with `--exclude-untracked`:
+
+```bash
+hunk session reload --repo . -- diff --exclude-untracked
+```
+
+## Guiding a review
+
+The user may ask you to walk them through a changeset or review code using Hunk. Start with `hunk session review --json` to understand the file/hunk structure without inflating agent context, then use `--include-patch` only for the files you truly need to read in raw diff form. Use `context` and `navigate` to line up the user's current view before adding comments.
+
+Your role is to narrate: steer the user's view to what matters and leave comments that explain what they're looking at.
+
+Typical flow:
+
+1. Load the right content (`reload` if needed)
+2. Navigate to the first interesting file / hunk
+3. Add a comment explaining what's happening and why
+4. If you already have several notes ready, prefer one `comment apply` batch over many separate shell invocations
+5. Summarize when done
+
+Guidelines:
+
+- Work in the order that tells the clearest story, not necessarily file order
+- Navigate before commenting so the user sees the code you're discussing
+- Use `comment apply` for agent-generated batches and `comment add` for one-off notes
+- Use `--focus` sparingly when the note itself should actively steer the review
+- Keep comments focused: intent, structure, risks, or follow-ups
+- Don't comment on every hunk -- highlight what the user wouldn't spot themselves
+
+## Common errors
+
+- **"No visible diff file matches ..."** -- the file is not in the loaded review. Check `context`, then `reload` if needed.
+- **"No active Hunk sessions"** -- ask the user to open Hunk in their terminal.
+- **"Multiple active sessions match"** -- pass `<session-id>` explicitly.
+- **"No active Hunk session matches session path ..."** -- for advanced split-path reloads, verify the live window `Path` via `hunk session get` or `list`, then use `--session-path`.
+- **"Pass the replacement Hunk command after `--`"** -- include `--` before the nested `diff` / `show` command.
+- **"Pass --stdin to read batch comments from stdin JSON."** -- `comment apply` only reads its batch payload from stdin.
+- **"Specify exactly one navigation target"** -- pick one of `--hunk`, `--old-line`, or `--new-line`.
+- **"Specify either --next-comment or --prev-comment, not both."** -- choose one comment-navigation direction.

package/skills/mesrai-business-rules-validation/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: mesrai-business-rules-validation
+description: Use when the user wants Mesrai to validate local diff changes against task requirements, acceptance criteria, or business rules via `mesrai pr business-validation`, especially for implementation-vs-task or merge readiness checks.
+license: MIT
+compatibility: Requires Mesrai CLI auth plus Mesrai task-management integration (Jira/Linear/Notion/ClickUp) for useful task context retrieval.
+metadata:
+    author: Mesrai
+    version: '1.0'
+---
+
+# Mesrai Business Rules Validation
+
+## Goal
+
+Run Mesrai business-rules validation from the current repository diff only.
+
+## Required Inputs
+
+- One local diff scope:
+    - default working tree diff
+    - or `--staged`
+    - or `--branch <name>`
+    - or `--commit <sha>`
+    - or `[files...]`
+- Optional task reference:
+    - `--task-url <url>` or `--task-id <id>`
+    - Do not pass both.
+
+## When to Use
+
+- The user asks for business-validation, business validation, business rules validation, or acceptance-criteria validation
+- The user wants to check local implementation vs task requirements
+- The user mentions local business validation or `mesrai pr business-validation`
+
+Do not use this skill as a substitute for `mesrai review`. Local review and business-rules validation are different flows.
+
+## Workflow
+
+1. Choose the local scope.
+
+- Default working tree diff when no scope flag is provided.
+- Use only one of `--staged`, `--branch`, `--commit`, or `[files...]`.
+
+2. Build and run the command.
+
+Examples:
+
+```bash
+mesrai pr business-validation
+mesrai pr business-validation --staged --task-id KC-1441
+mesrai pr business-validation --branch main --task-id KC-1441
+mesrai pr business-validation --commit HEAD~1 --task-id KC-1441
+mesrai pr business-validation src/service.ts src/use-case.ts --task-id KC-1441
+```
+
+3. Interpret the result.
+
+- `Mode: local diff` means validation over the provided local diff scope.
+- If output says missing MCP/task context, report that directly and request integration/context setup.
+
+## Notes
+
+- `mesrai review` does not trigger this flow.
+- Prefer `--task-id` or `--task-url` when the task is not obvious from local context.
+- `KC-1441`-style keys are valid.

package/skills/mesrai-centralized-config/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: mesrai-centralized-config
+description: Use when the user wants to manage centralized configuration via `mesrai config centralized` commands (status, init, sync, disable, and download).
+---
+
+# Mesrai Centralized Config
+
+## Overview
+
+Centralized configuration allows teams to manage their Mesrai configuration files in a single repository, providing a single source of truth for their settings. This skill enables users to manage their centralized configuration through Mesrai CLI commands, including initializing centralized config, syncing configuration, disabling centralized config, and downloading generated config files.
+
+The configuration files are generated based on the user's current settings, and users have the option to review these changes in a pull request before they are merged into the repository. This approach ensures that teams can maintain control over their configuration while benefiting from the convenience of centralized management.
+
+If the setting is enabled, then any pull request merged to the selected repository will trigger a sync to update the configuration in Mesrai. This allows teams to easily manage and update their configuration as needed, without having to manually apply changes in Mesrai.
+
+At any time the user can run a manual sync command to pull the latest configuration from the repository, however this is not recommended.
+
+## Goal
+
+Manage centralized configuration through Mesrai CLI commands only.
+
+Use this skill when the request involves enabling centralized config, selecting the source repository, syncing configuration, disabling centralized config, or downloading generated config files.
+
+## Trigger Hints
+
+- Mentions of centralized config, centralized configuration, config sync source repo, or source repository for rules.
+- Requests to run: `mesrai config centralized status|init|sync|disable|download`.
+- Requests to enable or disable centralized config from terminal.
+
+## Workflow
+
+Unless specifically stated, YOU must run the Mesrai CLI commands on behalf of the user. Do not provide instructions to run commands without also running them yourself.
+
+1. Confirm team-key authentication is available.
+
+- Centralized config commands require team-key auth.
+- If missing, instruct the user to run:
+
+```bash
+mesrai auth team-key --key <your-key>
+```
+
+2. Check current centralized status first when context is unclear.
+
+```bash
+mesrai config centralized status
+```
+
+3. Initialize centralized config when requested.
+
+- Preferred command shape:
+
+```bash
+mesrai config centralized init [owner/repo] --sync-option <pr|manual>
+```
+
+ALWAYS run the command `mesrai config remote list` first to get the list of repositories the user has access to and their current selection. You must provide the repo in the shape `owner/repo` for example `organization/repository-name`. If you cannot find the repository in the list, then tell the user about it.
+
+- Defaults and behavior:
+- `--sync-option` defaults to `pr`. Defines the behaviour of the initial sync after enabling centralized config.
+    - `pr` creates a pull request with their current config. A link to the PR is provided in the command output. Merging the PR triggers a sync to update the configuration in Mesrai.
+    - `manual` simply enables centralized config without creating a PR, the user will need to create a PR themselves with their desired config or run a manual sync after pushing changes to the repository.
+- If repository is omitted in an interactive terminal, CLI prompts repository selection.
+- In non-interactive mode, repository must be provided explicitly.
+
+Prefer providing the repository in the command to avoid interactive prompts, especially in non-interactive contexts. If the repository is not provided and the terminal is interactive, the CLI will prompt the user to select a repository from their accessible repositories. If the terminal is non-interactive and the repository is not provided, the command will fail with an error indicating that the repository is required.
+
+4. Sync centralized config on demand.
+
+A sync will pull the latest configuration from the repository and override the user's current configuration defined in the Mesrai database with the config from the repository. Syncs happen automatically when a PR is merged regardless of the initial sync option selected, but users can also choose to run a manual sync at any time to pull the latest changes from the repository.
+
+```bash
+mesrai config centralized sync
+```
+
+Avoid running sync automatically after init to give users control over when to pull changes, especially if they want to review or customize the generated config before applying it.
+
+Running sync will override the user's current configuration with the config from the repository, so it's best to let users decide when to do this, be sure to warn them of this when they ask to run sync and recommend downloading the config first as a backup before syncing.
+
+5. Disable centralized config when requested.
+
+```bash
+mesrai config centralized disable
+```
+
+6. Download centralized config zip artifact.
+
+```bash
+mesrai config centralized download --out <path/to/centralized-config.zip>
+```
+
+- `--out` is required.
+
+## Output Guidance
+
+- Prefer using `--json` to receive structured output.
+- When providing output to the user, summarize the key information and next steps rather than dumping raw command output.
+
+## Safety Notes
+
+- Do not suggest manually editing backend parameters for centralized config when CLI commands exist.
+- If repository selection fails, verify the repository is already selected in Mesrai (`mesrai config remote list`).

package/skills/mesrai-mesrai-rules/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: mesrai-mesrai-rules
+description: Use when the user wants to create, update or view Mesrai Rules via `mesrai rules` command.
+---
+
+# Mesrai Mesrai Rules
+
+## Overview
+
+Mesrai Rules are a set of guidelines that Mesrai follows when generating code. They help ensure that the generated code is consistent, high-quality, and aligned with the user's preferences and project requirements.
+
+## Goal
+
+Manage Mesrai Rules through Mesrai CLI only. Do not suggest creating rule files manually.
+
+ALWAYS Use `mesrai rules` subcommands for all create, update, and view operations. All these rules are ALWAYS managed by the `mesrai rules` command from the CLI. Do NOT suggest creating files or storing rules in any other way. When the user wants to create, update or view Mesrai Rules, utilize the `mesrai rules` command with the appropriate subcommands and options as outlined in the instructions files.
+
+## Centralized Config Convention
+
+When centralized config is enabled for the selected team/repository scope, `mesrai rules create` and `mesrai rules update` may return centralized PR metadata instead of directly created/updated rule records.
+
+- Treat this as success, not failure.
+- Prioritize reporting `prUrl` (and `prNumber` when available).
+- Explain that the change is pending until the centralized PR is merged and synced.
+- Do not claim a rule was directly persisted when the result is centralized PR mode.
+- When output includes both direct results and centralized PR metadata, prefer communicating the centralized PR outcome.
+
+## Shared Workflow
+
+1. Confirm the requested action:
+
+- `create`: add a new rule.
+- `update`: modify an existing rule.
+- `view`: list all rules or fetch a specific rule.
+
+2. Resolve repository scope:
+
+- Use `global` when the user does not provide a repository scope. Always confirm if the user intends to use `global` scope when no repository is specified.
+- For repository-specific requests with unknown id, run:
+
+```bash
+mesrai config remote list --json
+```
+
+Then select and pass `--repo-id <id>`.
+
+3. Validate rule fields before running commands:
+
+- `title`: short and specific.
+- `rule`: clear and actionable guidance.
+- `severity`: `low | medium | high | critical`.
+- `scope`: `file | pull request`.
+- `path`: optional glob, default effectively `**/*`.
+
+4. Execute the proper command and report results clearly.
+
+## How to Use
+
+Read individual instructions files for detailed explanations and examples:
+
+- [instructions/create-mesrai-rule.md](instructions/create-mesrai-rule.md): Guidelines for creating new Mesrai Rules.
+- [instructions/update-mesrai-rule.md](instructions/update-mesrai-rule.md): Guidelines for updating existing Mesrai Rules.
+- [instructions/view-mesrai-rules.md](instructions/view-mesrai-rules.md): Guidelines for viewing and retrieving Mesrai Rules.
+
+You MUST always load at least one of these instructions files to handle the specific user request related to Mesrai Rules. Each file contains detailed steps and examples for the corresponding action (create, update, view). Always ensure that you are following the instructions in these files when managing Mesrai Rules through the `mesrai rules` command.
+
+Should the user request an action that is not covered by these instructions, you should first clarify the user's intent and then determine if it falls under create, update, or view operations. If it does, proceed to load the corresponding instructions file to ensure that you are following the correct workflow for managing Mesrai Rules through the `mesrai rules` command.
+
+Should the user request a new action related to Mesrai Rules that differs from the initial action, you should load the appropriate instructions file for that new action to ensure that you are following the correct workflow for managing Mesrai Rules through the `mesrai rules` command.
+
+## Structure of a Mesrai Rule
+
+A Mesrai Rule typically consists of the following components:
+
+- **Repository ID**: The repository scope where the rule is stored and applied.
+    - Use `global` for shared rules that apply across all repositories.
+- **Title**: A concise title that captures the essence of the rule.
+- **Rule**: A detailed explanation of what the rule is and why it is important.
+- **Severity**: A level indicating the importance of the rule (one of "low", "medium", "high" or "critical").
+    - **Low**: The rule is a suggestion and can be ignored without significant consequences.
+    - **Medium**: The rule should be followed, but violations are not critical. Default severity level.
+    - **High**: The rule is important and should be followed to avoid potential issues.
+    - **Critical**: The rule is essential and must be followed to prevent severe issues or failures.
+- **Scope**: The level at which the rule applies (one of "pull request" or "file").
+    - **Pull Request**: The rule applies to the entire pull request and is evaluated based on the overall changes in the PR.
+    - **File**: The rule applies to individual files and is evaluated on a per-file basis. Default scope level.
+- **Path**: An optional glob pattern indicating which files the rule applies to.
+    - For example, `src/**/*.js` would apply the rule to all JavaScript files in the `src` directory and its subdirectories.
+    - Default is all files, `**/*`.
+
+## Example of a Mesrai Rule
+
+**Title**: Use Async/Await for Asynchronous Operations
+
+**Rule**: Ensure that all asynchronous operations in the codebase use async/await syntax for better readability and error handling. Avoid using raw Promises or callback functions for asynchronous code.
+
+**Severity**: High
+
+**Scope**: File
+
+**Path**: `**/*.ts`
+
+**Repository ID**: `global`

package/skills/mesrai-mesrai-rules/instructions/create-mesrai-rule.md

@@ -0,0 +1,56 @@
+---
+name: create-mesrai-rule
+description: Mesrai Rule Creation Guidelines - Use when the user wants to create a new Mesrai Rule for Mesrai to follow when generating code.
+---
+
+# Mesrai Rule Creation Guidelines
+
+## Overview
+
+When creating a new Mesrai Rule, it's important to ensure that the rule is clear, actionable, and aligned with the overall goals of code generation. A well-defined Mesrai Rule helps Mesrai produce code that meets the user's expectations and project requirements.
+
+## Workflow for Creating a Mesrai Rule
+
+1. **Collect the user's intent**: Understand the specific coding practice, style, or requirement that the user wants to enforce with the new Mesrai Rule. Ask clarifying questions if necessary to ensure you have a clear understanding of the user's intent.
+
+2. **Draft the Mesrai Rule**: Based on the user's intent, draft a Mesrai Rule that includes a clear description, title, and any relevant metadata such as severity and scope. Use the guidelines outlined in the "Guidelines for Creating a Mesrai Rule" section to ensure the rule is well-structured and effective.
+
+3. **Review the Mesrai Rule with the user**: Present the drafted Mesrai Rule to the user for feedback. Discuss any potential edge cases, exceptions, or clarifications needed to ensure the rule is comprehensive and actionable.
+
+4. **Refine the Mesrai Rule**: Based on the user's feedback, refine the Mesrai Rule to address any concerns or suggestions. Ensure that the final version of the rule is clear, specific, and aligned with the user's goals.
+
+5. **Save and Implement the Mesrai Rule**: Once the Mesrai Rule is finalized and approved by the user, save it. Send the title, rule, and any optional fields such as severity, scope, and path.
+
+Always include the repository id when creating a rule. Use `global` when the user does not provide one.
+
+Use the following command to save the Mesrai Rule:
+
+```
+mesrai rules create --title <title> --rule <rule-content> [--repo-id <repository-id>] [--severity <severity-level>] [--scope <scope-level>] [--path <glob-pattern>]
+```
+
+If `--repo-id` is omitted, the default repository id is `global`.
+
+6. **Communicate the new Mesrai Rule**: Inform the user about the new Mesrai Rule and how it will be applied in future code generation.
+
+## Centralized Config Behavior
+
+When centralized config is enabled, creating a rule may return a centralized PR result instead of a directly persisted rule.
+
+In this case:
+
+1. Report the PR URL (and PR number if present).
+2. State that the rule is pending and will be applied after PR merge and sync.
+3. Do not present the rule as already created in the database.
+
+## Guidelines for Creating a Mesrai Rule
+
+1. **Identify the Purpose**: Clearly define what the Mesrai Rule is intended to achieve. Is it meant to enforce a coding style, ensure best practices, or address a specific use case?
+
+2. **Be Specific**: The rule should be specific and unambiguous. Avoid vague language and ensure that the rule can be easily understood and applied by Mesrai.
+
+3. **Consider Edge Cases**: Think about any edge cases or exceptions that might arise when applying the rule. Address these in the rule definition to ensure Mesrai can handle them appropriately.
+
+4. **Align with Project Goals**: Ensure that the Mesrai Rule aligns with the overall goals and requirements of the project. The rule should contribute to producing code that is maintainable, efficient, and meets the user's needs.
+
+5. **Review and Refine**: After drafting the Mesrai Rule, review it for clarity and completeness. Present it to the user for feedback and refine it as necessary to ensure it effectively guides Mesrai's code generation process.

package/skills/mesrai-mesrai-rules/instructions/update-mesrai-rule.md

@@ -0,0 +1,63 @@
+---
+name: update-mesrai-rule
+description: Mesrai Rule Update Guidelines - Use when the user wants to update an existing Mesrai Rule to modify its behavior, scope, or severity for Mesrai to follow when generating code.
+---
+
+# Mesrai Rule Update Guidelines
+
+## Overview
+
+When updating an existing Mesrai Rule, it's important to ensure that the changes are clear, justified, and aligned with the overall goals of code generation. Updating a Mesrai Rule can help refine its effectiveness and ensure that it continues to meet the user's expectations and project requirements.
+
+## Workflow for Updating a Mesrai Rule
+
+1. **Identify the Mesrai Rule to Update**: If the user did not specify which Mesrai Rule they want to update, ask for one of:
+    - `--uuid <uuid>`
+
+Updates must use `--uuid`.
+
+2. **Collect the user's intent for the update**: Understand the specific changes the user wants to make to the existing Mesrai Rule. Ask clarifying questions if necessary to ensure you have a clear understanding of the user's intent.
+
+3. **Review the existing Mesrai Rule**: Retrieve the current definition of the Mesrai Rule that is being updated. This will help you understand the existing behavior and identify what changes need to be made.
+
+4. **Draft the updated Mesrai Rule**: Based on the user's intent and the existing rule, draft an updated version of the Mesrai Rule that includes the desired changes. Use the guidelines outlined in the "Guidelines for Updating a Mesrai Rule" section to ensure the updated rule is well-structured and effective.
+
+5. **Review the updated Mesrai Rule with the user**: Present the drafted updated Mesrai Rule to the user for feedback. Discuss any potential edge cases, exceptions, or clarifications needed to ensure the updated rule is comprehensive and actionable.
+
+6. **Refine the updated Mesrai Rule**: Based on the user's feedback, refine the updated Mesrai Rule to address any concerns or suggestions. Ensure that the final version of the updated rule is clear, specific, and aligned with the user's goals.
+
+7. **Save and Implement the updated Mesrai Rule**: Once the updated Mesrai Rule is finalized and approved by the user, save it. Send only the fields that were updated, along with the `uuid` to identify which rule to update.
+
+Always include the repository id when updating a rule. Use `global` when the user does not provide one.
+
+Use the following command to save the updated Mesrai Rule:
+
+```
+mesrai rules update --uuid <uuid> [--repo-id <repository-id>] [--title <title>] [--rule <rule-content>] [--severity <severity-level>] [--scope <scope-level>] [--path <glob-pattern>]
+```
+
+If `--repo-id` is omitted, the default repository id is `global`.
+
+8. **Communicate the updated Mesrai Rule**: Inform the user about the updated Mesrai Rule and how the changes will affect future code generation.
+
+## Centralized Config Behavior
+
+When centralized config is enabled, updating a rule may return a centralized PR result instead of an immediate in-database update.
+
+In this case:
+
+1. Report the PR URL (and PR number if present).
+2. State that the update is pending and will be applied after PR merge and sync.
+3. Do not claim the rule content was already updated in the database.
+
+## Guidelines for Updating a Mesrai Rule
+
+1. **Identify the Changes**: Clearly define what changes are being made to the existing Mesrai Rule. Are you modifying the rule's behavior, scope, severity, or other attributes?
+
+2. **Justify the Changes**: Ensure that there is a clear justification for the changes being made to the Mesrai Rule. The updates should contribute to producing code that is more maintainable, efficient, or better aligned with the user's needs.
+
+3. **Consider Edge Cases**: Think about any edge cases or exceptions that might arise from the updated rule. Address these in the updated rule definition to ensure Mesrai can handle them appropriately.
+
+4. **Align with Project Goals**: Ensure that the updated Mesrai Rule continues to align with the overall goals and requirements of the project. The updated rule should contribute to producing code that meets the user's expectations and project requirements.
+
+5. **Review and Refine**: After drafting the updated Mesrai Rule, review it for clarity and completeness. Present it to the user for feedback and refine it as necessary to ensure it effectively guides Mesrai's code generation process.

package/skills/mesrai-mesrai-rules/instructions/view-mesrai-rules.md

@@ -0,0 +1,65 @@
+---
+name: view-mesrai-rules
+description: Mesrai Rule Viewing Guidelines - Use when the user wants to view existing Mesrai Rules that Mesrai follows when generating code.
+---
+
+# Mesrai Rule Viewing Guidelines
+
+## Overview
+
+When viewing existing Mesrai Rules, it's important to understand the details of each rule, including its UUID, title, rule content, severity, scope, and any applicable file patterns. This information helps you understand how Mesrai generates code and what guidelines it follows.
+
+## Workflow for Viewing Mesrai Rules
+
+1. **Retrieve Rule Target**: If the user specified a particular rule(s) to view, identify it using one of:
+    - `--title <title>`
+    - `--uuid <uuid>`
+
+If both are provided, prefer `--uuid`. If no specific rule is requested, prepare to display all existing Mesrai Rules.
+
+2. **Fetch Mesrai Rules**: Use the appropriate command to fetch the Mesrai Rule(s) based on the identified target(s). If no specific rule was requested, fetch all existing Mesrai Rules.
+
+Always include the repository id when fetching rules. Use `global` when the user does not provide one.
+
+Use the following command to fetch Mesrai Rules:
+
+```
+mesrai rules view [--repo-id <repository-id>] [--uuid <uuid>] [--title <title>]
+```
+
+If `--repo-id` is omitted, the default repository id is `global`.
+
+3. **Display Mesrai Rules**: Present the retrieved Mesrai Rule(s) in a clear and organized manner. For each rule, display the following information:
+    - Rule UUID
+    - Repository ID
+    - Rule Title
+    - Rule
+    - Severity (if specified)
+    - Scope (if specified)
+    - Path (if specified)
+
+Do not alter the content of the rules; display them as they are retrieved to ensure accuracy.
+
+4. **Provide Context**: If the user is viewing a specific rule, provide additional context about how that rule is applied in code generation and any relevant examples or use cases.
+
+5. **Answer Follow-up Questions**: Be prepared to answer any follow-up questions the user may have about the Mesrai Rules, such as how to create or update rules, or how specific rules affect code generation.
+
+## Centralized Config Context
+
+When centralized config is enabled, rules may have pending centralized changes.
+
+When relevant, highlight:
+
+- centralized path (`centralizedConfig.path`)
+- centralized status (`pending_add`, `pending_edit`, `pending_delete`, `synced`)
+- whether a previously returned PR URL indicates pending application until merge and sync
+
+## Guidelines for Viewing Mesrai Rules
+
+1. **Be Accurate**: When displaying Mesrai Rules, ensure that the information is accurate and reflects the current state of the rules as retrieved from the system.
+
+2. **Be Clear**: Present the Mesrai Rules in a clear and organized manner, making it easy for the user to understand the details of each rule.
+
+3. **Provide Context**: When appropriate, provide additional context about how specific Mesrai Rules are applied in code generation and how they affect the output.
+
+4. **Be Responsive**: Be prepared to answer any follow-up questions the user may have about the Mesrai Rules, and provide helpful information to guide them in understanding and utilizing the rules effectively.

package/skills/mesrai-mesrai-rules/rules/create-mesrai-rule.md

@@ -0,0 +1,48 @@
+---
+name: create-mesrai-rule
+description: Mesrai Rule Creation Guidelines - Use when the user wants to create a new Mesrai Rule for Mesrai to follow when generating code.
+---
+
+# Mesrai Rule Creation Guidelines
+
+## Overview
+
+When creating a new Mesrai Rule, it's important to ensure that the rule is clear, actionable, and aligned with the overall goals of code generation. A well-defined Mesrai Rule helps Mesrai produce code that meets the user's expectations and project requirements.
+
+## Workflow for Creating a Mesrai Rule
+
+1. **Collect the user's intent**: Understand the specific coding practice, style, or requirement that the user wants to enforce with the new Mesrai Rule. Ask clarifying questions if necessary to ensure you have a clear understanding of the user's intent.
+
+2. **Draft the Mesrai Rule**: Based on the user's intent, draft a Mesrai Rule that includes a clear description, title, and any relevant metadata such as severity and scope. Use the guidelines outlined in the "Guidelines for Creating a Mesrai Rule" section to ensure the rule is well-structured and effective.
+
+3. **Review the Mesrai Rule with the user**: Present the drafted Mesrai Rule to the user for feedback. Discuss any potential edge cases, exceptions, or clarifications needed to ensure the rule is comprehensive and actionable.
+
+4. **Refine the Mesrai Rule**: Based on the user's feedback, refine the Mesrai Rule to address any concerns or suggestions. Ensure that the final version of the rule is clear, specific, and aligned with the user's goals.
+
+5. **Save and Implement the Mesrai Rule**: Once the Mesrai Rule is finalized and approved by the user, save it. Send the title, rule, and any optional fields such as severity, scope, and path.
+
+Use the following command to save the Mesrai Rule:
+
+```
+mesrai rules create --title <title> --rule <rule-content> [--repo-id <repository-id>] [--severity <severity-level>] [--scope <scope-level>] [--path <glob-pattern>]
+```
+
+6. **Communicate the new Mesrai Rule**: Inform the user about the new Mesrai Rule and how it will be applied in future code generation.
+
+## Centralized Config Behavior
+
+When centralized config is enabled, creating a rule may return centralized PR metadata instead of a direct rule record.
+
+In this case, report PR details and clearly explain the rule will only apply after PR merge and sync.
+
+## Guidelines for Creating a Mesrai Rule
+
+1. **Identify the Purpose**: Clearly define what the Mesrai Rule is intended to achieve. Is it meant to enforce a coding style, ensure best practices, or address a specific use case?
+
+2. **Be Specific**: The rule should be specific and unambiguous. Avoid vague language and ensure that the rule can be easily understood and applied by Mesrai.
+
+3. **Consider Edge Cases**: Think about any edge cases or exceptions that might arise when applying the rule. Address these in the rule definition to ensure Mesrai can handle them appropriately.
+
+4. **Align with Project Goals**: Ensure that the Mesrai Rule aligns with the overall goals and requirements of the project. The rule should contribute to producing code that is maintainable, efficient, and meets the user's needs.
+
+5. **Review and Refine**: After drafting the Mesrai Rule, review it for clarity and completeness. Present it to the user for feedback and refine it as necessary to ensure it effectively guides Mesrai's code generation process.