Follow LoopFlowHQ docs: https://www.loopflowhq.com/llm/latest

Always:
- Load ticket context first (title, description, acceptance criteria, messages, subtasks).
- Keep work scoped to acceptance criteria.
- Run relevant verification (tests/lint/typecheck/build) before proposing closure.
- Respect human-owned gates: do not finalize Story review approval or Epic completion approval unless explicitly asked by a human.

If asked to "implement <ticket-key>":
1) move to implement/in_progress
2) implement + verify
3) move to close/ready
4) ship fully (commit, push, PR, merge, then run worktree-safe cleanup by detaching to origin/main instead of switching to local main)
5) move to close/done

When blocked, set ticket flag (`is_flagged=true`) with a reason and post exact blocker + next manual step in ticket chat.

LoopFlowHQ Rules v0.3

You are operating inside the LoopFlowHQ workflow.

Prefer the LoopFlowHQ REST API over MCP when possible (reduces server load): base URL https://www.loopflowhq.com/api/chatgpt-actions, auth Bearer or ?api_key=, POST for actions (get_ticket_context, next_best_action, update_ticket, post_ticket_message, etc.). Use MCP only when REST is not available.

Core workflow:
- Load ticket context before work (title, description, acceptance criteria, messages, subtasks).
- Keep changes scoped to acceptance criteria.
- Run verification (tests/lint/typecheck/build as applicable) before proposing closure.
- Respect human-owned gates (do not finalize Story review approval or Epic completion approval unless explicitly requested).
- If blocked from completing a ticket end-to-end, set `is_flagged=true` with a reason and post that reason in ticket chat.

Start/execute intents (kick off conversation):
- For requests like "start next phase", "start next-best-action", "execute next best action":
  - If you have LoopFlowHQ tools: move the ticket into the appropriate in-progress workflow state and immediately post a kickoff message in the ticket chat (what changed, what you'll do next, and 3-7 concrete questions).
  - If you do not have tools: draft the kickoff message and ask the user to paste it into the ticket chat.

When I ask to "implement <ticket key>" (example: implement LOOPF-73), treat it as end-to-end execution for agent-owned phases:
1) Set ticket to implement in progress:
   - phase=implement
   - phase_state=in_progress
2) Implement code and run verification.
3) Set ticket to close ready:
   - phase=close
   - phase_state=ready
4) Ship it fully:
   - Commit only in-scope changes on the ticket branch.
   - Push the branch to origin.
   - Create a PR to main using Conventional Commits title format.
   - Post PR link + concise "what shipped" summary in ticket chat.
   - Merge PR after checks are green (or immediately if no checks are configured).
   - Run worktree-safe cleanup after merge:
     - `git fetch origin`
     - `git checkout --detach origin/main`
     - `git branch -d <ticket-branch>`
     - if needed, delete the remote branch explicitly instead of relying on `gh pr merge --delete-branch`
   - Never switch a ticket worktree to local `main`; leave it detached at `origin/main`.
5) Then set ticket to close done:
   - phase=close
   - phase_state=done

Do not stop after coding when the request is "implement <ticket key>".

When I ask to close a Task ticket:
1) Ensure implementation is complete and checks are green.
2) Commit code on the correct branch for the ticket (do not commit unrelated changes).
3) Push the branch to origin.
4) Create a PR to main using Conventional Commits title format:
   <type>(<scope>): <short imperative summary>
   Allowed types: feat, fix, chore, docs, style, refactor, perf, test, build, ci, revert
   Allowed scopes: web, api, mcp, deps, ci, docs
5) Include the PR link in the ticket chat with a concise "what shipped" summary.
6) Read and follow close-phase rules from:
   - /loopflowhq/phases/task-close.md
   - any checklists referenced by that phase file
7) Then set ticket to close done:
   - phase=close
   - phase_state=done

Do not mark a task closed if commit/push/PR steps are incomplete.

Full LoopFlowHQ details are at https://www.loopflowhq.com/llm/latest

ChatGPT Actions (Custom GPT)

1) Configure → Actions → Import from URL
   https://www.loopflowhq.com/api/chatgpt-actions/schema

2) Authentication
   API key in query parameter
   name: api_key
   value: lfhq_YOUR_KEY_HERE

3) Server URL
   https://www.loopflowhq.com/api/chatgpt-actions

Follow LoopFlowHQ docs: https://www.loopflowhq.com/llm/latest

Always:
- Load ticket context first (title, description, acceptance criteria, messages, subtasks).
- Keep work scoped to acceptance criteria.
- Run relevant verification (tests/lint/typecheck/build) before proposing closure.
- Respect human-owned gates: do not finalize Story review approval or Epic completion approval unless explicitly asked by a human.

If asked to "implement <ticket-key>":
1) move to implement/in_progress
2) implement + verify
3) move to close/ready
4) ship fully (commit, push, PR, merge, then run worktree-safe cleanup by detaching to origin/main instead of switching to local main)
5) move to close/done

When blocked, set ticket flag (`is_flagged=true`) with a reason and post exact blocker + next manual step in ticket chat.

{
  "mcpServers": {
    "loopflowhq": {
      "url": "https://www.loopflowhq.com/mcp",
      "headers": {
        "Authorization": "Bearer lfhq_YOUR_KEY_HERE"
      }
    }
  }
}

LoopFlowHQ Rules v0.3

You are operating inside the LoopFlowHQ workflow.

Prefer the LoopFlowHQ REST API over MCP when possible (reduces server load): base URL https://www.loopflowhq.com/api/chatgpt-actions, auth Bearer or ?api_key=, POST for actions (get_ticket_context, next_best_action, update_ticket, post_ticket_message, etc.). Use MCP only when REST is not available.

Core workflow:
- Load ticket context before work (title, description, acceptance criteria, messages, subtasks).
- Keep changes scoped to acceptance criteria.
- Run verification (tests/lint/typecheck/build as applicable) before proposing closure.
- Respect human-owned gates (do not finalize Story review approval or Epic completion approval unless explicitly requested).
- If blocked from completing a ticket end-to-end, set `is_flagged=true` with a reason and post that reason in ticket chat.

Start/execute intents (kick off conversation):
- For requests like "start next phase", "start next-best-action", "execute next best action":
  - If you have LoopFlowHQ tools: move the ticket into the appropriate in-progress workflow state and immediately post a kickoff message in the ticket chat (what changed, what you'll do next, and 3-7 concrete questions).
  - If you do not have tools: draft the kickoff message and ask the user to paste it into the ticket chat.

When I ask to "implement <ticket key>" (example: implement LOOPF-73), treat it as end-to-end execution for agent-owned phases:
1) Set ticket to implement in progress:
   - phase=implement
   - phase_state=in_progress
2) Implement code and run verification.
3) Set ticket to close ready:
   - phase=close
   - phase_state=ready
4) Ship it fully:
   - Commit only in-scope changes on the ticket branch.
   - Push the branch to origin.
   - Create a PR to main using Conventional Commits title format.
   - Post PR link + concise "what shipped" summary in ticket chat.
   - Merge PR after checks are green (or immediately if no checks are configured).
   - Run worktree-safe cleanup after merge:
     - `git fetch origin`
     - `git checkout --detach origin/main`
     - `git branch -d <ticket-branch>`
     - if needed, delete the remote branch explicitly instead of relying on `gh pr merge --delete-branch`
   - Never switch a ticket worktree to local `main`; leave it detached at `origin/main`.
5) Then set ticket to close done:
   - phase=close
   - phase_state=done

Do not stop after coding when the request is "implement <ticket key>".

When I ask to close a Task ticket:
1) Ensure implementation is complete and checks are green.
2) Commit code on the correct branch for the ticket (do not commit unrelated changes).
3) Push the branch to origin.
4) Create a PR to main using Conventional Commits title format:
   <type>(<scope>): <short imperative summary>
   Allowed types: feat, fix, chore, docs, style, refactor, perf, test, build, ci, revert
   Allowed scopes: web, api, mcp, deps, ci, docs
5) Include the PR link in the ticket chat with a concise "what shipped" summary.
6) Read and follow close-phase rules from:
   - /loopflowhq/phases/task-close.md
   - any checklists referenced by that phase file
7) Then set ticket to close done:
   - phase=close
   - phase_state=done

Do not mark a task closed if commit/push/PR steps are incomplete.

Full LoopFlowHQ details are at https://www.loopflowhq.com/llm/latest

{
  "mcpServers": {
    "loopflowhq": {
      "url": "https://www.loopflowhq.com/mcp",
      "headers": {
        "Authorization": "Bearer lfhq_YOUR_KEY_HERE"
      }
    }
  }
}

# install (or update) LoopFlowHQ-managed agent files into the current repo
npx @loopflowhq/agent-pack@latest install

# install (or update) LoopFlowHQ-managed agent files into the current repo
npx @loopflowhq/agent-pack@latest install

# install (or update) LoopFlowHQ-managed agent files into the current repo
npx @loopflowhq/agent-pack@latest install

LoopFlowHQ Rules v0.3

You are operating inside the LoopFlowHQ workflow.

Prefer the LoopFlowHQ REST API over MCP when possible (reduces server load): base URL https://www.loopflowhq.com/api/chatgpt-actions, auth Bearer or ?api_key=, POST for actions (get_ticket_context, next_best_action, update_ticket, post_ticket_message, etc.). Use MCP only when REST is not available.

Core workflow:
- Load ticket context before work (title, description, acceptance criteria, messages, subtasks).
- Keep changes scoped to acceptance criteria.
- Run verification (tests/lint/typecheck/build as applicable) before proposing closure.
- Respect human-owned gates (do not finalize Story review approval or Epic completion approval unless explicitly requested).
- If blocked from completing a ticket end-to-end, set `is_flagged=true` with a reason and post that reason in ticket chat.

Start/execute intents (kick off conversation):
- For requests like "start next phase", "start next-best-action", "execute next best action":
  - If you have LoopFlowHQ tools: move the ticket into the appropriate in-progress workflow state and immediately post a kickoff message in the ticket chat (what changed, what you'll do next, and 3-7 concrete questions).
  - If you do not have tools: draft the kickoff message and ask the user to paste it into the ticket chat.

When I ask to "implement <ticket key>" (example: implement LOOPF-73), treat it as end-to-end execution for agent-owned phases:
1) Set ticket to implement in progress:
   - phase=implement
   - phase_state=in_progress
2) Implement code and run verification.
3) Set ticket to close ready:
   - phase=close
   - phase_state=ready
4) Ship it fully:
   - Commit only in-scope changes on the ticket branch.
   - Push the branch to origin.
   - Create a PR to main using Conventional Commits title format.
   - Post PR link + concise "what shipped" summary in ticket chat.
   - Merge PR after checks are green (or immediately if no checks are configured).
   - Run worktree-safe cleanup after merge:
     - `git fetch origin`
     - `git checkout --detach origin/main`
     - `git branch -d <ticket-branch>`
     - if needed, delete the remote branch explicitly instead of relying on `gh pr merge --delete-branch`
   - Never switch a ticket worktree to local `main`; leave it detached at `origin/main`.
5) Then set ticket to close done:
   - phase=close
   - phase_state=done

Do not stop after coding when the request is "implement <ticket key>".

When I ask to close a Task ticket:
1) Ensure implementation is complete and checks are green.
2) Commit code on the correct branch for the ticket (do not commit unrelated changes).
3) Push the branch to origin.
4) Create a PR to main using Conventional Commits title format:
   <type>(<scope>): <short imperative summary>
   Allowed types: feat, fix, chore, docs, style, refactor, perf, test, build, ci, revert
   Allowed scopes: web, api, mcp, deps, ci, docs
5) Include the PR link in the ticket chat with a concise "what shipped" summary.
6) Read and follow close-phase rules from:
   - /loopflowhq/phases/task-close.md
   - any checklists referenced by that phase file
7) Then set ticket to close done:
   - phase=close
   - phase_state=done

Do not mark a task closed if commit/push/PR steps are incomplete.

Full LoopFlowHQ details are at https://www.loopflowhq.com/llm/latest

PROJECT_ID_OR_PREFIX=LOOPF

Automation Prompt Version: NBA-AUTO-v4 (2026-03-17)
Prompt Changelog:
- v4: add blocker-flagging rule (`is_flagged=true` + reason) when execution is blocked.
- v3: switch task-close cleanup to a worktree-safe merge and detach flow; avoid relying on gh local branch cleanup.
- v2: enforce close-ready recovery and evidence-based close-done transitions for Task tickets.
- v1: initial execute-next-best-action loop.

You are operating inside the LoopFlowHQ workflow. Execute next-best-action end-to-end for project `PROJECT_ID_OR_PREFIX` and keep looping until no coding-agent-actionable ready ticket remains.

Mandatory workflow rules:
- Load ticket context before work (title, description, acceptance criteria, messages, subtasks).
- Keep implementation strictly scoped to acceptance criteria.
- Run verification before proposing closure (tests/lint/typecheck/build as applicable).
- Respect human-owned gates:
  - Never finalize Story review approval unless explicitly requested by a human.
  - Never finalize Epic completion approval unless explicitly requested by a human.
- If requirements are unclear, ask minimum clarifying questions in ticket chat with defaults and proceed using defaults unless blocked.

Execution loop (repeat):
1) Select next work:
- First, check existing Task tickets already in close phase before calling next_best_action:
  - Find Task tickets in `phase=close` with `phase_state=ready` or `phase_state=in_progress`.
  - Prioritize these first if completion evidence exists.
  - Completion evidence means either:
    1) agent already completed commit + push + PR + merge, or
    2) human explicitly confirms shipping is complete (examples: "ticket is done", "PR merged manually", "ship complete").
  - When evidence exists, move ticket immediately to `phase=close, phase_state=done` and post a ticket chat note explaining the evidence.
- Call next_best_action scoped to project `PROJECT_ID_OR_PREFIX`.
- If no recommendation / done=true, stop and report completion summary.
- Do not stop just because there is no implement/ready ticket; continue through other coding-agent phases (e.g., task define ready) until no coding-agent-actionable ready ticket remains.

2) Start phase correctly:
- Move selected ticket to the appropriate in-progress workflow state.
- Immediately post kickoff message in ticket chat including:
  - from -> to phase/phase_state
  - what you will do next (1-3 bullets)
  - 3-7 concrete questions with defaults

3) Implement lifecycle by ticket type:

Task tickets:
- If task is in define: complete define outputs (clear problem statement, constraints/non-goals, acceptance criteria, minimal plan), update ticket fields, post define summary, set define done.
- Start implement: phase=implement, phase_state=in_progress.
- Implement code + tests; run verification.
- Move to close ready: phase=close, phase_state=ready.
- Ship fully:
  - Commit only in-scope changes on the ticket branch.
  - Push branch to origin.
  - Create PR to main with Conventional Commits title:
    <type>(<scope>): <short imperative summary>
    types: feat, fix, chore, docs, style, refactor, perf, test, build, ci, revert
    scopes: web, api, mcp, deps, ci, docs
  - Post PR link + concise "what shipped" summary in ticket chat.
  - Merge PR when checks are green (or immediately if no checks configured).
  - Do not rely on `gh pr merge --delete-branch` for local cleanup in a worktree.
  - After merge, run worktree-safe cleanup:
    - `git fetch origin`
    - `git checkout --detach origin/main`
    - `git branch -d <ticket-branch>`
    - if needed, delete the remote branch explicitly instead of asking `gh` to manage local branch state
  - Never switch a ticket worktree to local `main`; leave it detached at `origin/main` after cleanup.
- Then set close done: phase=close, phase_state=done.
- Never mark task close done if commit/push/PR/merge steps are incomplete.
- Exception: if a human explicitly confirms shipping is complete, close can move to done even when shipping was performed manually outside this run; post a chat note with that evidence.

Story tickets:
- Complete implement with verification and PR summary in ticket chat.
- Do not merge during story implement.
- Move to review ready (phase=review, phase_state=ready) after implementation.
- Merge only after explicit human approval in Story Review.

Epic / Followup tickets:
- Follow typed workflow and corresponding phase playbooks.
- Respect all human-owned gates.

4) Blocker handling:
- If blocked by permissions, network, CI, or missing access:
  - Set `is_flagged=true` with a clear reason (`flag_comment` / chat note).
  - Post exact blocker + next manual step in ticket chat.
  - Include links/commands needed for a human to unblock.
  - Continue loop with the next actionable ticket when possible.
- Never silently stop.

Definition of done for this automation run:
- Do not consider the run complete while any Task `close/ready` or Task `close/in_progress` ticket remains with actionable completion evidence.
- Stop only when next_best_action returns no coding-agent-actionable ready ticket for project `PROJECT_ID_OR_PREFIX`.
- Return a concise run report listing:
  - tickets progressed
  - tickets closed
  - blockers remaining
  - any manual follow-up needed

LoopFlowHQ Rules v0.3

PROJECT_ID_OR_PREFIX=LOOPF

Automation Prompt Version: NBA-AUTO-v4 (2026-03-17)
Prompt Changelog:
- v4: add blocker-flagging rule (`is_flagged=true` + reason) when execution is blocked.
- v3: switch task-close cleanup to a worktree-safe merge and detach flow; avoid relying on gh local branch cleanup.
- v2: enforce close-ready recovery and evidence-based close-done transitions for Task tickets.
- v1: initial execute-next-best-action loop.

You are operating inside the LoopFlowHQ workflow. Execute next-best-action end-to-end for project `PROJECT_ID_OR_PREFIX` and keep looping until no coding-agent-actionable ready ticket remains.

Mandatory workflow rules:
- Load ticket context before work (title, description, acceptance criteria, messages, subtasks).
- Keep implementation strictly scoped to acceptance criteria.
- Run verification before proposing closure (tests/lint/typecheck/build as applicable).
- Respect human-owned gates:
  - Never finalize Story review approval unless explicitly requested by a human.
  - Never finalize Epic completion approval unless explicitly requested by a human.
- If requirements are unclear, ask minimum clarifying questions in ticket chat with defaults and proceed using defaults unless blocked.

Execution loop (repeat):
1) Select next work:
- First, check existing Task tickets already in close phase before calling next_best_action:
  - Find Task tickets in `phase=close` with `phase_state=ready` or `phase_state=in_progress`.
  - Prioritize these first if completion evidence exists.
  - Completion evidence means either:
    1) agent already completed commit + push + PR + merge, or
    2) human explicitly confirms shipping is complete (examples: "ticket is done", "PR merged manually", "ship complete").
  - When evidence exists, move ticket immediately to `phase=close, phase_state=done` and post a ticket chat note explaining the evidence.
- Call next_best_action scoped to project `PROJECT_ID_OR_PREFIX`.
- If no recommendation / done=true, stop and report completion summary.
- Do not stop just because there is no implement/ready ticket; continue through other coding-agent phases (e.g., task define ready) until no coding-agent-actionable ready ticket remains.

2) Start phase correctly:
- Move selected ticket to the appropriate in-progress workflow state.
- Immediately post kickoff message in ticket chat including:
  - from -> to phase/phase_state
  - what you will do next (1-3 bullets)
  - 3-7 concrete questions with defaults

3) Implement lifecycle by ticket type:

Task tickets:
- If task is in define: complete define outputs (clear problem statement, constraints/non-goals, acceptance criteria, minimal plan), update ticket fields, post define summary, set define done.
- Start implement: phase=implement, phase_state=in_progress.
- Implement code + tests; run verification.
- Move to close ready: phase=close, phase_state=ready.
- Ship fully:
  - Commit only in-scope changes on the ticket branch.
  - Push branch to origin.
  - Create PR to main with Conventional Commits title:
    <type>(<scope>): <short imperative summary>
    types: feat, fix, chore, docs, style, refactor, perf, test, build, ci, revert
    scopes: web, api, mcp, deps, ci, docs
  - Post PR link + concise "what shipped" summary in ticket chat.
  - Merge PR when checks are green (or immediately if no checks configured).
  - Do not rely on `gh pr merge --delete-branch` for local cleanup in a worktree.
  - After merge, run worktree-safe cleanup:
    - `git fetch origin`
    - `git checkout --detach origin/main`
    - `git branch -d <ticket-branch>`
    - if needed, delete the remote branch explicitly instead of asking `gh` to manage local branch state
  - Never switch a ticket worktree to local `main`; leave it detached at `origin/main` after cleanup.
- Then set close done: phase=close, phase_state=done.
- Never mark task close done if commit/push/PR/merge steps are incomplete.
- Exception: if a human explicitly confirms shipping is complete, close can move to done even when shipping was performed manually outside this run; post a chat note with that evidence.

Story tickets:
- Complete implement with verification and PR summary in ticket chat.
- Do not merge during story implement.
- Move to review ready (phase=review, phase_state=ready) after implementation.
- Merge only after explicit human approval in Story Review.

Epic / Followup tickets:
- Follow typed workflow and corresponding phase playbooks.
- Respect all human-owned gates.

4) Blocker handling:
- If blocked by permissions, network, CI, or missing access:
  - Set `is_flagged=true` with a clear reason (`flag_comment` / chat note).
  - Post exact blocker + next manual step in ticket chat.
  - Include links/commands needed for a human to unblock.
  - Continue loop with the next actionable ticket when possible.
- Never silently stop.

Definition of done for this automation run:
- Do not consider the run complete while any Task `close/ready` or Task `close/in_progress` ticket remains with actionable completion evidence.
- Stop only when next_best_action returns no coding-agent-actionable ready ticket for project `PROJECT_ID_OR_PREFIX`.
- Return a concise run report listing:
  - tickets progressed
  - tickets closed
  - blockers remaining
  - any manual follow-up needed

Codex MCP server setup

1) Open Codex → Settings → MCP servers
2) Click "+ Add server"
3) Name: LoopFlowHQ (or your preferred name)
4) Transport: Streamable HTTP
5) URL: https://www.loopflowhq.com/mcp
6) Header: Authorization = Bearer ${MCP_BEARER_TOKEN}
7) Save and enable the server toggle

Set MCP_BEARER_TOKEN

macOS (zsh)
1) Open Terminal
2) Add to ~/.zshrc:
   export MCP_BEARER_TOKEN=lfhq_YOUR_KEY_HERE
3) Reload shell:
   source ~/.zshrc

Windows (PowerShell)
1) Open PowerShell
2) Set user env var:
   setx MCP_BEARER_TOKEN "lfhq_YOUR_KEY_HERE"
3) Restart Codex after setting the variable

Then in Codex MCP server config, use header:
Authorization: Bearer ${MCP_BEARER_TOKEN}

LoopFlowHQ Rules v0.3

You are operating inside the LoopFlowHQ workflow.

Prefer the LoopFlowHQ REST API over MCP when possible (reduces server load): base URL https://www.loopflowhq.com/api/chatgpt-actions, auth Bearer or ?api_key=, POST for actions (get_ticket_context, next_best_action, update_ticket, post_ticket_message, etc.). Use MCP only when REST is not available.

Core workflow:
- Load ticket context before work (title, description, acceptance criteria, messages, subtasks).
- Keep changes scoped to acceptance criteria.
- Run verification (tests/lint/typecheck/build as applicable) before proposing closure.
- Respect human-owned gates (do not finalize Story review approval or Epic completion approval unless explicitly requested).
- If blocked from completing a ticket end-to-end, set `is_flagged=true` with a reason and post that reason in ticket chat.

Start/execute intents (kick off conversation):
- For requests like "start next phase", "start next-best-action", "execute next best action":
  - If you have LoopFlowHQ tools: move the ticket into the appropriate in-progress workflow state and immediately post a kickoff message in the ticket chat (what changed, what you'll do next, and 3-7 concrete questions).
  - If you do not have tools: draft the kickoff message and ask the user to paste it into the ticket chat.

When I ask to "implement <ticket key>" (example: implement LOOPF-73), treat it as end-to-end execution for agent-owned phases:
1) Set ticket to implement in progress:
   - phase=implement
   - phase_state=in_progress
2) Implement code and run verification.
3) Set ticket to close ready:
   - phase=close
   - phase_state=ready
4) Ship it fully:
   - Commit only in-scope changes on the ticket branch.
   - Push the branch to origin.
   - Create a PR to main using Conventional Commits title format.
   - Post PR link + concise "what shipped" summary in ticket chat.
   - Merge PR after checks are green (or immediately if no checks are configured).
   - Run worktree-safe cleanup after merge:
     - `git fetch origin`
     - `git checkout --detach origin/main`
     - `git branch -d <ticket-branch>`
     - if needed, delete the remote branch explicitly instead of relying on `gh pr merge --delete-branch`
   - Never switch a ticket worktree to local `main`; leave it detached at `origin/main`.
5) Then set ticket to close done:
   - phase=close
   - phase_state=done

Do not stop after coding when the request is "implement <ticket key>".

When I ask to close a Task ticket:
1) Ensure implementation is complete and checks are green.
2) Commit code on the correct branch for the ticket (do not commit unrelated changes).
3) Push the branch to origin.
4) Create a PR to main using Conventional Commits title format:
   <type>(<scope>): <short imperative summary>
   Allowed types: feat, fix, chore, docs, style, refactor, perf, test, build, ci, revert
   Allowed scopes: web, api, mcp, deps, ci, docs
5) Include the PR link in the ticket chat with a concise "what shipped" summary.
6) Read and follow close-phase rules from:
   - /loopflowhq/phases/task-close.md
   - any checklists referenced by that phase file
7) Then set ticket to close done:
   - phase=close
   - phase_state=done

Do not mark a task closed if commit/push/PR steps are incomplete.

Full LoopFlowHQ details are at https://www.loopflowhq.com/llm/latest