Raven Issue Update

Follow working on GitHub tasks. Talk to the user in their language; keep the issue's existing language.

The instruction "update the issue with…" covers writing the body of one given existing issue. Do not require additional routine consent for that write. A plain question, an idea without a write instruction or a request for a proposal stays read-only. Do not create new issues, comments or a local backlog; do not change the title, dependencies, order, status, assignee, plan, code, PRD or Jira. Do not take up the task as In progress: writing a requirement does not start planning or implementation. This is an optional helper, without a mandatory review of every update.

Establish the target and intent

Resolve the exact issue URL/number or change ID from the repo instructions, the remote and the given plan. A bare number needs an unambiguous repo, a change ID needs an unambiguous mapping. Do not pick the newest/similar issue and do not scan the whole queue. With a missing target, ask only for its identification.

Read the current full body, the issue state and its link to a PR/change. Read the sources and decisions needed for the edit, including referenced threads. Do not copy the whole history or Jira tickets. Distinguish a new user requirement from an existing decision and from a technical proposal.

If the issue is closed or its change is merged, clarify before editing whether this corrects the description of delivered behavior or is new scope. Do not add unfulfilled scope to finished work, do not reopen the issue and do not create a follow-up on the side.

A significant contradiction with an earlier requirement, exclusion or decision needs the user's resolution before the dependent write. Show the concrete contradiction and ask about intent; do not weaken the addition or widen it yourself to fit the old text. An unambiguous instruction to replace an earlier requirement is already a decision. Settle minor editorial details yourself. When the addition requires changing other issues or splitting work, name the need for a separate raven-roadmap, without reorganizing in this invocation.

Weave the requirement in

Prepare the smallest semantic change to the existing description: extend the relevant scope and observable acceptance criteria, and possibly the directly affected exclusion or outcome description. Keep the issue's structure. Do not end with a loose "to remember", a comment or a note under the finished text. AC describe the outcome the user requires, without inventing parameters, guarantees or implementation decisions.