Agent Operations

<prompt>
  <task>
    Create a new skill for my AI coding agent called "goal-prompt-generator", stored
wherever my harness loads skills from.

The skill's job: turn an implementation plan or task description into a bounded goal
prompt another agent session can pursue autonomously and be checked against.

The skill must include: (1) trigger conditions — when I ask you to package work for
another session, write a goal prompt, or prepare a task for autonomous execution;
(2) a required structure for every goal prompt: the objective in one paragraph; an
explicit DEFINITION OF DONE as a checklist of verifiable statements; repo constraints
(files/areas that may be modified, files/areas that must NOT be touched); verification
gates — the exact commands to run and expected results before claiming completion; and
stop conditions — situations where the agent must halt and ask instead of improvising;
(3) a self-containment rule: the receiving session has none of our conversation
context, so the prompt must include exact paths and all needed background; (4) a
quality check before delivering: "could a competent agent with zero context execute
this and could I verify the result without re-deriving the plan?"

After writing it, test it by packaging the next real task I describe into a goal
prompt.
  </task>
</prompt>

<prompt>
  <task>
    Create a new skill for my AI coding agent called "visible-delegation", stored wherever
my harness loads skills from.

The skill's job: delegate work to another agent session while keeping it visible and
supervisable — shared terminal sessions, never hidden background runs.

Before writing it, check that tmux is installed (install it if not) and confirm which
agent CLI(s) I use for delegate sessions.

The skill must include: (1) trigger conditions — when I ask you to delegate, run
something in parallel, or hand work to another agent; (2) the launch procedure: create
a named tmux session, start the delegate agent in it, and pass a goal prompt (built
with my goal-prompt-generator skill if available) — then tell me how to attach and
watch; (3) monitoring rules: check the session at sensible intervals, and define what
warrants intervention (stuck loops, scope drift, destructive commands) versus patience;
(4) a results protocol: when the delegate claims completion, run the verification
gates from the goal prompt yourself before reporting success to me; (5) cleanup —
sessions get closed, not abandoned.

After writing it, test it by delegating one small real task end to end while I watch.
  </task>
</prompt>

<prompt>
  <task>
    Create a new skill for my AI coding agent called "session-operating-map", stored
wherever my harness loads skills from.

The skill's job: set up and maintain a repo-local operating map for projects where I
run multiple agent sessions in parallel — which lane owns what, current state,
blockers, and decisions.

The skill must include: (1) trigger conditions — when I start parallel workstreams in
a project, ask "what's in flight," or ask you to set up coordination for a repo;
(2) the map file: a single repo-local doc (suggest docs/operating-map.md) listing each
lane with a short name, its objective, owning session, current state, and blockers;
(3) lane discipline: one lane per concern, named so its purpose is obvious; (4) update
rules: a lane's entry gets updated when its state meaningfully changes — start, block,
handoff, done — not as a journal; (5) archive rules: finished lanes move to a done
section with a one-line outcome, and lessons worth keeping get promoted into the
project's docs or skills rather than dying with the lane; (6) a read-first rule: any
session joining the project reads the map before starting work.

After writing it, set up the map for my current project and populate it with what's
actually in flight.
  </task>
</prompt>

<prompt>
  <task>
    Create a new skill for my AI coding agent called "self-pr-merge", stored wherever my
harness loads skills from.

The skill's job: review and merge pull requests I authored myself, with real review
discipline despite GitHub not allowing self-approval.

Before writing it, confirm the gh CLI is authenticated and ask me for my merge
strategy preference (squash, merge, rebase) and my branch cleanup preference.

The skill must include: (1) trigger conditions — when I ask to merge my own PR or
review-and-merge something I wrote; (2) a genuine review pass FIRST: read the full
diff with fresh eyes, list anything questionable (bugs, debug leftovers, missing
tests, scope creep) and show me findings before merging — finding nothing must be a
conclusion, never a default; (3) pre-merge checks: CI status, mergeability, conflicts,
and an honest note about the self-approval limitation rather than working around it;
(4) the merge with my preferred strategy; (5) cleanup: delete the remote branch per my
preference, and if local worktrees are involved, use worktree-safe removal — never
plain branch deletion under a worktree; (6) a stop rule: any failing check or
unresolved review finding halts the merge and comes back to me.

After writing it, test it on my next real PR.
  </task>
</prompt>

<prompt>
  <task>
    Create a new skill for my AI coding agent called "stakeholder-update-email", stored
wherever my harness loads skills from.

The skill's job: after work ships with stakeholder-visible impact, send or draft a
short, truthful update email to the right person.

Before writing it, interview me for: who my recurring stakeholders are and what each
cares about, whether you should send directly (and through what — e.g. a Resend API
key in an env file) or always draft for my review, and whether I should be CC'd on
sends.

The skill must include: (1) trigger conditions — when work merges or ships with
visible impact for a stakeholder, or when I ask for an update email; (2) a gate: if
nothing stakeholder-visible changed, say so and send nothing; (3) writing rules:
describe shipped behavior in the recipient's vocabulary, not implementation detail;
never call anything done that wasn't verified; if something shipped partially, say
which part; (4) a consistent short format: what changed, what it means for them,
what's next; (5) the send/draft mechanics per my preference, with send requiring my
explicit confirmation.

After writing it, test it by drafting an update for the most recent thing I shipped.
  </task>
</prompt>

<prompt>
  <task>
    Create a new skill for my AI coding agent called "session-to-skill-extractor", stored
wherever my harness loads skills from.

The skill's job: at the end of substantial work sessions, evaluate whether anything we
did is worth preserving as a new skill or an update to an existing one — and if so,
draft it.

The skill must include: (1) trigger conditions — when I say "wrap up," "anything worth
keeping?", or at the natural end of a session where we solved something non-trivially;
(2) a high extraction bar, stated explicitly: the pattern must be RECURRING (I'll
plausibly need it again), NON-OBVIOUS (a fresh session wouldn't just derive it), and
CODIFIABLE (it can be written as a procedure) — most sessions yield nothing, and
"nothing worth extracting" is a good answer; (3) a check against my existing skill
library first: if an existing skill covers 80% of the pattern, propose an update, not
a new skill; (4) drafts follow my skills' standard format with trigger conditions, and
land somewhere for my review — never silently into the live library; (5) a sanitize
rule: extracted skills generalize the pattern and strip project/client specifics,
which stay in repo-local runbooks.

After writing it, test it on THIS session: evaluate whether our setup work contains an
extractable pattern, and show me your reasoning either way.
  </task>
</prompt>

<prompt>
  <task>
    Create a new skill for my AI coding agent called "agentic-harness-designer", stored
wherever my harness loads skills from.

The skill's job: when I'm designing or reviewing an agent-powered system or product,
walk the real architecture questions and produce a phased plan — treating the problem
as an agent-SYSTEM problem, not a model-choice problem.

The skill must include: (1) trigger conditions — designing, evaluating, or debugging
any AI-agent-powered product, tool, or serious automation; (2) the design walk, in
order: what tools the agent gets and their exact contracts; the permission model
(what's autonomous, what needs approval, what's forbidden); workflow state and
durability (what survives a crash or restart); context and memory strategy (what the
agent knows, from where, and what it must not accumulate); evaluation (how we'll know
it works — concrete checks, not vibes); observability (what's logged, what the
operator can see mid-run); (3) failure-mode review against the common killers: missing
approval gates, non-durable state, unbounded context growth, no evals, invisible
execution; (4) output: a design doc with decisions and rationale, plus a phased
implementation plan where each phase is independently shippable and testable.

After writing it, test it by reviewing an agent system or automation I describe — or
one we've already built — and showing me the design doc.
  </task>
</prompt>