/build-iterated-agentic-loop

name: build-iterated-agentic-loop
description: build a repo-local skill and install a matching iterated coding-agent GitHub Actions workflow, prompt, memory file, and reference templates

Build Iterated Agentic Loop

Use this skill when the user wants to turn a repeatable agent task into a repo-local skill plus a GitHub Actions workflow that runs a coding agent on a schedule, manually, or both.

The target shape is an iterated agentic loop: a focused skill defines the agent's judgement, a workflow invokes a coding agent with a repo-specific prompt, an agent-memory file carries standing feedback between runs, and each workflow labels its PRs so only one open PR exists per loop. The `narrow-react-prop-types` skill is the concrete reference pattern.

Outputs

Create or update these files in the target repo:

• `.claude/skills/<skill-name>/SKILL.md` for the repo-local agent behavior.
• `.github/workflows/agent-<task-name>.yml` for the recurring coding-agent automation.
• `.github/agent-memory/<task-name>.md` for stable feedback and scope constraints.
• Optional references under `.claude/skills/<skill-name>/references/` when the skill needs templates, examples, or long supporting material.

Workflow

1. Explore the target repo

Read before asking setup questions:

• Existing `.github/workflows/*.yml` and `.github/actions/**` to understand runner, checkout, dependency install, cache, and PR patterns.
• Package manager files such as `package.json`, `bun.lock`, `pnpm-lock.yaml`, `yarn.lock`, `package-lock.json`, `pyproject.toml`, `go.mod`, or `Cargo.toml`, or other package management-related files
• Existing validation scripts, especially typecheck, lint, test, quality, format, and package-scoped commands.
• Existing `.claude/skills` and `.agents/skills` to avoid duplicating conventions.

Completion criterion: you can name the repo's package manager, install command, likely validation commands, and existing workflow conventions.

2. Ask setup questions

Walk the user through these decisions. Recommend defaults from repo evidence instead of presenting a blank form.

1. **Coding Agent**: Claude Code, Codex, OpenCode, or CodeLayer. Explain the required secret and headless command for the recommended choice. Use `references/agent-runner-templates.md`. CodeLayer is Humanlayer's ultra-lightweight agent harness. 2. **Cadence**: daily, weekly, weekdays, monthly, manual-only, or custom cron. Recommend a cadence based on task risk and review burden - most likely weekdays, daily, or weekly. 3. **Task**: What task should the agent loop accomplish?

• Are there existing skills for doing this? (you can do research before asking the user this)
• Ask the user if you should look at recent PRs, git history, or other particular parts of the codebase for reference.

4. **Scope**: which directories/packages the loop may change and which it may only inspect 5. **Validation**: which commands must pass before the agent commits (You should propose this to the user based on your earlier research and ask them to confirm) 6. **PR bounding**: Ask if scheduled runs should no-op when open PRs from this agent already exist, and if so, how many open PRs to allow before blocking new runs.

• **Recommended: Yes, bound to 1 open PR per agent loop.** This prevents the agent from creating unbounded work that piles up faster than humans can review. Without bounding, a daily agent could generate 5+ unreviewed PRs in a week, creating review fatigue and merge conflicts.
• The workflow uses a label (e.g., `agent-<task-slug>`) to identify PRs from each agent loop. Scheduled runs check `gh pr list --label <label> --state open` and skip if the count meets or exceeds the bound.
• Manual `workflow_dispatch` runs bypass the bound check, allowing forced runs when needed.

7. **PR metadata**: label name, PR title prefix, and branch prefix.

• Suggest `[MM/DD][Agent: <Agent Name>]: <Concise Description>` as a template, e.g. `[6/23][Agent: Effect Migrator]: Migrate XYZ module`

8. **Response format**: How should the CI agent format its final response (which becomes the PR body)?

• Show the user `references/response-template.md` for examples (fix/migration, generation, refactor).
• Ask what information reviewers need: summary stats, risk levels, verification steps, file lists, etc.
• Create a customized response template that the generated skill will reference in its `references/` directory

9. **Iteration behavior**: whether `/iterate` comments should update the existing PR.

• If enabled, install `references/agent-iteration.ts` to the repo. Ask the user's preferred location: `.github/scripts/`, `ci-scripts/`, or `scripts/`.
• The script has two modes: `footer` (adds the PR body marker) and `prompt` (builds the iteration prompt from PR context).
• If disabled, remove the `issue_comment` trigger and iteration-only steps from the workflow.

Completion criterion: every placeholder in the workflow, prompt, and memory template has a chosen value or an explicit default.

3. Define the agent job

Extract the smallest repeatable job the agent should perform. Work through these three questions with the user:

**What are we finding?** How does the agent identify targets for this run?

• A CLI tool that reports issues (e.g., `bunx react-doctor`, `eslint --format json`)
• A search pattern (e.g., files matching `*.test.ts` without coverage, components using deprecated APIs)
• A diff or changelog (e.g., new dependencies since last release, changed files in a PR)
• An old pattern that should be replaced with a new pattern or migrated to a new framework
• A flaky test based on previous CI runs

**What are we changing?** What transformation does the agent apply to each target?

• Fix: resolve a reported issue in place
• Migrate: update code from one pattern to another
• Generate: create new files based on existing sources
• Refactor: restructure without changing behavior

**How do we validate?** What proves the change is