- Write the issue body as a human-facing request. For abstract requests, infer the primary outcome as a working hypothesis, then include the target and context, expected outcome, task-specific success criteria, constraints, and unknowns. Use 5W1H as an internal coverage checklist, not required headings: who needs the result, what artifact or state must exist, why it matters, when timing or freshness matters, where source-of-truth inputs live, and how the result should be used or delivered.
- For broad AlpacaLoop-managed goals, include the primary outcome, success axis, important non-goals, approval boundaries, and initial runnable frontier in natural human-facing prose.
- If the requester does not explicitly limit the completion level to prototype, MVP, research, or documentation, preserve the broader requested deliverable as the target state and record narrower milestones as possible phases or unknowns, not as the final done state.
- For abstract improvement or optimization requests, distinguish the desired direction from measurable success. Capture the improvement target, current state or baseline to inspect, metric or evaluation axis, source of truth, measurement window when relevant, target or decision threshold when provided, guardrails or non-goals that prevent proxy success, and unknowns. Do not invent numeric targets when the user did not provide them.
- For AlpacaLoop-managed issue requests, keep the issue body human-facing and describe observable success evidence, constraints, and unresolved decisions without overusing internal routing terms such as `child_issue`, workflow state, or continuation strategy.
- When requested work depends on setup, assets, permissions, commands, external state, or shared prerequisites, capture the required prerequisites, source of truth, readiness checks, execution-start condition, readiness-failure handling, and unknowns.
- For comparison, experiment, validation, sandbox, or alternative-based optimization requests, capture the concrete target work, any source input that must be preserved exactly, the wrapper work needed to prepare or evaluate it, baseline or current behavior, candidate scope, target repository, sandbox repository, source repository or seed source when relevant, shared inputs, evaluation criteria, fair-run constraints, execution-start condition, success rule, adoption or rejection rule, safety constraints, and unknowns. Keep reusable procedure guidance out of the issue body; include only concrete one-off procedure details when the user explicitly wants this issue to define them.
- When a request wraps another unit of work, separate orchestration context from target content. Orchestration context describes how to run, isolate, constrain, compare, stop, or report the work; target content describes the user outcome or artifact to execute, review, replay, or evaluate. Preserve the target content's stated intent and constraints unless the wrapper explicitly changes them, and do not let wrapper metadata redefine a clearly stated target.
- For bounded, sampled, partial, or time-limited execution requests, state what the requested run is intended to prove, what it cannot prove, and how the result should be used for completion, comparison, adoption, deferral, or residual-risk reporting.
- When no issue template matches, write short natural Markdown without forcing fixed headings.
- For unknown issue template field values, use a natural phrase equivalent to `Unconfirmed` in the configured output language.
