mini-a toolkit
Agents, slash commands, hooks & skills — ready to use.
A curated gallery of reusable agents, slash commands, hooks, and skills for mini-a. Browse, search, and copy-paste straight into your projects.
Add Them To mini-a
Use the default home folder when you want the customization available in every session:
mkdir -p ~/.openaf-mini-a/commands ~/.openaf-mini-a/skills ~/.openaf-mini-a/hooks
1. Add a slash command
Create a markdown template in ~/.openaf-mini-a/commands/<name>.md:
Follow these instructions exactly.
Target: {{arg1}}
Raw args: {{args}}
Parsed args: {{argv}}Run it in the console:
/my-command repo-a --fast "include docs"Run it directly from the CLI:
mini-a exec="/my-command repo-a --fast \"include docs\""Load commands from extra directories:
mini-a extracommands=/path/to/team-commands,/path/to/project-commandsNotes:
- Default commands in
~/.openaf-mini-a/commands/win overextracommands. - Earlier
extracommandspaths win over later ones. - Built-ins such as
/helpstill win over custom commands.
2. Add a skill
mini-a supports two skill layouts:
~/.openaf-mini-a/skills/my-skill/SKILL.md
~/.openaf-mini-a/skills/my-skill.mdExample single-file skill:
Review the current change carefully.
Focus on correctness, edge cases, and missing tests.Invoke it with either form:
/my-skill src/auth
$my-skill src/authLoad skills from extra directories:
mini-a extraskills=/path/to/shared-skills,/path/to/project-skillsNotes:
- Default skills in
~/.openaf-mini-a/skills/win overextraskills. - If a skill and a slash command share the same name, the skill wins.
- Use
/skillsor/skills <prefix>to list discovered skills.
3. Add a hook
Create a hook definition in ~/.openaf-mini-a/hooks/*.yaml, *.yml, or *.json:
name: block-dangerous-shell
event: before_shell
command: "echo \"$MINI_A_SHELL_COMMAND\" | grep -E '(rm -rf|mkfs|dd if=)' >/dev/null && exit 1 || exit 0"
timeout: 1500
failBlocks: trueCommon hook events:
before_goalafter_goalbefore_toolafter_toolbefore_shellafter_shell
Load hooks from extra directories:
mini-a extrahooks=/path/to/team-hooks,/path/to/project-hooksNotes:
- Hooks are additive. mini-a merges hooks from the default folder and all
extrahookspaths. - Matching hooks from multiple directories all run; hooks do not override each other the way commands and skills do.
4. Keep custom files in your repo instead of your home folder
This is useful for team-shared skills, commands, and hooks:
mini-a \
extracommands=.mini-a/commands \
extraskills=.mini-a/skills \
extrahooks=.mini-a/hooksYou can combine repo-local folders with the defaults in ~/.openaf-mini-a/ on the same run.
Browse the Gallery
Code Reviewer
Reviews pull requests and flags issues by severity (critical, warning, suggestion). Integrates with GitHub via MCP.
---
name: code-reviewer
description: Reviews pull requests and flags issues by severity
capabilities:
- useutils
- usetools
tools:
- type: stdio
cmd: npx -y @modelcontextprotocol/server-github
constraints:
- Always cite file and line numbers when flagging issues.
- Categorize findings as: critical, warning, or suggestion.
- Do not suggest stylistic changes unless explicitly asked.
youare: |
You are a senior software engineer performing a thorough code review.
You prioritize correctness and security over style.
mini-a:
useplanning: true
usestream: true
maxsteps: 25
format: json
outfile: review.json
---
Review the staged changes in the current git repository.mini-a agent=code-reviewer.agent.md
Git Changelog Generator
Generates structured changelogs from git history since the last tag. Organizes entries into breaking changes, features, and bug fixes.
---
name: git-changelog
description: Generates structured changelogs from git history
capabilities:
- useshell
- readwrite
constraints:
- Use conventional commit prefixes (feat:, fix:, chore:, etc.).
- Group entries under Breaking Changes, Features, and Bug Fixes.
mini-a:
format: md
outfile: CHANGELOG_draft.md
---
Generate a structured changelog from the git log since the last tag.
Include sections for breaking changes, new features, and bug fixes.mini-a agent=git-changelog.agent.md
Documentation Writer
Writes or updates API documentation from source code. Reads functions, classes, and modules and produces Markdown docs.
---
name: doc-writer
description: Writes documentation from source code
capabilities:
- useutils
- useshell
- readwrite
youare: |
You are a technical writer specializing in developer documentation.
You produce clear, accurate, and well-structured Markdown.
constraints:
- Document every exported function, class, and constant.
- Include parameter types, return types, and examples.
- Use JSDoc/TSDoc-style descriptions where applicable.
mini-a:
format: md
useplanning: true
---
Document all exported symbols in the target file or directory.mini-a agent=doc-writer.agent.md goal="document src/api.js"
Unit Test Writer
Generates unit tests for existing code. Detects the test framework in use and follows project conventions.
---
name: test-writer
description: Generates unit tests for existing code
capabilities:
- useutils
- useshell
- readwrite
youare: |
You are an expert in test-driven development.
You write thorough, well-named tests that cover happy paths and edge cases.
constraints:
- Follow the existing test framework and style conventions.
- Cover happy path, boundary conditions, and error cases.
- Use descriptive test names that explain the behaviour being tested.
mini-a:
useplanning: true
maxsteps: 20
---
Identify the test framework in use, then write comprehensive unit tests
for the specified file or module.mini-a agent=test-writer.agent.md goal="write tests for src/utils.js"
Docker Manager
Manages Docker containers, images, and compose stacks. Diagnoses issues and suggests fixes using shell and MCP tools.
---
name: docker-manager
description: Manages Docker containers and diagnoses issues
capabilities:
- useutils
- useshell
youare: |
You are a senior DevOps engineer specializing in containerisation.
You diagnose issues systematically and always verify before making changes.
constraints:
- Never remove volumes or data without explicit confirmation.
- Always show the command you are about to run before running it.
mini-a:
useplanning: true
usestream: true
---
Diagnose and fix issues with Docker containers, images, or compose stacks.
Use shell commands and MCP tools to investigate and resolve problems.mini-a agent=docker-manager.agent.md goal="check why my compose stack is unhealthy"
Security Auditor
Performs a security audit of a codebase. Identifies vulnerabilities, insecure patterns, and suggests remediations.
---
name: security-auditor
description: Security audit agent for code and configuration
capabilities:
- useutils
- useshell
youare: |
You are an application security engineer specialising in OWASP Top 10,
secrets exposure, injection vulnerabilities, and supply-chain risks.
constraints:
- Assign a CVSS-style severity to every finding (Critical/High/Medium/Low).
- Provide remediation steps for each finding.
- Do not output exploits or payloads.
mini-a:
useplanning: true
deepresearch: true
format: md
outfile: security-report.md
---
Perform a security audit of the specified codebase or module.
Identify vulnerabilities, insecure patterns, and provide remediation steps.mini-a agent=security-auditor.agent.md goal="audit the auth module"
Summary Starter
Shipped `.agent.md` starter aligned with `summary.yaml`. Good baseline for a small, tool-grounded summarization agent.
---
name: summary
description: Agent profile starter aligned with summary.yaml
model: "(type: openai, model: gpt-5-mini, key: '...')"
capabilities:
- useutils
- usetools
# - useshell
# - readwrite
mini-a:
useplanning: true
usestream: false
tools:
- type: ojob
options:
job: mcps/mcp-time.yaml
constraints:
- Prefer tool-grounded outputs.
- Keep responses deterministic and concise.
knowledge: |
Starter context for summary.
youare: |
You are a specialized AI agent for summary workflows.
---
# Notes
- Tune capabilities and tools for your scenario.
- Run with: mini-a agent=examples/summary.agent.md goal="..."mini-a agent=summary.agent.md goal="summarize this project"
Learn From Chat Starter
Shipped `.agent.md` starter aligned with `learn-from-chat.yaml`. Useful as a base profile for extracting patterns or reusable knowledge from prior conversations.
---
name: learn-from-chat
description: Agent profile starter aligned with learn-from-chat.yaml
model: "(type: openai, model: gpt-5-mini, key: '...')"
capabilities:
- useutils
- usetools
# - useshell
# - readwrite
mini-a:
useplanning: true
usestream: false
tools:
- type: ojob
options:
job: mcps/mcp-time.yaml
constraints:
- Prefer tool-grounded outputs.
- Keep responses deterministic and concise.
knowledge: |
Starter context for learn-from-chat.
youare: |
You are a specialized AI agent for learn-from-chat workflows.
---
# Notes
- Tune capabilities and tools for your scenario.
- Run with: mini-a agent=examples/learn-from-chat.agent.md goal="..."mini-a agent=learn-from-chat.agent.md goal="extract durable lessons from this thread"
/git-commit
Generate a meaningful commit message based on the currently staged changes and commit them. Follows conventional commit format and best practices.
---
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
/explain
Explains a file, function, or code snippet in plain language. Great for onboarding or understanding unfamiliar code.
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
/summarize
Summarizes the current conversation or a provided document. Useful for long sessions or handing off context.
{{#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
/translate
Translates code from one language or format to another (e.g., JS → TS, JSON → YAML, Python 2 → 3).
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
/deps
Checks project dependencies for outdated versions and known vulnerabilities. Works with npm, pip, and Maven.
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
/gh-wf-update
Analyzes GitHub Actions workflows to identify outdated action versions and recommend updates. Focuses on security and stability best practices.
---
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
/git-delete-prs
Use the GitHub CLI to close PRs and delete branches. Passes PR numbers or branch names directly to the model.
---
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
/git-branch
Switch to a different branch in the current git repository. Passes the branch name directly to the model.
---
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
/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.
---
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
Shell Guard
Blocks destructive shell commands (rm -rf, mkfs, dd) before they are executed. Exits with code 1 to abort the tool call.
event: before_shell
command: >
echo "$MINI_A_SHELL_COMMAND" |
grep -qE '(rm\s+-[a-zA-Z]*r[a-zA-Z]*f|mkfs|dd\s+if=|:\(\)\{|>\s*/dev/sda)' &&
exit 1 || exit 0
timeout: 1500
failBlocks: truebefore_shell
Response Logger
Appends every model response to a session log file. Useful for audit trails and post-session review.
event: after_goal
command: >
mkdir -p ~/.openaf-mini-a/logs &&
echo "--- $(date -Iseconds) ---" >> ~/.openaf-mini-a/logs/session.log &&
echo "$MINI_A_RESULT" >> ~/.openaf-mini-a/logs/session.log
timeout: 2000
failBlocks: falseafter_goal
Pre-Goal Banner
Prints a formatted banner to the terminal before each goal starts. Helps visually separate runs in long sessions.
event: before_goal
command: >
echo "" >> ~/.openaf-mini-a/logs/session.log &&
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━" >> ~/.openaf-mini-a/logs/session.log &&
echo " mini-a ▸ $(date '+%H:%M:%S')" >> ~/.openaf-mini-a/logs/session.log &&
echo " Goal: $(echo "$MINI_A_GOAL" | head -c 80)" >> ~/.openaf-mini-a/logs/session.log &&
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━" >> ~/.openaf-mini-a/logs/session.log
timeout: 1000
failBlocks: falsebefore_goal
Tool Allow-List
Only allows a predefined set of MCP tool names to be called. All other tools are blocked before execution.
event: before_tool
# Edit the ALLOWED list to match your permitted tools
command: >
ALLOWED="read_file,list_directory,search_files,get_current_time" &&
echo "$ALLOWED" | tr ',' '\n' | grep -qxF "$MINI_A_TOOL_NAME" ||
exit 1
timeout: 500
failBlocks: truebefore_tool
Kubectl Read-Only Guard
Blocks mutating `kubectl` shell commands while allowing read-only inspection commands like `get`, `describe`, and `logs`.
name: kubectl-readonly
event: before_shell
failBlocks: true
injectOutput: false
timeout: 3000
command: |
bash -c '
cmd="$MINI_A_SHELL_COMMAND"
if ! echo "$cmd" | grep -qE "(^|[|;&[:space:]])kubectl([[:space:]]|$)"; then
exit 0
fi
subcmd=$(echo "$cmd" | grep -oP "kubectl\s+\K\S+")
readonly_cmds="get describe logs explain top version api-resources api-versions cluster-info diff"
for allowed in $readonly_cmds; do
[ "$subcmd" = "$allowed" ] && exit 0
done
echo "BLOCKED: kubectl \"$subcmd\" is not a read-only command" >&2
exit 1
'before_shell
Code Review Checklist
A structured skill that guides the model through a rigorous code review checklist covering correctness, security, and performance.
Target: {{arg1}}
Conduct a structured code review of {{arg1}} using the following checklist:
## Correctness
- [ ] Logic is accurate and matches the stated intent
- [ ] Edge cases and error conditions are handled
- [ ] No off-by-one errors or null pointer risks
## Security
- [ ] No hard-coded secrets or credentials
- [ ] Inputs are validated and sanitized
- [ ] Authentication and authorisation checks are present where needed
- [ ] No SQL/command injection risks
## Performance
- [ ] No unnecessary loops or N+1 queries
- [ ] Data structures are appropriate for the access pattern
- [ ] Expensive operations are cached where suitable
## Maintainability
- [ ] Code is readable and self-explanatory
- [ ] Functions are small and single-purpose
- [ ] Tests exist for critical paths
Report findings with file name, line number, severity, and suggested fix./code-review-checklist src/payments/
Explain Code
Explains a piece of code, algorithm, or module in plain English. Suitable for onboarding or documentation generation.
Target: {{arg1}}
Explain the code at {{arg1}} as if teaching a developer who is new to this
codebase but experienced with programming in general.
Structure your explanation as follows:
1. **One-line summary** — what this code does
2. **Context** — where it fits in the broader system
3. **Key concepts** — any algorithms, patterns, or domain terms
4. **Walk-through** — step-by-step explanation of the main logic
5. **Gotchas** — anything surprising or non-obvious/explain-code src/algo/kd-tree.js
Refactor Assistant
Suggests targeted refactoring improvements for a file or function. Preserves behaviour while improving readability and structure.
Target: {{arg1}}
Refactor {{arg1}} to improve readability, maintainability, and structure
without changing observable behaviour.
Apply these principles where applicable:
- Extract long functions into smaller, named helpers
- Replace magic numbers and strings with named constants
- Remove dead code and redundant comments
- Simplify complex conditionals
- Improve variable and function names
For each change, explain the motivation.
Present the refactored code followed by a diff summary./refactor src/legacy/parser.js
README Generator
Generates a comprehensive README.md for a project from its source files and structure.
Inspect the project in the current directory and generate a comprehensive
README.md with the following sections:
1. **Project name and one-line description**
2. **Features** — bullet list of key capabilities
3. **Prerequisites** — required tools and versions
4. **Installation** — copy-paste install commands
5. **Usage** — the most common commands with examples
6. **Configuration** — key environment variables or config files
7. **Contributing** — brief contribution guide
8. **License**
Base all content on the actual code and existing documentation.
Do not invent features that are not present./generate-readme
SQL Query Explainer
Explains and optimises a SQL query. Identifies potential performance issues and suggests improvements with an execution plan analysis.
SQL query:
{{arg1}}
1. Explain what this query does in plain English.
2. Identify potential performance issues (missing indexes, full-table scans,
N+1 subquery patterns, non-sargable predicates).
3. Suggest an optimised version with comments explaining each change.
4. List the indexes that would most improve this query's performance./sql-explain
Add Your Own
Have an agent, slash command, hook or skill worth sharing? Open a pull request on GitHub.