g1t-agent · merged · 15 entries · 4 tool calls
What happened
- Told about 2 other pull requests in progress: #8, #7.
- Running on Claude Sonnet 5.5.
Prompt
You are a coding agent working in the git repository checked out in the current directory, on pull request #81 of this repository. Issue #80: CI: fail when a flag is missing from the README Every flag `parse_args` in `src/lib.rs` accepts (`--shout`, `--times`, `-L` and so on) should be listed in the README's options table. Nothing checks that today, so a new flag can land undocumented. Add a step to `.g1t/workflows/ci.yml`, before the tests, named **Every flag is documented**. It should find each flag the parser matches on and fail, naming the flags, when one of them does not appear in `README.md`. Keep it a short shell step; no new dependencies. Other agents and people are working in this repository at the same time. These pull requests are in progress, and any of them may merge before yours: - #8 Greet in Spanish and French (for issue #2), by g1t-agent: changes Cargo.lock, src/lib.rs, src/main.rs - #7 Greet in Spanish and French (for issue #2), by g1t-agent: changes README.md, src/lib.rs, src/main.rs Keep your change to what your task needs. Where you have to change the same files as one of these, keep your edits small and local so both can merge cleanly: do not reformat, reorder or move code you do not need to change, and do not do work that belongs to one of them. You have g1t's own tools (mcp__g1t__…) for this repository. Use them to work with the other agents and people here rather than around them: if you find something that needs doing outside your task, open an issue for it with create_issue, saying what and why and naming the pull request you are working on, instead of widening your change; to tell another pull request's author something, such as a conflict you can see coming, comment on it with add_comment; to ask the agent working on another pull request something, or hand it work that belongs there, use message_agent with kind question or handoff and your own pull request as from_number, and keep working: the answer reaches you at a later step. Answer what other agents send you with answer_message. If the work mentions a ticket or alert from another system, such as a Jira key like TECH-1234 or a Sentry link, get_context fetches it as it is now. get_pull_request shows another pull request's change and the files it shares with others. The repository's GitHub Actions workflows run on every commit you push: list_workflow_runs with your pull request's number shows how they went, and get_workflow_run and get_job_logs show why one failed. Mention anything you opened, asked or answered in your summary. Make the change and keep it focused on the issue. Commit your work with a clear message. Do not push; that is done for you. Finish with a short summary of what you changed and why. It becomes the description of your pull request, so write it for a reviewer: plain sentences, no headings, no emoji, no checklists, and nothing about whether anything was committed or pushed. Say what you did not verify.
- Bash
cat .g1t/workflows/ci.yml; grep -n '"-' src/lib.rs; grep -n -- '--\|-L' README.md | head -30 - Bash
python3 - <<'E' p='.g1t/workflows/ci.yml' s=open(p).read() new=''' - name: Every flag is documented run: | missing="" for flag in $(grep -o 'arg == "-[^"]*"' src/lib.rs | cut -d'"' -f2 | sort -u); do grep '^|' README.md | grep -qF -- "\\`$flag\\`" || missing="$missing $flag" done if [ -n "$missing" ]; then echo "Flags missing from the README options table:$missing" exit 1 fi ''' s=s.replace(" - name: Tests\n",new+" - name: Tests\n") open(p,'w').write(s) E sed -n 25,40p .g1t/workflows/ci.yml # simulate missing="" for flag in $(grep -o 'arg == "-[^"]*"' src/lib.rs | cut -d'"' -f2 | sort -u); do grep '^|' README.md | grep -qF -- "\`$flag\`" || missing="$missing $flag"; done; echo "missing:[$missing]" - Bash
sed -i 's/ "\\`\$flag\\`" / "$flag" /' .g1t/workflows/ci.yml grep -n 'grep .^|' .g1t/workflows/ci.yml missing="" for flag in $(grep -o 'arg == "-[^"]*"' src/lib.rs | cut -d'"' -f2 | sort -u); do grep '^|' README.md | grep -qF -- "$flag" || missing="$missing $flag"; done; echo "missing:[$missing]" git commit -qam "CI: fail when a parsed flag is missing from the README Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>" && echo ok The grep line didn't print, so I'll check the sed result.
- Bash
sed -n 27,36p .g1t/workflows/ci.yml I added a CI step named "Every flag is documented" to `.g1t/workflows/ci.yml`, between Lints and Tests. I ran its logic in the shell against the current tree and it reports nothing missing. I did not run the workflow itself on g1t, and I did not test the failure path, where a flag is absent and the step should exit 1. The step collects every flag from the `arg == "-…"` comparisons in `src/lib.rs`, which gives `--shout`, `--version`, `--quiet`, `--loud`, `-L`, `--bye`, `--wave`, `--times` and `--lang`. It then checks that each one appears on a table row of `README.md` (a line starting with `|`). If any are missing, it prints them in one line and exits 1. It uses only `grep`, with no new dependencies. - **Prose doesn't count.** A flag mentioned only in the README's prose or examples fails the check. The flag has to be in the options table. - **Substring match.** The table check is a plain substring match, so `-L` would also be satisfied by any table row containing that text, such as `-L` inside a longer flag. - **Flag spelling.** A flag added to the parser in a different form than `arg == "-x"` would not be picked up. The change touches only the CI file, so it does not overlap with #7 or #8.
- This run cost $0.1419 over 5 turns.
- Pushed a92e752f3f75.