feat: community polish — examples, badges, discussions#72
Conversation
📝 WalkthroughWalkthroughAdds README badges and "Self-hostable" tagline, introduces multiple example scripts and a self-hosted config template, and augments package metadata in Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces several example scripts and a self-hosted configuration file to demonstrate the capabilities of magic-code, alongside updating the README with project status badges. The review feedback highlights several opportunities to improve the robustness of these examples, such as using trap for temporary file cleanup, avoiding brittle output parsing with tail, and ensuring correct flag usage for headless CI environments. Additionally, there are suggestions to resolve a conflict between set -e and manual exit status checks and to fix a documentation mismatch in the streaming example.
| set -e | ||
|
|
||
| echo "Running tests..." | ||
| if cargo test --workspace 2>&1 | tail -5 | grep -q "FAILED"; then |
There was a problem hiding this comment.
Restricting the failure check to the last 5 lines of output using tail -5 is brittle. If the "FAILED" indicator is pushed further up by other output, grep will fail, and the script will incorrectly report "All tests pass." despite the actual failure. This could lead to false positives in CI.
| if cargo test --workspace 2>&1 | tail -5 | grep -q "FAILED"; then | |
| if cargo test --workspace 2>&1 | grep -q "FAILED"; then |
| # Batch code review: review multiple files | ||
| # Usage: ./batch-review.sh src/*.rs | ||
|
|
||
| TMPFILE=$(mktemp) |
There was a problem hiding this comment.
The temporary file created with mktemp is not cleaned up if the script is interrupted (e.g., via Ctrl+C) or fails before reaching the explicit rm command. It is safer to use a trap to ensure the file is removed upon exit.
| TMPFILE=$(mktemp) | |
| TMPFILE=$(mktemp) | |
| trap 'rm -f "$TMPFILE"' EXIT |
| #!/bin/bash | ||
| # CI/CD: Auto-fix failing tests with magic-code | ||
| # Usage: ./ci-fix.sh | ||
| set -e |
There was a problem hiding this comment.
Using set -e in combination with manual exit status checks (like if [ $? -eq 0 ] on line 13) can lead to unexpected behavior. If magic-code fails, the script will terminate immediately at line 11, making the else block on line 16 unreachable. It is generally better to avoid set -e when you intend to handle errors manually.
| echo "Running tests..." | ||
| if cargo test --workspace 2>&1 | tail -5 | grep -q "FAILED"; then | ||
| echo "Tests failed. Asking magic-code to fix..." | ||
| magic-code --yes --json \ |
There was a problem hiding this comment.
In an automated CI/CD context, the bash tool will still prompt for user confirmation unless the --dangerously-allow-bash flag is provided, even if --yes is used. To ensure the script runs headlessly as intended, you should include this flag.
| magic-code --yes --json \ | |
| magic-code --yes --dangerously-allow-bash --json \ |
| @@ -0,0 +1,15 @@ | |||
| #!/bin/bash | |||
| # NDJSON streaming: pipe magic-code events to a web app | |||
| # Usage: ./stream-to-webapp.sh "your prompt" | |||
There was a problem hiding this comment.
The usage example in the comment refers to a different filename (stream-to-webapp.sh) than the actual file (stream-events.sh).
| # Usage: ./stream-to-webapp.sh "your prompt" | |
| # Usage: ./stream-events.sh "your prompt" |
1. GitHub Discussions enabled 2. Examples directory: - ci-fix.sh: auto-fix failing tests in CI - batch-review.sh: review multiple files - stream-events.sh: NDJSON streaming to web app - config-selfhosted.toml: Qwen 3.5 via LiteLLM config 3. README badges: CI, Security, License, Release 4. Repo topics: ai, coding-agent, rust, tui, self-hosted, etc.
kienbui1995
force-pushed
the
feat/community-polish
branch
from
134276c to
1ba8252
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
examples/ci-fix.sh (1)
6-22: Consider addingclippyto mirror the project’s pre-commit quality gate.This example validates tests only; adding
cargo clippy --workspace --all-targetswould catch additional CI failures earlier.Based on learnings, "Run
cargo test --workspace && cargo clippy --workspace --all-targetsbefore committing".🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@examples/ci-fix.sh` around lines 6 - 22, Add a cargo clippy check to the CI script so linting mirrors the project's pre-commit gate: run "cargo test --workspace && cargo clippy --workspace --all-targets" (or run clippy immediately after the initial cargo test) before invoking magic-code; update the conditional logic around the existing cargo test invocation (the block using "cargo test --workspace 2>&1 | tail -5 | grep -q 'FAILED'" and the subsequent magic-code call) to consider clippy failures the same as test failures (capture clippy's exit status and treat non-zero as a failure to trigger the fix flow or to fail CI).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@examples/batch-review.sh`:
- Around line 5-11: The script currently creates TMPFILE with mktemp and writes
to it without ensuring cleanup on failure or interruption and allows running
with zero args; add a strict shell header (set -euo pipefail) and an early
argument guard that exits with a usage message if "$#" is zero, replace echo
with printf for portability when writing the per-file review prompts to TMPFILE,
and register a trap 'trap "rm -f \"$TMPFILE\"" EXIT' immediately after creating
TMPFILE so the temp file is removed on any exit; update references to TMPFILE
and the magic-code --yes --json --batch "$TMPFILE" invocation accordingly.
In `@examples/ci-fix.sh`:
- Around line 7-19: Capture cargo test's exit status and output instead of
relying on tail+grep and make magic-code failure reachable by not letting set -e
short-circuit; specifically, run cargo test --workspace with its stdout/stderr
redirected into a variable/file (e.g., test_output="$(cargo test --workspace
2>&1)" and test_exit=$?), then inspect test_exit (and optionally grep
"$test_output" for "FAILED") to decide whether to invoke magic-code; likewise
run magic-code in a way that preserves its exit code (e.g., magic-code ... -o
fix-result.json; magic_exit=$?) and branch on magic_exit to either re-run cargo
test or print the failure message and exit non-zero, updating the script's cargo
test / magic-code checks instead of relying on tail/grep and unsettable set -e
behavior.
In `@examples/config-selfhosted.toml`:
- Around line 4-9: The TOML example places provider-level key "base_url" and
runtime-level key "notifications" under the [default] section, but DefaultLayer
(mc/crates/mc-config/src/types.rs) does not accept those keys so they will be
ignored; move "provider" and "base_url" into the provider-specific section
(e.g., [providers.litellm] or whatever provider block your config uses) and move
"notifications" into the runtime or top-level section that the config expects
(e.g., [runtime] or the top-level flags) so the self-hosted example actually
applies to localhost:4000 and enables/disables notifications correctly. Ensure
keys remain named exactly "base_url" and "notifications" and reference the same
provider name "litellm" used in the [default] model mapping.
In `@examples/stream-events.sh`:
- Around line 3-5: Update the usage message in examples/stream-events.sh to
reference the correct script name "stream-events.sh" and add a check for the
prompt argument ($1) before calling magic-code; if $1 is empty or missing, print
the corrected usage string and exit with a non-zero status. Specifically, adjust
the header line that currently mentions "stream-to-webapp.sh" to
"stream-events.sh", validate $1 (the prompt) at the top of the script, and only
run the pipeline magic-code --yes --ndjson "$1" | while IFS= read -r line; do
when the argument is present.
---
Nitpick comments:
In `@examples/ci-fix.sh`:
- Around line 6-22: Add a cargo clippy check to the CI script so linting mirrors
the project's pre-commit gate: run "cargo test --workspace && cargo clippy
--workspace --all-targets" (or run clippy immediately after the initial cargo
test) before invoking magic-code; update the conditional logic around the
existing cargo test invocation (the block using "cargo test --workspace 2>&1 |
tail -5 | grep -q 'FAILED'" and the subsequent magic-code call) to consider
clippy failures the same as test failures (capture clippy's exit status and
treat non-zero as a failure to trigger the fix flow or to fail CI).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 4b1a11d7-73b8-4b1e-9b48-108810892429
📒 Files selected for processing (5)
README.mdexamples/batch-review.shexamples/ci-fix.shexamples/config-selfhosted.tomlexamples/stream-events.sh
| TMPFILE=$(mktemp) | ||
| for file in "$@"; do | ||
| echo "Review $file for bugs, security issues, and improvements. Be specific about line numbers." >> "$TMPFILE" | ||
| done | ||
|
|
||
| magic-code --yes --json --batch "$TMPFILE" | ||
| rm "$TMPFILE" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check if the file exists and examine its full contents
find . -name "batch-review.sh" -type fRepository: kienbui1995/mc-code
Length of output: 89
🏁 Script executed:
# If file exists, read its full contents
cat examples/batch-review.sh 2>/dev/null || echo "File not found"Repository: kienbui1995/mc-code
Length of output: 371
🏁 Script executed:
# Verify the script's current state matches the snippet
wc -l examples/batch-review.sh 2>/dev/null || echo "Cannot determine line count"Repository: kienbui1995/mc-code
Length of output: 90
Harden temp-file lifecycle and empty-args behavior.
The script creates a temp file without cleanup on failure or interruption, and silently accepts zero arguments, creating an empty batch file. Add an EXIT trap for cleanup, set -euo pipefail for safety, an argument guard, and use printf for portability.
Suggested patch
#!/bin/bash
# Batch code review: review multiple files
# Usage: ./batch-review.sh src/*.rs
+set -euo pipefail
+
+if [ "$#" -eq 0 ]; then
+ echo "Usage: ./batch-review.sh <files...>" >&2
+ exit 2
+fi
TMPFILE=$(mktemp)
+trap 'rm -f "$TMPFILE"' EXIT
for file in "$@"; do
- echo "Review $file for bugs, security issues, and improvements. Be specific about line numbers." >> "$TMPFILE"
+ printf 'Review %s for bugs, security issues, and improvements. Be specific about line numbers.\n' "$file" >> "$TMPFILE"
done
magic-code --yes --json --batch "$TMPFILE"
-rm "$TMPFILE"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@examples/batch-review.sh` around lines 5 - 11, The script currently creates
TMPFILE with mktemp and writes to it without ensuring cleanup on failure or
interruption and allows running with zero args; add a strict shell header (set
-euo pipefail) and an early argument guard that exits with a usage message if
"$#" is zero, replace echo with printf for portability when writing the per-file
review prompts to TMPFILE, and register a trap 'trap "rm -f \"$TMPFILE\"" EXIT'
immediately after creating TMPFILE so the temp file is removed on any exit;
update references to TMPFILE and the magic-code --yes --json --batch "$TMPFILE"
invocation accordingly.
| if cargo test --workspace 2>&1 | tail -5 | grep -q "FAILED"; then | ||
| echo "Tests failed. Asking magic-code to fix..." | ||
| magic-code --yes --json \ | ||
| "The tests are failing. Read the test output, find the bug, and fix it. Run tests again to verify." \ | ||
| -o fix-result.json | ||
|
|
||
| if [ $? -eq 0 ]; then | ||
| echo "Fix applied. Re-running tests..." | ||
| cargo test --workspace | ||
| else | ||
| echo "magic-code could not fix the issue." | ||
| exit 1 | ||
| fi |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n examples/ci-fix.shRepository: kienbui1995/mc-code
Length of output: 842
Failure detection via pipeline loses cargo test exit code; $? check is dead code due to set -e.
The pipeline on line 7 loses the cargo test exit code. If tests fail without "FAILED" appearing in the last 5 lines, the condition evaluates false and the else block incorrectly reports success. Additionally, with set -e active, the else block (lines 16–18) is unreachable—if magic-code fails, the script exits immediately rather than executing that branch.
Suggested patch
echo "Running tests..."
-if cargo test --workspace 2>&1 | tail -5 | grep -q "FAILED"; then
+TEST_LOG=$(mktemp)
+trap 'rm -f "$TEST_LOG"' EXIT
+
+if ! cargo test --workspace >"$TEST_LOG" 2>&1; then
echo "Tests failed. Asking magic-code to fix..."
- magic-code --yes --json \
- "The tests are failing. Read the test output, find the bug, and fix it. Run tests again to verify." \
- -o fix-result.json
-
- if [ $? -eq 0 ]; then
+ if magic-code --yes --json \
+ "The tests are failing. Use this test output to find and fix the bug:
+$(tail -n 200 "$TEST_LOG")
+Run tests again to verify." \
+ -o fix-result.json; then
echo "Fix applied. Re-running tests..."
cargo test --workspace
else
echo "magic-code could not fix the issue."
exit 1
fi
else
echo "All tests pass."
fi🧰 Tools
🪛 Shellcheck (0.11.0)
[style] 13-13: Check exit code directly with e.g. 'if mycmd;', not indirectly with $?.
(SC2181)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@examples/ci-fix.sh` around lines 7 - 19, Capture cargo test's exit status and
output instead of relying on tail+grep and make magic-code failure reachable by
not letting set -e short-circuit; specifically, run cargo test --workspace with
its stdout/stderr redirected into a variable/file (e.g., test_output="$(cargo
test --workspace 2>&1)" and test_exit=$?), then inspect test_exit (and
optionally grep "$test_output" for "FAILED") to decide whether to invoke
magic-code; likewise run magic-code in a way that preserves its exit code (e.g.,
magic-code ... -o fix-result.json; magic_exit=$?) and branch on magic_exit to
either re-run cargo test or print the failure message and exit non-zero,
updating the script's cargo test / magic-code checks instead of relying on
tail/grep and unsettable set -e behavior.
| [default] | ||
| model = "qwen3.5-9b" | ||
| provider = "litellm" | ||
| base_url = "http://localhost:4000" | ||
| max_tokens = 4096 | ||
| notifications = false |
There was a problem hiding this comment.
base_url and notifications look scoped to the wrong section.
DefaultLayer (from mc/crates/mc-config/src/types.rs) does not define these keys, so placing them under [default] risks silently ignoring them. Please move provider-level and runtime-level keys to their supported sections so this self-hosted example actually targets localhost:4000.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@examples/config-selfhosted.toml` around lines 4 - 9, The TOML example places
provider-level key "base_url" and runtime-level key "notifications" under the
[default] section, but DefaultLayer (mc/crates/mc-config/src/types.rs) does not
accept those keys so they will be ignored; move "provider" and "base_url" into
the provider-specific section (e.g., [providers.litellm] or whatever provider
block your config uses) and move "notifications" into the runtime or top-level
section that the config expects (e.g., [runtime] or the top-level flags) so the
self-hosted example actually applies to localhost:4000 and enables/disables
notifications correctly. Ensure keys remain named exactly "base_url" and
"notifications" and reference the same provider name "litellm" used in the
[default] model mapping.
| # Usage: ./stream-to-webapp.sh "your prompt" | ||
|
|
||
| magic-code --yes --ndjson "$1" | while IFS= read -r line; do |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, check if examples/stream-events.sh exists and read its content
cat -n examples/stream-events.shRepository: kienbui1995/mc-code
Length of output: 676
🏁 Script executed:
# Check if stream-to-webapp.sh exists
fd -a "stream-to-webapp" examples/Repository: kienbui1995/mc-code
Length of output: 45
🏁 Script executed:
# List all files in examples directory to understand the structure
ls -la examples/Repository: kienbui1995/mc-code
Length of output: 430
Fix usage string and validate prompt input.
The usage line references a non-existent script name stream-to-webapp.sh instead of the actual script name stream-events.sh, and $1 is used without an argument check. Users calling this script without arguments will pass an empty string to magic-code.
Suggested patch
#!/bin/bash
# NDJSON streaming: pipe magic-code events to a web app
-# Usage: ./stream-to-webapp.sh "your prompt"
+# Usage: ./stream-events.sh "your prompt"
+set -euo pipefail
+
+if [ "$#" -lt 1 ]; then
+ echo 'Usage: ./stream-events.sh "your prompt"' >&2
+ exit 2
+fi
magic-code --yes --ndjson "$1" | while IFS= read -r line; do🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@examples/stream-events.sh` around lines 3 - 5, Update the usage message in
examples/stream-events.sh to reference the correct script name
"stream-events.sh" and add a check for the prompt argument ($1) before calling
magic-code; if $1 is empty or missing, print the corrected usage string and exit
with a non-zero status. Specifically, adjust the header line that currently
mentions "stream-to-webapp.sh" to "stream-events.sh", validate $1 (the prompt)
at the top of the script, and only run the pipeline magic-code --yes --ndjson
"$1" | while IFS= read -r line; do when the argument is present.
|
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
examples/ci-fix.sh (1)
7-19:⚠️ Potential issue | 🟠 MajorFix test-failure detection and unreachable
magic-codefailure branch.Current control flow can miss failing tests and incorrectly print “All tests pass.” Also, with
set -e, a failingmagic-codeexits before the$?branch runs, so Lines 16–18 won’t execute as intended.Suggested patch
echo "Running tests..." -if cargo test --workspace 2>&1 | tail -5 | grep -q "FAILED"; then +TEST_LOG="$(mktemp)" +trap 'rm -f "$TEST_LOG"' EXIT + +if ! cargo test --workspace >"$TEST_LOG" 2>&1; then echo "Tests failed. Asking magic-code to fix..." - magic-code --yes --json \ - "The tests are failing. Read the test output, find the bug, and fix it. Run tests again to verify." \ - -o fix-result.json - - if [ $? -eq 0 ]; then + if magic-code --yes --json \ + "The tests are failing. Use this output to find and fix the bug: +$(tail -n 200 "$TEST_LOG") +Run tests again to verify."; then echo "Fix applied. Re-running tests..." cargo test --workspace else echo "magic-code could not fix the issue." exit 1 fi else echo "All tests pass." fi🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@examples/ci-fix.sh` around lines 7 - 19, Detect failing tests reliably by avoiding losing exit status through pipes and by handling magic-code failures when set -e is enabled: run cargo test --workspace 2>&1 | tee test-output and then check grep -q "FAILED" test-output (or enable set -o pipefail before the pipe) instead of relying on piped exit status, and invoke magic-code in a safe way that captures its exit code (e.g., temporarily disable errexit with set +e; run magic-code --yes --json ... -o fix-result.json; rc=$?; set -e; then test rc with if [ $rc -eq 0 ]; then ...) so the "magic-code could not fix" branch executes correctly when magic-code fails; refer to the cargo test invocation, the magic-code call, and usage of $?/rc in the script to locate where to change.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@examples/ci-fix.sh`:
- Around line 9-11: The CLI currently prints JSON and returns early when the
--json flag is set, which prevents the -o output-file logic from running; update
the command handling so that when both --json and -o are provided the JSON is
written to the specified file instead of (or in addition to) only printing to
stdout. Change the handler that prints JSON to either: a) write the JSON string
to the path from the -o option before returning, or b) skip the early return and
funnel the same JSON payload into the existing file-write routine used by the -o
branch; ensure you reference the --json flag handling and the -o output-file
logic so both paths produce the artifact.
---
Duplicate comments:
In `@examples/ci-fix.sh`:
- Around line 7-19: Detect failing tests reliably by avoiding losing exit status
through pipes and by handling magic-code failures when set -e is enabled: run
cargo test --workspace 2>&1 | tee test-output and then check grep -q "FAILED"
test-output (or enable set -o pipefail before the pipe) instead of relying on
piped exit status, and invoke magic-code in a safe way that captures its exit
code (e.g., temporarily disable errexit with set +e; run magic-code --yes --json
... -o fix-result.json; rc=$?; set -e; then test rc with if [ $rc -eq 0 ]; then
...) so the "magic-code could not fix" branch executes correctly when magic-code
fails; refer to the cargo test invocation, the magic-code call, and usage of
$?/rc in the script to locate where to change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: b6138c32-cdbc-4750-92bd-8467aa24af5c
📒 Files selected for processing (7)
README.mdexamples/batch-review.shexamples/ci-fix.shexamples/config-selfhosted.tomlexamples/demo.shexamples/stream-events.shmc/Cargo.toml
✅ Files skipped from review due to trivial changes (5)
- README.md
- mc/Cargo.toml
- examples/config-selfhosted.toml
- examples/demo.sh
- examples/stream-events.sh
🚧 Files skipped from review as they are similar to previous changes (1)
- examples/batch-review.sh
| magic-code --yes --json \ | ||
| "The tests are failing. Read the test output, find the bug, and fix it. Run tests again to verify." \ | ||
| -o fix-result.json |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify `--json` return path occurs before `-o` output write handling.
rg -n -C4 'if json_output|if let Some\(path\) = output_path|return Ok\(\);' mc/crates/mc-cli/src/main.rsRepository: kienbui1995/mc-code
Length of output: 726
--json bypasses -o output file creation due to early return.
The function returns at line 1722 after printing JSON output, before reaching the -o file-write logic at lines 1724-1726. Using both --json and -o together will silently ignore the output file flag. Redirect stdout or drop --json if an artifact is required.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@examples/ci-fix.sh` around lines 9 - 11, The CLI currently prints JSON and
returns early when the --json flag is set, which prevents the -o output-file
logic from running; update the command handling so that when both --json and -o
are provided the JSON is written to the specified file instead of (or in
addition to) only printing to stdout. Change the handler that prints JSON to
either: a) write the JSON string to the path from the -o option before
returning, or b) skip the early return and funnel the same JSON payload into the
existing file-write routine used by the -o branch; ensure you reference the
--json flag handling and the -o output-file logic so both paths produce the
artifact.
1 participant
Community & Adoption
Summary by CodeRabbit
Documentation
New Features
Chores