# Task: Improve my agent automation flow
You are improving my existing multi-ticket AI coding agent setup. Don't assume paths. Discover them.
IMPORTANT: my setup already works and other things depend on it. The Target Rules below
are SUGGESTIONS, not a spec. Improve incrementally. Do NOT redesign or rewrite.
## Preservation rules (highest priority)
- My existing setup wins. If a Target Rule conflicts with it, keep mine and flag the
conflict. Never silently replace it.
- Keep all existing paths, folder names, file names, command names, script names,
and file formats. Adapt the suggestions to them, not the other way round.
- Never delete, rename, or move existing files, folders, or commands.
- Prefer ADDING (new section, new optional command, new script) over EDITING.
When an edit is needed, keep it minimal: change only the lines needed, never
rewrite whole files.
- Don't touch anything outside the agent setup files (instruction files, settings, commands, ticket
folders, workflow scripts). Never touch service source code.
- Skip a suggestion when its value is low or its risk of breaking something is unclear.
## Hard constraints (never violate)
- LOCAL CHANGES ONLY. Never run: git add, commit, push, pull, fetch, merge, rebase,
reset, checkout, switch, stash, branch -d/-D, tag, worktree remove, or anything that
touches a remote or rewrites git history.
- Allowed git (read-only): status, diff, log, show, branch --list, worktree list, rev-parse.
- No destructive commands: rm -rf, deleting files outside tickets/<KEY>/scripts|logs,
DB writes, deploys, docker push.
- No commands are allowlisted. Every shell command costs me one manual approval.
Your top goal: minimize shell approvals.
## Step 1: Discover (built-in tools only, NO shell)
Using your built-in file tools (read, list/glob, search), find and read:
- every agent instruction/memory file (root and nested), agent settings, custom commands
- the ticket folder structure (where tickets live, what files each has)
- the service/repo list and where each service lives, plus its build/test tool
(pom.xml, build.gradle, package.json, Makefile...)
- any existing scripts, launcher, or notes about my workflow
Then report: a map of my current setup (paths, files, commands), max 30 lines.
## Step 2: Gap analysis
Compare my setup against the Target Rules below. Table with columns:
rule | status (already have / missing / conflicts) | suggestion | risk (low/med/high) | value
- "already have" rows: keep as is, no change.
- "conflicts" rows: explain what mine does vs. the suggestion, and ask me which to keep.
Default = keep mine.
- Also estimate the approval count for a typical ticket today vs. after the changes.
- Exception to "mine wins": any existing rule/command that runs git commit/push or other
forbidden commands. Flag it and propose disabling it (not deleting it).
Keep it short.
## Step 3: Propose small changes
A numbered list, ordered by value/risk (highest value, lowest risk first). Each item has:
- file + exact diff (only changed lines, with a few lines of context)
- why it helps (approvals saved)
- what could break, and how to undo it
Areas where changes are likely (only where there's a real gap):
- Instruction file: ADD a new section (e.g. "## Approval-minimizing rules") using MY paths and
names. Don't reorganize the existing sections.
- Custom commands: add missing ticket commands only. If a similar command exists,
suggest a small tweak to it instead of a new one. Never overwrite one.
- scripts: add new reusable scripts only if nothing similar exists.
DO NOT write files yet. Wait for my answers to the conflict questions and my "apply".
## Step 4: Apply
- "apply 1,3" = apply only those items; "apply" = all items.
- Before editing an existing file, save a backup copy next to it (<file>.bak) with your file-write tool.
- Use targeted edits for existing files (no full-file rewrites). Use full-file writes only
for new files. No shell.
- Afterwards, list what changed and how to roll back (restore from .bak).
---
# Target Rules (SUGGESTIONS: adapt to my setup, my existing conventions win)
## R1. Built-in tools over shell (no approval needed)
- read: built-in read tool. Never cat/head/tail/sed -n/less.
- find: built-in list/glob tool. Never find/ls -R.
- search: built-in search tool. Never grep/rg/ag.
- edit: built-in edit/write tools. Never sed -i, awk, echo >, tee, heredoc.
- Read logs from earlier runs with the built-in read tool. Never re-run a command to see its output.
- Shell ONLY for: build, test, lint, format, running local apps, read-only git.
## R2. One script per phase, run once
Never run shell commands one at a time. Per phase:
1. List every command the phase needs.
2. Write ONE script (built-in write tool) to <ticket-dir>/scripts/<NN>-<phase>.sh (NN increasing, never overwrite).
3. Run once: bash <ticket-dir>/scripts/<NN>-<phase>.sh
4. On failure: fix the code, then write a NEW script covering only failed + remaining steps.
Phases (max one script each):
- inspect: read-only git status/diff/log across touched services, dependency trees,
tool versions (only what built-in tools can't do)
- build-test: compile + unit tests for all touched services
- verify: lint, format check, integration tests
- diff-report: git diff --stat + git diff per service → written to <ticket-dir>/CHANGES.md
for my review (replaces commit; I commit manually)
## R3. Script template (required)
```bash
#!/usr/bin/env bash
set -uo pipefail
export CI=true GIT_PAGER=cat PAGER=cat
TICKET_DIR="<ticket-dir>"
LOG="$TICKET_DIR/logs/$(basename "$0" .sh).log"
mkdir -p "$(dirname "$LOG")"; : > "$LOG"
FAIL=()
step() { # step <name> <dir> <cmd...>
local name=$1 dir=$2; shift 2
echo "=== $name ($dir): $* ===" >> "$LOG"
if (cd "$dir" && "$@") >> "$LOG" 2>&1; then echo "OK $name"
else echo "FAIL $name"; FAIL+=("$name"); fi
}
# --- steps ---
# step "svc-a test" /path/to/svc-a ./gradlew test -q
# --- summary ---
echo "---- ${#FAIL[@]} failed: ${FAIL[*]:-none} | log: $LOG"
[ ${#FAIL[@]} -gt 0 ] && grep -nE "ERROR|FAIL|Exception|error:|No such file|not found" "$LOG" | head -40
exit ${#FAIL[@]}
```
- No set -e: independent steps keep going, so one run shows ALL failures.
- Full output goes to the log. Stdout shows only OK/FAIL plus the top 40 error lines.
- Non-interactive flags always (-q, -y, --no-pager, -B for maven, --no-daemon if needed).
- Idempotent; safe to re-run.
- Scripts must obey the Hard Constraints. No git write commands, ever.
## R4. Cadence
- Finish all edits for a logical change first (edits cost no approval), then ONE build-test.
- Don't run tests after every small edit.
- Target per ticket: ≤ 3–4 approvals (inspect?, build-test, fix-retest, diff-report).
- Before any shell call, ask yourself: "Can a built-in tool do this?" and "Can I merge
this into the next planned script?"
## R5. Ticket state (so any new session can resume)
<ticket-dir> keeps:
- TICKET.md: Jira key, description, acceptance criteria, touched services
- PLAN.md: checkbox steps
- LOG.md: after each script: script name, OK/FAIL count, findings, next step
- CHANGES.md: latest diff-report for my manual review/commit
On resume: read those 4 files first, summarize in ≤ 10 lines, continue from "next step".
## R6. Session identity
- Jira key = ticket folder name = saved session name.
- At the end of each phase, update LOG.md and remind me to save the session as <KEY> (if my agent supports saved sessions).