/moai feedback
The command for submitting feedback or bug reports to MoAI-ADK.
InfoOne-line summary:/moai feedbackauto-creates a GitHub issue from your improvement proposal or bug report about MoAI-ADK itself.
InfoSlash command: In Claude Code, type/moai:feedbackto run this command directly. Typing just/moaishows the list of all available subcommands.
Use this command when you find a bug while using MoAI-ADK, need a new feature, or come up with an improvement idea. There is no need to open GitHub and write an issue manually — you can submit feedback right inside Claude Code.
InfoImportant: this command does not modify your project’s code. It delivers feedback about the MoAI-ADK tool itself to the development team.
# Standard form
> /moai feedback
# Short aliases
> /moai fb
> /moai bug
> /moai issueRunning the command guides you through choosing the feedback type and entering the content.
/moai feedback takes no flags. The feedback type is determined automatically from the free-form content you enter, and the title and description are collected in a single AskUserQuestion round from the orchestrator. Just describe the problem or proposal in natural language.
Running /moai feedback proceeds as follows.
flowchart TD
A["/moai feedback run"] --> B["Choose feedback type"]
B --> C["Write the content"]
C --> D["Auto-collect current
environment info"]
D --> E["Auto-create
GitHub issue"]
E --> F["Return the issue URL"]The following information is included automatically when submitting feedback, so the development team can diagnose the problem faster.
| Collected item | Description | Example | Collection mode |
|---|---|---|---|
| MoAI-ADK version | Currently installed version (moai version) | v3.1.3 | Guaranteed (always collected) |
| OS info | Operating system and version (uname) | macOS 15.2 | Guaranteed (always collected) |
| Go toolchain version | Build provenance of the tool binary (go version) | go1.23.4 | best-effort (omitted where the Go toolchain is not installed) |
| Error logs | Error context passed by the orchestrator (if any) | TypeError: … | best-effort (included only when the orchestrator passes it; the workflow itself does not read session transcripts) |
/moai feedback reinforces the issue-creation process with the following behaviors.
As in the table above, the MoAI-ADK version (moai version) and OS info (uname) are guaranteed items that are always collected. The Go toolchain version (go version) and the error context passed by the orchestrator are best-effort items — when the conditions are not met (e.g. an environment with only the prebuilt moai binary and no Go toolchain installed), they are omitted, and that is not a failure.
Once the issue title is set, and before creating the issue, gh issue list --repo <target repo> --search "<title keywords>" --state open searches the target repository for open duplicate issues. This step does not prompt the user directly — it only produces a “possible duplicate issues” candidate report (issue number, title, URL, state), and the orchestrator decides whether to proceed with a new issue or direct you to the existing one.
Right before issue creation, gh auth status is checked. If gh is unauthenticated or the GitHub API rate limit has been hit, it responds gracefully:
- Notifies you of the detected state (unauthenticated or rate-limited).
- Suggests running
gh auth loginif unauthenticated, or waiting for the limit to reset if rate-limited. - Offers to save the written issue content locally at
.moai/state/feedback-draft-<timestamp>.md.
Your written feedback is never lost due to a gh failure — the local draft file is the recovery path.
The repository where /moai feedback creates issues is configured via the feedback.repository value in .moai/config/sections/feedback.yaml. The default is modu-ai/moai-adk (the MoAI-ADK tool repository itself), and users maintaining a fork can redirect feedback by changing this value to their fork repository.
Before an issue is created, /moai feedback shows what would be posted — the title, the body in full, and a summary of any values it masked (secrets, tokens, absolute home paths) — and asks whether to go ahead. The feedback.auto_submit value in .moai/config/sections/feedback.yaml controls that question: the shipped default false asks every time, and true submits without asking.
feedback:
repository: modu-ai/moai-adk
auto_submit: falsemoai init also asks for this value in the setup wizard, and it can be changed later from the web console’s Feedback section. Setting it to true skips only the question — masking still runs, and a report that reads as a security-vulnerability disclosure is still refused and routed to the private advisory path instead of a public issue.
Between the drafted report and gh issue create, a scrubbing contract runs. A masking scrubber covers sensitive values such as secrets, tokens, and paths; a vulnerability classifier decides whether the body reads as a security disclosure; and the masked-value list (mask log) and any failed submissions (retry queue) are each kept as a record. You can inspect this procedure directly from the terminal with the moai feedback scrub (masking preview) and moai feedback queue (retry queue) verbs.
The classifier reads the body before masking. A vulnerability report is recognized by the very strings masking removes, so classifying afterwards would fail silently on exactly the path whose cost is a public disclosure. The order is therefore fixed.
This contract is a convention the skill body follows, not a sandbox. Opening an issue by hand on GitHub bypasses all three (masking, classification, the confirmation question) — the same caution is yours when writing into a public repository directly.
Reports an error or unexpected behavior encountered while using MoAI-ADK.
> /moai feedback
# Type (auto-detected): bug report
# Title: characterization tests not generated when running /moai run
# Description: I ran /moai run for SPEC-AUTH-001, but the PRESERVE stage
# did not generate characterization tests and it moved straight
# to the IMPROVE stage.
# Reproduction: run /moai run SPEC-AUTH-001Proposes a new feature you would like added to MoAI-ADK.
> /moai feedback
# Type (auto-detected): feature request
# Title: add an option to /moai loop to target specific files only
# Description: it would be great if /moai loop could target a specific
# directory or file instead of the whole project.
# Example: /moai loop --path src/auth/Asks a question about how to use MoAI-ADK or how it behaves.
> /moai feedback
# Type (auto-detected): question
# Title: what is the difference between /moai fix and /moai loop?
# Description: both commands seem to fix errors, but I am curious
# about when to use which one.The /moai feedback command is executed directly by the orchestrator, with no subagent delegation:
flowchart TD
User["User request"] --> Orchestrator["MoAI orchestrator"]
Orchestrator --> Collect["Collect environment info"]
Collect --> Info1["MoAI-ADK version (guaranteed)"]
Collect --> Info2["OS info (guaranteed)"]
Collect --> Info3["Go toolchain version (best-effort)"]
Collect --> Info4["Error logs (best-effort)"]
Info1 --> Format["Issue formatting"]
Info2 --> Format
Info3 --> Format
Info4 --> Format
Format --> Dup["Duplicate-issue candidate search
gh issue list --search"]
Dup --> GitHub["Orchestrator direct execution
(no subagent delegation)
gh issue create"]
GitHub --> Complete["Return issue URL"]Responsible parties:
| Party | Role | Main work |
|---|---|---|
| MoAI orchestrator | Runs the entire feedback process directly (no subagent delegation) | Collects type/title/description, gathers environment info, searches duplicate-issue candidates, runs gh issue create directly, returns the URL |
Not spawning a subagent for a simple single-procedure task is also a tokenomics principle — delegate only when needed, via the cheapest path.
# The situation where the error occurred
> /moai "Implement payment feature" --branch
# Error: Branch creation failed - permission denied
# Submit feedback
> /moai feedbackThe MoAI orchestrator asks for the feedback type, title, and description in turn. Once you answer, a GitHub issue is created automatically and the issue URL is returned.
A GitHub issue has been created:
https://github.com/modu-ai/moai-adk/issues/1234
The development team will review it and respond.InfoFeedback is always welcome! Even minor inconveniences submitted as feedback are a big help in improving MoAI-ADK.
Yes, you can edit or close the issue directly on GitHub. The issue URL is provided, so you can access it any time.
Duplicate issues are checked on GitHub, so there is no need to worry. If the problem has already been reported, you are directed to the existing issue.
The development team responds with a comment on the issue after review. Complex problems may take time to resolve.
/moai feedback automatically collects environment information so the development team can understand the problem faster. It is more efficient than creating an issue manually.