我的 AI Agent Prompt Tips：Workflow、Subagent 与 Agent Team

For this conversation, use the smallest execution mechanism that can prove the result.

- Default to the main agent for small tasks. Run independent delegated starts concurrently; serialize only stages that need an earlier result.
- Use a subagent only when isolated context, independent verification, or a distinct file owner creates measurable value.
- Use a Workflow only for a reusable dependency graph or a bounded batch.
- Use an Agent Team only when workers must communicate directly; otherwise use ordinary subagents.
- Never run a Workflow and an Agent Team at the same time.
- Before dispatching, state the task level, the weighted worker-start budget (haiku 0.25, sonnet 0.5, opus 1, fable 2.5), planned concurrency, explicit model for every worker, and delegated Fable allowance.
- Count restarts, resumes, repairs, reruns, pipeline items, workflow agents, forks, and teammates as new worker starts.
- Do not spend the budget merely because it is available. Stop spawning when the next worker cannot change the decision or acceptance evidence.
- A delegated Fable worker is prohibited unless this prompt explicitly grants one critical slot.

Create one goal and one Claude Code Workflow for the issues below. The main agent accepts the result; each worker owns named evidence or files.

Use one hour as the dispatch deadline. At the boundary, start no workers and report completed evidence, changed files, failed checks, remaining risks, and unused worker starts.

Authorized external actions: <none | stage | commit | push | publish | named destructive operation>. Treat unlisted actions as outside scope. If scope changes or an unlisted action becomes the only next step, name that boundary and stop.

Before running the Workflow:

1. Group duplicate symptoms by root cause.
2. For each work item, list acceptance evidence, owned files, and excluded scope.
3. Apply the active project policy for task level, worker limits, model and effort routing, concurrency, and approvals.
4. Show the Workflow phases and dispatch ledger before any worker starts.

Known issues:
<issue list>

/goal Complete W1-W7. Success means <verification commands> pass and the intended changes are staged but uncommitted. If the only remaining step lacks authorization, report that step and end.

/goal Complete W1-W7, pass <verification commands>, and create one local commit. This command authorizes that commit; do not push or publish.

$env:CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS = '1'
$env:CLAUDE_CODE_ENABLE_TODO_TOOLS = '1'
claude

Create an Agent Team only because the workers in this task must exchange findings, challenge assumptions, or coordinate dependent decisions directly.

Team budget and routing:

- The current session is the sole team lead, integrator, and final acceptance owner.
- Treat any Agent Team as an L3 or explicitly approved L4 task under the active project policy.
- Spawn at most 3 teammates and never create a nested team.
- Use a named subagent definition with an explicit model for every teammate. A teammate always runs at the lead's effort level; the definition's effort frontmatter does not apply to teammates, so report the lead's effort as the teammate effort.
- Use Haiku for narrow reconnaissance and evidence inventory, Sonnet for planning, review, or QA, and Opus for implementation.
- A delegated Fable teammate is prohibited unless I explicitly grant one critical slot in this conversation.
- If one delegated Fable slot is granted, use it only after normal-role workers have produced a compact evidence packet, run it serially, and never use a second Fable start, replacement, resume, or repair.
- Do not start or resume a Workflow while any teammate is active.
- Count every teammate, replacement, restart, and resumed execution against the same task-level worker-start budget.

Ownership and coordination:

- Give every teammate a stable name, one bounded objective, explicit in-scope and out-of-scope work, owned files or modules, acceptance criteria, required verification, forbidden actions, and a compact evidence format.
- Partition write ownership so no two teammates edit the same file. Agent Team does not automatically provide worktree isolation.
- Teammates must not delegate further, stage, commit, push, publish, change the overall goal, or modify planning and memory files unless I explicitly authorize that exact action.
- Use direct teammate messages only when information changes another member's work; avoid status chatter that repeats the shared task list.
- Do not rely on session resume to restore in-process teammates. Collect every required result before shutdown, or explicitly budget replacement teammates after a resumed session.
- The lead must wait for all required evidence, inspect every diff, resolve blocking findings, and then shut down the team cleanly.
- If Agent Teams is disabled or unavailable, report that fact and stop. Do not silently simulate the team with an unbounded parallel subagent batch.

Task:
<task requiring direct worker communication>

Use two strictly sequential orchestration phases. Never overlap a Workflow and an Agent Team.

Shared task envelope:

- Apply one total worker-start budget across both phases.
- Use a budget of 6 Opus-equivalent starts for L3 or 8 for explicitly approved L4 (haiku 0.25, sonnet 0.5, opus 1, fable 2.5).
- Run independent starts concurrently within the runtime caps; the budget is the weighted start total, not the concurrency.
- Use at most one delegated Fable-worker start across the entire task, and default to zero.
- Count Workflow agents, pipeline items, teammates, replacements, restarts, resumes, repairs, and reruns in the same ledger.

Phase 1 — evidence Workflow:

- Run one bounded Workflow using Haiku for narrow discovery and Sonnet for synthesis or verification.
- Produce a compact evidence packet, unresolved decisions, ownership map, and a recommendation on whether direct worker communication is still necessary.
- Stop the Workflow completely before Phase 2.

Decision gate:

- If the remaining work is independent or only needs main-agent fan-in, do not create a Team.
- Start Phase 2 only when the evidence proves that teammates must exchange findings or coordinate dependent changes.

Phase 2 — small Agent Team:

- Spawn at most 2 teammates for L3 or 3 teammates for approved L4.
- Assign disjoint ownership and use named definitions with explicit models. Teammates run at the lead's effort level regardless of the definition's effort frontmatter; report that level.
- Do not repeat discovery already completed in Phase 1.
- If one delegated Fable slot was explicitly approved, reserve it for one serial critical decision after the Sonnet evidence has converged; do not place that worker in the parallel team batch.

At completion, report one combined budget ledger, accepted evidence, rejected hypotheses, exact changes, verification results, and remaining external gaps.

Task:
<task>

For this coordinator profile/session, use the supported opus alias with high effort for decomposition, dispatch, evidence integration, and final acceptance.

This profile choice does not replace or prohibit the intentional global Fable 5.1 main-session default, whose per-model effort the owner adjusts per project.

A delegated Fable 5.1 critical role (critical-implementer or critical-reviewer) may be used for at most one invocation per task. The read-only reviewer-fable role at low effort is an ordinary start and may be used whenever a Sonnet review is uncertain or the diff is high-stakes.

Use it only for a verified security, concurrency, data-migration, architectural, or exceptionally difficult implementation decision unresolved after normal-role evidence gathering.

Use the configured delegated Fable 5.1 critical role at high. Raise it to xhigh only when an eval on real tasks shows headroom at high.

If the delegated Fable worker ends with a refusal stop reason, report it, do not count it as a failed normal-role attempt, and rerun the same task on Opus/xhigh without spending another Fable start. Automatic switching on a classifier flag is off on this machine (switchModelsOnFlag: false): an interactive session pauses and offers the switch, a -p run ends with the refusal, so treat this manual rerun as the fallback path for delegated work.

For a new delegated Fable workload, official guidance is to start at high and compare low, medium, xhigh, and max with real evals before changing that role.

Low may be cost-effective, but verification-heavy delegated work should use it only when eval evidence supports it.

All delegated reconnaissance, file mapping, log summarization, ordinary QA, routine implementation, formatting, and documentation work must use Haiku, Sonnet, or Opus according to the configured role. Override within a role's allowed set when the task calls for it: ask first whether the worker did not try hard enough (raise effort or rerun) or did not know enough (move to a stronger model).

Never place a delegated Fable worker in a batch, Workflow parallel(), pipeline(), broad review fan-out, Agent Team fan-out, automatic retry, restart, resume, repair, or rerun.

For a long delegated Fable 5.1 tool chain, send a start note, brief progress updates, and a standalone final recap.

Finish the assigned task unless an explicit scope, authority, cost, or evidence boundary is reached. Do not widen scope to keep working.

The lead may handle other genuinely independent work while background subagents run, but only inside the same weighted start budget. Parallelism is free in tokens; do not invent independent work to fill it.

Before using the delegated Fable slot, show the exact question, compact evidence packet, expected decision value, selected model, the selected role definition's effort, and the remaining task budget.

If that case is not proven, do not spend the slot.

Formulate a bounded subagent dispatch strategy. Do not write code in the main thread. Use the main agent only for deep research framing, planning, Workflow design, dispatch, evidence integration, code review, and final acceptance.

Delegated Fable workers, including reviewer-fable, are strictly prohibited for this entire task. Delegate all code writing and refactoring to Opus workers.

Delegate QA, runtime reproduction, browser checks, and mechanical reconnaissance to Sonnet, or to Haiku for trivial narrow searches.

Every Agent call and Workflow agent() must explicitly specify its model. Never rely on inheritance. If a dispatch is discovered without an explicit model, stop it and dispatch a correctly configured replacement only if the same task budget still permits another start.

Before dispatching, write the approved strategy to <planning-path>. Also persist the confirmed reusable rule to <memory-or-instruction-path> only because this prompt explicitly authorizes that exact file. Preserve unrelated content and show the diff.

Follow the current task-level limits for the weighted start budget and the number of active Workflows. Do not create an Agent Team unless this conversation separately authorizes it.

Subagent model discipline is mandatory.

- Every subagent dispatch must explicitly specify the model. This applies to the Agent tool's model parameter and Workflow agent(..., { model }) calls.
- Every Agent role must define explicit effort in its selected definition. Workflow agent() may set effort.
- Never rely on main-session model inheritance for delegated work.
- Before every dispatch, verify the requested agent type, model, definition-level effort, permissions, owned scope, and remaining start budget.
- If a model-less dispatch is discovered, stop it. Re-dispatch only when the replacement still fits the original budget; do not hide the extra start.
- A worker may use the main-session model only when I explicitly request that model for that worker in this conversation.

- Do not preserve backward compatibility unless I explicitly require it or an external contract proves it is necessary. Remove obsolete paths instead of adding compatibility layers, permanent fallbacks, or speculative migrations.
- Choose the simplest implementation that fully meets the current requirement. Avoid speculative abstractions, configuration, indirection, feature flags, and helpers for one-time operations.
- Grow the system in working end-to-end layers. Add each capability on top of a product that still works.
- Keep components modular and responsibilities clearly separated.
- Prefer established, maintained libraries when they reduce total complexity or improve reliability.
- Inspect existing dependencies, documentation, source, and types before reimplementing functionality or adding packages.
- Make durable architectural decisions, but do not build hypothetical future systems that the current requirement does not need.
- Preserve user-owned dirty files and do not stage, commit, push, or publish unless the current request explicitly authorizes it.
- When uncertainty remains, name each unknown and find the smallest direct counterexample, failing case, command output, or source reference that proves whether it matters.
- If the evidence is not quickly available, stop and report the unknown instead of adding guards, retries, fallbacks, compatibility shims, broad validation, or extra abstraction to hide it.

This is a strictly read-only review. Do not modify code, tests, documentation, configuration, tracking files, generated artifacts, Git state, or external systems.

Inspect the requested scope and report only evidence-backed findings. For every finding, include severity, exact file and line, the violated invariant, a minimal failure scenario, and the smallest plausible remediation direction. Separate confirmed defects from risks and unresolved unknowns. Do not implement fixes.

The root agent is the sole coordinator, integrator, and final acceptance owner. Delegate production and test implementation to one explicitly selected write-capable worker at a time, with exact file ownership.

Every delegated task must define its objective, in-scope and out-of-scope work, owned files, acceptance criteria, required verification, forbidden actions, compact evidence format, and stopping conditions. Workers must not widen scope, delegate further, stage, commit, push, publish, or modify planning and memory files unless I authorize that exact action.

A worker completion is an evidence handoff, not acceptance. The root agent must inspect the diff, review verification output, resolve blocking findings, preserve unrelated dirty files, and decide whether the requested outcome is actually complete.

Make one coherent thematic commit only when I explicitly authorize commits and the implementation, tests, documentation, and relevant verification for that theme are complete.

Modernize the project's foundational dependencies to the latest versions that the current product explicitly supports.

This is not a version-number-only upgrade and not an exercise in preserving old implementation patterns. Read the current release notes, migration guides, installed source, and types. Update the architecture and business implementation to use the current APIs and conventions.

Remove obsolete compatibility code unless an external contract requires it. Keep the scope limited to changes proven necessary by the upgrade. Verify the affected build, type, test, runtime, and migration paths, and clearly report external environments that were not available.

This is NOT the Next.js you know. The installed version may contain breaking changes to APIs, conventions, caching behavior, and file structure relative to your training data.

Before writing code, inspect package.json and the installed Next.js version, then read the relevant guide under node_modules/next/dist/docs/. Treat the installed documentation, source, and types as authoritative. Heed deprecation notices and do not restore legacy patterns for compatibility unless an external contract requires them.

Do not treat Material 3 as the application's foundational UI framework.

Define the product's own Professional Design System and use Compose Foundation as the design-system-neutral primitive layer for custom components. Derive tokens, typography, color, spacing, shape, elevation, motion, interaction states, accessibility, and component APIs from the product's visual language instead of inheriting Material defaults.

Before implementation, audit which existing Material components are product dependencies and which are replaceable presentation choices. Migrate only the scope required by the current task and verify interaction, accessibility, rendering performance, and visual consistency.

Perform a bounded evidence-backed engineering audit of the current project. Look beyond isolated bugs and evaluate the core architecture, data security, permissions, correctness boundaries, UI rendering performance, operational failure modes, test coverage, and user-visible friction.

Separate confirmed defects, plausible risks, and unresolved unknowns. Every blocking finding must cite a concrete code path, failing case, measurement, or authoritative source. Do not turn the audit into implementation unless I explicitly authorize changes.

Audit the project's non-code engineering system, including current and stale documentation, specifications, plans, architecture decisions, AI guidance, operational runbooks, release evidence, and maintenance conventions.

Identify what is authoritative, duplicated, obsolete, missing, or inconsistent with the current implementation. Propose the smallest durable documentation set and an ownership or update rule for each artifact. Include project-specific AI, architecture, engineering-practice, and operational knowledge that should be preserved. Do not rewrite documents until I approve the proposed scope.

Load the skill at https://innei.in/skills/codebase-value-audit/SKILL.md as guidance, verify that it is available and applicable, and then evaluate the current project as requested below.

Separate product value, engineering quality, maintainability, differentiation, operational risk, and evidence gaps. Cite repository evidence for each major claim. Do not modify code or documents unless I explicitly authorize it.

Task:
<project value question>

Persist only the policy confirmed in this conversation.

Authorized targets:

- Planning document: <exact path or none>
- Project instruction: <exact path or none>
- User instruction: <exact path or none>
- Memory note: <exact path or none>

Write model-facing instructions in English. Keep human explanation outside the prompt or configuration block. Preserve unrelated content, avoid duplication, and place each rule at the narrowest scope where it remains true.

Before editing, show the proposed rule and why each target is appropriate. After editing, show the exact diff and validation evidence. Do not modify any target marked none, and do not invent a memory update without explicit authorization.

The product is functionally stable. Create an evidence-backed comprehensive test strategy covering critical user journeys, destructive and recovery paths, permissions, data integrity, concurrency, compatibility boundaries, sustained load, peak load, resource exhaustion, and UI performance.

Do not launch multiple Workflows merely because the matrix is large. First deduplicate the risks, classify the task level, and fit the plan inside the approved weighted start budget. Prioritize the tests that can falsify the highest-impact assumptions.

Run stress or destructive cases only in an explicitly approved disposable environment. Distinguish local automation from external device, browser, service, production, or release evidence. Do not claim unavailable external verification as complete.

Use a dynamic Workflow and a profiler to get the named p95 latency below 300 ms. Do not stop until the target is repeatedly proven, the required regressions pass, or the approved worker, time, cost, or authority boundary is reached.

Use a profiler to reduce the named p95 latency below 300 ms without changing the product contract.

First reproduce the issue and record the exact baseline environment, command, dataset, warm-up, sample count, p50, p95, p99, and profiler evidence. Optimize only the dominant measured bottleneck. Repeat the same benchmark and run the focused functional regression checks after each accepted change.

Do not claim success from a single fast run, an average, or intuition. Stop when repeated measurements meet the threshold and required regressions pass, or when the approved worker, time, cost, or authority boundary is reached. Report the remaining evidence and hypotheses instead of silently extending the budget.

Create a custom Codex agent named luna_worker at:
~/.codex/agents/luna-worker.toml

Use this model configuration:

model = "gpt-5.6-luna"
model_reasoning_effort = "max"

Add a clear description and instructions. luna_worker handles only tasks that are narrow, self-contained, independently verifiable, and explicitly delegated by the root agent. It must not change the overall objective, widen scope, delegate further, stage, commit, push, publish, or modify planning and memory files unless I explicitly authorize that exact action.

Preserve all existing Codex configuration and unrelated agents. Do not overwrite or delete unrelated content.

After creating the file:

1. Check the format against my currently installed Codex version.
2. Show the exact diff.
3. Validate that the configuration loads successfully.
4. Explain the tasks for which luna_worker should and should not be selected.

For future delegated tasks that match this bounded role, prefer luna_worker over a more expensive general-purpose worker. Do not make it the automatic choice for tasks that exceed its scope or quality boundary.