solo

Automates CI/CD pipeline setup, adapted for the Mezon Mentor Bot ("MeKnow") platform. Use when setting up or modifying build and deployment pipelines, the GitHub Actions workflow (.github/workflows/rag-engine.yml), quality gates, or the /solo:implement verify step. Use when configuring the polyglot test runner (Python/uv, Go, TS/pnpm) with a pgvector service container or debugging CI failures.

Conducts multi-axis code review (MeKnow-adapted, polyglot). Use before merging any change. Use when reviewing code written by yourself, another agent, or a human across Python/Go/TypeScript. Use when you need to assess code quality across correctness, readability, architecture, security, and performance before it enters main. Complements the built-in `/code-review` and `/security-review` slash commands and the `/solo:address-review` PR-comment loop.

Simplifies code for clarity (MeKnow-adapted, polyglot + OpenSpec). Use when refactoring code for clarity without changing behavior in this repo. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity. Every change keeps the resolver-selected gates (uv/go/pnpm) green and respects the repo's invariants.

Collaborative bug-fixing mode — agent + human work together to triage, diagnose, fix, and verify bugs directly in the project code. Works for both FE (UI component bugs) and BE (logic/data/test bugs). Core pattern: understand → confirm with a failing test (Red) → fix to pass (Green). The test is both proof of understanding and a permanent regression guard.

Guides systematic root-cause debugging (Mezon Mentor Bot "MeKnow" platform). Use when a toolchain gate fails (`uv ... pytest`, `pyright`, `go test -race`, `pnpm test`), a build breaks, retrieval/runtime behavior doesn't match expectations, a citation is missing or a tenant boundary leaks, or you hit any unexpected error. Use when you need a systematic approach to finding and fixing the root cause rather than guessing.

Records decisions and documentation, adapted for the Mezon Mentor Bot ("MeKnow") platform. Use when making architectural decisions, changing the API contract (OpenAPI) or the BotPolicy/MCP boundary, shipping features, or recording context future engineers and agents need. Notes how OpenSpec design.md files serve as lightweight ADRs, that former RFCs live in docs/design/, and where docs/ lives.

Structures git workflow practices, adapted for the Mezon Mentor Bot ("MeKnow") platform — the platform/ git submodule of funix-mezon-bot. Use when making any code change. Use when committing, branching, resolving conflicts, writing Conventional Commit messages, opening PRs via gh, bumping the superproject gitlink, maintaining CHANGELOG.md, or organizing work across parallel streams.

Delivers changes incrementally (MeKnow-adapted, polyglot + OpenSpec). Use when implementing any feature or change that touches more than one file in this repo. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step. Each slice stays buildable and green under the resolver-selected gates (uv/go/pnpm as applicable + ci-free-gates.sh + solo-spec validate).

Autonomous SDLC orchestrator that manages the full software development lifecycle inside a mework sandbox. Spawns child agents, communicates with humans, and orchestrates the solo pipeline.

Breaks work into ordered tasks (MeKnow-adapted onto OpenSpec). Use when you have an OpenSpec proposal or clear requirements and need to fill the change's design.md and tasks.md with implementable, verifiable units. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.

Runs the discovery front-end that precedes planning — brainstorm the idea, research the market landscape + technical approach, brainstorm and author the PRD, then author the docs the project needs. Use at the very start of a project (greenfield) or before a significant new initiative on an existing codebase (brownfield). Delegates to the researcher, product-owner, and architect subagents and writes the standardized docs/ tree.

Hardens code against vulnerabilities (MeKnow-adapted, polyglot). Use when handling untrusted documents or webhook payloads, working with tenant isolation or server-side ACL in retrieve_kb, encrypting/decrypting provider credentials, the service JWT between backend and workers, or any answer-producing path. Use when building any feature that accepts untrusted data, manages tokens, or crosses a tenant boundary. Maps the OWASP Top 10 onto this repo's concrete controls (multi-tenant isolation + ACL-cohort cache keys, server-side ACL in retrieve_kb, Fernet credential encryption, HS256 service JWT, HMAC-signed inbound webhooks, citations-mandatory refusal, the compression invariant against KB prompt-injection).

Creates a new OpenSpec change with the standard artifact structure — proposal.md, design.md, tasks.md, ui.md, and delta specs. Detects when a change has a user-facing surface and creates ui.md. Includes design language discovery guidance.

Merges a change's delta specs into the canonical .solo/spec/specs/ tree. Idempotent — re-running is a no-op.

Creates specs before coding (MeKnow-adapted onto OpenSpec). Use when starting a new feature or significant change and no OpenSpec change exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea. Maps SPECIFY/PLAN/TASKS/IMPLEMENT onto /solo:propose, design.md, tasks.md, and /solo:implement (ship-plan → ship-code) — former RFCs now live as capability specs (rationale in docs/design/); do not invent a competing PRD file.

Six-axis spec review methodology — Structure, Clarity, Testability, Minimality, Consistency, Completeness, and UX Pattern Consistency. Each axis is evaluated independently, then findings are consolidated into a review report.

Documents the deterministic tag-driven skill/hook routing system. Tags on tasks and units determine which skills and hooks are loaded at each pipeline phase — no conditional text needed. Use to understand how tags work, what tags exist, and how to tag tasks.

Drives development with tests (polyglot + OpenSpec). Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality. Red-Green-Refactor with language-appropriate tests, the resolver-selected gates, and the `/solo:implement` Test(Red) phase. Project specifics (test commands, file patterns, fixtures, invariants) come from `solo.yaml` (pipeline section) and the project's `tdd` template.

Guides the AI through UX pattern-driven UI design for user-facing OpenSpec changes. Produces ui.md as a formal design handoff — anchored to the project's existing UX patterns, abstract business flows, and visual concepts. Use when a change has a visible surface (new screens, component changes, UX improvements).

Discovers and invokes agent skills (MeKnow-adapted). Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked, and it routes work onto this repo's solo-driven OpenSpec lifecycle (/solo:propose → /solo:spec → /solo:spec-pr → /solo:implement [ship-plan → ship-code] → /solo:address-review → /solo:archive).

Discovers and documents a project's UX language — the abstract patterns, business flows, and visual concepts that make its design consistent. Use before creating the first ui.md in a project, when making UX-significant changes, or when a human requests a design audit. Outputs .solo/spec/patterns/ux-patterns.md.

Collaborative UI concept mode — agent + human co-craft HTML artifacts with live preview, clean structure, and inline documentation. Use for wireframes, UI mockups, flow diagrams, and design exploration. This is "plan mode but in HTML": propose a concept, review the rendered preview, request changes, iterate until approved. The HTML artifact becomes shared documentation for both human and AI readers.

Scaffolds a new Solo workspace (product project) from the workspace/ template and installs the Solo tooling into it. Use when initializing a new project (/solo:init) or re-installing/upgrading the tooling in an existing workspace. Separates the two development angles — the Solo framework vs the workspace product — and lays down a self-contained product repo.