🛠️ UNIOSS Plugin

An A→Z, human-gated ticket pipeline for the UNIOSS team.
A GitLab ticket in — an investigated, planned, coded, reviewed, tested, ship-ready change out.

_{An AI Agent plugin by ttncode.}

---

Problem

• Agents miss deep context — misread the ask, ship the wrong thing.
• Passive agents, verbose replies, hard to act on.
• Every run means re-writing the same detailed brief from scratch.
• Feature checks still done by hand in the browser.

Solution

• Agent thinks before it acts — unclear ask gets clarified, never spec'd blind.
• One ticket URL in — a ship-ready, high-quality change out.
• Every stage automated: Investigate → Spec → Plan → Code → Review → Scope → Verify (test cases + evidence) → Ship.

How it works

Sub-agents

• Investigator — reads the ticket in depth (title, description, related tickets, comments), the codebase, and production DB.
• Planner — brainstorms to clarify the ask, writes the spec + plan (line-by-line real changes — no placeholders, no "TBD").
• Coder — writes clean code, 100% spec-compliant, backed by passing unit tests.
• Reviewer — checks the diff against UNIOSS's own review checklist.
• Scope — maps the blast radius of the change.
• Verify — writes test cases, drives the feature end-to-end, captures evidence screenshots.
• Shipper — pushes the branch and opens the merge request.

Quality & safety

• Human-gated — stops at 4 gates (clarify, spec, plan, review).
• Protected branches — direct pushes to master, v3-master, v3-develop, etc. are blocked.
• Read-only GitLab token — API scope can't write, so nothing gets touched by accident.

Pipeline & Gate

8 stages, 4 human gates. Gates stop for approval — nothing runs until you confirm:

sequenceDiagram
    autonumber
    actor You as You (PM)
    participant Main as Main Agent
    participant Inv as Investigator (opus)
    participant Spec as Spec Writer (sonnet)
    participant Plan as Planner (opus)
    participant Rev as Reviewer (opus)
    participant Scope as Scope (sonnet)
    participant Ver as Verify (sonnet)

    You->>Main: /unioss-pipeline <gitlab-url>
    Main->>Inv: dispatch — read ticket + codebase + DB
    Inv->>Main: INVESTIGATION.md + REPORT.md
    Main->>You: GATE 0 — clarify (only if unclear)
    You->>Main: confirm
    Main->>Spec: dispatch — write spec
    Spec->>Main: SPEC.md
    Main->>You: GATE 1 — approve spec / edit
    You->>Main: approve
    Main->>Plan: dispatch — write plan
    Plan->>Main: IMPLEMENTATION_V1.md
    Main->>You: GATE 2 — approve plan / edit
    You->>Main: approve
    Main->>Main: Code — CHANGES.md + fast tests
    Main->>Rev: dispatch — review diff
    Rev->>Main: REVIEW.md
    Main->>You: GATE 3 — fix / accept
    You->>Main: accept
    Main->>Scope: dispatch — map blast radius
    Scope->>Main: SCOPE.md
    Main->>Ver: dispatch — black-box verify (DB+UI)
    Ver->>Main: TEST_RESULTS.md

    note over Main,You: Finalize — branch + commit (no push/MR)

Loading

From Claude Code:

Install

Claude Code

/plugin marketplace add https://github.com/ttncode/unioss-plugins
/plugin install unioss-pipeline

Antigravity

agy plugin install https://github.com/ttncode/unioss-plugins
# If the plugin hasn't been loaded yet -> Ask the agent to load it

Codex

codex marketplace add https://github.com/ttncode/unioss-plugins
codex plugin install unioss-pipeline

After installation, run /unioss-doctor to verify the environment.

Commands

Pipeline (unioss-pipeline plugin)

Command	What
/unioss-doctor	Check dependencies
/unioss-pipeline <gitlab-url>	New ticket — e.g. /unioss-pipeline https://gitlab.unioss.jp/unioss/AdminPage/-/work_items/1834
/unioss-ship staging	Create a new merge request into v3-develop-tps branch
/unioss-ship customer	Create a new merge request into v3-develop branch (sync with the v3-master branch & re-run tests)
/unioss-mr-feedback <merge-url> [...]	Reviewer feedback — e.g. /unioss-mr-feedback https://gitlab.unioss.jp/unioss/AdminPage/-/merge_requests/3818
/unioss-feedback <gitlab-url>	Customer feedback — e.g. /unioss-feedback https://gitlab.unioss.jp/unioss/AdminPage/-/work_items/1834
/unioss-task "<description>"	Specific task — e.g. /unioss-task "Add a CSV export button to the product detail screen"
/unioss-api-spec <endpoint|controller>	Write the API spec for a new/changed endpoint

Usage

Commonly used:

Something broke? — run /unioss-doctor first.

New ticket, start to ship

1. /unioss-pipeline <gitlab-url> — full A→Z run, approve at each gate
2. /unioss-ship staging — ship to staging
3. /unioss-mr-feedback <merge-url> — improve based on the reviewer's feedback (if any)
4. /unioss-ship customer — ship to customer

Customer feedback on a shipped ticket

1. /unioss-feedback <gitlab-url> — improve based on the customer's feedback
2. /unioss-ship staging — re-ship to staging
3. /unioss-ship customer — ship to customer

Configuration

Everything lives in one file: .walkthrough/.config/unioss.config.json. You can change it if needed.

• Setup: run /unioss-doctor — scaffolds the file, checks it, and offers fixes.
• Module keys: admin-page, front-end, common-helper, common-models — each has a disk path (source.modules.<key>) and a GitLab project id (gitlab.projects.<key>).
• Secrets (env only): GITLAB_TOKEN (required).

Requirements

Dependency	Required	Notes
Node.js	✅	Hooks and scripts
jq	✅	JSON processing
Docker + mysql-unioss3 + php-unioss3	✅	DB + PHP runtime
GITLAB_TOKEN env var	✅	GitLab API access
Google Chrome	✅	Tester UI verification (Playwright MCP)

Run /unioss-doctor to check and auto-fix them all.

License

MIT