Seed Plan-Implement-Feature Run
Use this skill to seed a plan-implement-feature run from the target
repository root.
By default, do not force --backend passive. This workflow is meant
to plan, pause for caller approval, then implement in the same run. Only
use a passive backend if the user explicitly asks for a passive handoff
and understands that you will have to drive the run manually.
This skill stops after initialization. It does not drive the planning stage, approve the plan, implement code changes, run the internal code review, open or merge a PR, or create/remove a worktree.
Scope
Do this:
- Confirm the target repository.
- Confirm or derive a short task slug.
- Summarize the agreed feature/design work clearly enough to seed the single-run workflow.
- Write the handoff prompt to a temporary file.
- Initialize a
plan-implement-featurerun from the repository root using--message-file. - Return the repo root and run id.
Do not do this as part of this skill:
- drive the run's planning stage
- approve the generated plan
- implement code changes
- launch the internal
code-reviewrun - open or merge a PR
- create or remove a worktree
- create or attach
assignment-seed.md
Required Inputs
Before running commands, make sure you know:
- repository root (for example
/path/to/repo) - task slug (for example
plan-implement-feature-summary) - short run title (2-4 words when possible)
- concise feature/design summary to pass as the run message
- handoff prompt file path in a temporary directory
If the user has not provided a slug, derive one from the task title/feature and confirm it when needed.
Handoff Prompt Files
The handoff prompt is the run's initial message file. Its contents are frozen into the run at init time, so the file itself is throwaway — create it in a temporary directory:
/tmp/agent-runner-planner-seeds/<task-slug>.md
Use one markdown file per feature, named with the git-safe task slug.
Pass the handoff file with --message-file; do not pass the handoff
body as positional text. This local message file is only the run's
initial user message. It is not assignment-seed.md, and this skill
does not attach it to the run.
Recommended Flow
1. Preflight from repo root
cd /path/to/<repo-name>
git status --porcelain
- If the repo root is dirty, stop and ask the user what to do before initializing the run.
2. Initialize the single-run workflow from the repo root
mkdir -p /tmp/agent-runner-planner-seeds
agent-runner init \
--agent generic \
--assignment plan-implement-feature \
--name "<short-descriptive-name>" \
--message-file /tmp/agent-runner-planner-seeds/<task-slug>.md
Use the actual agreed summary as the contents of the handoff file.
If you are running through the local workspace script instead of a globally installed binary, use the repo's preferred equivalent, for example:
npm run agent-runner -- init \
--agent generic \
--assignment plan-implement-feature \
--name "<short-descriptive-name>" \
--message-file /tmp/agent-runner-planner-seeds/<task-slug>.md
Do not pass --var worktree_slug; plan-implement-feature does not use
the separate implementer-worktree variables from plan-feature.
Only if the user explicitly asks for a passive handoff / passive single-run workflow, use:
agent-runner init \
--agent generic \
--backend passive \
--assignment plan-implement-feature \
--name "<short-descriptive-name>" \
--message-file /tmp/agent-runner-planner-seeds/<task-slug>.md
Output
After init succeeds, report:
- repository root
- run id
- handoff prompt path
- exact brief command for the new run
Example:
- Repo root:
/path/to/repo - Run id:
<run-id> - Handoff:
/tmp/agent-runner-planner-seeds/<task-slug>.md - Brief:
agent-runner run brief <run-id>
Guidance
- Keep the summary concise but concrete.
- Prefer a short explicit
--namerather than reusing a long feature description. - Stop immediately after the run is initialized unless the user explicitly asks for the next step.
- Treat this skill as bootstrap/orchestration only; the
plan-implement-featureassignment remains the source of truth for the single-run planning and implementation workflow. - The run itself will produce and attach
assignment-summary.md, pause for caller approval, implement after approval, run the internalcode-reviewassignment, and gate merge/finalization on explicit caller approval.
Source: kcosr/agent-runner — distributed by TomeVault.