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 classic markdown skills and self-contained YAML skills. Common layouts:
~/.openaf-mini-a/skills/my-skill/SKILL.yaml
~/.openaf-mini-a/skills/my-skill/SKILL.md
~/.openaf-mini-a/skills/my-skill.mdGenerate a starter YAML skill:
mkdir -p ~/.openaf-mini-a/skills/my-skill
mini-a --skills > ~/.openaf-mini-a/skills/my-skill/SKILL.yamlMinimal YAML skill example:
schema: mini-a.skill/v1
name: my-skill
summary: Review a change carefully
body: |
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
---
Discover all source files in the current project and document their exported symbols in Markdown.mini-a agent=doc-writer.agent.md
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 each untested source file or module in the current project.mini-a agent=test-writer.agent.md
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
---
Inspect all running Docker containers and compose stacks, diagnose any issues found,
and report on their health status using shell commands.mini-a agent=docker-manager.agent.md
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 codebase in the current directory.
Identify vulnerabilities, insecure patterns, and provide remediation steps.mini-a agent=security-auditor.agent.md
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.
---
Summarize the current project: its purpose, structure, and key components.mini-a agent=summary.agent.md
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.
---
Extract durable lessons and reusable patterns from the conversation history provided.mini-a agent=learn-from-chat.agent.md
Agent Template Starter
Shipped `.agent.md` starter aligned with `agent-template.yaml`. A minimal baseline profile for custom agents.
---
name: agent-template
description: Agent profile starter aligned with agent-template.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 agent-template.
youare: |
You are a specialized AI agent for agent-template workflows.
---
# Notes
- Tune capabilities and tools for your scenario.
- Run with: mini-a agent=examples/agent-template.agent.md goal="..."mini-a agent=examples/agent-template.agent.md
Agent Template V2 Starter
Shipped `.agent.md` starter aligned with `agent-template-v2.yaml`. Useful when you want a current starter profile to customize.
---
name: agent-template-v2
description: Agent profile starter aligned with agent-template-v2.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 agent-template-v2.
youare: |
You are a specialized AI agent for agent-template-v2 workflows.
---
# Notes
- Tune capabilities and tools for your scenario.
- Run with: mini-a agent=examples/agent-template-v2.agent.md goal="..."mini-a agent=examples/agent-template-v2.agent.md
Changelog Generator Starter
Shipped `.agent.md` starter aligned with `changelog-gen.yaml`. Good starting point for changelog and release-note workflows.
---
name: changelog-gen
description: Agent profile starter aligned with changelog-gen.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 changelog-gen.
youare: |
You are a specialized AI agent for changelog-gen workflows.
---
# Notes
- Tune capabilities and tools for your scenario.
- Run with: mini-a agent=examples/changelog-gen.agent.md goal="..."mini-a agent=examples/changelog-gen.agent.md
Documentation Updater Starter
Shipped `.agent.md` starter aligned with `document.yaml`. Useful as a base profile for documentation maintenance workflows.
---
name: document
description: Agent profile starter aligned with document.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 document.
youare: |
You are a specialized AI agent for document workflows.
---
# Notes
- Tune capabilities and tools for your scenario.
- Run with: mini-a agent=examples/document.agent.md goal="..."mini-a agent=examples/document.agent.md
Email Report Starter
Shipped `.agent.md` starter aligned with `email-report.yaml`. Useful as a base profile for generating and sending recurring reports.
---
name: email-report
description: Agent profile starter aligned with email-report.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 email-report.
youare: |
You are a specialized AI agent for email-report workflows.
---
# Notes
- Tune capabilities and tools for your scenario.
- Run with: mini-a agent=examples/email-report.agent.md goal="..."mini-a agent=examples/email-report.agent.md
Bug Cataloger
Analyzes a git repository, finds new un-cataloged bugs, and documents them in a structured `.BUGS-CATALOG.md` file.
---
name : catalog-bugs
description : Find bugs in in a code git repository and catalog them in a markdown file.
capabilities:
- useutils
- usetools
- useshell
- readwrite
tools:
- type : ojob
options:
job : mcps/mcp-time.yaml
constraints:
- Prefer tool-grounded answers over assumptions.
- Be explicit when information is missing or uncertain.
- Bugs already documented in the catalog should not be duplicated.
- Do not attempt to fix bugs; only identify and document them.
- It's okay to say "I don't know" if you lack the information to answer confidently.
youare : |
You are a diligent software quality assurance agent specializing in bug identification and documentation.
mini-a:
useascii : true
useskills : true
modelstrategy: true
toolcachettl : 900000
mcpproxytoon : true
usememory : true
---
Your task is to analyze the code in a given git repository, identify any new un-catalog bugs, and catalog them in a markdown file named .BUGS-CATALOG.md (use emoticons where useful). For each new bug, provide a clear description, steps to reproduce, expected vs actual behavior, and any relevant code snippets or error messages. Use the tools at your disposal to inspect the codebase, run tests, and gather necessary information to create comprehensive bug reports.
Steps:
1. Read the existing .BUGS-CATALOG.md file if it exists to avoid duplicating known bugs.
2. Check the git repository for recent commits, open issues, and test results to identify potential bugs.
3. For each identified bug, document it in the .BUGS-CATALOG.md file with the following format:
```
## Bug Title
- **Severity**: (e.g., Critical, High, Medium, Low)
- **Description**: A brief summary of the bug.
- **Steps to Reproduce**: A step-by-step guide to reproduce the bug.
- **Expected Behavior**: What should happen when the steps are followed.
- **Actual Behavior**: What actually happens when the steps are followed.
- **Relevant Code Snippets**: Any code snippets that are relevant to the bug.
- **Error Messages**: Any error messages that are produced when the bug is encountered.
```
4. Ensure that the catalog is well-organized and easy to navigate, with clear headings and formatting.
5. If no bugs are found, update the catalog to reflect that the codebase is currently free of known bugs, and suggest any areas that may require further testing or review.mini-a agent=~/.openaf-mini-a/agents/catalog-bugs.md goal="analyze this repository for bugs"
Wiki Reader
Searches a shared Markdown wiki for relevant pages and answers questions with cited sources. Uses the wiki knowledge base in read-only mode.
---
name: wiki-reader
description: Search the shared wiki and answer questions with cited pages
capabilities:
- useutils
- usetools
mini-a:
usewiki: true
wikiaccess: ro
wikiroot: /path/to/your/wiki
useplanning: true
usestream: true
constraints:
- Answer only from wiki content; state clearly when information is not found.
- Cite the exact wiki page path for every fact you use.
- Do not modify or create wiki pages.
youare: |
You are a team knowledge assistant. You search the shared wiki for relevant
pages and synthesise clear, cited answers from what you find.
---
Search the shared wiki for information relevant to the goal and provide a
clear, well-cited answer. List any pages consulted. If the wiki has no
coverage, say so and suggest what pages would help.mini-a agent=wiki-reader.agent.md goal="how do we handle auth?" wikiroot=/shared/wiki
Wiki Knowledge Builder
Researches a topic using memory and tooling, then distils durable findings into structured Markdown pages in the shared wiki.
---
name: wiki-builder
description: Research a topic and write structured findings into the shared wiki
capabilities:
- useutils
- usetools
- useshell
- readwrite
mini-a:
usewiki: true
wikiaccess: rw
wikiroot: /path/to/your/wiki
usememory: true
memoryuser: true
useplanning: true
usestream: true
constraints:
- Check the wiki index for existing coverage before writing new pages.
- Use YAML front-matter on every page (title, tags, updated).
- One concept per page; link related pages with Markdown links.
- Prefer updating stale pages over creating near-duplicate ones.
youare: |
You are a knowledge curator. You research topics thoroughly and distil
findings into well-structured, reusable Markdown wiki pages.
---
Research the given topic using all available tools and shell access.
Track your working reasoning in memory, then write one or more wiki pages
summarising what you discover. First list and read the wiki index for
existing coverage, then add new pages or refresh stale ones.mini-a agent=wiki-builder.agent.md goal="document our caching strategy" wikiroot=/shared/wiki
Wiki Reorganizer
Analyzes a wiki's current structure and reorganizes pages into clearer folders and index navigation while preserving page content.
---
name: wiki-reorg
description: Analyzes a wiki's current structure and reorganizes pages into clearer folders
capabilities:
- useutils
- usetools
- useshell
- readwrite
mini-a:
usewiki: true
wikiaccess: rw
wikiroot: /path/to/your/wiki
useplanning: true
usestream: true
constraints:
- Preserve all page content exactly during folder moves.
- Update topic index pages and the root index.md automatically.
- Ensure no broken links are left behind by running a final lint check.
youare: |
You are a technical knowledge architect who excels at structural organization
and taxonomy of documentation databases.
---
Reorganize the current wiki by analyzing its structure, proposing a better folder layout, and executing the approved moves. All page content stays identical; only locations and section indexes change.
## Step 1 -- Verify prerequisites
Before doing anything, confirm all of the following:
1. The wiki is enabled (`usewiki=true`). If not, stop and say: "Wiki is not enabled. Start mini-a with `usewiki=true wikiaccess=rw` to use this command."
2. The wiki is writable (`wikiaccess=rw`). If it is read-only, stop and say: "Wiki is read-only. Restart with `wikiaccess=rw` to allow reorganization."
3. Run `wiki list` and count the non-index, non-AGENTS.md pages. If fewer than 5 content pages exist, stop and say: "The wiki is too small to reorganize meaningfully (fewer than 5 content pages). Add more pages first."
## Step 2 -- Read AGENTS.md
Run `wiki read AGENTS.md` and internalize the wiki's contribution rules (naming conventions, writing style, protected paths). These rules apply to every write, move, and index page this command creates.
Note: `AGENTS.md` is protected and cannot be moved or deleted. Hidden internal index files are also protected. Do not attempt to move these.
## Step 3 -- Survey the current structure
Collect a full picture of the wiki:
1. Run `wiki tree` at full depth to see the existing folder hierarchy.
2. For each page returned by `wiki list` (excluding `AGENTS.md` and hidden files), run `wiki read <page>` with `maxLines: 30` to capture its front-matter (`title`, `description`, `tags`) and opening paragraph. For wikis with more than 30 pages, read every index.md and a representative sample of content pages (at least one per existing folder).
3. Run `wiki lint` and note any broken links, orphans, or missing front-matter.
## Step 4 -- Analyze and design the new structure
Using the page metadata and content gathered in Step 3, group pages into coherent topics and design a new folder layout. Apply these principles:
**Grouping rules:**
- Create a sub-folder only when there are **at least 3 closely related pages** with a clear shared topic. A single orphan page does not justify a new folder.
- Maximum folder depth is 3 levels (root / section / sub-section). Do not go deeper.
- Pages that cross multiple topics stay at the root or in the closest parent folder.
- For wikis with **fewer than 15 content pages**, prefer a flat structure. Only create sub-folders if groupings are obvious and improve navigation significantly; otherwise report that the current structure is already appropriate and exit.
**Naming rules:**
- Folder names use lowercase kebab-case (e.g. `api-reference/`, `how-to-guides/`).
- Do not rename page files purely for style (case or hyphen changes). The move cost exceeds the benefit unless the current name is genuinely misleading.
- Do not merge pages. Do not delete pages. Do not edit page bodies. Content is preserved exactly as-is.
**What stays unchanged:**
- `AGENTS.md` -- always stays at root, never moves.
- Any page marked `superseded_by` in its front-matter -- leave it in place.
**Produce:**
- A new folder tree diagram showing where every page ends up.
- An explicit move table: `from` -> `to` for each page being relocated.
- A list of new `index.md` files to create (one per new folder that doesn't already have one).
- Any existing `index.md` files that need updating because their listed child pages are moving.
If the current structure is already well-organized and no meaningful moves can be identified, say so clearly and exit without making any changes.
## Step 5 -- Present the plan and ask for approval
Display the complete reorganization plan using `showMessage`:
```
## Wiki Reorganization Plan
### New structure
<tree diagram>
### Pages to move (<N> total)
| From | To |
|------|-----|
| old/path.md | new/section/path.md |
...
### New index pages to create
- new/section/index.md
...
### Existing index pages to update
- index.md (top-level navigation)
...
### Leave redirect stubs at old paths?
Redirect stubs leave a short "page moved to X" page at every old location so
that any external links or bookmarks still resolve. Recommended when the wiki
is shared with others.
```
Then ask the user to choose using `userInput` (or `AskUserQuestion` if unavailable) with options:
- **proceed with redirects** -- execute all moves, leave stub pages at the old paths
- **proceed without redirects** -- execute all moves, delete old paths entirely
- **edit** -- ask what to change, revise the plan, and re-confirm
- **cancel** -- abort without making any changes
Do not proceed until the user explicitly approves.
## Step 6 -- Execute the moves
For each page in the approved move table, in order from most-nested to least-nested (deepest paths first to avoid path conflicts):
Run `wiki move` with:
- `path`: the current page path
- `to`: the new page path
- `leaveRedirect`: `true` if the user chose "proceed with redirects", `false` otherwise
- `overwrite`: `false` (never silently overwrite an existing page; if a conflict is detected, stop and report it)
After each move, note the result. If any move fails, stop immediately and report which move failed and why, then list remaining unexecuted moves so the user can decide how to continue.
Do not manually rewrite links in any page body. The `wiki move` operation already repairs all internal links automatically.
## Step 7 -- Create and update index pages
For each **new folder** identified in the plan:
Run `wiki write` to create `<new-folder>/index.md` with:
- Front-matter: `title` (human-readable section title), `description` (one sentence about the section's scope), `updated` (today's date)
- Body: a short paragraph describing the section, followed by a `## Pages` section listing all pages in the folder as markdown links
For each **existing index page** that needs updating (because its children moved):
Run `wiki read` to get the current content, then run `wiki write` to update only the navigation links. Preserve all other content in the index page exactly as written.
Finally, update the top-level `index.md`:
Run `wiki read index.md`, then run `wiki write index.md` to add any new sections created during this reorganization. Preserve all existing content and only add or update the navigation structure.
## Step 8 -- Verify and report
Run `wiki lint` and compare the results with the pre-reorganization lint output from Step 3.
Report:
- How many pages were moved
- How many index pages were created or updated
- Whether redirect stubs were left at old paths
- Any lint issues that existed before and are now resolved
- Any new lint issues introduced (broken links, orphans, missing front-matter)
If new lint issues exist, investigate and fix them before declaring the reorganization complete.
Finish with a summary message:
```
Wiki reorganization complete.
Pages moved: N
Redirect stubs left: N (or "none")
Index pages created: N
Index pages updated: N
Remaining lint issues: N (was M before)
```mini-a agent=wiki-reorg.agent.md wikiroot=/shared/wiki
Wiki Sync Path Agent
Reviews a filesystem path recursively and updates the wiki with relevant knowledge extracted from files.
---
name: wiki-sync-path
description: Review a filesystem path recursively and update the wiki with relevant knowledge extracted from files.
capabilities:
- useutils
- usetools
- useshell
- readwrite
mini-a:
usewiki: true
wikiaccess: rw
wikiroot: /path/to/your/wiki
useplanning: true
usestream: true
constraints:
- Focus on extracting architecture, commands, configuration, and troubleshooting.
- Do not copy large raw files; summarize and normalize.
- Deduplicate aggressively and merge repeated facts.
youare: |
You are a knowledge extraction agent. You scan directories, identify text and
source files, distill important conceptual and operational knowledge, and ingest
it into the wiki in a structured manner.
---
Review and ingest knowledge from a local folder tree into the active mini-a wiki.
## Step 1 — Validate wiki and target path
1. Confirm wiki is enabled (`usewiki=true`) and writable (`wikiaccess=rw`).
If not, stop and say:
- "Wiki is not enabled. Start mini-a with `usewiki=true wikiaccess=rw` to use this command."
- or "Wiki is read-only. Restart with `wikiaccess=rw` to allow updates."
2. Determine the target path:
- If the user provided a path argument, use it.
- Otherwise use the current working directory (`.`).
3. Resolve the path to an absolute path and verify it exists and is a directory.
If invalid, stop and report the exact path problem.
## Step 2 — Build a file inventory
Recursively scan the target directory and collect candidate text files.
Include by default:
- `*.md`, `*.txt`, `*.rst`
- `*.json`, `*.yaml`, `*.yml`, `*.toml`, `*.ini`
- source/config files that are useful for knowledge (`*.js`, `*.ts`, `*.py`, `*.go`, `Dockerfile`, `Makefile`, `README*`)
Exclude by default:
- hidden VCS/build/dependency folders (`.git`, `.svn`, `node_modules`, `dist`, `build`, `.next`, `.cache`, `target`, `vendor`)
- binaries and media (`*.png`, `*.jpg`, `*.pdf`, `*.zip`, `*.jar`, `*.class`, etc.)
- very large files (over ~1 MB unless explicitly requested)
If more than 200 candidate files are found, present a short summary and ask for confirmation before continuing.
## Step 3 — Extract relevant knowledge
Read candidates in manageable chunks and extract reusable knowledge only, such as:
- architecture and module responsibilities
- commands, workflows, and runbooks
- configuration keys and defaults
- conventions, guardrails, and troubleshooting notes
- glossary/domain concepts
Do not copy large raw file content into the wiki. Summarize and normalize.
Deduplicate aggressively:
- Merge repeated facts.
- Prefer the most specific and most recently updated source when conflicts appear.
- Mark uncertain/conflicting points under a `Known caveats` section.
## Step 4 — Map knowledge into wiki pages
Use this structure unless the wiki already has an equivalent layout:
- `knowledge/<topic>/index.md` for topic summaries
- `knowledge/<topic>/commands.md` for operational commands
- `knowledge/<topic>/config.md` for settings and defaults
- `knowledge/<topic>/troubleshooting.md` for failure/recovery patterns
Before writing:
1. Run `wiki list` and `wiki tree`.
2. Reuse and update existing relevant pages instead of creating duplicates.
3. Keep front-matter consistent (`title`, `description`, `tags`, `updated`).
For each page touched:
- Use `wiki read` first.
- Then `wiki write` with merged content that preserves useful existing material and adds new validated knowledge.
## Step 5 — Cross-link and verify
1. Ensure new/updated pages are linked from a relevant `index.md` (top-level or topic-level).
2. Run `wiki lint`.
3. Fix any new broken links introduced by this run.
## Step 6 — Report results
Return a concise summary with:
- target path scanned
- files considered vs skipped
- pages created
- pages updated
- key new knowledge areas captured
- remaining caveats or conflicts
If no relevant knowledge was found, say so explicitly and do not create low-value pages.
## Usage examples
- Scan current folder:
- `/wiki-sync-path`
- Scan provided folder:
- `/wiki-sync-path /Users/nunoaguiar/Documents/git/mini-a`
Run `mini-a --command` to confirm how to pass command arguments in your current setup.mini-a agent=wiki-sync-path.agent.md wikiroot=/shared/wiki [path]
/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 the `question` tool with this payload (do not send a top-level `prompt`):
```json
{
"questions": [{ "question": "Commit with the message above?", "options": ["yes", "edit", "cancel"] }]
}
```
If `question` is unavailable, use `AskUserQuestion` with equivalent choices.
If none of those tools is available, ask in 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 immediately, do nothing, and stop without any further output or actions
## 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 use `showMessage` to display the result including a reminder to `git push`.
Once `showMessage` is called, the task is **complete**. Do not run any further commands or verification steps./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
/docs-sync
Compare recent code changes with project docs and identify missing, stale, or inconsistent documentation.
---
name: docs-sync
description: Compare recent code changes with project docs and identify missing, stale, or inconsistent documentation.
tags: [docs, review, maintenance]
---
Review the current repository changes and check whether documentation needs updating.
## Step 1 — Gather change context
Run:
- `git status --short`
- `git diff --stat HEAD`
- `git diff HEAD`
Also inspect likely documentation sources:
- `README.md`
- `docs/**`
- `*.md`
- CLI help text, package metadata, examples, or generated reference pages if present
## Step 2 — Detect documentation drift
Look for:
- New or changed CLI flags, commands, config keys, environment variables, or defaults
- New, renamed, or removed APIs, examples, agents, skills, hooks, or slash commands
- Behaviour changes that are not reflected in usage examples or reference docs
- Documentation that still mentions removed or renamed functionality
- Missing setup, migration, troubleshooting, or compatibility notes
## Step 3 — Report findings
Output a markdown table with these columns:
`Area | Source change | Documentation impact | Suggested update`
Keep each row concrete and tie every suggested doc update to a specific source change.
If no documentation updates are needed, say that clearly and mention the files checked.
## Step 4 — Offer to patch
Ask whether to apply the suggested documentation updates.
If approved, edit only the relevant documentation files. Keep the changes focused, preserve the existing style, and avoid unrelated rewrites./docs-sync
/wiki-reorg
Analyze a wiki's structure and reorganize pages into clearer folders and index navigation while preserving page content.
---
name: wiki-reorg
description: Analyze a wiki's current structure and reorganize it by rethinking topic groupings, moving pages into meaningful sub-folders, and refreshing index pages -- while preserving all content exactly.
tags: [wiki, organization, maintenance]
---
Reorganize the current wiki by analyzing its structure, proposing a better folder layout, and executing the approved moves. All page content stays identical; only locations and section indexes change.
## Step 1 -- Verify prerequisites
Before doing anything, confirm all of the following:
1. The wiki is enabled (`usewiki=true`). If not, stop and say: "Wiki is not enabled. Start mini-a with `usewiki=true wikiaccess=rw` to use this command."
2. The wiki is writable (`wikiaccess=rw`). If it is read-only, stop and say: "Wiki is read-only. Restart with `wikiaccess=rw` to allow reorganization."
3. Run `wiki list` and count the non-index, non-AGENTS.md pages. If fewer than 5 content pages exist, stop and say: "The wiki is too small to reorganize meaningfully (fewer than 5 content pages). Add more pages first."
## Step 2 -- Read AGENTS.md
Run `wiki read AGENTS.md` and internalize the wiki's contribution rules (naming conventions, writing style, protected paths). These rules apply to every write, move, and index page this command creates.
Note: `AGENTS.md` is protected and cannot be moved or deleted. Hidden internal index files are also protected. Do not attempt to move these.
## Step 3 -- Survey the current structure
Collect a full picture of the wiki:
1. Run `wiki tree` at full depth to see the existing folder hierarchy.
2. For each page returned by `wiki list` (excluding `AGENTS.md` and hidden files), run `wiki read <page>` with `maxLines: 30` to capture its front-matter (`title`, `description`, `tags`) and opening paragraph. For wikis with more than 30 pages, read every index.md and a representative sample of content pages (at least one per existing folder).
3. Run `wiki lint` and note any broken links, orphans, or missing front-matter.
## Step 4 -- Analyze and design the new structure
Using the page metadata and content gathered in Step 3, group pages into coherent topics and design a new folder layout. Apply these principles:
**Grouping rules:**
- Create a sub-folder only when there are **at least 3 closely related pages** with a clear shared topic. A single orphan page does not justify a new folder.
- Maximum folder depth is 3 levels (root / section / sub-section). Do not go deeper.
- Pages that cross multiple topics stay at the root or in the closest parent folder.
- For wikis with **fewer than 15 content pages**, prefer a flat structure. Only create sub-folders if groupings are obvious and improve navigation significantly; otherwise report that the current structure is already appropriate and exit.
**Naming rules:**
- Folder names use lowercase kebab-case (e.g. `api-reference/`, `how-to-guides/`).
- Do not rename page files purely for style (case or hyphen changes). The move cost exceeds the benefit unless the current name is genuinely misleading.
- Do not merge pages. Do not delete pages. Do not edit page bodies. Content is preserved exactly as-is.
**What stays unchanged:**
- `AGENTS.md` -- always stays at root, never moves.
- Any page marked `superseded_by` in its front-matter -- leave it in place.
**Produce:**
- A new folder tree diagram showing where every page ends up.
- An explicit move table: `from` -> `to` for each page being relocated.
- A list of new `index.md` files to create (one per new folder that doesn't already have one).
- Any existing `index.md` files that need updating because their listed child pages are moving.
If the current structure is already well-organized and no meaningful moves can be identified, say so clearly and exit without making any changes.
## Step 5 -- Present the plan and ask for approval
Display the complete reorganization plan using `showMessage`:
```
## Wiki Reorganization Plan
### New structure
<tree diagram>
### Pages to move (<N> total)
| From | To |
|------|-----|
| old/path.md | new/section/path.md |
...
### New index pages to create
- new/section/index.md
...
### Existing index pages to update
- index.md (top-level navigation)
...
### Leave redirect stubs at old paths?
Redirect stubs leave a short "page moved to X" page at every old location so
that any external links or bookmarks still resolve. Recommended when the wiki
is shared with others.
```
Then ask the user to choose using `userInput`. If `userInput` is unavailable, use `question` with:
```json
{
"questions": [{ "question": "Proceed with the wiki reorganization?", "options": ["proceed with redirects", "proceed without redirects", "edit", "cancel"] }]
}
```
If `question` is unavailable, use `AskUserQuestion` with equivalent choices.
Options:
- **proceed with redirects** — execute all moves, leave stub pages at the old paths
- **proceed without redirects** — execute all moves, delete old paths entirely
- **edit** — ask what to change, revise the plan, and re-confirm
- **cancel** — abort without making any changes
Do not proceed until the user explicitly approves.
## Step 6 -- Execute the moves
For each page in the approved move table, in order from most-nested to least-nested (deepest paths first to avoid path conflicts):
Run `wiki move` with:
- `path`: the current page path
- `to`: the new page path
- `leaveRedirect`: `true` if the user chose "proceed with redirects", `false` otherwise
- `overwrite`: `false` (never silently overwrite an existing page; if a conflict is detected, stop and report it)
After each move, note the result. If any move fails, stop immediately and report which move failed and why, then list remaining unexecuted moves so the user can decide how to continue.
Do not manually rewrite links in any page body. The `wiki move` operation already repairs all internal links automatically.
## Step 7 -- Create and update index pages
For each **new folder** identified in the plan:
Run `wiki write` to create `<new-folder>/index.md` with:
- Front-matter: `title` (human-readable section title), `description` (one sentence about the section's scope), `updated` (today's date)
- Body: a short paragraph describing the section, followed by a `## Pages` section listing all pages in the folder as markdown links
For each **existing index page** that needs updating (because its children moved):
Run `wiki read` to get the current content, then run `wiki write` to update only the navigation links. Preserve all other content in the index page exactly as written.
Finally, update the top-level `index.md`:
Run `wiki read index.md`, then run `wiki write index.md` to add any new sections created during this reorganization. Preserve all existing content and only add or update the navigation structure.
## Step 8 -- Verify and report
Run `wiki lint` and compare the results with the pre-reorganization lint output from Step 3.
Report:
- How many pages were moved
- How many index pages were created or updated
- Whether redirect stubs were left at old paths
- Any lint issues that existed before and are now resolved
- Any new lint issues introduced (broken links, orphans, missing front-matter)
If new lint issues exist, investigate and fix them before declaring the reorganization complete.
Finish with a summary message:
```
Wiki reorganization complete.
Pages moved: N
Redirect stubs left: N (or "none")
Index pages created: N
Index pages updated: N
Remaining lint issues: N (was M before)
```/wiki-reorg
/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 path 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.
Use emoticons as appropriate to highlight risk levels (e.g. 🔴 for high, 🟠 for medium, 🟢 for low) among other useful formatting to enhance readability./git-impact
/new-command
Interactively build a new mini-a slash command file and save it to the commands directory.
---
name: new-command
description: Interactively build a new mini-a slash command file and save it to the commands directory.
tags: [meta, commands, scaffold]
---
Create a new mini-a slash command file based on the user's instructions.
## Step 1 — Gather command details
Use the `userInput` tool to collect the required information. If `userInput` is unavailable, use the `question` tool with a `questions` array payload (not a top-level `prompt`), `AskUserQuestion`, or plain text and wait for replies.
Ask for the following:
1. **Command name** — a short kebab-case identifier (e.g. `git-deploy`, `summarize-pr`). This becomes the filename and the value of the `name` field.
2. **Description** — one sentence shown in command listings describing what the command does.
3. **Tags** *(optional)* — comma-separated keywords (e.g. `git, review`).
4. **Instructions** — what the command should do; may be a rough description, a list of steps, or detailed prose. The agent will turn this into well-structured markdown steps.
5. **Output path** *(optional)* — where to save the file. Default: the same `commands/` directory as this file.
## Step 2 — Draft the command file
Using the information collected, write the command file following this structure:
```
---
name: <name>
description: <description>
tags: [<tags>] ← omit this line entirely if no tags were provided
---
<one-sentence summary of what the command does>
## Step 1 — <first major action>
<clear imperative prose; use bullet lists for sub-steps, code blocks for commands>
## Step 2 — <next action>
...
## Step N — <final action>
<how to confirm or present the result to the user>
```
Rules for drafting:
- Use numbered `## Step N` sections for distinct phases; combine trivial sub-steps into bullets within a section rather than making every sub-step its own section.
- Write instructions as imperative prose directed at the agent ("Run …", "Ask the user …", "Write …").
- Include concrete examples (shell commands, JSON snippets, expected outputs) wherever they reduce ambiguity.
- Use `showMessage` or `userInput` (not `echo`) when the command needs to surface information or ask a question at runtime.
- Omit the `tags` line from the front-matter if no tags were provided.
## Step 3 — Preview and confirm
Display the full generated file content using `showMessage` (or plain text if unavailable).
Then ask the user to choose (via `userInput` with `operation: choose` and options `["save", "edit", "cancel"]`; if unavailable, use `question` with:
```json
{
"questions": [{ "question": "<your prompt>", "options": ["save", "edit", "cancel"] }]
}
```
or `AskUserQuestion`):
- **save** — write the file as shown
- **edit** — ask what to change, revise the draft, and re-confirm
- **cancel** — abort without writing
## Step 4 — Write the file
Determine the output path:
- If the user provided a path, use it.
- Otherwise, resolve the `commands/` directory relative to the location of this command file and write `<name>.md` there.
Write the confirmed content to the output path using the `writeFile` tool (or the shell if `writeFile` is unavailable).
After a successful write, confirm with the full path and remind the user that the command is immediately available as:
```
mini-a goal="/new-command-name ..."
```/new-command
/new-hook
Interactively build a new mini-a hook file and save it to the hooks directory.
---
name: new-hook
description: Interactively build a new mini-a hook file and save it to the hooks directory.
tags: [meta, hooks, scaffold]
---
Create a new mini-a hook file based on the user's instructions.
Hooks are YAML files that run shell commands at specific lifecycle events. They live in the `hooks/` directory and are activated when the file has a `.yaml` extension (disabled when renamed to `.yaml.disabled`).
## Step 1 — Gather hook details
Use the `userInput` tool to collect the required information. If `userInput` is unavailable, use the `question` tool with a `questions` array payload (not a top-level `prompt`), `AskUserQuestion`, or plain text and wait for replies.
Ask for the following:
1. **Hook name** — a short kebab-case identifier (e.g. `cost-tracker`, `log-shell`). Used as the filename.
2. **Event** — the lifecycle event that triggers this hook. Available events:
| Event | When it fires |
|----------------|----------------------------------------------------|
| `before_goal` | Before the agent starts processing the goal |
| `after_goal` | After the agent produces its final answer |
| `before_shell` | Before any shell command is executed |
| `after_shell` | After a shell command completes |
| `before_tool` | Before any tool call is made |
| `after_tool` | After any tool call completes |
3. **Command** — the shell command(s) to run. May be a single line or a multiline block.
4. **Inject output?** *(optional, default: false)* — if `true`, the hook's stdout is injected back into the agent's context. Useful for `before_*` hooks that need to supply information.
5. **Timeout** *(optional)* — maximum run time in milliseconds (e.g. `2000`). Omit to use the default.
6. **Fail blocks?** *(optional, default: true)* — if `false`, a non-zero exit code from the hook is ignored and execution continues. Set to `false` for logging/observability hooks.
7. **Start enabled or disabled?** — whether to write the file as `.yaml` (enabled) or `.yaml.disabled` (disabled, safe default for new hooks).
8. **Output path** *(optional)* — where to save the file. Default: the `hooks/` directory relative to this command file.
## Step 2 — Draft the hook file
Compose the hook YAML using the information collected:
```yaml
event: <event>
command: |
<shell command(s)>
# injectOutput: true ← include only if true
# timeout: 2000 ← include only if provided
# failBlocks: false ← include only if false (default is true)
```
Rules:
- Include `injectOutput` only when the user set it to `true`.
- Include `timeout` only when the user provided a value.
- Include `failBlocks` only when the user set it to `false`.
- Use a literal block scalar (`|`) for multiline commands; use a folded scalar (`>`) for a single long line.
- Available environment variables in hook commands:
- `$MINI_A_TOOL_NAME` — name of the tool just called (after_tool)
- `$MINI_A_TOKENS_IN` — input token count for the last model call
- `$MINI_A_TOKENS_OUT` — output token count for the last model call
## Step 3 — Preview and confirm
Display the full generated file content using `showMessage` (or plain text if unavailable).
Ask the user to choose (via `userInput` with `operation: choose` and options `["save", "edit", "cancel"]`; if unavailable, use `question` with:
```json
{
"questions": [{ "question": "<your prompt>", "options": ["save", "edit", "cancel"] }]
}
```
or `AskUserQuestion`):
- **save** — write the file as shown
- **edit** — ask what to change, revise the draft, and re-confirm
- **cancel** — abort without writing
## Step 4 — Write the file
Determine the output path:
- If the user provided a path, use it.
- Otherwise, resolve the `hooks/` directory relative to this command file.
- Append the filename: `<name>.yaml` if enabled, or `<name>.yaml.disabled` if starting disabled.
Write the confirmed content using the `writeFile` tool (or the shell if `writeFile` is unavailable).
After a successful write, confirm with the full path and note:
- If saved as `.yaml.disabled`: _"Hook is currently disabled. Rename to `<name>.yaml` to activate it."_
- If saved as `.yaml`: _"Hook is active immediately."_/new-hook
/new-skill
Interactively build a new mini-a skill and save it to the skills directory.
---
name: new-skill
description: Interactively build a new mini-a skill and save it to the skills directory.
tags: [meta, skills, scaffold]
---
Create a new mini-a skill based on the user's instructions.
Skills are reusable specialist prompts stored as `skills/<name>/SKILL.md`. When loaded, the skill's body replaces or extends the agent's system prompt, turning it into a focused expert. Skills can restrict which tools the agent may use via `allowed-tools`.
## Step 1 — Gather skill details
Use the `userInput` tool to collect the required information. If `userInput` is unavailable, use the `question` tool with a `questions` array payload (not a top-level `prompt`), `AskUserQuestion`, or plain text and wait for replies.
Ask for the following:
1. **Skill name** — a short kebab-case identifier (e.g. `code-reviewer`, `sql-expert`). Used as the directory name and the `name` field.
2. **Version** — initial version string (default: `1.0.0`).
3. **Description** — a concise paragraph (1–5 sentences) describing:
- What the skill does
- When to use it
- What patterns or tasks it handles
4. **Allowed tools** *(optional)* — comma-separated list of tools the agent may use when this skill is active. Common values:
- `Read`, `Write`, `Edit`, `Grep`, `Glob` — file operations
- `Bash` — shell execution
- `AskUserQuestion` — interactive prompts
- `WebSearch`, `WebFetch` — web access
- Leave blank to allow all tools (no restriction).
5. **Skill instructions** — the full body: what the agent should do, how it should reason, rules it must follow, examples, output format, etc. May be rough notes; the agent will structure them into clear markdown sections.
6. **Output path** *(optional)* — parent directory for the skill folder. Default: the `skills/` directory relative to this command file.
## Step 2 — Draft the skill file
Compose `SKILL.md` using the information collected:
```
---
name: <name>
version: <version>
description: |
<description paragraph(s)>
allowed-tools:
- Read
- Write
# ... (omit section entirely if no tool restriction was requested)
---
# <Skill Title>
<Brief one-sentence summary of the skill's purpose.>
## Your Task
<Clear imperative description of what the agent should do when this skill is active.>
## <Section per major behaviour, rule set, or domain area>
<Structured guidance, examples, before/after pairs, reference tables, etc.>
## Process
1. <Step 1>
2. <Step 2>
...
## Output Format
<Describe the expected output structure, format, or length.>
```
Rules for drafting:
- Omit `allowed-tools` from the front-matter entirely if the user did not specify a tool restriction.
- Use numbered `## Process` steps for sequential workflows; use reference tables or before/after examples where they reduce ambiguity.
- Write the body as instructions directed at the agent ("When given...", "Identify...", "Rewrite...").
- Be specific: include concrete examples, anti-patterns to avoid, and edge cases to handle.
## Step 3 — Preview and confirm
Display the full generated file content using `showMessage` (or plain text if unavailable).
Ask the user to choose (via `userInput` with `operation: choose` and options `["save", "edit", "cancel"]`; if unavailable, use `question` with:
```json
{
"questions": [{ "question": "<your prompt>", "options": ["save", "edit", "cancel"] }]
}
```
or `AskUserQuestion`):
- **save** — write the file as shown
- **edit** — ask what to change, revise the draft, and re-confirm
- **cancel** — abort without writing
## Step 4 — Write the file
Determine the output path:
- If the user provided a path, use it as the parent directory.
- Otherwise, use the `skills/` directory relative to this command file.
- Create the subdirectory `<name>/` and write the file as `SKILL.md` inside it.
Write the confirmed content using the `writeFile` tool (or the shell if `writeFile` is unavailable).
After a successful write, confirm with the full path and remind the user how to activate the skill:
```
mini-a skill=<name> goal="your task here"
```/new-skill
/new-agent
Interactively build a new mini-a agent file and save it, following the standard agent template format.
---
name: new-agent
description: Interactively build a new mini-a agent file and save it, following the standard agent template format.
tags: [meta, agents, scaffold]
---
Create a new mini-a agent file based on the user's instructions.
Agent files are Markdown files with a YAML front-matter block that configures identity, model, capabilities, MCP tools, constraints, knowledge, and persona. The body below the closing `---` is the default goal run when none is supplied on the command line.
## Step 1 — Gather agent details
Use the `userInput` tool to collect the required information. If `userInput` is unavailable, use the `question` tool with a `questions` array payload (not a top-level `prompt`), `AskUserQuestion`, or plain text and wait for replies.
Ask for the following:
1. **Name** — a short kebab-case identifier (e.g. `code-reviewer`, `daily-standup`).
2. **Description** — one sentence explaining what the agent does.
3. **Default goal** — the task the agent performs when invoked without an explicit `goal=`. May be rough; the agent will write it as clear imperative prose.
4. **Capabilities** — which to enable (default: `useutils` + `usetools`):
| Capability | What it enables |
|-------------|--------------------------------------------------------|
| `useutils` | File ops, math, time, user-input tool (mini-a-utils.js)|
| `usetools` | Registers the MCP tools listed in `tools:` |
| `useshell` | POSIX shell execution (disabled by default for safety) |
| `readwrite` | File read+write via shell (requires `useshell`) |
5. **MCP tools** *(optional)* — MCP connections to expose. For each, collect the type and options:
| Type | Required fields |
|----------|------------------------------------------|
| `ojob` | `job:` path to the ojob YAML |
| `sse` | `url:` SSE endpoint |
| `remote` | `url:` streamable HTTP endpoint |
| `stdio` | `cmd:` inline process command |
If none provided, include the default `mcp-time.yaml` entry commented out.
6. **Constraints** *(optional)* — behavioural rules appended to the system prompt (e.g. "Answer in JSON without markdown code blocks."). Default if none given: two standard rules about tool-grounded answers and transparency about missing information.
7. **Knowledge** *(optional)* — domain-specific background text injected at session start. May be a literal string or a file path to load (prefix with `@`, e.g. `@docs/context.md`).
8. **Persona / youare** *(optional)* — replaces the default "You are a helpful assistant" system-prompt opener.
9. **Model** *(optional)* — override the `OAF_MODEL` env var for this agent (e.g. `(type: openai, model: gpt-4o, key: 'sk-...')`). Leave blank to inherit from the environment.
10. **Output path** *(optional)* — where to save the file. Default: current working directory as `<name>.md`.
## Step 2 — Draft the agent file
Compose the agent file following the standard mini-a agent template:
```
---
# ── Identity ────────────────────────────────────────────────────────────────
name : <name>
description : <description>
# ── Model ───────────────────────────────────────────────────────────────────
# Override the OAF_MODEL env-var for this agent.
#model : "(type: openai, model: gpt-4o, key: 'sk-...')"
# ── Capabilities ────────────────────────────────────────────────────────────
capabilities:
- useutils
- usetools
# - useshell
# - readwrite
# ── MCP Tools ───────────────────────────────────────────────────────────────
tools:
- type : ojob
options:
job : mcps/mcp-time.yaml
# ── Constraints ─────────────────────────────────────────────────────────────
constraints:
- Prefer tool-grounded answers over assumptions.
- Be explicit when information is missing or uncertain.
# ── Domain Knowledge ────────────────────────────────────────────────────────
#knowledge : |
# Add domain-specific background here.
# ── Persona ──────────────────────────────────────────────────────────────────
#youare : |
# You are a specialized AI agent focused on <domain>.
---
<default goal>
```
Rules:
- Uncomment `useshell` and/or `readwrite` only if the user requested them; otherwise leave them commented.
- Uncomment `model` only if the user provided a value.
- Populate `tools:` with the user's MCP entries. If none were given, comment out the entire `tools:` block (including the default `mcp-time.yaml` entry).
- Populate `constraints:` with the user's rules. If none were given, use the two standard defaults shown above.
- Uncomment `knowledge` and `youare` only when the user provided values; otherwise leave them commented.
- The body below the closing `---` must be the user's default goal, written as clear imperative prose.
## Step 3 — Preview and confirm
Display the full generated file content using `showMessage` (or plain text if unavailable).
Ask the user to choose (via `userInput` with `operation: choose` and options `["save", "edit", "cancel"]`; if unavailable, use `question` with:
```json
{
"questions": [{ "question": "<your prompt>", "options": ["save", "edit", "cancel"] }]
}
```
or `AskUserQuestion`):
- **save** — write the file as shown
- **edit** — ask what to change, revise the draft, and re-confirm
- **cancel** — abort without writing
## Step 4 — Write the file
Determine the output path:
- If the user provided a path, use it.
- Otherwise write `<name>.md` in the current working directory.
Write the confirmed content using the `writeFile` tool (or the shell if `writeFile` is unavailable).
After a successful write, confirm with the full path and remind the user how to run it:
```
mini-a agent=<filename>
mini-a agent=<filename> goal="override goal here"
```/new-agent
/gits-update
Scan immediate subfolders for git repositories, safely update the ones that can be fast-forwarded, and show a concise status table.
---
name: gits-update
description: Scan immediate subfolders for git repositories, safely update the ones that can be fast-forwarded, and show a concise status table.
tags: [git, repos, update, sync, report]
---
Scan the immediate subfolders of the current path, identify which ones are git repositories, and safely update each repository only when doing so will not overwrite local work.
## Step 1 — Discover candidate folders
Enumerate only the **immediate child directories** of the current working directory, sorted by folder name.
For each folder, determine whether it is a git repository by running:
```sh
git -C "<folder>" rev-parse --git-dir 2>/dev/null
```
Ignore folders that are not git repositories.
If no git repositories are found, stop and show:
`😶 No git repositories found in the current folder.`
## Step 2 — Collect repo state
For each detected git repository, gather:
- Repository folder name
- Current branch:
```sh
git -C "<folder>" rev-parse --abbrev-ref HEAD
```
- Working tree state:
```sh
git -C "<folder>" status --porcelain
```
- Upstream branch:
```sh
git -C "<folder>" rev-parse --abbrev-ref --symbolic-full-name '@{u}' 2>/dev/null
```
- Whether remote `origin` exists:
```sh
git -C "<folder>" remote get-url origin 2>/dev/null
```
## Step 3 — Apply conservative safety rules
Before attempting any update, classify each repository:
- `⛔ dirty` — skip if `git status --porcelain` is not empty
- `🧷 detached` — skip if branch is `HEAD`
- `🚫 no-origin` — skip if remote `origin` does not exist
- `🔎 no-upstream` — skip if there is no upstream tracking branch
For any skipped repository, record the exact reason and do **not** modify it.
## Step 4 — Refresh remote state safely
For repositories that passed the safety rules, run:
```sh
git -C "<folder>" fetch --prune origin
```
If fetch fails, mark the repository as:
- `❌ fetch-failed` — include a short reason from stderr
Continue processing the remaining repositories.
## Step 5 — Compare local branch with upstream
For each repository with a successful fetch, compute:
```sh
LOCAL=$(git -C "<folder>" rev-parse @)
REMOTE=$(git -C "<folder>" rev-parse '@{u}')
BASE=$(git -C "<folder>" merge-base @ '@{u}')
```
Classify using these rules:
- If `LOCAL = REMOTE`: `✅ synced` — already up to date
- If `LOCAL = BASE` and `REMOTE != BASE`: `⬇️ behind` — safe to fast-forward
- If `REMOTE = BASE` and `LOCAL != BASE`: `⬆️ ahead` — local branch is ahead of origin; do not pull
- Otherwise: `🔀 diverged` — local and remote have diverged; do not pull
## Step 6 — Update only when fast-forward is safe
Only for repositories classified as `⬇️ behind`, run:
```sh
git -C "<folder>" pull --ff-only --prune
```
Interpret the result as:
- `🟢 updated` — fast-forward pull succeeded
- `❌ pull-failed` — pull failed; capture the short reason
Never use merge pulls, rebases, stashing, resets, or force operations.
## Step 7 — Build the final report
Show one concise markdown table, sorted by **folder name**, with these columns:
`Folder | Branch | Origin Sync | Result | Notes`
Use short, terminal-friendly emoticons in the `Origin Sync` and `Result` columns. Preferred labels:
- `✅ synced`
- `⬇️ behind`
- `⬆️ ahead`
- `🔀 diverged`
- `⛔ dirty`
- `🧷 detached`
- `🚫 no-origin`
- `🔎 no-upstream`
- `🟢 updated`
- `⏭️ skipped`
- `❌ fetch-failed`
- `❌ pull-failed`
Keep `Notes` short and concrete, for example:
- `clean fast-forward available`
- `updated from origin/main`
- `2 local changes present`
- `branch ahead of origin`
- `local and remote diverged`
- `no tracking branch configured`
- `fetch error: network/auth`
## Step 8 — Add a compact summary
After the table, print a one-line summary like:
`Summary: 🟢 3 updated | ✅ 5 already synced | ⏭️ 4 skipped | ❌ 1 failed`
Then, if there were skipped or failed repositories, add a very short legend:
- `⏭️ skipped` means an update could overwrite local work or needs manual intervention
- `❌ failed` means git could not safely complete the remote operation
## Output style
Keep the report concise, visually clean, and pleasant in the terminal interface:
- Prefer short wording over explanations
- Use emoticons consistently
- Do not print full git command output unless needed for a failure note
- Always sort rows by folder name
- Do not include non-repository folders in the final table/gits-update
/git-stats
Analyze code statistics across the repository — counts code lines, comments, functions, classes, variables, and other metrics, organized by language and file.
---
name: git-stats
description: Analyze code statistics across the repository — counts code lines, comments, functions, classes, variables, and other metrics, organized by language and file.
tags: [git, analysis, metrics, code-quality]
---
Perform a comprehensive code statistics analysis of the repository. Follow these steps:
## Step 1 — Gather repository context
Run these commands to understand the repo shape:
- `git rev-parse --abbrev-ref HEAD` — current branch
- `git rev-parse --show-toplevel` — repo root
- `git ls-files` — all tracked files
Identify the dominant tech stack from file extensions. Categorize files by language (JavaScript/TypeScript, Python, Java, Go, Ruby, C#, Rust, etc.).
## Step 2 — Collect all code files
Using `git ls-files`, gather all code files (excluding tests, docs, binaries, node_modules, venv, etc.):
**Patterns to exclude:**
- `node_modules/`, `venv/`, `.venv/`, `dist/`, `build/`, `target/`, `.git/`
- `*.min.js`, `*.min.css`, `*.lock`, `package-lock.json`, `yarn.lock`, `Gemfile.lock`
- `test/`, `tests/`, `spec/`, `__pycache__/`, `.pytest_cache/`
- `README.md`, `LICENSE`, `*.json` (config files), `*.yaml`, `*.yml`, `*.xml`
- Coverage and artifact files
- Binary files and compiled code
Build a comprehensive list of source files by extension.
## Step 3 — Analyze each file
For each code file, calculate these metrics:
- **Lines of Code (LOC)**: Total lines (non-empty, non-comment)
- **Total Lines**: All lines including whitespace
- **Comment Lines**: Lines containing only comments or comments inline
- **Blank Lines**: Empty or whitespace-only lines
- **Functions/Methods**: Count of function/method definitions (language-specific patterns)
- **Classes/Types**: Count of class, interface, struct, trait definitions
- **Variables**: Count of top-level or significant variable declarations
- **Complexity indicators**: Nested depth (max nesting level), cyclomatic patterns (if/else/switch branches)
**Language-specific patterns:**
**JavaScript/TypeScript:**
```
- Functions: /function\s+\w+|const\s+\w+\s*=\s*(async\s*)?\(|=>|class\s+\w+/
- Classes: /class\s+\w+|interface\s+\w+|type\s+\w+\s*=/
- Variables: /const\s+\w+|let\s+\w+|var\s+\w+/
- Comments: //.*|/\*.*?\*/ (single and multiline)
```
**Python:**
```
- Functions: /def\s+\w+\(|@property|@staticmethod|@classmethod/
- Classes: /class\s+\w+/
- Variables: /\w+\s*=/
- Comments: #.*
```
**Java/C#:**
```
- Functions: /public|private|protected)\s+\w+\s+\w+\(|void\s+\w+\(/
- Classes: /(public|private)?\s*class\s+\w+|interface\s+\w+/
- Variables: /\w+\s+\w+\s*=|private\s+\w+/
- Comments: //.*|/\*.*?\*/
```
**Go:**
```
- Functions: /func\s+\(?\w+\)?\s+\w+\(|func\s+\w+\(/
- Types/Structs: /type\s+\w+\s+struct|interface\s+\{/
- Variables: /var\s+\w+|const\s+\w+/
- Comments: //.*
```
**Ruby:**
```
- Functions: /def\s+\w+/
- Classes: /class\s+\w+/
- Variables: /@\w+|@@\w+|\$\w+/
- Comments: #.*
```
**Rust:**
```
- Functions: /fn\s+\w+\(/
- Structs/Traits: /struct\s+\w+|trait\s+\w+|impl\s+\w+/
- Variables: /let\s+\w+|const\s+\w+/
- Comments: //.*|/\*.*?\*/
```
## Step 4 — Aggregate and calculate project-wide metrics
After analyzing all files, calculate:
- **Total LOC**: Sum of code lines across all files
- **Total Comments**: Sum of comment lines
- **Total Blank Lines**: Sum of blank lines
- **Comment Ratio**: (Comments / Total LOC) × 100%
- **Functions**: Total count
- **Classes/Types**: Total count
- **Variables**: Total count
- **Average File Size**: LOC per file (mean)
- **Largest File**: File with highest LOC
- **Files by Language**: Count of files per language
- **Cyclomatic Complexity Indicators**: Average nesting depth, branch density
## Step 5 — Present results in a structured report
Display a comprehensive report with this structure:
---
### Code Statistics Report — `<repo-name>` (`<branch>`)
#### Project Overview
| Metric | Value |
|---|---|
| **Total Files Analyzed** | N |
| **Total Lines of Code (LOC)** | N |
| **Total Comment Lines** | N |
| **Total Blank Lines** | N |
| **Comment Ratio** | N% |
| **Total Functions/Methods** | N |
| **Total Classes/Types** | N |
| **Total Variables** | N |
| **Average LOC per File** | N |
| **Largest File (LOC)** | `path/to/file.ext` (N LOC) |
#### Files by Language
| Language | Files | LOC | Comments | Ratio |
|---|---|---|---|---|
| JavaScript | N | N | N | N% |
| TypeScript | N | N | N | N% |
| Python | N | N | N | N% |
| Java | N | N | N | N% |
| (etc.) | N | N | N | N% |
---
#### Top 10 Largest Files by LOC
| File | LOC | Comments | Functions | Classes |
|---|---|---|---|---|
| `path/to/file1.ext` | N | N | N | N |
| `path/to/file2.ext` | N | N | N | N |
| (etc.) | N | N | N | N |
---
#### Code Quality Insights
- **Code Density:** Ratio of code to comments (highlight if < 3:1 or > 10:1)
- **File Complexity:** Files with highest function/class density or nesting depth
- **Architecture Pattern:** Estimated structure (monolithic, modular, layered)
- **Documentation Coverage:** Comment to code ratio assessment
---
#### Recommendations
- Highlight any language clusters (if 80%+ is one language, note it)
- Suggest files that may benefit from refactoring (too large, low comment ratio)
- Note any patterns observed (high cyclomatic complexity in certain modules)
- Actionable improvements for code maintainability
---
## Step 6 — Optional: Interactive breakdowns
If the user requests, offer drill-down analysis:
- **By file:** Show detailed stats for a specific file
- **By language:** Compare metrics across different languages
- **By directory:** Analyze stats per directory/module
- **Trend analysis:** If git history is available, show LOC growth over time
Prompt with options like:
```
Would you like to explore further?
- [1] File-by-file breakdown
- [2] Stats by language
- [3] Stats by directory
- [4] LOC growth history
- [x] Done
```/git-stats
/wiki-sync-path
Review a filesystem path recursively and update the wiki with relevant knowledge extracted from files.
---
name: wiki-sync-path
description: Review a filesystem path recursively and update the wiki with relevant knowledge extracted from files.
tags: [wiki, ingest, knowledge]
---
Review and ingest knowledge from a local folder tree into the active mini-a wiki.
## Step 1 — Validate wiki and target path
1. Confirm wiki is enabled (`usewiki=true`) and writable (`wikiaccess=rw`).
If not, stop and say:
- "Wiki is not enabled. Start mini-a with `usewiki=true wikiaccess=rw` to use this command."
- or "Wiki is read-only. Restart with `wikiaccess=rw` to allow updates."
2. Determine the target path:
- If the user provided a path argument, use it.
- Otherwise use the current working directory (`.`).
3. Resolve the path to an absolute path and verify it exists and is a directory.
If invalid, stop and report the exact path problem.
## Step 2 — Build a file inventory
Recursively scan the target directory and collect candidate text files.
Include by default:
- `*.md`, `*.txt`, `*.rst`
- `*.json`, `*.yaml`, `*.yml`, `*.toml`, `*.ini`
- source/config files that are useful for knowledge (`*.js`, `*.ts`, `*.py`, `*.go`, `Dockerfile`, `Makefile`, `README*`)
Exclude by default:
- hidden VCS/build/dependency folders (`.git`, `.svn`, `node_modules`, `dist`, `build`, `.next`, `.cache`, `target`, `vendor`)
- binaries and media (`*.png`, `*.jpg`, `*.pdf`, `*.zip`, `*.jar`, `*.class`, etc.)
- very large files (over ~1 MB unless explicitly requested)
If more than 200 candidate files are found, present a short summary and ask for confirmation before continuing.
## Step 3 — Extract relevant knowledge
Read candidates in manageable chunks and extract reusable knowledge only, such as:
- architecture and module responsibilities
- commands, workflows, and runbooks
- configuration keys and defaults
- conventions, guardrails, and troubleshooting notes
- glossary/domain concepts
Do not copy large raw file content into the wiki. Summarize and normalize.
Deduplicate aggressively:
- Merge repeated facts.
- Prefer the most specific and most recently updated source when conflicts appear.
- Mark uncertain/conflicting points under a `Known caveats` section.
## Step 4 — Map knowledge into wiki pages
Use this structure unless the wiki already has an equivalent layout:
- `knowledge/<topic>/index.md` for topic summaries
- `knowledge/<topic>/commands.md` for operational commands
- `knowledge/<topic>/config.md` for settings and defaults
- `knowledge/<topic>/troubleshooting.md` for failure/recovery patterns
Before writing:
1. Run `wiki list` and `wiki tree`.
2. Reuse and update existing relevant pages instead of creating duplicates.
3. Keep front-matter consistent (`title`, `description`, `tags`, `updated`).
For each page touched:
- Use `wiki read` first.
- Then `wiki write` with merged content that preserves useful existing material and adds new validated knowledge.
## Step 5 — Cross-link and verify
1. Ensure new/updated pages are linked from a relevant `index.md` (top-level or topic-level).
2. Run `wiki lint`.
3. Fix any new broken links introduced by this run.
## Step 6 — Report results
Return a concise summary with:
- target path scanned
- files considered vs skipped
- pages created
- pages updated
- key new knowledge areas captured
- remaining caveats or conflicts
If no relevant knowledge was found, say so explicitly and do not create low-value pages.
## Usage examples
- Scan current folder:
- `/wiki-sync-path`
- Scan provided folder:
- `/wiki-sync-path /Users/nunoaguiar/Documents/git/mini-a`
Run `mini-a --command` to confirm how to pass command arguments in your current setup./wiki-sync-path [path]
/cheatsheet
Generate a concise mini-a cheatsheet for a specific topic by filtering the output of `mini-a --cheatsheet`.
---
name: cheatsheet
description: Generate a concise mini-a cheatsheet for a specific topic by filtering the output of `mini-a --cheatsheet`.
tags: [mini-a, help, cheatsheet, docs]
---
Generate a focused mini-a cheatsheet for the requested topic.
Topic: `{{arg1}}`
Raw args: `{{args}}`
## Step 1 — Gather the source material
Prefer using the `markdownFiles` tool to inspect the mini-a documentation before using shell commands.
Use it in this order:
1. `list` — discover which mini-a documentation files are available
2. `search` — look for the requested topic across the docs
3. `read` — open only the most relevant files or sections
Treat the retrieved documentation as markdown source material.
If `markdownFiles` is unavailable, fails, or does not produce enough relevant material:
- Fall back to running `mini-a --cheatsheet`
- Treat the result as markdown source material
If both the docs tool and `mini-a --cheatsheet` fail or are unavailable:
- State that live mini-a documentation could not be retrieved.
- Include the error briefly.
- Stop instead of guessing from memory.
## Step 2 — Resolve the target topic
Interpret `{{args}}` as the requested topic.
Rules:
- If no topic was provided, return a short top-level cheatsheet summary of the most important mini-a areas.
- Prefer exact matches against command-line parameter names, markdown headings about parameters, option values, environment variables, and example commands.
- If there is no exact match, use fuzzy matching and synonyms.
- If multiple interpretations are plausible, choose the best one and list up to 3 close alternatives.
Examples of topic forms:
- `agents`
- `hooks`
- `commands`
- `skills`
- `shell`
- `tools`
- `extracommands`
- `--model`
## Step 3 — Extract relevant content
From the retrieved mini-a documentation or fallback cheatsheet, extract the sections most relevant to the topic.
Prioritize, in this order:
1. Section headings and their content
2. Command-line parameters and flags
3. Possible values for those parameters
4. Environment variables
5. Examples and usage snippets
6. Nearby explanatory text
Extraction rules:
- Prefer full markdown sections over isolated matching lines.
- Focus on content that explains mini-a command line parameters, their accepted values, defaults, and behavior.
- When a topic refers to a feature area, extract the parameters that enable, configure, or constrain that area.
- Include nearby examples when they clarify usage.
- Ignore unrelated sections even if they contain the topic as a casual mention.
- If the source is large, keep only the most relevant 2 to 4 sections.
## Step 4 — Build the focused cheatsheet
Rewrite the extracted material into a concise markdown cheatsheet with this structure:
### mini-a cheatsheet: `<topic>`
**What it is**
<1 to 3 short sentences>
**Relevant command line parameters**
| Parameter | Possible values | Description |
|---|---|---|
| `<parameter>` | `<value list, range, enum, or default>` | `<short description>` |
**Examples**
| Example | Purpose |
|---|---|
| `mini-a ...` | `<what this example demonstrates>` |
**Related topics**
| Topic | Why it is related |
|---|---|
| `<topic>` | `<short reason>` |
Formatting rules:
- Prefer markdown tables whenever the content is list-shaped.
- The main table SHOULD focus on mini-a command line parameters, their possible values, and their descriptions.
- Prefer parameter names exactly as documented, such as `--flag`, `param=value`, or other CLI forms used by mini-a.
- Include defaults, enums, ranges, or example values in the **Possible values** column whenever the source provides them.
- If the requested topic is broader than a single parameter, populate the main table with the parameters most relevant to that topic.
- Do not use commands, headings, or related topics as substitutes in the main table unless they are directly part of parameter usage.
- Use the **Examples** table instead of a plain code block when you can pair each example with a short purpose.
- Keep example commands exact and copy-pasteable.
- Preserve exact parameter names, command names, and environment variable names from the source.
- Rewrite descriptions for clarity, but do not invent capabilities that are not present in the source cheatsheet.
- Prefer examples and wording taken from the mini-a docs when available; use the fallback cheatsheet only when needed.
- If no topic was provided, rename the heading to `mini-a cheatsheet: overview`.
- Only fall back to bullets or a code block if table output would become awkward or materially less readable.
## Step 5 — Handle weak matches
If the topic is weakly matched or not found:
- Say that no strong cheatsheet section was found for the requested topic.
- Present up to 5 closest matching topics, headings, or options from the source cheatsheet in a markdown table.
- Use the columns `Candidate` | `Type` | `Why it matches`.
- Include a one-line suggestion for how the user could retry.
## Step 6 — Present the result
Return only the focused cheatsheet in markdown.
Do not dump the full raw output of `mini-a --cheatsheet` unless the user explicitly asks for it./cheatsheet [topic]
/git-prs
Analyze pull requests of the current git repo and build a table of the merge impact into main in terms of functionality and possible breaking impact.
---
name: Analyze pull requests
description: Analyze pull requests {{args}} of the current git repo on the current folder and build me a table of the merge impact into main in terms of functionality and possible breaking impact.
---
Analyze pull requests {{args}} of the current git repo on the current folder and build me a table of the merge impact into main in terms of functionality and possible breaking impact/git-prs [PR numbers or filter]
/git-review
Review the current repository changes against the default base branch and produce prioritized, actionable code-review findings.
---
name: Git Review
description: Review the current repository changes against the default base branch and produce prioritized, actionable code-review findings.
tags: [git, review, code review]
---
Review the current git changes in the current folder against the repository default branch (`main` or `master`) and produce a proper code review.
This is a **review**, not a change summary. Prioritize bugs, regressions, correctness issues, unsafe assumptions, missing validation, contract breaks, and missing tests.
## Step 1 — Detect git context
Run the following commands:
- `git rev-parse --is-inside-work-tree` — verify the current folder is a git repository
- `git rev-parse --abbrev-ref HEAD` — current branch name
- `git remote show origin 2>/dev/null | grep 'HEAD branch' | awk '{print $NF}'` — detect the default remote branch; fallback to `git branch --list main master`
- `git status --short` — detect local uncommitted changes
- `git merge-base HEAD <default-branch>` — find the comparison base
If the current folder is not a git repository, stop and say so clearly.
## Step 2 — Gather the review material
Collect both branch-level and local-uncommitted context so the review covers everything visible in the working tree:
- `git log --oneline $(git merge-base HEAD <default-branch>)..HEAD` — commits in the current branch
- `git diff --stat $(git merge-base HEAD <default-branch>)..HEAD` — branch diff summary
- `git diff $(git merge-base HEAD <default-branch>)..HEAD` — full branch diff
- `git diff --stat HEAD` — uncommitted diff summary
- `git diff HEAD` — full uncommitted diff
If the diff is large, inspect the full set of changed files and then drill into the most important files individually with:
- `git diff $(git merge-base HEAD <default-branch>)..HEAD -- <file>`
- `git diff HEAD -- <file>`
Do not review from stats alone. Read enough of the actual diff to support each finding.
## Step 3 — Review with a code-review mindset
Look specifically for:
- **Correctness bugs** — broken logic, wrong conditions, off-by-one errors, incorrect defaults
- **Behaviour regressions** — changed semantics, missing edge-case handling, altered user-visible behaviour
- **Contract / API issues** — signature changes, response-shape changes, schema mismatches, backward compatibility risks
- **Data and state risks** — migrations, persistence, cache invalidation, concurrency, idempotency
- **Security / safety issues** — auth gaps, secret exposure, injection risks, unsafe shelling out, trust-boundary mistakes
- **Operational risks** — config drift, CI/build breakage, dependency issues, rollout hazards
- **Test gaps** — risky logic changed without adequate tests, outdated assertions, missing regression coverage
Increase scrutiny for:
- shared utilities
- public interfaces
- configuration and workflow files
- data model or schema changes
- files with broad blast radius
## Step 4 — Decide what is actually a finding
Only report an item as a finding when all of the following are true:
1. There is a plausible defect, regression, or meaningful risk.
2. The concern is grounded in the diff or nearby code, not guesswork.
3. The issue is actionable for the author.
Avoid low-value comments such as pure style nitpicks, speculative refactors, or generic "add more tests" remarks without naming the missing scenario.
When useful, include:
- the concrete scenario that breaks
- why the current change causes it
- the likely impact
- the missing test that would catch it
## Step 5 — Output format
Present findings first, ordered by severity.
Use this structure:
### Findings
- **High** — `[path/to/file.ext:line]` Brief title
Explain the defect or regression clearly, including the failure mode and impact.
- **Medium** — `[path/to/file.ext:line]` Brief title
Explain the risk and why it matters.
- **Low** — `[path/to/file.ext:line]` Brief title
Explain the issue briefly.
### Open questions
- List only genuine uncertainties that affect review confidence.
### Summary
- Give a short overall assessment of merge readiness.
- Mention notable testing gaps or residual risk.
## Review rules
- Prefer precise file/line references for every finding.
- Quote only short snippets when needed.
- Keep the tone factual and direct.
- If there are **no findings**, say explicitly: `No findings.`
- If there are no findings, still mention any residual review limits such as very large diffs, generated files, or areas not deeply inspected./git-review
/git-qa
Generate a structured QA test plan covering all changes in the current branch (local uncommitted + committed) compared with the main/master branch.
---
name: Git QA Test Plan Generator
description: Generate a structured QA test plan covering all changes in the current branch (local uncommitted + committed) compared with the main/master branch.
---
Generate a structured QA test plan covering all changes in the current branch (local uncommitted + committed) compared with the main/master branch.
## Step 1 — Detect git context
Run the following commands:
- `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 locally via `git branch --list main master`
- `git status --short` — local uncommitted changes (staged + unstaged)
- `git log --oneline $(git merge-base HEAD <default-branch>)..HEAD` — commits in this branch vs default branch
- `git diff --stat HEAD` — stats for local uncommitted changes
- `git diff --stat $(git merge-base HEAD <default-branch>)..HEAD` — stats for all branch-level changes vs default branch
- `git diff HEAD` — full local diff (limit to 200 lines per file if large, note when truncated)
- `git diff $(git merge-base HEAD <default-branch>)..HEAD` — full branch diff (limit to 200 lines per file if large, note when truncated)
Combine both sets of changes into a unified view of everything that differs from the default branch, including local work not yet committed.
## Step 2 — Map changes to functional areas
Analyse the diffs and group changed files into **functional areas** — logical sections of the system rather than individual files. Use your understanding of the code to infer areas such as:
- **API / public interface** — exported functions, REST endpoints, CLI commands, event contracts
- **Business logic / core** — domain logic, algorithms, data processing
- **Data layer** — database queries, schema, migrations, models, serialization
- **Configuration / environment** — config files, env handling, feature flags, defaults
- **Authentication / authorisation** — auth flows, permission checks, session handling
- **UI / presentation** — templates, components, styles, client-side logic
- **Integration points** — calls to external services, SDKs, message queues
- **Build / deployment** — CI pipelines, Dockerfiles, build scripts, dependency manifests
- **Tests** — test files, fixtures, mocks (note: changes here affect test reliability)
- **Documentation** — README, changelogs, inline docs
Each file should map to one primary area; a file may appear in a secondary area if it crosses concerns.
## Step 3 — Identify side-effect and regression zones
For each functional area with changes, reason about what else could be affected even if not directly modified:
- Functions/modules that **import or call** changed code
- Behaviours that depend on changed **configuration or schema**
- **User-facing flows** that pass through changed logic
- **Downstream consumers** of changed APIs or contracts
- **Edge cases** that the change may have altered implicitly (null handling, error paths, boundary values)
List these as "watch areas" — places to pay extra attention during testing even though the code there was not changed.
## Step 4 — Build the test plan
Present the test plan using this structure:
---
### Summary
One short paragraph describing what this branch changes at a high level and the overall scope of testing needed.
---
### Coverage map
A table showing which areas are touched and their test priority:
| Area | Files changed | Priority | Rationale |
|---|---|---|---|
| _e.g. Business logic_ | _file-a.ts, file-b.ts_ | **High** | _Core algorithm modified_ |
Priority levels: **High** (correctness-critical, user-facing, data-affecting) · **Medium** (supporting logic, config) · **Low** (docs, formatting, test-only changes).
---
### Test cases
For each **High** and **Medium** priority area, list concrete test cases. Group by area. Each test case must be:
- Written as an action + expected result: _"Do X → expect Y"_
- Actionable without deep code knowledge (a QA engineer should be able to follow it)
- Focused on behaviour, not implementation
Format per area:
#### [Area name] — _[Priority]_
_Brief description of what changed and why it needs testing._
- [ ] **TC-N** · [Short label] — [Action] → [Expected result]
- [ ] **TC-N** · [Edge case label] — [Action with boundary/edge input] → [Expected result]
- [ ] **TC-N** · [Regression label] — [Action that exercises existing behaviour] → [Confirm no regression]
---
### Watch areas (regression risks)
A bullet list of areas that were **not** directly changed but could be affected, with a one-line reason each. These should be spot-checked even if not covered by a dedicated test case.
---
### Out of scope
Briefly note any areas that were explicitly **not** changed and do not need re-testing for this branch (helps the reader prioritise).
---
## Step 5 — Deliver the plan
Output the full test plan in markdown, ready to paste into a PR description, ticket, or test tracker.
Keep test cases concrete and numbered sequentially (TC-1, TC-2, …) across all areas so they can be referenced in bug reports.
If the diff is very large (> 30 files or > 500 lines total), note the most critical 5–10 test cases at the top in a **"Critical path"** section before the full coverage map./git-qa
/git-cleanup
Clean up local git branches that no longer exist on the remote origin, with safety checks for recently active branches.
---
name: Git Branch Cleanup
description: Clean up local git branches that no longer exist on the remote origin, with safety checks for recently active branches.
---
Clean up local git branches that no longer exist on the remote origin, with safety checks for recently active branches.
## Step 1 — Verify git repository
Run `git rev-parse --git-dir 2>/dev/null` to confirm the current directory is a git repository.
If it is **not** a git repo, stop and inform the user: _"Not a git repository. Navigate to a git project directory and try again."_
## Step 2 — Detect default branch and current branch
Run:
- `git rev-parse --abbrev-ref HEAD` — current branch name (save as `CURRENT_BRANCH`)
- `git remote show origin 2>/dev/null | grep 'HEAD branch' | awk '{print $NF}'` — detect the default remote branch (save as `DEFAULT_BRANCH`; fallback: check `git branch --list main master` and pick whichever exists)
## Step 3 — Sync with remote
Run `git fetch --prune origin` to update all remote-tracking refs and prune stale ones. This ensures the comparison in the next step reflects the true current state of the remote.
If the fetch fails (e.g. no network, no remote), warn the user: _"Could not reach origin. Results may be outdated."_ and continue with cached remote-tracking data.
## Step 4 — Identify local branches not present on the remote
Run:
```
git branch --format='%(refname:short)'
```
to list all local branches.
Run:
```
git branch -r --format='%(refname:short)' | sed 's|origin/||'
```
to list all remote branches (strip the `origin/` prefix).
Compute the difference: local branches that do **not** appear in the remote list. This is the set of **stale local branches** (`STALE_BRANCHES`).
Exclude from `STALE_BRANCHES`:
- The current branch (`CURRENT_BRANCH`)
- The default branch (`DEFAULT_BRANCH`)
If `STALE_BRANCHES` is empty, stop and inform the user: _"All local branches exist on the remote. Nothing to clean up."_
## Step 5 — Analyse each stale branch
For every branch in `STALE_BRANCHES`, collect the following data:
| Data point | Command |
|---|---|
| Last commit date | `git log -1 --format='%ci' <branch>` |
| Last commit age (days) | `git log -1 --format='%cr' <branch>` |
| Last commit message | `git log -1 --format='%s' <branch>` |
| Last commit author | `git log -1 --format='%an' <branch>` |
| Commits ahead of default | `git rev-list --count <DEFAULT_BRANCH>..<branch>` |
| Merge status | `git merge-base --is-ancestor <branch> <DEFAULT_BRANCH> && echo merged \|\| echo unmerged` |
Classify each branch into one of two groups:
- **SAFE** — last commit is **older than 7 days** OR the branch is **fully merged** into the default branch. These can be deleted without asking.
- **ACTIVE** — last commit is **within the last 7 days** AND the branch is **not fully merged**. These require explicit user confirmation before deletion.
## Step 6 — Present the analysis table
Display a consolidated table of all stale branches:
```
Branch | Last Commit | Age | Author | Commits Ahead | Merged? | Action
```
Mark **SAFE** branches with `[auto-delete]` and **ACTIVE** branches with `[needs confirmation]`.
## Step 7 — Delete SAFE branches
For each SAFE branch, run `git branch -d <branch>`. If `-d` fails, fall back to `git branch -D <branch>` and note it.
## Step 8 — Confirm ACTIVE branches individually
For each ACTIVE branch, display its details and ask: **yes** (delete) / **no** (keep) / **skip-all**.
## Step 9 — Final summary
Show a clean summary: Deleted / Kept / Failed counts with branch names./git-cleanup
/git-bug
Bug review of the current repository — scans for null/undefined derefs, error handling gaps, race conditions, logic errors, and other defects, then reports all findings ordered by criticality.
---
name: git-bug
description: Bug review of the current repository — scans for null/undefined derefs, error handling gaps, race conditions, logic errors, and other defects, then reports all findings ordered by criticality.
tags: [git, bugs, audit]
---
Perform a bug review of the current repository. Follow these steps:
## Step 1 — Gather repository context
Run these commands to understand the repo shape:
- `git rev-parse --abbrev-ref HEAD` — current branch
- `git rev-parse --show-toplevel` — repo root (use as base for all searches below)
- `git ls-files` — all tracked files (note dominant languages and file types)
- `git log --oneline -10` — recent commits (focus extra attention on recently changed files)
Identify the dominant tech stack from file extensions and manifests so you can apply language-specific checks in later steps. Collect the list of recently modified files from the log for prioritisation.
## Step 2 — Scan for null, undefined, and uninitialized access
**JavaScript / TypeScript:**
```
git grep -nEi "\w+\.\w+\.\w+" -- '*.js' '*.ts' | grep -v "//\|test\|spec"
git grep -nEi "\.length\b" -- '*.js' '*.ts' | grep -v "if\s*(\|&&\|check\|guard"
git grep -nEi "req\.body\.\w+|req\.params\.\w+|req\.query\.\w+" -- '*.js' '*.ts'
git grep -nEi "JSON\.parse\b" -- '*.js' '*.ts'
```
**Python:**
```
git grep -nEi "\w+\[0\]|\w+\[-1\]" -- '*.py'
git grep -nEi "\.get\(\w+\)\." -- '*.py'
git grep -nEi "int\s*\(|float\s*\(" -- '*.py'
```
**Go:**
```
git grep -nEi "\[0\]\|\[err\]\s*!=" -- '*.go'
git grep -nEi "if err != nil" -- '*.go'
git grep -nE "_, err :=|err :=" -- '*.go' | grep -v "if err"
```
## Step 3 — Scan for missing or swallowed error handling
**JavaScript / TypeScript:**
```
git grep -nEi "\.catch\s*\(\s*\)" -- '*.js' '*.ts'
git grep -nEi "catch\s*\([^)]*\)\s*\{\s*\}" -- '*.js' '*.ts'
git grep -nEi "Promise\b" -- '*.js' '*.ts' | grep -v "await\|\.then\|\.catch"
```
**Python:**
```
git grep -nEi "except\s*:" -- '*.py'
git grep -nEi "except\s+Exception\s*:" -- '*.py'
git grep -nEi "pass$" -- '*.py'
```
**Go:**
```
git grep -nE "err != nil" -- '*.go' -A 1 | grep -E "^\s*(//|_\s*=)"
git grep -nE "_\s*,\s*err\b|err\s*:?=\b" -- '*.go' | grep -v "if err\|return err\|log"
```
## Step 4 — Scan for race conditions and concurrency bugs
**JavaScript / TypeScript:**
```
git grep -nEi "setInterval\|setTimeout" -- '*.js' '*.ts'
git grep -nEi "global\.\w+\s*\+\+|global\.\w+\s*--" -- '*.js' '*.ts'
```
**Python:**
```
git grep -nEi "threading\b|Thread\b|multiprocessing\b" -- '*.py'
git grep -nEi "global\s+\w+" -- '*.py'
git grep -nEi "Lock\(\)|RLock\(\)|Semaphore\(\)" -- '*.py'
```
**Go:**
```
git grep -nEi "go\s+func\b|goroutine\b" -- '*.go'
git grep -nEi "sync\.(WaitGroup|Mutex|RWMutex|Once)\b" -- '*.go'
git grep -nEi "chan\b" -- '*.go'
```
## Step 5 — Scan for off-by-one and boundary errors
```
git grep -nEi "\[len\(\w+\)\]|\[\.length\]" -- '*.py' '*.js' '*.ts' '*.java' '*.go' '*.rb' '*.cs'
git grep -nEi "for\s+\w+\s*=\s*0\s*;\s*\w+\s*<=\s*\w+\.length" -- '*.js' '*.ts' '*.java' '*.cs'
git grep -nEi "range\(1,\s*len\(\w+\)\)|range\(0,\s*len\(\w+\)\s*\+\s*1\)" -- '*.py'
```
## Step 6 — Scan for incorrect type coercion and comparison
**JavaScript / TypeScript:**
```
git grep -nEi "==\s*[^=]|!=\s*[^=]" -- '*.js'
git grep -nEi "parseInt\b|parseFloat\b|Number\(" -- '*.js' '*.ts'
```
**Python:**
```
git grep -nEi "is\s+[0-9]|is\s+['\"]|is\s+True|is\s+False" -- '*.py'
git grep -nEi "==\s*None\b|!=\s*None\b" -- '*.py'
```
## Step 7 — Scan for resource and state management bugs
```
git grep -nEi "open\s*\(" -- '*.py' | grep -v "with open\|#"
git grep -nEi "def\s+\w+\s*\(\s*\w+\s*=\s*\[\|def\s+\w+\s*\(\s*\w+\s*=\s*\{" -- '*.py'
git grep -nEi "Object\.assign\(\w+," -- '*.js' '*.ts' | grep -v "{},"
git grep -nEi "\.sort\(\)" -- '*.js' '*.ts' | grep -v "\.slice\(\)\."
```
## Step 8 — Check for missing input validation at boundaries
```
git grep -nEi "req\.body|req\.params|req\.query" -- '*.js' '*.ts' | grep -v "validate\|schema\|sanitize\|check\|guard"
git grep -nEi "request\.form\|request\.args\|request\.json" -- '*.py' | grep -v "validate\|schema\|check"
git grep -nEi "r\.FormValue\|r\.URL\.Query\(\)" -- '*.go' | grep -v "validate\|check\|parse"
```
## Step 9 — Scan for logic and control-flow bugs
```
git grep -nEi "if\s*\(\s*(true|false)\b" -- '*.js' '*.ts' '*.java' '*.cs'
git grep -nEi "if\s+True:|if\s+False:" -- '*.py'
git grep -nEi "switch\s*\(" -- '*.js' '*.ts' '*.java' '*.go' '*.cs' | grep -v "default"
```
## Step 10 — Compile and present the bug report
Present a single consolidated report:
### Bug Review — `<repo-name>` (`<branch>`)
#### Summary table
| Severity | Count |
|---|---|
| **Critical** | N |
| **High** | N |
| **Medium** | N |
| **Low** | N |
| **Info** | N |
#### Findings
List every finding grouped by severity (Critical → Info):
**[SEVERITY] — Short title**
- **File:** `path/to/file.ext:line`
- **Detail:** What was found and why it is likely a bug or defect
- **Recommendation:** Specific fix or defensive pattern to apply
Severity definitions: **Critical** = crash-inducing at runtime; **High** = likely incorrect behaviour under normal use; **Medium** = incorrect in edge cases; **Low** = defensive coding gaps; **Info** = code smell with no confirmed bug.
#### Overall bug risk assessment
Write a short paragraph (4–6 sentences) summarising the most dangerous defects, which modules carry the most risk, and the top 3 actionable recommendations./git-bug
/git-sec
Security review of the current repository — scans for secrets, vulnerable patterns, risky configs, and exposed files, then reports all findings ordered by criticality.
---
name: git-security
description: Security review of the current repository — scans for secrets, vulnerable patterns, risky configs, and exposed files, then reports all findings ordered by criticality.
tags: [git, security, audit]
---
Perform a security review of the current repository. Follow these steps:
## Step 1 — Gather repository context
Run these commands to understand the repo shape:
- `git rev-parse --abbrev-ref HEAD` — current branch
- `git rev-parse --show-toplevel` — repo root
- `git ls-files` — all tracked files
- `git ls-files --others --exclude-standard` — untracked files not in .gitignore (potential leaks)
- `ls -la $(git rev-parse --show-toplevel)` — root directory listing
- `cat $(git rev-parse --show-toplevel)/.gitignore 2>/dev/null || echo "(no .gitignore)"` — review ignore rules
## Step 2 — Scan for exposed secrets and credentials
```
git grep -nEi "(password|passwd|pwd)\s*[:=]\s*['\"][^'\"]{4,}" -- ':!*.md' ':!*.lock'
git grep -nEi "(secret|api_key|apikey|api_secret|client_secret)\s*[:=]\s*['\"][^'\"]{6,}" -- ':!*.md' ':!*.lock'
git grep -nEi "(token|auth_token|access_token|bearer)\s*[:=]\s*['\"][^'\"]{8,}" -- ':!*.md' ':!*.lock'
git grep -nEi "(aws_access_key_id|aws_secret|AKIA[0-9A-Z]{16})" -- ':!*.md'
git grep -nEi "(private_key|BEGIN (RSA|EC|DSA|OPENSSH) PRIVATE KEY)" -- ':!*.md'
git grep -nEi "(database_url|db_url|mongo_uri|redis_url|postgres://|mysql://|mongodb://)" -- ':!*.md'
```
## Step 3 — Check sensitive file exposure
```
git ls-files | grep -Ei '\.(pem|key|p12|pfx|jks|keystore|cer|crt|ppk)$'
git ls-files | grep -Ei '^\.env(\..+)?$|\.env\.local|\.env\.production|\.env\.staging'
git ls-files | grep -Ei '(id_rsa|id_dsa|id_ecdsa|id_ed25519|\.ssh/)'
git ls-files | grep -Ei '(credentials|secrets)\.(json|yaml|yml|xml|txt)$'
git ls-files | grep -Ei '\.(sqlite|sqlite3|db)$'
```
## Step 4 — Scan for insecure code patterns
**Injection risks:**
```
git grep -nEi "eval\s*\(" -- '*.js' '*.ts' '*.py' '*.rb' '*.php'
git grep -nEi "exec\s*\(|system\s*\(|shell_exec|passthru|popen" -- '*.py' '*.rb' '*.php'
git grep -nEi "subprocess\.call|os\.system|os\.popen" -- '*.py'
git grep -nEi "child_process|exec\(|execSync\(" -- '*.js' '*.ts'
```
**SQL injection:**
```
git grep -nEi "\"SELECT.+\+|'SELECT.+\+" -- '*.java' '*.py' '*.rb' '*.php' '*.go' '*.cs'
git grep -nEi "string\.format.*SELECT|f['\"]SELECT" -- '*.py'
```
**Dangerous deserialization:**
```
git grep -nEi "pickle\.loads|yaml\.load\s*\(" -- '*.py'
git grep -nEi "ObjectInputStream|XMLDecoder|XStream" -- '*.java'
```
**Weak crypto / hashing:**
```
git grep -nEi "(md5|sha1)\s*\(|hashlib\.(md5|sha1)" -- '*.py' '*.js' '*.ts' '*.rb' '*.php' '*.go'
git grep -nEi "Math\.random\(\)" -- '*.js' '*.ts' '*.java'
```
**Insecure HTTP / TLS:**
```
git grep -nEi "verify\s*=\s*False|InsecureRequestWarning|CERT_NONE" -- '*.py'
git grep -nEi "rejectUnauthorized\s*:\s*false|NODE_TLS_REJECT_UNAUTHORIZED" -- '*.js' '*.ts'
git grep -nEi "http://" -- '*.env*' '*.yaml' '*.yml' '*.json' '*.config'
```
## Step 5 — Review dependency files for known-risky signals
Check `package.json`, `requirements.txt`, `Gemfile`, `go.mod`, `pom.xml` for:
- Packages fetched over HTTP
- Wildcard/unpinned versions
- `git+` or `file:` references to unreviewed sources
## Step 6 — Check configuration and infrastructure files
```
git ls-files | grep -Ei '(Dockerfile|docker-compose|\.github/workflows|\.gitlab-ci|Jenkinsfile|\.circleci|\.travis\.yml|Makefile)' | xargs -I{} git show HEAD:{} 2>/dev/null
```
Look for: `--privileged`, secrets injected via `ARG`, `curl | bash`, CI steps echoing env vars with secrets, `chmod 777`, running as root.
## Step 7 — Check .gitignore coverage
Report which of these common sensitive patterns are **missing** from `.gitignore`:
`.env`, `*.pem`, `*.key`, `*.p12`, `*.pfx`, `*.jks`, `*.sqlite`, `*.db`, `id_rsa`, `.aws/credentials`, `credentials.json`, `secrets.yaml`, `secrets.json`, `*.log`
## Step 8 — Compile and present the security report
### Security Review — `<repo-name>` (`<branch>`)
#### Summary table
| Severity | Count |
|---|---|
| **Critical** | N |
| **High** | N |
| **Medium** | N |
| **Low** | N |
| **Info** | N |
#### Findings
**[SEVERITY] — Short title**
- **File:** `path/to/file.ext:line`
- **Detail:** What was found and why it is a risk
- **Recommendation:** Specific remediation step
Severity definitions: **Critical** = plaintext secret/credential committed; **High** = direct injection vector, insecure TLS disabled; **Medium** = weak hash, HTTP for non-local URLs, unpinned deps; **Low** = missing `.gitignore` entries, hardcoded localhost in non-test code; **Info** = observations with no immediate risk.
#### Overall security posture
Write a short paragraph (4–6 sentences) summarising the most critical risks, areas with highest attack surface, whether the repo is safe to make public, and the top 3 recommendations./git-sec
/git-perf
Performance review of the current repository — scans for algorithmic anti-patterns, expensive I/O, memory leaks, bloated assets, and missing optimisations, then reports all findings ordered by impact.
---
name: git-performance
description: Performance review of the current repository — scans for algorithmic anti-patterns, expensive I/O, memory leaks, bloated assets, and missing optimisations, then reports all findings ordered by impact.
tags: [git, performance, audit]
---
Perform a performance review of the current repository. Follow these steps:
## Step 1 — Gather repository context
- `git rev-parse --abbrev-ref HEAD` — current branch
- `git rev-parse --show-toplevel` — repo root
- `git ls-files` — all tracked files
- `git ls-files | wc -l` — total tracked file count
- `git log --oneline -10` — recent commits
Identify the dominant tech stack so you can apply language-specific checks in later steps.
## Step 2 — Detect large and binary files in the repository
```
git ls-files | xargs -I{} du -sh {} 2>/dev/null | sort -rh | head -30
git ls-files | grep -Ei '\.(png|jpg|jpeg|gif|bmp|tiff|ico|webp|svg)$' | xargs -I{} du -sh {} 2>/dev/null | sort -rh | head -20
git ls-files | grep -Ei '\.(mp4|mov|avi|mkv|mp3|wav|ogg|flac|zip|tar|gz|bz2|7z|rar|jar|war|ear|wasm)$'
git count-objects -vH
```
Report total repo size and flag any single file over **1 MB** that is tracked in git.
## Step 3 — Scan for algorithmic anti-patterns
**Nested loops and O(n²) patterns:**
```
git grep -nEi "\.forEach\(.+\.forEach\(|\.map\(.+\.map\(" -- '*.js' '*.ts'
git grep -nEi "while\s*(true|1|True)" -- '*.py' '*.js' '*.ts' '*.java' '*.go' '*.rb' '*.cs'
```
**Repeated expensive lookups inside loops:**
```
git grep -nEi "\.(find|filter|indexOf|includes)\(" -- '*.js' '*.ts'
git grep -nEi "list\.contains\(|stream\(\)\.filter\(" -- '*.java'
```
## Step 4 — Scan for database and query anti-patterns
```
git grep -nEi "SELECT \*" -- '*.sql' '*.py' '*.js' '*.ts' '*.java' '*.rb' '*.go' '*.cs' '*.php'
git grep -nEi "fetchAll|fetchMany|\.list\(\)" -- '*.py' '*.java' '*.go'
git grep -nEi "OFFSET\s+[0-9]" -- '*.sql' '*.py' '*.js' '*.ts' '*.java' '*.rb'
git grep -nEi "\.execute\(|cursor\.execute\(" -- '*.py'
```
Look for queries built inside loops (N+1), unbounded `SELECT *`, large-offset pagination, and missing `LIMIT` clauses.
## Step 5 — Scan for memory and resource management issues
**Memory leaks and unbounded growth:**
```
git grep -nEi "global\s+\w+" -- '*.py' '*.js' '*.ts' '*.php'
git grep -nEi "window\.\w+\s*=" -- '*.js' '*.ts'
git grep -nEi "static\s+(List|Map|Set|ArrayList|HashMap)" -- '*.java'
```
**Missing resource cleanup:**
```
git grep -nEi "open\s*\(" -- '*.py' | grep -v "with open"
git grep -nEi "fs\.open\b|fs\.createReadStream\b" -- '*.js' '*.ts'
```
**Synchronous / blocking I/O in async contexts:**
```
git grep -nEi "fs\.readFileSync|fs\.writeFileSync|execSync\b" -- '*.js' '*.ts'
git grep -nEi "time\.sleep\b|requests\.get\b" -- '*.py'
```
## Step 6 — Scan for inefficient patterns by language
**JavaScript / TypeScript:**
```
git grep -nEi "\.innerHTML\s*\+=" -- '*.js' '*.ts'
git grep -nEi "JSON\.parse\(JSON\.stringify\(" -- '*.js' '*.ts'
git grep -nEi "new\s+RegExp\(" -- '*.js' '*.ts'
```
**Python:**
```
git grep -nEi "\+\s*=\s*['\"]|str\s*\+\s*str" -- '*.py'
git grep -nEi "range\(len\(" -- '*.py'
git grep -nEi "import \*" -- '*.py'
```
**Java / Kotlin:**
```
git grep -nEi "String\s*\+=" -- '*.java' '*.kt'
git grep -nEi "System\.out\.print" -- '*.java'
```
## Step 7 — Check caching and memoisation signals
```
git grep -nEi "\@cache|\@lru_cache|functools\.cache|memoize" -- '*.py' '*.rb' '*.js' '*.ts'
git grep -nEi "redis|memcached|caffeine|guava.*cache" -- '*.py' '*.java' '*.go' '*.js' '*.ts' '*.rb'
```
Note whether caching infrastructure exists. If expensive operations are found without corresponding cache usage, flag the gap.
## Step 8 — Inspect dependency and bundle size signals
```
cat package.json 2>/dev/null | grep -E '"dependencies"|"devDependencies"' -A 100 | head -60
cat package-lock.json 2>/dev/null | grep '"node_modules"' | wc -l
git ls-files | grep -Ei '\.(min\.js|bundle\.js|vendor\.js)$'
```
Flag: large number of transitive deps, bundled vendor files committed to git, missing tree-shaking or code-splitting configuration.
## Step 9 — Check build and CI performance signals
Look for: no layer caching in Dockerfile, rebuilding dependencies on every CI run, running the full test suite without parallelisation, no build artifact caching between stages, missing `.dockerignore`.
## Step 10 — Compile and present the performance report
### Performance Review — `<repo-name>` (`<branch>`)
#### Summary table
| Impact | Count |
|---|---|
| **Critical** | N |
| **High** | N |
| **Medium** | N |
| **Low** | N |
| **Info** | N |
#### Findings
**[IMPACT] — Short title**
- **File:** `path/to/file.ext:line` (or `(repo-wide)` if applies globally)
- **Detail:** What was found and why it hurts performance
- **Recommendation:** Specific, actionable fix
Impact definitions: **Critical** = severe latency or memory exhaustion at scale; **High** = significant overhead degrading user-facing performance; **Medium** = inefficient patterns that accumulate under load; **Low** = minor inefficiencies; **Info** = observations with no direct runtime cost.
#### Overall performance posture
Write a short paragraph (4–6 sentences) summarising the highest-impact bottlenecks, which layers carry the most risk, whether the codebase is likely to hold up under production load, and the top 3 recommendations./git-perf
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
Release Notes Generator (YAML format)
Drafts release notes from commits and a changelog. Demonstrates the self-contained SKILL.yaml format with embedded refs and placeholders.
schema: mini-a.skill/v1
name: release-notes
summary: Draft release notes from commits and changelog context
body: |
Produce release notes for version {{arg1}}.
Use the voice defined in @voice.md and the template in @template.md.
Commits to summarise:
{{args}}
meta:
tags: [docs, changelog]
refs:
voice.md: |
Keep language concise and user-focused.
Avoid internal jargon.
template.md: |
## Highlights
- …
## Bug Fixes
- …/release-notes v2.4.0
Security Audit
Comprehensive security audit covering OWASP Top-10, hardcoded secrets, and dependency risks. Uses the YAML skill format with embedded check refs and a children sub-folder for per-domain rules.
schema: mini-a.skill/v1
name: security-audit
summary: Comprehensive security audit covering OWASP Top-10, secrets, and dependency risks
body: |
Target: {{arg1}}
Perform a comprehensive security audit of {{arg1}}.
Work through each section defined in the reference files below:
@owasp.md
@secrets.md
@deps.md
For each finding report:
- **File** and **line number** (when applicable)
- **Severity**: Critical / High / Medium / Low / Info
- **Category**: e.g. Injection, Hardcoded Secret, Outdated Dep
- **Description**: what the issue is and why it matters
- **Remediation**: specific fix or mitigation
Finish with a one-paragraph executive summary of overall risk.
meta:
tags: [security, audit, owasp]
refs:
owasp.md: |
## OWASP Top-10 checks
- A01 Broken Access Control: missing auth checks, IDOR, path traversal
- A02 Cryptographic Failures: weak ciphers, missing TLS, unencrypted PII at rest
- A03 Injection: SQL, command, LDAP, XSS, template injection
- A04 Insecure Design: missing rate limiting, absent threat modelling artefacts
- A05 Security Misconfiguration: debug flags, default creds, overly broad CORS
- A06 Vulnerable Components: outdated libraries with known CVEs
- A07 Auth Failures: weak passwords, missing MFA, broken session handling
- A08 Integrity Failures: unsigned packages, untrusted deserialization
- A09 Logging Failures: no audit trail, sensitive data in logs
- A10 SSRF: user-supplied URLs fetched without validation
secrets.md: |
## Secrets and credential checks
Scan all files for:
- Hard-coded API keys, tokens, passwords, or private keys
- Patterns: `password =`, `secret =`, `api_key =`, `-----BEGIN`, base64 blobs > 40 chars
- .env files committed to the repository
- Credentials embedded in connection strings or config files
- Tokens appearing in log output or error messages
deps.md: |
## Dependency risk checks
- Parse dependency manifests (package.json, requirements.txt, go.mod, pom.xml, Gemfile)
- Flag packages with known CVEs or suspicious naming (typosquatting)
- Identify dependencies pinned to mutable references (branches, `latest`)
- Note transitive dependencies that dominate the vulnerability surface/security-audit src/
Docker Audit
Audits Dockerfiles and docker-compose files for security issues and layer inefficiencies. Uses the YAML skill format with separate refs for security rules, layer hygiene, and compose-specific checks.
schema: mini-a.skill/v1
name: docker-audit
summary: Audit Dockerfiles and docker-compose files for security and layer efficiency
body: |
Target: {{arg1}}
Audit the Docker artefacts at {{arg1}} (or the current directory if omitted).
If available, run `docker inspect` and `docker history` on built images to enrich the analysis.
Apply the checks from each section below:
@security.md
@layer-hygiene.md
@compose-rules.md
For each finding report:
- **File** and **line** (or image layer index)
- **Severity**: Critical / High / Medium / Low
- **Rule** violated
- **Remediation**: corrected snippet or recommended fix
End with a prioritised action list ordered by severity.
meta:
tags: [docker, security, devops]
refs:
security.md: |
## Dockerfile security checks
- Base image: prefer official minimal images (alpine, distroless); flag `latest` tags
- Running as root: flag missing `USER` instruction; verify non-root UID is set
- Secrets at build time: flag `ARG` or `ENV` carrying passwords/tokens; recommend BuildKit secrets
- `ADD` vs `COPY`: flag `ADD` with remote URLs (prefer `COPY` + explicit download step)
- Package managers: flag `apt-get` without `--no-install-recommends` and without cache cleanup in the same layer
- Exposed ports: flag unnecessarily broad `EXPOSE` directives
- `HEALTHCHECK`: flag images with no `HEALTHCHECK` instruction
- Read-only filesystem: note if the image can run with `--read-only` at runtime
layer-hygiene.md: |
## Layer efficiency checks
- Combine related `RUN` commands with `&&` to minimise layer count
- Flag cache-busting: `COPY . .` placed before dependency install steps
- Order instructions least-to-most volatile (deps before source code)
- Flag large layers: build tools, dev dependencies, or test fixtures left in the final image
- Multi-stage builds: flag single-stage builds that include compilers or build tools in the final image
- `.dockerignore`: warn if missing or lacking key entries (`.git`, `node_modules`, `*.log`)
compose-rules.md: |
## docker-compose checks
- Secrets: flag plain-text passwords in `environment:` blocks; recommend Docker secrets or env files
- Volumes: flag bind-mounts to sensitive host paths (`/etc`, `/var/run/docker.sock`)
- Network isolation: flag services on `host` network mode without justification
- Resource limits: flag services missing `mem_limit` / `cpus` constraints
- Restart policy: flag `restart: always` on services that should not auto-restart on failure
- Image versions: flag services using `:latest` or no tag at all
- Healthchecks: flag services with no `healthcheck:` and no `depends_on:` condition/docker-audit .
Test Generator
Generates a complete, runnable unit test file for a target source file. Auto-detects the framework (Jest, pytest, Go testing, OpenAF ow.test) and applies the matching template from embedded refs.
schema: mini-a.skill/v1
name: test-generator
summary: Generate unit tests for a target file, detecting the framework automatically
body: |
Target: {{arg1}}
Inspect {{arg1}} and generate a complete, runnable unit test file for it.
## Step 1 — Detect the language and test framework
Read the file extension and content, then check for framework config files:
- `jest.config.*` or `"jest"` in package.json → use @jest.md
- `pytest.ini`, `pyproject.toml`, or `setup.cfg` with `[tool:pytest]` → use @pytest.md
- `go.mod` present → use @go-test.md
- `autoTestAll.allJobs.yaml` present or `ow.load*` calls in source → use @openaf.md
If multiple signals conflict, prefer the one with the most config-file evidence.
## Step 2 — Identify what to test
- List all exported/public functions, methods, or classes
- For each: identify inputs, outputs, side effects, and error paths
- Prioritise: happy path, null/empty inputs, boundary values, error conditions
## Step 3 — Generate the test file
Follow the template for the detected framework exactly.
Cover at minimum: one happy-path test, one null/empty-input test, one error/exception test.
@jest.md
@pytest.md
@go-test.md
@openaf.md
## Step 4 — Output
Print the complete test file, ready to save and run.
State the suggested save path.
List any setup steps needed (install deps, seed data, required env vars).
meta:
tags: [testing, quality]
refs:
jest.md: |
## Jest (JavaScript / TypeScript)
Use when: `.js`, `.ts`, `.jsx`, or `.tsx` file with `package.json` present.
```javascript
import { myFunc } from '../src/myModule';
describe('myFunc', () => {
it('returns expected output for valid input', () => {
expect(myFunc('hello')).toBe('HELLO');
});
it('throws on null input', () => {
expect(() => myFunc(null)).toThrow();
});
it('handles empty string', () => {
expect(myFunc('')).toBe('');
});
});
```
Rules:
- One `describe` block per module; one `it` per behaviour
- Use `jest.fn()` for mocks; `beforeEach`/`afterEach` for setup/teardown
- Test observable behaviour, not implementation details
- Suggested path: `<dir>/__tests__/<name>.test.ts` or `<name>.spec.ts`
pytest.md: |
## pytest (Python)
Use when: `.py` files present.
```python
import pytest
from mymodule import my_func
def test_my_func_basic():
assert my_func("hello") == "HELLO"
def test_my_func_none_raises():
with pytest.raises(TypeError):
my_func(None)
def test_my_func_empty():
assert my_func("") == ""
@pytest.fixture
def sample_data():
return {"key": "value"}
def test_my_func_with_fixture(sample_data):
assert my_func(sample_data["key"]) == "VALUE"
```
Rules:
- One test file per module; prefix all test functions with `test_`
- Use `@pytest.fixture` for shared setup; `tmp_path` for temporary files
- Use `pytest.raises` for exception assertions
- Suggested path: `tests/test_<module>.py`
go-test.md: |
## Go testing (standard library)
Use when: `.go` files and `go.mod` present.
```go
package mypackage_test
import (
"testing"
"github.com/user/repo/mypackage"
)
func TestMyFuncBasic(t *testing.T) {
got := mypackage.MyFunc("hello")
want := "HELLO"
if got != want {
t.Errorf("MyFunc(%q) = %q, want %q", "hello", got, want)
}
}
func TestMyFunc_TableDriven(t *testing.T) {
tests := []struct {
name string
input string
want string
}{
{"basic", "hello", "HELLO"},
{"empty", "", ""},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
if got := mypackage.MyFunc(tt.input); got != tt.want {
t.Errorf("got %q, want %q", got, tt.want)
}
})
}
}
```
Rules:
- Use external test package (`package foo_test`) to test the public API
- Prefer table-driven tests for multiple input/output cases
- Use `t.Helper()` in shared assertion helpers
- Suggested path: `<name>_test.go` alongside the source file
openaf.md: |
## OpenAF (ow.test framework)
Use when: `.js` files in an OpenAF project — `autoTestAll.allJobs.yaml` present or `ow.load*` calls in source.
### JS test file — `autoTestAll.<Area>.js`
```javascript
// Tests for <module description>
(function() {
exports.testMyFuncBasic = function() {
ow.loadFormat(); // load the OpenAF module under test
var result = myModule.myFunc("hello");
ow.test.assert(result, "HELLO", "myFunc should uppercase the input");
};
exports.testMyFuncNull = function() {
var result = myModule.myFunc(null);
ow.test.assert(result, null, "myFunc should return null for null input");
};
exports.testMyFuncWithCleanup = function() {
var tmpFile = "autoTestAll.myFunc.tmp";
try {
myModule.myFuncWriteFile(tmpFile, "data");
ow.test.assert(io.fileExists(tmpFile), true, "Output file should exist");
} finally {
io.rm(tmpFile);
}
};
})();
```
### Orchestrator YAML — `autoTestAll.<Area>.yaml`
```yaml
include:
- oJobTest.yaml
jobs:
- name: <Area>::Init
exec: |
args.tests = require("autoTestAll.<Area>.js");
- name: <Area>::Basic
from: <Area>::Init
to : oJob Test
exec: args.func = args.tests.testMyFuncBasic;
- name: <Area>::Null input
from: <Area>::Init
to : oJob Test
exec: args.func = args.tests.testMyFuncNull;
- name: <Area>::Cleanup
from: <Area>::Init
to : oJob Test
exec: args.func = args.tests.testMyFuncWithCleanup;
todo:
- <Area>::Init
- <Area>::Basic
- <Area>::Null input
- <Area>::Cleanup
```
Rules:
- Wrap all code in `(function() { ... })()` — no global variable leaks
- Export names must start with `test` (CamelCase after the prefix)
- Do NOT call `ow.loadTest()` — the framework loads it once before your tests run
- Load OpenAF modules (`ow.loadFormat()`, `ow.loadObj()`) inside each test function
- Clean up temporary files in a `try/finally` block using `io.rm()`
- Register the new YAML in `autoTestAll.allJobs.yaml`
- Run one area: `ojob autoTestAll.<Area>.yaml`
- Run full suite: `ojob autoTestAll.yaml`/test-generator src/utils/parser.js
oJob Builder
Generates a complete, runnable OpenAF oJob YAML file from a free-form description. Covers basic JS jobs, shell jobs, built-in shortcuts, multi-file includes, oJob-common modules, and validation patterns.
schema: mini-a.skill/v1
name: build-ojob
summary: Generate a complete OpenAF oJob YAML file from a free-form description
body: |
Build an OpenAF oJob YAML file for the following:
{{args}}
## Step 1 — Analyse the request
Identify:
- What each job does and what language it needs (default JS, shell, python, etc.)
- Whether jobs run sequentially or can run in parallel / fan-out
- Which args the user must supply (mandatory) vs. can omit (optional with defaults)
- Whether the task needs conditional branching, looping, or parallel collection processing
- Whether any external includes, remote ojob.io jobs, or oJob-common modules are a natural fit
## Step 2 — Select building blocks
Always consult @basics.md for the core structure.
Then consult whichever additional refs apply:
- @validation.md — any job that accepts typed inputs or produces typed outputs
- @shell.md — any job that runs shell/bash commands
- @shortcuts.md — conditional branching, parallel execution, or inline todo operations
- @includes.md — when the oJob uses other files, oPacks, or remote ojob.io jobs
- @common.md — when oJob-common modules (testing, SQL, HTTP, file I/O) are a natural fit
## Step 3 — Design the job graph
Before writing YAML, reason through:
- Job names — use Namespace::JobName for multi-file oJobs, plain names for single-file ones
- Execution order in todo
- Arg flow: which job sets which key, which job reads it
- from/to vs deps — use from/to for before/after wrappers; deps for strict prerequisites
- Where each(data) fan-out applies for parallel collection processing
## Step 4 — Write the oJob YAML
Produce a complete, runnable file:
- help section: text plus an expects entry for every user-facing argument
- init section: sensible defaults for optional args (available as args.init.* in all jobs)
- ojob section: opacks list, logToConsole, catch handler, any owraps/loadLibs
- jobs array: all job definitions with exec, check, catch, typeArgs as needed
- todo array: correct execution order with shortcut entries where appropriate
## Step 5 — Output
Print the complete YAML file, ready to save and run.
State the suggested filename (e.g. checkS3.yaml).
List any oPacks or system tools required.
Show the exact run command: ojob myFile.yaml arg1=value1 arg2=value2
meta:
tags: [openaf, ojob, yaml, automation]
refs:
basics.md: |
## oJob basics — structure and JavaScript jobs
### Minimal skeleton
```yaml
help:
text : What this oJob does.
expects:
- name : inputFile
desc : Path to the input file
mandatory: true
example : data.json
- name : verbose
desc : Enable verbose output
mandatory: false
example : "true"
init:
outputDir: /tmp/results # available as args.init.outputDir in all jobs
ojob:
opacks :
- openaf: ">=20230601"
logToConsole: true
catch : logErr("[" + job.name + "] " + exception)
jobs:
- name: My Job
exec: | #js
log("Running: " + job.name)
var data = io.readFileJSON(args.inputFile)
args.result = data.items.length
todo:
- My Job
```
### Job with default args using ${key:-default} syntax
```yaml
jobs:
- name: Connect
args:
host: "${dbHost:-localhost}"
port: "${dbPort:-5432}"
exec: | #js
log("Connecting to " + args.host + ":" + args.port)
```
### Sequential multi-job pipeline
```yaml
jobs:
- name: Load
exec: | #js
args.data = io.readFileJSON(args.inputFile)
- name: Transform
exec: | #js
args.data = args.data.map(r => merge(r, { processed: true }))
- name: Save
exec: | #js
io.writeFileJSON(args.outputFile, args.data, "")
todo:
- Load
- Transform
- Save
```
### from / to — before/after wrappers
`from` runs prerequisite jobs before exec; the main job inherits their args output.
`to` runs follow-up jobs after exec.
```yaml
jobs:
- name: Connect DB
exec: | #js
global.db = new DB(args.url, args.user, args.pass)
- name: Disconnect DB
exec: | #js
if (global.db) global.db.close()
- name: Query
from: Connect DB
to : Disconnect DB
exec: | #js
args.rows = global.db.q("SELECT * FROM items").results
```
### Parallel fan-out with each
```yaml
jobs:
- name: Process All Files
each:
- Process One File
exec: | #js
io.listFiles(".").files.forEach(f => each(f))
- name: Process One File
exec: | #js
log("Processing " + args.canonicalPath)
```
### Error handling
```yaml
jobs:
- name: Risky Job
catch: | #js
logErr("Failed: " + exception)
return true # true = handled; false/omit = propagate
exec : | #js
// your code here
```
### Periodic (scheduled) job
```yaml
ojob:
daemon: true
jobs:
- name : Heartbeat
type : periodic
typeArgs:
cron : "0 */5 * * * *" # every 5 minutes
waitForFinish: true
exec : | #js
log("tick " + new Date())
todo:
- Heartbeat
```
### Shutdown job
```yaml
jobs:
- name: Cleanup
type: shutdown
exec: | #js
log("shutting down — releasing resources")
```
### deps — strict prerequisites
```yaml
jobs:
- name: Main Job
deps:
- Setup Job
- name : Config Job
onSuccess: | #js
log("config loaded")
onFail : | #js
logErr("config failed")
return false # stop execution
exec: | #js
log("dependencies satisfied")
```
validation.md: |
## oJob validation — check.in and check.out
The `check` section validates and coerces args before (`in`) and after (`out`) exec.
Failures throw before the job body runs, so exec can assume clean types.
### Common validator chains
| Chain | Meaning |
|-------|---------|
| `isString` | Must be a string |
| `isNumber` | Must be a number |
| `isBoolean` | Must be a boolean |
| `isMap` | Must be an object/map |
| `isArray` | Must be an array |
| `toNumber.isNumber` | Coerce from string then validate |
| `toBoolean.isBoolean` | Coerce from string then validate |
| `.default(x)` | Use x when arg is undefined |
| `.oneOf([...])` | Restrict to an allowed set of values |
| `.between(a, b)` | Number must be in range |
| `.minLength(n)` | String or array minimum length |
| `.match(/re/)` | String must match regex |
| `.hasKeys([...])` | Map must contain listed keys |
### Example
```yaml
jobs:
- name : Import Data
check:
in:
inputFile: isString
port : toNumber.isNumber.default(5432)
mode : isString.oneOf(['fast','safe']).default('safe')
tags : isArray.default([])
enabled : toBoolean.isBoolean.default(true)
timeout : isNumber.between(1000,60000).default(30000)
out:
rowCount : isNumber.default(0)
status : isString.oneOf(['ok','error'])
exec : | #js
// args.port is already a number; args.mode is guaranteed 'fast' or 'safe'
args.rowCount = 42
args.status = "ok"
```
### Validation in todo entries
```yaml
todo:
- name: Import Data
args:
inputFile: data.csv
port : "5432" # string — toNumber coerces it
mode : fast
```
shell.md: |
## Shell jobs — lang: shell
Set `lang: shell` to run the exec body as a shell script instead of JavaScript.
### Arg flow
- Input args are available as the env variable `$aInputArgs` (a JSON string).
Individual values can be referenced inside the script as `\{{argName}}` tokens,
which oJob substitutes before executing the script.
- Output: print a single JSON object to stdout on the last line; oJob merges it
back into args. All other output lines are treated as log output.
### Minimal example
```yaml
jobs:
- name: Check Disk
lang: shell
check:
in:
path: isString.default("/")
exec: | #shell
USAGE=$(df -h \{{path}} | tail -1 | awk '{print $5}')
echo "{\"diskUsage\": \"$USAGE\"}"
```
### Reading the full args map
```yaml
jobs:
- name: Run Script
lang: shell
exec: | #shell
echo "All args: $aInputArgs"
INFILE=$(echo "$aInputArgs" | python3 -c "import sys,json; print(json.load(sys.stdin)['inputFile'])")
COUNT=$(wc -l < "$INFILE")
echo "{\"lineCount\": $COUNT}"
```
### Shell with log prefix
```yaml
jobs:
- name: Install Packages
lang: shell
typeArgs:
shellPrefix: install
exec: | #shell
apt-get update
apt-get install -y curl jq
echo "{}"
```
### Multi-step shell job with error exit
```yaml
jobs:
- name: Build and Test
lang: shell
exec: | #shell
set -e
./gradlew build
./gradlew test
echo "{\"buildStatus\": \"success\"}"
```
### Mixed JS + shell in one oJob
```yaml
jobs:
- name: Prepare
exec: | #js
args.target = io.readFileString("target.txt").trim()
- name: Deploy
lang: shell
exec: | #shell
echo "Deploying to \{{target}}..."
rsync -av dist/ user@\{{target}}:/var/www/
echo "{\"deployed\": true}"
todo:
- Prepare
- Deploy
```
shortcuts.md: |
## oJob shortcuts — concise todo operations
Shortcuts appear directly in the `todo` array (or inside `((then))`/`((else))` blocks).
Single parens `(name)` is the primary arg; double parens `((arg))` are named options.
### Conditional — (if)
```yaml
todo:
- (if ): "args.env == 'prod'"
((then)):
- Deploy to Prod
((else)):
- Deploy to Staging
```
### Parallel execution — (parallel)
```yaml
todo:
- (parallel):
- Check Service A
- Check Service B
- Check Service C
```
### Pass args inline — (pass)
```yaml
todo:
- (pass):
env : prod
region: eu-west-1
- Deploy
```
### Set / get a global key — (set) / (get)
```yaml
todo:
- (set ): configKey
((data)): { host: "db.example.com", port: 5432 }
- (get ): configKey
```
### Output results — (output)
```yaml
todo:
- (output ): results
((format)): json
```
### Call a function — (fn)
```yaml
todo:
- (fn): ow.loadFormat
```
### Load a file into args — (fileget)
```yaml
todo:
- (fileget): config.yaml
((out )): config
```
### Run an external oJob — (runfile)
```yaml
todo:
- (runfile): deploy.yaml
((args )): { target: "prod" }
```
### Channel operation — (ch)
```yaml
todo:
- (ch ): results
((op)): set
((k )): { id: 1 }
((v )): { status: "done" }
```
### Repeat N times — (repeat)
```yaml
todo:
- (repeat): 3
((todo)):
- Retry Job
```
### Loop over a collection — (each)
```yaml
todo:
- (each ): items
((todo)):
- Process Item
```
### Switch on a value — (options)
```yaml
todo:
- (options): environment
((dev )):
- Dev Setup
((prod )):
- Prod Setup
```
### State guard — (state) / when
```yaml
todo:
- (state): ready
- name : Guarded Job
when : ready
```
### Wait — (wait)
```yaml
todo:
- (wait): 5000 # wait 5 seconds
```
### Print markdown — (printmd)
```yaml
todo:
- (printmd): |
# Report
Items processed: \{{count}}
```
### LLM prompt — (llm)
```yaml
todo:
- (llm ): "Summarise the following in 3 bullet points"
((inKey )): rawData
((context)): "monthly sales records"
((outPath)): summary
```
### Security secrets — (secget)
```yaml
todo:
- (secget ): "db.password"
((secRepo )): "myrepo"
((secBucket)): "app-secrets"
```
includes.md: |
## oJob includes and oPacks
### include — full oJob (jobs + todo executed)
Loads another oJob file and runs both its jobs and its todo list.
Use for composing complete sub-workflows.
```yaml
include:
- common-setup.yaml # local file
- oJob-common::oJobTest.yaml # from an installed oPack
- ojob.io/docker/_common # remote ojob.io job, fetched at runtime
```
### jobsInclude — job definitions only (todo not run)
Imports job definitions without triggering the included file's todo.
Use for reusable job libraries.
```yaml
jobsInclude:
- ojob.io/util/osArch # adds "Get current OS and Arch" job
- shared/db-jobs.yaml # local shared definitions
```
### oPacks declaration
Declare required oPacks in `ojob.opacks`; oJob installs them if missing.
```yaml
ojob:
opacks:
- openaf: ">=20230601" # minimum version constraint
- S3 # latest version
- oJob-common
```
### owraps and loadLibs
```yaml
ojob:
owraps :
- Server # loads ow.server.*
- Java # loads ow.java.*
loadLibs:
- s3.js # JS library from an installed oPack
```
### Multi-file oJob pattern
Split large oJobs across files using Namespace::JobName conventions:
```yaml
# main.yaml — entry point
include:
- jobs/setup.yaml
- jobs/process.yaml
todo:
- Setup::Init
- Process::Run
- Setup::Teardown
```
```yaml
# jobs/setup.yaml — job definitions only, no top-level todo
jobs:
- name: Setup::Init
exec: | #js
log("initialising environment")
- name: Setup::Teardown
type: shutdown
exec: | #js
log("releasing resources")
```
### Referencing remote ojob.io jobs
```yaml
include:
- ojob.io/docker/_common # provides Docker connect/disconnect jobs
jobsInclude:
- ojob.io/util/osArch # adds "Get current OS and Arch" job only
jobs:
- name: Build Image
from: Check for docker # job provided by ojob.io/docker/_common
exec: | #js
$sh("docker build -t myimage .").get(0)
```
common.md: |
## oJob-common modules
Declare `oJob-common` in `ojob.opacks`, then include the module you need.
```yaml
ojob:
opacks:
- oJob-common
```
---
### oJobBasics — general utilities
Provides simple utility jobs: start/stop/exit, sleep, stringify, set/get paths.
```yaml
include:
- oJob-common::oJobBasics.yaml
todo:
- oJob Start
- My Job
- oJob Stop
```
---
### oJobTest — unit test framework
One init job loads the JS test file; each test job chains `from: Init` → `to: oJob Test`.
```yaml
include:
- oJob-common::oJobTest.yaml # provides the "oJob Test" runner job
jobs:
- name: MyArea::Init
exec: | #js
args.tests = require("autoTestAll.MyArea.js")
- name: MyArea::Basic case
from: MyArea::Init
to : oJob Test
exec: args.func = args.tests.testBasicCase
- name: MyArea::Error path
from: MyArea::Init
to : oJob Test
exec: args.func = args.tests.testErrorPath
todo:
- MyArea::Init
- MyArea::Basic case
- MyArea::Error path
```
Companion JS file (`autoTestAll.MyArea.js`):
```javascript
(function() {
exports.testBasicCase = function() {
ow.loadFormat()
ow.test.assert(myFunc("hello"), "HELLO", "should uppercase")
}
exports.testErrorPath = function() {
var threw = false
try { myFunc(null) } catch(e) { threw = true }
ow.test.assert(threw, true, "should throw on null input")
}
})()
```
---
### oJobSQL — database operations
```yaml
include:
- oJob-common::oJobSQL.yaml
jobs:
- name: Query Orders
exec: | #js
args.rows = $job("SQL Execute Query", {
sql: "SELECT * FROM orders WHERE status = 'open'",
db : global.db
}).results
todo:
- Query Orders
```
---
### oJobHTTPd — embedded HTTP server
```yaml
include:
- oJob-common::oJobHTTPd.yaml
ojob:
daemon: true
todo:
- name: Start HTTPd
args:
port: 8080
host: "0.0.0.0"
- name : HTTPd handler
args :
uri : /api/status
handler: | #js
return { status: "ok", time: now() }
```
---
### oJobIO — file I/O utilities
```yaml
include:
- oJob-common::oJobIO.yaml
```
Provides jobs for file copy, move, delete, compress, and recursive folder operations./build-ojob a periodic job that checks an S3 bucket and logs any new files
Suggest Skills from History
Analyzes conversation history from ~/.openaf-mini-a/history/*.json to identify recurring task patterns not yet covered by existing commands or skills, then suggests concrete new skills to build.
# Suggest Skills from History
Analyze the user's conversation history to find recurring task patterns and
recommend new mini-a skills that would automate or streamline them.
## Step 1 — Inventory existing commands and skills
```bash
ls ~/.openaf-mini-a/commands/*.md 2>/dev/null | xargs -I{} basename {} .md
ls ~/.openaf-mini-a/skills/ 2>/dev/null
```
## Step 2 — Analyze history
Run a Python script to parse ~/.openaf-mini-a/history/*.json, extract the
first substantive user goal per conversation (filtering noise like "yes",
"ok", arithmetic), and print all goals.
## Step 3 — Cluster goals into themes
Group goals by topic (code-analysis, network-lookup, web-research, etc.)
and count frequency per theme.
## Step 4 — Subtract covered themes
Cross-reference with the inventory from Step 1 and mark already-covered
themes (git operations, cheatsheet, scaffolding, humanizer, …).
## Step 5 — Generate the report
Print a prioritised Markdown report of suggested skills (frequency ≥ 3),
each with: gap description, trigger phrases, example goals, and a proposed
skill description. Include an "Already Covered" summary table./suggest-skills
Add Your Own
Have an agent, slash command, hook or skill worth sharing? Open a pull request on GitHub.