🛠️ 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.}

---

Why use it

⚡ Fast setup

• Two commands to install; /unioss-doctor checks deps.
• Zero config on a standard UNIOSS environment.
• Every setting in one file config.mjs.

🤖 Automation (A→Z)

• Reads the GitLab ticket + linked issues, analyzes the dumped production DB and codebase.
• Runs all the stages automatically: Investigate → Spec → Plan → Code → Review → Verify → Ship.
• Rounds — customer feedback continues with new rounds on the same ticket.
• One command opens the staging / customer MRs with the right branch, reviewers, and options.

✅ Quality & safety

• Human-gated — stops at 4 gates (spec, plan, review, ship). No runaway edits.
• Review enforces the UNIOSS CI3 + PHP 8.1 clean-code + security checklist.
• Real tests — PHPUnit in Docker; UI driven in a real browser (Playwright) with screenshots.
• Never commits or pushes a protected branch — a hook blocks it, not just a rule in a doc.

🧠 Team knowledge

• Every ticket turned into an agent-written report in your language — ask what happened today, this week, or on any past ticket without digging through GitLab.
• Ask free-form questions like "what did customers complain about this week?" and get an answer, not a search.
• Facts and rules learned from past tickets carry forward automatically into new investigations, so the pipeline gets sharper over time.

Pipeline

╭─ UNIOSS Pipeline · AP#1834 · round-1 ────────────────────────────────╮
│                                                                      │
│  #   Stage        Runs as            Output                          │
│  ───────────────────────────────────────────────────────────────     │
│  1   Investigate  subagent · opus    INVESTIGATION + REPORT          │
│  ⛔  GATE 0       you                clarify (only if unclear)       │
│  2   Spec         subagent · opus    SPEC.md                         │
│  ⛔  GATE 1       you                approve spec / edit             │
│  3   Plan         subagent · opus    IMPLEMENTATION_V1               │
│  ⛔  GATE 2       you                approve plan / edit             │
│  4   Code         main · sonnet      CHANGES.md + fast tests         │
│  5   Review       subagent · opus    REVIEW.md                       │
│  ⛔  GATE 3       you                fix / accept                    │
│  6   Verify       subagent · sonnet  TEST_RESULTS.md (DB+UI)         │
│  7   Finalize     main               branch + commit (no push/MR)    │
│                                                                      │
│  Gates stop for approval. Nothing runs until you confirm.            │
╰──────────────────────────────────────────────────────────────────────╯

Artifacts land in .walkthrough/<PREFIX>#<IID>/round-<N>/, surfaced as Ctrl+Click-able paths.

Commands

Pipeline (unioss-pipeline plugin)

Command	What
/unioss-pipeline <gitlab-url>	New ticket — e.g. /unioss-pipeline https://gitlab.unioss.jp/unioss/AdminPage/-/work_items/1834
/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-mr-feedback <merge-url> [...]	Reviewer feedback — e.g. /unioss-mr-feedback https://gitlab.unioss.jp/unioss/AdminPage/-/merge_requests/3818
/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-api-spec <endpoint|controller>	Write the API spec for a new/changed endpoint
/unioss-doctor	Check dependencies

Knowledge (unioss-knowledge plugin)

Command	What
/unioss-knowledge-today	Report new issues today?
/unioss-knowledge-ticket <gitlab-url>	Report a specific issue?
/unioss-knowledge-refresh [daily|weekly|monthly|yearly]	Refresh the knowledge — If you want the Agent to remember, run /unioss-knowledge-approve
/unioss-knowledge-approve	Approve staged rules — only then injected into the agents' brain
/unioss-knowledge-ask "<question>" [period]	Ask anything — e.g. /unioss-knowledge-ask "What did customers complain about this week?"
/unioss-knowledge	Check of the knowledge base status

Install

Claude Code

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

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
codex plugin install unioss-knowledge

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

Usage

Commonly used:

Something broke? — /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 — open the staging MR
3. /unioss-mr-feedback <merge-url> — improve based on the reviewer's feedback (if any)
4. /unioss-ship customer — open the staging MR

Customer feedback on a shipped ticket

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

Morning catch-up

1. /unioss-knowledge-today — What's new today?
2. /unioss-knowledge-ask "What did customers complain about this week?" — ask for anything

Monthly knowledge upkeep (keeps agents sharp)

1. /unioss-knowledge-refresh monthly — distill sentiment, rebuild the global brief, stage rules
2. /unioss-knowledge-approve — review staged rules; approved ones are injected into every agent session
3. /unioss-knowledge — confirm freshness

Configuration

One file holds everything: .walkthrough/.config/unioss.config.json via /unioss-doctor command.

• Scaffold: node "${CLAUDE_PLUGIN_ROOT}/scripts/config.mjs" init — writes every key, grouped per-machine → per-team → project-wide.
• Resolution: env → file → default, deep-merged.
• Module keys (admin-page, front-end, common-helper, common-models) are the one vocabulary: source.modules.<key> is its path on disk, gitlab.projects.<key> is its GitLab project id.
• Inspect / validate: config.mjs print · config.mjs check (/unioss-doctor runs check).
• Wrong module paths: config.mjs scan locates them; scan --write repairs the file (/unioss-doctor offers this).
• Secrets (env only): GITLAB_TOKEN (required) · DB_PASSWORD (optional).
• Tester browser: ! npx playwright install --with-deps chrome if Chrome is missing.
• Tester URLs/credentials are not configured — they live in skills/unioss-verify/tester-access.md.

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

Run /unioss-doctor to check them all at once.

License

MIT