Slash command templates live in ~/.openaf-mini-a/commands/<name>.md. They support Handlebars-style placeholders for arguments.

# Use a slash command in interactive mode
/<name> arg1 arg2

# Run non-interactively
mini-a exec="/<name> arg1 arg2"

# Load a custom commands directory
mini-a extracommands=/path/to/team-commands

Placeholders: · · ·, ``, …

slash command

/git-commit

Generate a meaningful commit message based on the currently staged changes and commit them. Follows conventional commit format and best practices.

gitcommitproductivity
---
name: git-commit
description: Generate a meaningful commit message based on the currently staged changes and commit them.
---

Commit the currently staged files with a meaningful commit message derived from the staged diff.

## Step 1 — Check for staged changes

Run `git diff --cached --name-status`.

If no files are staged, stop and tell the user: _"No staged changes found. Use `git add` to stage files before committing."_

## Step 2 — Gather diff information

Run:

- `git diff --cached --stat` — lines changed per file
- `git diff --cached` — full diff (cap at 300 lines if large)
- `git rev-parse --abbrev-ref HEAD` — current branch name

## Step 3 — Compose the commit message

Analyse the diff and write a commit message:

- **Subject** (line 1): `<type>(<scope>): <short imperative summary>` — max 72 chars, no trailing period
- **Body** (optional, separated by a blank line): explain *what* and *why*; wrap at 72 chars

Pick the type that best fits:

| Type | Use when |
|---|---|
| `feat` | New feature or behaviour |
| `fix` | Bug fix |
| `refactor` | Code restructure, no behaviour change |
| `test` | Adding or updating tests |
| `docs` | Documentation only |
| `chore` | Build, config, deps, tooling |
| `perf` | Performance improvement |
| `style` | Formatting/whitespace only |

Do **not** add AI attribution or "Co-authored-by" lines.

## Step 4 — Show the proposed commit message

Use the `showMessage` tool to display the proposed commit message to the user.

Call `showMessage` with the full commit message text so the user can read it clearly before deciding.

## Step 5 — Ask the user to confirm

Use the `userInput` tool to ask the user whether to proceed:

```json
{
  "operation": "choose",
  "prompt": "Commit with the message above?",
  "options": ["yes", "edit", "cancel"]
}
```

If `userInput` is **not** available, use `AskUserQuestion` to ask:
> "Commit with the message above? Reply **yes**, **edit**, or **cancel**."

If neither tool is available, ask as plain text and wait for the reply.

- **yes** — commit using the message
- **edit** — ask the user for a revised message (via `userInput` or `AskUserQuestion`), then commit with the new version
- **cancel** — abort and do nothing

## Step 6 — Commit and confirm

Run `git commit` using only staged files (no `-a` flag):

- No body: `git commit -m "<subject>"`
- With body: `git commit -m "<subject>" -m "<body>"`

After a successful commit, run `git log -1 --oneline` and show the result.

Remind the user to `git push` if they want to share their changes.

Notes: 'echo' commands are not visible to the user, so use `showMessage` or `userInput` to communicate important information.
/git-commit
slash command

/explain

Explains a file, function, or code snippet in plain language. Great for onboarding or understanding unfamiliar code.

codedocslearning
Target: {{arg1}}

Explain {{arg1}} in plain language suitable for a developer unfamiliar
with this codebase. Cover:
1. Purpose and responsibility
2. Inputs and outputs
3. Key algorithms or patterns used
4. Any gotchas or non-obvious behaviour
/explain src/utils/tokenizer.js
slash command

/summarize

Summarizes the current conversation or a provided document. Useful for long sessions or handing off context.

contextproductivitysummary
{{#if arg1}}Target document: {{arg1}}{{/if}}

Produce a concise summary of {{#if arg1}}{{arg1}}{{else}}the conversation so far{{/if}}.
Include:
- Key decisions made
- Open questions or blockers
- Next steps
/summarize
slash command

/translate

Translates code from one language or format to another (e.g., JS → TS, JSON → YAML, Python 2 → 3).

coderefactormigration
Source: {{arg1}}
Target format: {{arg2}}

Translate {{arg1}} to {{arg2}}.
Preserve all semantics exactly. Add comments where the translation
requires non-obvious choices or where idioms differ between formats.
/translate config.json yaml
slash command

/deps

Checks project dependencies for outdated versions and known vulnerabilities. Works with npm, pip, and Maven.

dependenciessecuritydevops
Inspect the dependency manifest in the current directory
(package.json, requirements.txt, pom.xml, or similar).

For each dependency:
1. Check if a newer version is available.
2. Flag any known CVEs.
3. Suggest the upgrade command.

Output a markdown table with columns: Package | Current | Latest | CVEs.
/deps
slash command

/gh-wf-update

Analyzes GitHub Actions workflows to identify outdated action versions and recommend updates. Focuses on security and stability best practices.

githubcidevopssecurity
---
name: "GitHub Workflow Update Checker"
description: "Analyze GitHub Actions workflows in this repository to identify outdated action versions and recommend updates"
---

## Task
Scan all GitHub Actions workflow files in this repository (typically in `.github/workflows/`) and identify actions that are using outdated versions.

## Steps

1. **Discover workflow files**: Find all YAML workflow files in `.github/workflows/` directory

2. **Extract action references**: For each workflow, identify all `uses:` statements that reference GitHub Actions (format: `owner/repo@version`)

3. **Analyze versions**: For each action:
   - Determine if it uses a version tag (e.g., `\@v1`, `\@v2.1.0`) or a commit SHA
   - Check if the version is a major version pin (recommended) or a specific minor/patch version
   - Identify actions using `@main`, `@master`, or `@latest` (should be pinned to specific versions)

4. **Check for updates**: For each action, determine if a newer version exists:
   - Compare current version against the latest available release
   - Note any security advisories or deprecation notices

5. **Report findings**: Create a summary table with:
   - Action name
   - Current version
   - Latest available version
   - Update urgency (critical/security, recommended, optional)
   - File(s) where used

## Output Format

Present results in a markdown table sorted by update urgency, followed by specific update commands or PR suggestions.

## Best Practices to Enforce

- ✅ Prefer major version tags (e.g., `@v4`) over full semver for stability
- ✅ Never use `@main`, `@master`, or branch names in production workflows
- ⚠️ Flag actions that haven't been updated in over 1 year
- 🔴 Highlight actions with known security vulnerabilities
/gh-wf-update
slash command

/git-delete-prs

Use the GitHub CLI to close PRs and delete branches. Passes PR numbers or branch names directly to the model.

gitgithubclipr-management
---
name: Delete PRs
description: Use the GitHub CLI to close PRs and delete branches.
---

using 'gh' close athe following PRs and delete the corresponding branches: {{args}}
/git-delete-prs 123 124 feature-branch
slash command

/git-branch

Switch to a different branch in the current git repository. Passes the branch name directly to the model.

gitclibranch-management
---
title: git branch
description: Switch to a different branch in the current git repository.
---

change the current folder git repo branch to origin '{{args}}'
/git-branch feature-xyz
slash command

/git-impact

Perform a git impact and risk analysis for the current repository. Assesses both local uncommitted changes and branch-level changes compared to the default branch.

gitrisk analysiscode review
---
name: Git Impact and Risk Analysis
description: A structured approach to assess the impact and risk of changes in a git repository, both for local uncommitted changes and for branch-level changes compared to the default branch.
tags: [git, risk analysis, code review]
---

Perform a git impact and risk analysis for the current repository. Follow these steps:

## Step 1 — Gather git context

Run the following commands to collect data:
- `git rev-parse --abbrev-ref HEAD` — current branch name
- `git remote show origin 2>/dev/null | grep 'HEAD branch' | awk '{print $NF}'` — detect default remote branch (main or master), fallback to checking if `main` or `master` exists locally via `git branch --list main master`
- `git status --short` — uncommitted local changes (staged + unstaged)
- `git diff --stat HEAD` — stats for uncommitted changes vs last commit
- `git diff HEAD -- <each changed file>` — actual diffs for each changed file (limit to first 150 lines per file if too large)
- `git log --oneline $(git merge-base HEAD <default-branch>)..HEAD` — commits in current branch vs default branch
- `git diff --stat $(git merge-base HEAD <default-branch>)..HEAD` — stats for all branch changes vs default branch
- `git diff $(git merge-base HEAD <default-branch>)..HEAD -- <each changed file>` — full diffs for branch-level changes (limit to first 150 lines per file if too large)

## Step 2 — Classify each changed file

For each file changed (both locally and in the branch), classify it:

| Category | Examples | Base Risk |
|---|---|---|
| **Core logic** | main entry points, business logic, algorithms | High |
| **Configuration** | yaml, json, env, package files | Medium-High |
| **API / interfaces** | exported functions, public API, contracts | High |
| **Tests** | test files, specs, fixtures | Low |
| **Documentation** | README, md, docs | Low |
| **Build / CI** | Makefile, Dockerfile, CI pipelines | Medium |
| **Dependencies** | package-lock, yarn.lock, go.sum | Medium-High |
| **Data / Schema** | migrations, schema files, data models | High |
| **Utilities / helpers** | shared utilities, common libs | Medium |

Increase risk if: many lines changed, file has no tests, file is imported/used widely, file is a shared dependency.

## Step 3 — Present two impact reports

### Report A: Local uncommitted changes

Present a table with columns: **File** | **+Lines** | **−Lines** | **Category** | **Risk** | **Impact summary**

Then write a short paragraph explaining the overall risk of committing the current local changes, highlighting the most dangerous files and why.

### Report B: Full branch changes vs `<default-branch>`

Present the same table format for all files changed in the branch (relative to the merge-base with the default branch), grouped by risk level (High → Medium → Low).

Then write a paragraph with an overall branch-level risk assessment:
- What areas of the codebase are affected
- Which files are most likely to break existing functionality if merged
- Whether the change set looks safe to merge or needs extra review/testing
- Any missing tests or risky patterns spotted in the diffs

Use **bold** for high-risk items. Keep the tone factual and actionable.
/git-impact