Linear Brasa

Linear Brasa Workflow

You manage the entire development lifecycle for the brasa project in Linear.

Announce at start: "I'm using the linear-brasa skill to manage the brasa project in Linear."

Always use the Linear MCP tools (mcp__plugin_linear_linear__*) for all communication with Linear — never use the gh CLI or direct API calls.

Workspace constants (use these IDs directly — no need to look them up):

• Team: Wilsonfreitas — ID 6c3534b0-9f98-476c-a1d6-3f99119e9f88
• Project: brasa — ID 700095cc-dd63-405b-b285-1895aabce09d
• Labels: Idea · Bug · Improvement · Feature
• New issues always go to project brasa with state Backlog and no priority. The user can update these later during refinement/planning.

Flow 1 — Save an Idea

Trigger: user wants to capture an idea, feature request, or bug they thought of.

1. If the user gave only a title, ask for a short description (one paragraph is enough — or proceed without one if they say it's enough as-is).
2. Recommend a label — don't just list them. Read the title and description, then lead with a concrete suggestion plus a one-line justification; the user only overrides if it's wrong.
   • Phrase it like: "This looks like an Improvement (it enhances existing functionality). Confirm, or pick a different label: Bug / Feature / Idea."
   • The four labels are Idea, Feature, Improvement, Bug. Default to Idea only when the request is genuinely exploratory and not yet refined.
   • Wait for the user to confirm or override before creating the issue.
3. Create the issue via mcp__plugin_linear_linear__save_issue:
   • team: Wilsonfreitas team ID
   • project: brasa project ID
   • state: "Backlog"
   • priority: no priority (omit the field)
   • labels: the chosen label
4. Confirm with the issue identifier (e.g., WIL-42 created).

Flow 2 — Refine (Design) an Issue

Trigger: user wants to brainstorm and produce a design for an existing issue — "refine WIL-X", "brainstorm WIL-X", "design WIL-X".

Delegate to the linear-brasa-brainstorm skill. That skill sequences brainstorm → grill → synthesize, saves the result as a Design Document on the issue (not a description section), runs the user review gate, converts the label from Idea to Feature / Improvement / Bug, and moves the issue to Refined.

Flow 3 — Plan an Issue

Trigger: user wants to write an implementation plan for an already-designed issue — "plan WIL-X", "write the plan for WIL-X".

Delegate to the linear-brasa-plan skill. That skill reads the Design Document, runs the plan-writing flow, saves the result as an Implementation Plan Document on the issue (not a description section), and moves the issue to Planned.

Per-Issue Information Architecture

Every brasa issue follows this layout (single issue, no sub-issues):

Issue WIL-X
│  description  = original idea text          (write-once, never modified after creation)
│  status       = stage machine (see below)
├─ Document: Design                           (write-once, produced by linear-brasa-brainstorm)
├─ Document: Implementation Plan              (write-once, produced by linear-brasa-plan;
│                                              checkboxes flipped - [ ] → - [x] during execution)
└─ Comment: Execution Log                     (append-only; one comment edited in place;
                                               holds FINDING entries = the audit trail)

Status lifecycle:

Backlog ──(refine)──▶ Refined ──(plan)──▶ Planned ──(execute start)──▶ In Progress ──(gates green)──▶ Done

Each status advance is read-back verified and only happens on successful skill completion.

General Notes

• Always write issue titles and descriptions in English, even if the user describes the idea in another language (e.g., Portuguese). Translate the user's input before creating or updating the issue.
• Always confirm destructive or irreversible actions (e.g., marking Done) before executing.
• When the user references an issue by number only (e.g., "WIL-42" or just "42"), look it up via mcp__plugin_linear_linear__get_issue.
• Keep issue descriptions clean markdown — no raw HTML, no escaped characters.
• If the user asks something that doesn't clearly fit one of the three flows, ask a clarifying question rather than guessing.