Copy as Markdown

↵ Open esc Close

Use the task board

Find an issue, save a board view, create and organise work, then check an assignment and follow its comments or linked pull request.

What you'll have

An issue you can find again, with the right attributes and dependencies, and a clear place to follow its work.

Use Issues to organise the work in a channel. A board can collect that work in saved views. The steps below use the controls in the Issues surface; a connected provider can offer different write capabilities.

Before you start

Open a channel with Issues available. You need permission to create or change issues for the editing steps. Reading a board does not grant permission to save its shared views. If a control is absent, check A control in a guide is not visible .

Find the issue

  1. Open the Issues tab in the channel.

    Result The channel shows its issue list.

  2. Enter the issue key or words from its title or body in Search issues.

    Result Matching issues appear within the current view.

  3. Use Add a filter to narrow the result. Choose a field and its value. Board views offer different fields from a plain channel’s list.

    Result The chosen filter narrows the result.

  4. Use the grouping or sorting controls when you need a different arrangement. These controls change the view, not issue attributes.

    Result The list shows the chosen arrangement.

  5. Select the issue to open its detail pane.

    Result The issue detail pane opens.

  6. If this doesn't work

    If the list shows no match, clear the search and filters. Check another saved view before assuming the issue no longer exists.

If no issue matches, clear the search and applied filters before assuming someone deleted the issue. On a board, open the Issues tab’s three-dot menu and select a view that includes the issue’s channel. A pinned issue can appear outside the view’s normal filter, so a visible pinned row is not proof that its attributes match that filter.

Keep a board view

  1. Open the Issues tab’s three-dot menu and select the view to start from.

    Result The selected view opens.

  2. Change its filters, grouping or sort. Check the result before saving.

    Result The list reflects your changes.

  3. Open the tab menu again. Save the current view’s changes to update that shared view, or choose Save as new view to keep a separate one.

    Result The menu offers the available save actions.

  4. Name the view if you are creating one and confirm the form.

    Result The saved view appears in the menu.

  5. Reopen the menu and select the saved view to check its result.

    Result The selected saved view opens.

  6. If this doesn't work

    If someone else changed the saved views, read the refreshed view before saving again. Use a separate view when you need to preserve a different arrangement.

A dot on the tab marks unsaved changes. Reset them to return to the saved view. Saving and creating views require board editing permission; readers can still change their own temporary view. Search text is temporary, so use a filter for a condition the saved view must keep.

Create an issue

  1. Select the plus control labelled New issue. It opens a draft in the detail pane.

    Result The new issue draft opens.

  2. Enter a title and describe the work. Set its status, priority and assignment.

    Result The draft holds the work description and assignment.

  3. Select labels, a milestone or an existing iteration when they help identify the work. Check any status or priority already supplied by the current view.

    Result The draft shows the chosen attributes.

  4. Confirm the draft with its create action.

    Result Crusible attempts to create the issue.

  5. Check the issue key and the new issue’s detail pane.

    Result The issue key identifies the saved record.

  6. If this doesn't work

    If creation reports that the issue already exists, reload before creating another. Ask an admin to check access for a permission refusal.

Crusible files nothing until you confirm the draft. A view restricted to 1 status or priority can supply that value to a new draft. Review those values before filing so the issue lands where you expect.

To start from a conversation, use Create issue from message on the message. Forge drafts from that message’s context. Review the proposed title, description and attributes, then create the issue. Drafting does not create an issue or start a coding session on its own.

If creation reports that the issue already exists, reload and find it before submitting another draft. If Crusible refuses the draft as written, correct the reported field. If your role cannot create issues in that channel, ask an admin to check access rather than repeatedly submitting.

Organise the work

  1. Open the issue’s detail pane.

    Result The issue detail pane opens.

  2. Select its status or priority value and choose the new value.

    Result The selected attribute changes if Crusible accepts it.

  3. Open the labels value to select or remove labels. Check the scope when 2 labels have the same name.

    Result The issue shows the selected labels.

  4. Select a milestone or an existing iteration. Use the offered new-milestone action only when you have permission to create one.

    Result The issue shows the selected milestone or iteration.

  5. Choose a parent when the issue is part of a larger issue.

    Result The issue belongs to the selected parent.

  6. Use the plus beside Blocked by or Blocks to search for a dependency.

    Result The chosen dependency appears beside the issue.

  7. Check the activity after editing. A refused change can restore the previous value and show its reason.

    Result The activity records accepted changes.

  8. If this doesn't work

    If an attribute reverts, read the refusal below it. Leave the issue unchanged until you know whether the blocker is permission or an unavailable write.

Edit each issue separately. A public multi-issue bulk editor remains planned. Type and token estimates stay read-only; an estimate is not a field you need to fill before filing. Creating iterations from this picker is unavailable.

Send work and find the result

  1. Check the issue description and acceptance criteria before asking Forge to act on it.

    Result The issue states the expected work.

  2. Use Send to Forge on the conversation’s issue card, or open the issue’s assignee picker and choose an eligible destination under Forge on a Sandbox.

    Result Crusible attempts to send or request the assignment.

  3. Check the assignment and any reason shown beside it. The destination owner must accept a consent request before work can start.

    Result The assignment shows its current state.

  4. Open the offered terminal link when you need to inspect the coding session.

    Result The coding session opens when you have access.

  5. Return to the dispatch’s conversation thread for replies. Open the issue’s Pull requests section for linked proposals.

    Result The thread and issue show recorded results.

  6. If this doesn't work

    If work does not start, read the reason beside the assignment. Keep its trace or reference with the issue key when asking an admin for help.

An assignment can wait behind other issues. Urgent and high-priority issues take precedence; medium and no-priority issues share a band. Changing the board’s sort does not reorder the dispatch queue. Crusible can refuse a send when the queue is full. Wait for capacity before sending again. A public queue editor and pause control remain planned; do not expect board ordering controls to manage the dispatch queue.

The Sandbox card’s machine menu offers restart and power-off actions when your access and the machine state allow them. These can end the active dispatch. Read the confirmation before acting. Neither changing an issue’s status nor changing a board filter stops a coding session. A queue pause control remains planned separately from these machine controls.

When work does not start

Read the reason beside the assignee. Hover the reason glyph to read the details, or select it to copy the trace or reference. Keep that reference with the issue key when asking your workspace admin for help.

What you seeNext step
Not started with a consent requestWait for the destination owner to accept or decline. Repeated sends do not grant permission.
A declined, cancelled or expired requestChoose an eligible destination or make a new request when appropriate.
The queue already holds 20 issuesWait for an issue to start before sending again.
Agent setup is incompleteFinish the named coding agent’s setup, then send again.
No suitable or idle terminalInspect the destination’s terminal state. Wait for the active work or choose an eligible destination.
The delivery path is not configuredGive the issue key and failure reference to an admin. Repeated sends cannot configure it.
Could not startRead and keep its reason and reference. Check whether work started before retrying.

A waiting assignment stays waiting if its permission, setup or capacity blocker remains. A queue-selection fault can retry automatically; that does not mean every refused send retries. Follow the particular reason shown.

When a reply or update is missing

  1. Check the dispatch’s conversation thread rather than only the issue activity.

    Result The thread shows the dispatch conversation.

  2. Inspect the terminal link to distinguish a session that started from an assignment that is still waiting.

    Result The terminal shows the coding session state.

  3. Open Pull requests on the issue. A linked pull request can exist without a new notification or a complete terminal transcript in the conversation.

    Result The issue shows any recorded pull request links.

  4. If the dispatch shows a stop or failure, read its reason before sending it again. Stopping a session does not prove that anyone merged a pull request.

    Result The dispatch reason identifies its blocker.

  5. Confirm the issue key and channel, then check the board filters. Compare the field in the detail pane with the issue activity. Keep the issue key and differing field when reporting an update that has not appeared.

    Result The comparison identifies the record and field to report.

  6. If this doesn't work

    If you cannot see the destination or thread, ask an admin to check access. Reloading does not grant permission or recover an ended session.

A reload can retry a failed read of an assignment’s destination. It cannot grant access to that destination or recover an ended session. If a comment fails to post, its text remains in the composer. Check whether the comment appeared before trying again.

Import and triage limits

A public CSV/XLSX issue-import flow remains planned. There is no documented upload control, supported-column contract or rejected-row report to follow here. Changing a file extension does not establish support for its format. Keep the original file when reporting an import that did not finish. Include the visible failure and any reference. Keep confidential rows out of the report.

Use individual issue drafts and attributes for manual triage today. A dedicated triage queue, a general field-suggestion acceptance workflow and bulk editing remain planned. Accepting an agent’s draft before creation is a different operation from accepting a suggested edit on an existing issue.

The Issues reference explains the fields, view scope and provider boundaries used by this guide.