Write Issue

Write issues that let teammates understand what the work is trying to change and act on its result. Read together, the project, parent, and issue titles should reveal the larger agenda. Each body supplies the context, concrete result, and evidence its reader needs without reconstructing the author's activity history.

The rules for shape (title, body, what to leave out, language) are defaults: the user's instruction and the team's own template or convention win over them. Apply copydesk for shared meaning-preservation and writing guidance when available; this skill owns issue structure, tracker fields, and publication authority. The link check and shared-record safety run on every issue whatever the convention, and the assignee follows its rule unless the user says who.

Normal Path

1. Read before writing. Fetch the issue being edited, its project or parent, any applicable template, and enough neighboring issues to understand the intended outcome and existing division of work. Match the team's language and conventions; for a request to another team, those are the receiving team's. For a portfolio review, inspect the relevant set, including work that may overlap or already have a suitable parent.
2. Identify what this work enables: a behavior change, a usable artifact, or a decision. Choose whether it belongs in an existing issue, a distinct issue, or a project or parent, then draft the title, body, and fields with the rules below. Read the worked outcome and consolidation examples when turning an activity list into issues.
3. Reread the draft as a reader who never saw the conversation. They should be able to tell what is asked or changed, why, what already exists, and what to do first; fix the draft where they cannot. Cut what only the author needed: terms coined during the work, narration of how the draft was made, inventories of everything checked, hedges, and a statement repeated in another place. Then run the check in State The Claim, Justify Every Link on every link, path, and attachment.
4. Decide whether to show it first. Reuse authorization already established in the session. Show the complete draft with its intended field values and wait when the user asked for a draft, publication intent is unclear, a change to someone else's issue has not been authorized, the destination or audience needs a consequential guess, or the check dropped a link or file the user explicitly required. Otherwise the request to create, edit, or reorganize is the grant: follow the harness's approval rules and add no second confirmation.
5. Write through the tracker's tool. On create, set only the fields the request or the team's convention calls for and leave the rest at the tracker's defaults. On edit, change only the requested fields. Read the result back and report.

Without a working tracker tool or authentication, deliver the draft and its field values as text, and say that the issue was not created and that the team's conventions could not be read. Do not install or authenticate a tool implicitly.

Start With The Outcome

Understand why the work matters before compressing it. Who needs the result, what will they be able to change or decide, and what must exist for them to act? Answer those questions from the available work and the user's intent. They guide selection of content; they are not mandatory headings or a three-step plan.