@loopflowhq/agent-pack 0.4.0 → 0.5.0

package/.cursor/commands/lfq-next-best-action.md

@@ -1,4 +1,3 @@
 # lfq-next-best-action — Next best action
 
 Follow `loopflowhq/commands/next-best-action.md`.
-

package/.cursor/commands/lfq-start-next-best-action.md

@@ -0,0 +1,4 @@
+# lfq-start-next-best-action — Start next best action
+
+Follow `loopflowhq/commands/start-next-best-action.md`.
+

package/.cursor/commands/lfq-start-next-phase.md

@@ -0,0 +1,4 @@
+# lfq-start-next-phase — Start next phase
+
+Follow `loopflowhq/commands/start-next-phase.md`.
+

package/loopflowhq/agent.md

@@ -36,7 +36,7 @@ This file is the canonical, repo-local description of how LoopFlowHQ work. It is
 
 - Epic: `discovery` -> `refine` -> `plan` -> `implement` -> `close`
 - Story: `plan` -> `implement` -> `review` -> `close`
-- Task: `define` -> `implement`
+- Task: `define` -> `implement` -> `close`
 - Followup: `review` -> `close`
 
 See phase playbooks (ticket_type routed):
@@ -58,6 +58,7 @@ See phase playbooks (ticket_type routed):
   - Task:
     - define: `loopflowhq/phases/task-define.md`
     - implement: `loopflowhq/phases/task-implement.md`
+    - close: `loopflowhq/phases/task-close.md`
   - Followup:
     - review: `loopflowhq/phases/followup-review.md`
     - close: `loopflowhq/phases/followup-close.md`
@@ -82,6 +83,10 @@ Moving to the next phase:
 
 - When a phase is `done`, the next phase starts at `ready`.
 
+Story autonomy expectation:
+
+- In `story` Implement, a coding agent should be able to complete the work without further human input (based on the approved plan + acceptance criteria), then move the ticket to `phase=review`, `phase_state=ready` and post the PR link in ticket chat.
+
 ## Required ticket context (before doing work)
 
 Before doing ticket work in any phase, load the ticket context from LoopFlowHQ so work stays aligned with the source of truth:
@@ -106,6 +111,34 @@ If MCP / Actions tools are available, the standard loop is:
 2. `update_ticket` to set `phase` / `phase_state` as you start and finish a step.
 3. `post_ticket_message` to write a concise step summary (what changed, what was decided, what is next).
 
+## "Start/Execute" intent (kick off a conversation)
+
+When the user's intent is to **start / execute / do** work (not just inspect), for example:
+
+- "start next phase"
+- "start next-best-action"
+- "start next phase of ticket LOOPF-123"
+- synonyms: "execute", "start", "do"
+
+Then **do not only move workflow state**. Also **start a conversation immediately** in the ticket chat.
+
+Required behavior (when tools are available):
+
+1. Move the ticket into the correct working state:
+   - If the user is starting the next phase for a specific ticket:
+     - compute the transition deterministically from the typed workflow (ticket type + current `phase`/`phase_state`)
+     - do not use `next_best_action` for this case
+   - If the user intent is "next best action" (especially when no ticket is specified and a ticket must be selected):
+     - call `next_best_action` to select the ticket and recommended next workflow step
+   - set `phase_state=in_progress` for the phase you are starting (use `update_ticket` or `update_ticket_status` depending on your tool surface)
+2. Post a kickoff message via `post_ticket_message` that includes:
+   - what you changed (from -> to `phase/phase_state`)
+   - what you will do next (1-3 bullets)
+   - what you need from the human (3-7 concrete questions, with defaults if possible)
+3. Optional (recommended when you need structured answers): also call `post_ticket_agent_questions` with the same questions.
+
+Fallback (no tool access): draft the kickoff message and ask the user to paste it into the ticket chat.
+
 ## API-first ticket operations (deterministic)
 
 When you need deterministic ticket CRUD, prefer the LoopFlowHQ Actions REST API when it is available in your environment.

package/loopflowhq/commands/next-best-action.md

@@ -2,14 +2,25 @@
 
 Goal: determine the recommended next workflow transition for a ticket (or pick the next ticket to work on).
 
+If the user intent is to **start/execute** the work (not just inspect), use:
+
+- `loopflowhq/commands/start-next-best-action.md`
+
 ## Steps
 
-1. Ensure you have a ticket key/ID. If none is available, ask the user which ticket to use.
-2. Call `next_best_action`.
+1. Determine the **requester type** (who is asking for next best action):
+   - `human`: a human in the LoopFlowHQ UI/app
+   - `chat agent`: a discussion LLM (e.g. ChatGPT/Claude/Gemini)
+   - `code agent`: a coding agent (e.g. Codex/Cursor/Claude Code)
+2. Ensure you have a ticket key/ID. If none is available, ask the user which ticket to use.
+3. Call `next_best_action`.
    - If a ticket is provided: `next_best_action({ ticket })`
    - If no ticket is provided: `next_best_action({ limit })`
-3. Report:
+4. If a ticket was selected, call `get_ticket({ ticket })` so you can report its `type` (e.g. epic/story/task/followup).
+5. Report:
+   - requester type (`human|chat agent|code agent`)
    - selected ticket (id/key/title when present)
+   - selected ticket type (epic/story/task/followup when available; otherwise the raw `ticket.type`)
    - current `{ phase, phase_state }`
    - next `{ phase, phase_state }` (or null)
 
@@ -17,8 +28,9 @@ Goal: determine the recommended next workflow transition for a ticket (or pick t
 
 ```
 ## Next best action
+- Requester: <human|chat agent|code agent>
 - Ticket: <KEY or id> — <title>
+- Ticket type: <epic|story|task|followup|...> (or "unknown")
 - Current: <phase>/<phase_state>
 - Next: <phase>/<phase_state> (or "none")
 ```
-

package/loopflowhq/commands/start-next-best-action.md

@@ -0,0 +1,53 @@
+# Command: Start Next Best Action
+
+Goal: pick the next ticket (if none is provided), start the recommended workflow step, and immediately kick off a conversation in the ticket chat.
+
+This command is for user intents like:
+
+- "start next-best-action"
+- "execute next best action"
+- "do the next best action"
+
+## Steps
+
+1. Determine requester type:
+   - `human`: a human in the LoopFlowHQ UI/app
+   - `chat agent`: a discussion LLM (e.g. ChatGPT/Claude/Gemini)
+   - `code agent`: a coding agent (e.g. Codex/Cursor/Claude Code)
+2. Call `next_best_action`.
+   - If a ticket is provided: `next_best_action({ ticket })`
+   - If no ticket is provided: `next_best_action({ limit })`
+3. If `next` is null: report "none" and stop (do not invent work).
+4. Load ticket context:
+   - `get_ticket({ ticket })` for type/title
+   - `get_ticket_context({ ticket, messages_limit })` if you need context before asking questions
+5. Start the work (move workflow state):
+   - Determine the target phase/state:
+     - If `next.phase_state` is `in_progress`: use it as-is.
+     - If `next.phase_state` is `ready`: set target to `{ phase: next.phase, phase_state: in_progress }` (start the phase).
+     - If `next.phase_state` is `done`: do **not** apply it for a "start" intent; ask for confirmation.
+   - Update the ticket (one call):
+     - Prefer `update_ticket({ ticket, phase, phase_state })`
+     - If you must use `update_ticket_status`, set `status` consistent with the target phase (legacy mapping):
+       - discovery -> discovery
+       - refine/plan -> planning
+       - implement -> in_progress
+       - review/close -> review (close done becomes done)
+6. Kick off the conversation immediately:
+   - Call `post_ticket_message({ ticket, content })` with:
+     - the transition you applied (`from` -> `to`)
+     - what you will do next (1-3 bullets)
+     - 3-7 concrete questions (with default assumptions)
+   - Optional (recommended): also call `post_ticket_agent_questions` with the same questions.
+
+## Output format
+
+```
+## Started next best action
+- Requester: <human|chat agent|code agent>
+- Ticket: <KEY or id> — <title>
+- Ticket type: <epic|story|task|followup|...>
+- Transition: <from phase/state> -> <to phase/state>
+- Kickoff: posted to ticket chat (message + optional structured questions)
+```
+

package/loopflowhq/commands/start-next-phase.md

@@ -0,0 +1,49 @@
+# Command: Start Next Phase (for a ticket)
+
+Goal: for a specific ticket, start the next phase of work and immediately kick off a conversation in the ticket chat.
+
+This command is for user intents like:
+
+- "start next phase"
+- "start next phase of ticket LOOPF-123"
+- "execute the next phase"
+
+## Steps
+
+1. Ensure you have a ticket key/ID. If none is available, ask the user which ticket to use.
+2. Load the ticket's current typed workflow state:
+   - Call `get_ticket({ ticket })` (or `get_ticket_context({ ticket })`) and read `{ type, phase, phase_state }`.
+   - Do **not** call `next_best_action` when the user is already talking about a specific ticket and the intent is "start next phase".
+     - Reserve `next_best_action` for "next best action" intents, especially when no ticket is specified and you need to select work.
+3. Decide what "start" means (non-destructive defaults):
+   - If `current.phase_state` is `ready`: start the current phase (`phase_state=in_progress`).
+   - If `current.phase_state` is `changes_requested`: start rework in the same phase (`phase_state=in_progress`).
+   - If `current.phase_state` is `done`: start the next phase (`phase_state=in_progress`) by advancing deterministically using the typed workflow for the ticket type:
+     - Epic: `discovery` -> `refine` -> `plan` -> `implement` -> `close`
+     - Story: `plan` -> `implement` -> `review` -> `close`
+     - Task: `define` -> `implement` -> `close`
+     - Followup: `review` -> `close`
+     - If the current phase is already the last phase for the ticket type, do not advance; post a kickoff message and ask what the user wants next.
+   - If `current.phase_state` is `in_progress`: do not mark done; post a kickoff message anyway and ask what to do next.
+4. Update the ticket to the target `{ phase, phase_state }`:
+   - Prefer `update_ticket({ ticket, phase, phase_state })`.
+   - If using `update_ticket_status`, choose a legacy `status` consistent with the target phase:
+     - discovery -> discovery
+     - refine/plan -> planning
+     - implement -> in_progress
+     - review/close -> review (close done becomes done)
+5. Kick off the conversation immediately:
+   - Call `post_ticket_message({ ticket, content })` with:
+     - the transition you applied (`from` -> `to`)
+     - what you will do next (1-3 bullets)
+     - 3-7 concrete questions (with default assumptions)
+   - Optional (recommended): also call `post_ticket_agent_questions` with the same questions.
+
+## Output format
+
+```
+## Started next phase
+- Ticket: <KEY or id> — <title>
+- Transition: <from phase/state> -> <to phase/state>
+- Kickoff: posted to ticket chat (message + optional structured questions)
+```

package/loopflowhq/phases/epic-close.md

@@ -1,6 +1,6 @@
 # Ticket Type: Epic - Phase: Close
 
-Goal: finish the loop: ship, document, and leave the system clean.
+Goal: close the epic by confirming the outcome, capturing what shipped and verification evidence, and creating followups when needed.
 
 ## Inputs
 
@@ -10,14 +10,16 @@ Goal: finish the loop: ship, document, and leave the system clean.
 
 ## Outputs (minimum)
 
-- “What shipped” summary
+- "What shipped" summary
 - Verification steps (and results)
-- Followups created if needed
+- Followups created if needed (or explicitly skipped)
 
 ## Agent checklist
 
 - Load ticket context (see `loopflowhq/agent.md`).
-- Ensure the ticket summary matches what actually changed.
+- Ensure the epic summary matches what actually changed.
 - If cancelled, record why and whether a followup is needed.
-- Prefer small cleanup over “nice-to-have” refactors.
+- Prefer small cleanup over "nice-to-have" refactors.
 - Run verification (lint/build/test/manual) appropriate to the change before closing.
+- Post a final Close summary in the ticket chat (`post_ticket_message`).
+

package/loopflowhq/phases/epic-implement.md

@@ -1,23 +1,26 @@
 # Ticket Type: Epic - Phase: Implement
 
-Goal: deliver the epic’s acceptance criteria by implementing planned changes, with tests and minimal risk.
+Goal: deliver the epic's acceptance criteria by executing the approved plan (typically via child Stories), with tests and minimal risk.
 
 ## Inputs
 
 - LoopFlowHQ ticket ID (pattern: `LOOPF-<number>` / regex: `LOOPF-\\d+`)
-- Approved plan
+- Approved plan (story breakdown + sequencing)
 
 ## Outputs (minimum)
 
-- Code changes
-- Tests (or explicit justification if not added)
-- Verification evidence (commands run, expected outputs)
+- Planned child stories progressed through implement/review/close
+- Epic `phase_state` reflects overall progress (`ready` / `in_progress` / `done`)
+- Verification evidence captured for anything that shipped (commands run, expected outputs)
 
 ## Agent checklist
 
-- Implement the acceptance criteria from the ticket; if unclear or missing, ask before proceeding.
-- Implement in small diffs; keep changes scoped.
-- Write/update tests that cover the acceptance criteria (or document why tests are not feasible).
-- Run the project’s standard checks (lint/typecheck/test/build) when applicable.
-- Call out any behavior changes and migrations.
-- Do not open a PR unless explicitly requested; shipping is handled separately.
+- Load ticket context (see `loopflowhq/agent.md`).
+- Confirm the epic has an approved plan; if missing or stale, send it back to Epic Plan.
+- Prefer executing work via child Stories:
+  - Identify the next child Story from the epic plan / linked stories.
+  - Start that Story's Implement phase and work it through Review and Close per the Story playbooks.
+- If there are epic-level tasks that must be executed directly, follow the same standards as Story/Task:
+  - small diffs, tests, and `npm run lint` / `npm run test` / `npm run build` as applicable.
+- Keep the epic's `phase_state` in sync with overall progress.
+

package/loopflowhq/phases/epic-plan.md

@@ -13,6 +13,7 @@ Goal: decide the smallest safe implementation plan with verification.
 - Step-by-step plan (small diffs)
 - Verification steps (tests/lint/build/manual steps)
 - Risks and rollback plan (if needed)
+- Story breakdown (sequenced, deployable chunks with clear acceptance criteria)
 - Plan stored in the ticket description (as a `## Plan` section)
 
 ## Agent checklist

package/loopflowhq/phases/epic-refine.md

@@ -14,6 +14,8 @@ Goal: turn discovery output into a precise, buildable specification.
 - Non-goals and explicit exclusions
 - Implementation shape (high-level architecture, key files/modules)
 - Risks / rollout notes (if applicable)
+ - Story list / execution shape (what will be delivered and in what chunks)
+ - Refine summary captured in the ticket chat (via `post_ticket_message`)
 
 ## Agent checklist
 

package/loopflowhq/phases/followup-close.md

@@ -1,23 +1,21 @@
 # Ticket Type: Followup - Phase: Close
 
-Goal: finish the loop: ship, document, and leave the system clean.
+Goal: close the loop: summarize the outcome and leave the system clean.
 
 ## Inputs
 
 - LoopFlowHQ ticket ID (pattern: `LOOPF-<number>` / regex: `LOOPF-\\d+`)
 - Approved outcome (or explicit cancellation reason)
-- Any rollout/release constraints
 
 ## Outputs (minimum)
 
-- “What shipped” summary
-- Verification steps (and results)
+- "What changed" / "What was decided" summary in ticket chat
 - Followups created if needed
 
 ## Agent checklist
 
 - Load ticket context (see `loopflowhq/agent.md`).
-- Ensure the ticket summary matches what actually changed.
+- Ensure the ticket summary matches what actually happened.
 - If cancelled, record why and whether a followup is needed.
-- Prefer small cleanup over “nice-to-have” refactors.
-- Run verification (lint/build/test/manual) appropriate to the change before closing.
+- Prefer small cleanup over "nice-to-have" refactors.
+

package/loopflowhq/phases/followup-review.md

@@ -1,23 +1,25 @@
 # Ticket Type: Followup - Phase: Review
 
-Goal: validate correctness, quality, and alignment with requirements.
+Goal: validate the followup outcome and decide whether it is acceptable as-is.
 
 ## Inputs
 
 - LoopFlowHQ ticket ID (pattern: `LOOPF-<number>` / regex: `LOOPF-\\d+`)
-- Implemented changes
-- Acceptance criteria
+- Implemented change (if any) and the reported outcome
+- Any acceptance criteria (if present)
 
 ## Outputs (minimum)
 
-- Review notes (bugs, risks, missing tests)
-- Decision: approve or request changes
+- Review notes captured in ticket chat
+- One of:
+  - Approved: set `phase=review`, `phase_state=done`, then move to Close (`phase=close`, `phase_state=ready`)
+  - Changes requested: set `phase=review`, `phase_state=changes_requested` with an actionable list of fixes
 
 ## Agent checklist
 
 - Load ticket context (see `loopflowhq/agent.md`).
 - Prioritize correctness and regressions over style.
-- Ensure acceptance criteria is demonstrably met.
-- If changes are requested, be explicit about what must change and why.
-- If issues are found, fix them and re-review before marking Review done.
-- Post the review notes in the ticket chat (avoid writing `.review/*` files).
+- Ensure acceptance criteria (if present) is demonstrably met.
+- Post a single consolidated list of requested changes if not approved.
+- Do not mark human-owned gates complete unless explicitly instructed by the human owner.
+

package/loopflowhq/phases/shared-close-checklist.md

@@ -0,0 +1,15 @@
+# Shared: Close Checklist (Story/Task)
+
+Use this checklist to avoid duplicating close/shipping guidance across Story/Task phases.
+
+## Checklist items to cover
+
+- Load ticket context (see `loopflowhq/agent.md`).
+- Confirm you have the PR link and checks are green.
+- Merge and ship:
+  - merge the PR to `main` automatically when checks pass
+  - if the project uses a different ship mechanism than “merge to main” (merge queue, release-please, manual promote, etc.), follow the repo’s standard process and run it instead
+  - if merge/deploy is blocked by missing permissions, post exact instructions and the PR link in ticket chat so a human can perform the single action
+- Post a concise “what shipped” summary in ticket chat (include PR link and any deploy evidence).
+- Ensure the ticket summary matches what actually changed.
+- Create followups if needed (bugs, tech debt, missing tests, rollout tasks).

package/loopflowhq/phases/shared-execution-checklist.md

@@ -0,0 +1,33 @@
+# Shared: Execution Checklist (Story/Task)
+
+Use this checklist to avoid duplicating execution guidance across Story/Task phases.
+
+## Requirements
+
+- Each subtask should be small and independently committable.
+- Prefer 1 subtask = 1 commit (or a small sequence of commits) so work can be reviewed and reverted safely.
+- Before each commit, run the standard checks (or the closest equivalents for the repo):
+  - `npm run lint`
+  - `npm run test`
+  - `npm run build`
+- If the change includes UI:
+  - include explicit subtasks to verify light mode and dark mode
+  - include explicit subtasks to verify desktop and mobile layouts
+- UX/UI rules are project-specific:
+  - follow the current repo's UX/UI spec and components; do not invent a new design system
+- Reuse existing components and patterns; do not duplicate functionality unless there is a clear reason.
+- Do a self code review before each commit (review diff for correctness, edge cases, a11y, and unintended behavior changes).
+- When implementation is complete, move the ticket forward in the typed workflow:
+  - Story Implement -> `phase=review`, `phase_state=ready` (post PR link)
+  - Task Implement -> `phase=close`, `phase_state=ready` (post summary / PR link if used)
+
+## Checklist items to cover
+
+- Implement code (small diffs)
+- Implement UI per project UX/UI rules (states: loading/empty/error; copy; a11y; responsiveness)
+- Write tests (unit/integration/e2e as appropriate)
+- Run tests and regression checks
+- Ensure `npm run lint`, `npm run build`, `npm run test` pass
+- Call out any behavior changes and migrations (and any follow-ups)
+- Update project docs (architecture/feature docs) when warranted
+- Create/update ADRs when warranted

package/loopflowhq/phases/shared-planning-checklist.md

@@ -0,0 +1,17 @@
+# Shared: Planning Checklist (Story/Task)
+
+Use this checklist to avoid duplicating planning and refinement guidance across phases.
+
+## Checklist items to cover
+
+- Scan the codebase/docs first to confirm whether the work is already partially or fully implemented.
+- Rewrite the ticket to be implementation-ready:
+  - title: short, specific, outcome-oriented
+  - description: problem + scope + constraints
+  - explicit non-goals / out-of-scope
+  - concrete acceptance criteria (testable)
+- Create an execution plan:
+  - add a `## Plan` section to the ticket description
+  - list small, atomic subtasks that are independently committable
+  - ensure the subtask plan covers `loopflowhq/phases/shared-execution-checklist.md`
+- Identify risks/dependencies and document mitigations (migrations, permissions, rollout, data backfills, performance).

package/loopflowhq/phases/story-close.md

@@ -5,19 +5,23 @@ Goal: finish the loop: ship, document, and leave the system clean.
 ## Inputs
 
 - LoopFlowHQ ticket ID (pattern: `LOOPF-<number>` / regex: `LOOPF-\\d+`)
-- Approved outcome (or explicit cancellation reason)
+- Approved outcome from Review (or explicit cancellation reason)
 - Any rollout/release constraints
 
 ## Outputs (minimum)
 
-- “What shipped” summary
+- "What shipped" summary
 - Verification steps (and results)
 - Followups created if needed
 
 ## Agent checklist
 
 - Load ticket context (see `loopflowhq/agent.md`).
+- Confirm Story Review is complete and approved (unless explicitly cancelling):
+  - ticket is `phase=review`, `phase_state=done`
+- Use `loopflowhq/phases/shared-close-checklist.md`.
 - Ensure the ticket summary matches what actually changed.
 - If cancelled, record why and whether a followup is needed.
-- Prefer small cleanup over “nice-to-have” refactors.
+- Prefer small cleanup over "nice-to-have" refactors.
 - Run verification (lint/build/test/manual) appropriate to the change before closing.
+

package/loopflowhq/phases/story-implement.md

@@ -6,18 +6,28 @@ Goal: make the change in code, with tests and minimal risk.
 
 - LoopFlowHQ ticket ID (pattern: `LOOPF-<number>` / regex: `LOOPF-\\d+`)
 - Approved plan
+- Ticket subtasks (if present)
 
 ## Outputs (minimum)
 
 - Code changes
-- Tests (or explicit justification if not added)
-- Verification evidence (commands run, expected outputs)
+- Tests added/updated for the acceptance criteria (or explicit justification if not added)
+- Verification evidence (commands run, expected outputs) posted in the ticket chat
+- PR link for human review (when applicable to your repo workflow)
 
 ## Agent checklist
 
-- Implement the acceptance criteria from the ticket; if unclear or missing, ask before proceeding.
-- Implement in small diffs; keep changes scoped.
-- Write/update tests that cover the acceptance criteria (or document why tests are not feasible).
-- Run the project’s standard checks (lint/typecheck/test/build) when applicable.
-- Call out any behavior changes and migrations.
-- Do not open a PR unless explicitly requested; shipping is handled separately.
+- Load ticket context + start/end phase transitions (see `loopflowhq/agent.md`).
+  - Ensure subtasks are loaded (`get_ticket_context` or `get_ticket_subtasks`) when present.
+  - If a parent Epic exists, load it too (read-only) for additional constraints.
+- No human-in-the-loop in this phase:
+  - implement based on the approved plan + acceptance criteria
+  - do not block on questions; if assumptions are required, proceed safely and log them in ticket chat
+  - if the plan/AC is missing or clearly stale, stop and send the ticket back to Story Plan instead of guessing
+- Implement the acceptance criteria from the ticket.
+- Implement in small diffs; keep scope tight.
+- Follow `loopflowhq/phases/shared-execution-checklist.md`.
+- If you must make assumptions, document them in the ticket chat and proceed when safe.
+- When the story is implemented:
+  - open a PR (if your workflow uses PRs for Story Review) and post the PR link + a concise change summary in the ticket chat
+  - move the ticket to Story Review: set `phase=review`, `phase_state=ready`

package/loopflowhq/phases/story-plan.md

@@ -1,25 +1,35 @@
 # Ticket Type: Story - Phase: Plan
 
-Goal: decide the smallest safe implementation plan with verification.
+Goal: decide the smallest safe implementation plan (small diffs) with verification, and make the story implementation-ready.
 
 ## Inputs
 
 - LoopFlowHQ ticket ID (pattern: `LOOPF-<number>` / regex: `LOOPF-\\d+`)
-- Final requirements + acceptance criteria
+- Final requirements + constraints
 - System constraints (tech stack, performance, security, rollout)
 
 ## Outputs (minimum)
 
-- Step-by-step plan (small diffs)
-- Verification steps (tests/lint/build/manual steps)
-- Risks and rollback plan (if needed)
-- Plan stored in the ticket description (as a `## Plan` section)
+- Updated ticket title + description:
+  - clear problem statement
+  - explicit scope + non-goals
+- Concrete, testable acceptance criteria
+- Plan stored in the ticket description as a `## Plan` section:
+  - small, atomic, independently committable subtasks
+  - explicit verification steps (tests/lint/build/manual)
+- Risks and rollback notes (if needed)
 
 ## Agent checklist
 
 - Load ticket context (see `loopflowhq/agent.md`).
-- Keep the plan minimal and aligned with current project patterns.
-- Identify where human approval is needed (review gates, product decisions).
-- Prefer “prove it” steps (tests, screenshots, logs) over promises.
-- Do not implement in this phase; produce the plan as the deliverable.
-- Do not change repo files in this phase.
+- This is a human-in-the-loop phase:
+  - ask the minimum clarification questions needed to remove ambiguity
+  - do not implement code in this phase
+- Scan the codebase/docs to confirm whether the work is already partially or fully implemented.
+- Use `loopflowhq/phases/shared-planning-checklist.md`.
+- Ensure the subtask plan covers `loopflowhq/phases/shared-execution-checklist.md`.
+- Keep subtasks small (mergeable on their own).
+- Save the `## Plan` section into the ticket description via `update_ticket`.
+- When the plan is agreed and the ticket is implementation-ready:
+  - set `phase=plan`, `phase_state=done`
+

package/loopflowhq/phases/story-review.md

@@ -1,23 +1,40 @@
 # Ticket Type: Story - Phase: Review
 
-Goal: validate correctness, quality, and alignment with requirements.
+Goal: human review of the implemented PR: validate correctness, quality, and alignment with requirements.
 
 ## Inputs
 
 - LoopFlowHQ ticket ID (pattern: `LOOPF-<number>` / regex: `LOOPF-\\d+`)
-- Implemented changes
+- PR link (required)
+- Deployed preview URL (if available)
+- Implemented changes (code + tests)
 - Acceptance criteria
 
 ## Outputs (minimum)
 
-- Review notes (bugs, risks, missing tests)
-- Decision: approve or request changes
+- Review notes captured in ticket chat (approval or requested changes)
+- One of:
+  - Approved: set `phase=review`, `phase_state=done` and move to Close (`phase=close`, `phase_state=ready`)
+  - Changes requested: set `phase=review`, `phase_state=changes_requested` with an actionable list
 
 ## Agent checklist
 
 - Load ticket context (see `loopflowhq/agent.md`).
-- Prioritize correctness and regressions over style.
-- Ensure acceptance criteria is demonstrably met.
-- If changes are requested, be explicit about what must change and why.
-- If issues are found, fix them and re-review before marking Review done.
-- Post the review notes in the ticket chat (avoid writing `.review/*` files).
+- This is a human-in-the-loop phase:
+  - do not implement code in this phase
+  - ask questions / request clarifications from the human reviewer when needed
+- Review focus:
+  - acceptance criteria is demonstrably met
+  - correctness + regressions + edge cases
+  - tests and coverage for critical paths
+  - UI behavior (states, responsiveness, a11y) when applicable
+- Approval path:
+  - post a concise approval note in ticket chat
+  - set `phase=review`, `phase_state=done`
+  - move to Close (`phase=close`, `phase_state=ready`)
+- Changes requested path:
+  - ask for each comment in enough detail to be actionable (repro steps, expected vs actual, screenshots if relevant)
+  - collect a complete list ("any more?") before switching phases
+  - post a single consolidated list of requested changes in ticket chat
+  - set `phase=review`, `phase_state=changes_requested`
+

package/loopflowhq/phases/task-close.md

@@ -0,0 +1,20 @@
+# Ticket Type: Task - Phase: Close
+
+Goal: ship the task, close the loop, and leave the system clean.
+
+## Inputs
+
+- LoopFlowHQ ticket ID (pattern: `LOOPF-<number>` / regex: `LOOPF-\\d+`)
+- PR link (from Task Implement)
+- Any rollout/release constraints
+
+## Outputs (minimum)
+
+- “What shipped” summary
+- Ship/deploy evidence (merge link, deploy link/logs, or release notes)
+
+## Agent checklist
+
+- Use `loopflowhq/phases/shared-close-checklist.md`.
+- When shipping is complete:
+  - set `phase=close`, `phase_state=done`

package/loopflowhq/phases/task-define.md

@@ -1,11 +1,11 @@
 # Ticket Type: Task - Phase: Define
 
-Goal: turn a vague task into an executable shape (what, why, constraints).
+Goal: turn a vague task into an executable shape (what, why, constraints) and a minimal plan.
 
 ## Inputs
 
 - LoopFlowHQ ticket ID (pattern: `LOOPF-<number>` / regex: `LOOPF-\\d+`)
-- Ticket title (may be vague)
+- Ticket title/description (may be vague)
 - Any context from prior messages
 
 ## Outputs (minimum)
@@ -13,12 +13,20 @@ Goal: turn a vague task into an executable shape (what, why, constraints).
 - Clear problem statement (1-3 sentences)
 - Constraints and non-goals
 - Concrete acceptance criteria (or a proposal to confirm)
+- A minimal `## Plan` section with small, atomic subtasks (when applicable)
 - Define summary captured in the ticket chat (via `post_ticket_message`)
 
 ## Agent checklist
 
 - Load ticket context (see `loopflowhq/agent.md`).
-- Ask clarification questions in this chat, one at a time; wait for answers before asking the next.
-- Ask the minimum questions needed to remove ambiguity.
+- Ask the minimum clarification questions needed to remove ambiguity.
 - Propose acceptance criteria if missing; get confirmation.
 - Identify dependencies/risks early (APIs, migrations, permissions, rollout).
+- Use `loopflowhq/phases/shared-planning-checklist.md` when a plan is needed.
+- Update the ticket title/description/AC and write the `## Plan` section via `update_ticket`.
+- If the task needs explicit execution steps, create/update task subtasks via `update_ticket_subtasks`.
+- Post a concise Define summary via `post_ticket_message`:
+  - what changed in the ticket (title/description/AC)
+  - the plan summary (high level)
+  - key assumptions/risks
+

package/loopflowhq/phases/task-implement.md

@@ -15,9 +15,11 @@ Goal: make the change in code, with tests and minimal risk.
 
 ## Agent checklist
 
+- Load ticket context + start/end phase transitions (see `loopflowhq/agent.md`).
 - Implement the acceptance criteria from the ticket; if unclear or missing, ask before proceeding.
 - Implement in small diffs; keep changes scoped.
 - Write/update tests that cover the acceptance criteria (or document why tests are not feasible).
-- Run the project’s standard checks (lint/typecheck/test/build) when applicable.
+- Run the project's standard checks (lint/typecheck/test/build) when applicable.
 - Call out any behavior changes and migrations.
-- Do not open a PR unless explicitly requested; shipping is handled separately.
+- When the task is complete, move the ticket to Close (`phase=close`, `phase_state=ready`) and summarize in ticket chat.
+

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@loopflowhq/agent-pack",
-  "version": "0.4.0",
+  "version": "0.5.0",
   "private": false,
   "type": "module",
   "bin": {

package/.cursor/commands/lfq01-discovery.md

@@ -1,24 +0,0 @@
-# lfq01-discovery — Discovery step
-
-**Requirement:** Ticket key or URL may be in the command; if omitted, infer from conversation context (see lfq-ticket-workflow.md §1). Ask only if no ticket can be inferred or if multiple tickets are referenced and the intended one is unclear.
-
-**When asking questions:** Use an interactive CLI style — ask one question at a time, wait for the user's answer, then ask the next. This makes it easier to answer.
-
-**Ticket workflow:** For resolve ticket ID, load ticket, and when-done steps (post summary, transition, confirm), follow **lfq-ticket-workflow.md**. This step uses Discovery typed transitions: start with `phase=discovery`, `phase_state=in_progress`, and finish with `phase=discovery`, `phase_state=done` via `update_ticket`.
-
-## Discovery work
-
-- Explore scope and clarify requirements.
-- Analyze codebase and identify ambiguities.
-- Ask clarification questions **here in this chat**, one at a time (interactive CLI style). Wait for each answer before asking the next. Do **not** send questions via LoopFlowHQ MCP — ask the user directly in the conversation.
-  <!-- Optionally post questions/answers to the ticket via `post_ticket_agent_questions` (one at a time) or summarize in `post_ticket_message` when done. -->
-- Document findings for next steps.
-
-## Summary example (for post_ticket_message)
-
-```
-## Discovery done
-- Scope: [brief]
-- Clarifications received: [key points]
-- Open questions / risks: [if any]
-```

package/.cursor/commands/lfq02-planning.md

@@ -1,71 +0,0 @@
-# lfq02-planning — Planning step
-
-**Requirement:** Ticket key or URL may be in the command; if omitted, infer from conversation context (see lfq-ticket-workflow.md §1). Ask only if no ticket can be inferred or if multiple tickets are referenced and the intended one is unclear.
-
-**When asking questions:** Use an interactive CLI style — ask one question at a time, wait for the user's answer, then ask the next. This makes it easier to answer.
-
-**Ticket workflow:** For resolve ticket ID, load ticket and context, and when-done steps, follow **lfq-ticket-workflow.md**. This step uses Planning typed transitions: start with `phase=plan`, `phase_state=in_progress`, finish with `phase=plan`, `phase_state=done` via `update_ticket`. Use prior step summaries (e.g. Discovery done) as context.
-
-**What this step does:** Read the repo and prior context only. Produce a markdown plan and save it in the LFQ ticket (update ticket description with a **Plan** section via `update_ticket` action / REST API). Do **not** change any files in the repo. Documentation steps (ADRs, feature docs) are only TODOs in the plan—they are done in a later step, not in this phase. **Think:** Does this work require updating the `/privacy` page (e.g. new data collection, third-party services, cookies)? If so, add a plan item for it.
-
----
-
-## Plan requirements
-
-- Include clear, minimal, concise steps.
-- **Scope:** Do NOT add extra scope or unnecessary complexity beyond explicitly clarified details.
-- **Step style:** Steps should be modular, elegant, minimal, and integrate seamlessly within the existing codebase.
-
----
-
-## Plan structure (save in LFQ ticket)
-
-Produce a markdown plan with this structure. Preserve any existing ticket description and add or update a clear `## Plan` section with the content below.
-
-**Title**
-After discovery, check the ticket context and adjust the name of the ticket
-
-**## TLDR**
-
-Short summary of what we're building and why.
-
-**## Critical Decisions**
-
-Key architectural/implementation choices made during exploration:
-
-- Decision 1: [choice] - [brief rationale]
-- Decision 2: [choice] - [brief rationale]
-
-**## Documentation**
-
-When the work warrants documentation, add **plan items** (TODOs) for later—do not write docs in this phase:
-
-- **ADRs** (docs-adr): For significant architectural decisions. Plan path: `docs/decisions/NNN-slug.md`.
-- **Feature docs** (docs-feature): For major features with non-obvious implementation. Plan path: `docs/FEATURE_NAME.md`.
-- **Privacy page** (`/privacy`): When the work involves new data collection, third-party services, cookies, or processing of user data, add a plan item to update the privacy page if required.
-
-**## Tasks**
-
-- [ ] 🟥 **Step 1: [Name]**
-  - [ ] 🟥 Subtask 1
-  - [ ] 🟥 Subtask 2
-
-- [ ] 🟥 **Step 2: [Name]**
-  - [ ] 🟥 Subtask 1
-  - [ ] 🟥 Subtask 2
-
-- [ ] 🟥 **Document: [Create ADR for X | Create feature doc for Y]** (when warranted)
-
-...
-
----
-
-Again, it's still not time to build yet. Just write the clear plan document. No extra complexity or extra scope beyond what we discussed. Save it in the LFQ ticket by updating the ticket description with a **Plan** section (do not save to a file, do not change any repo files).
-
-## Summary example (for post_ticket_message)
-
-```
-## Planning done
-- Plan: stored in ticket description (Plan section)
-- Steps: [count]
-```

package/.cursor/commands/lfq03-implementing.md

@@ -1,25 +0,0 @@
-# lfq03-implementing — Implementing step
-
-**Requirement:** Ticket key or URL may be in the command; if omitted, infer from conversation context (see lfq-ticket-workflow.md §1). Ask only if no ticket can be inferred or if multiple tickets are referenced and the intended one is unclear.
-
-**When asking questions:** Use an interactive CLI style — ask one question at a time, wait for the user's answer, then ask the next. This makes it easier to answer.
-
-**Ticket workflow:** For resolve ticket ID, load ticket and context, and when-done steps, follow **lfq-ticket-workflow.md**. This step uses Implementing typed transitions: start with `phase=implement`, `phase_state=in_progress`, finish with `phase=implement`, `phase_state=done` via `update_ticket`. Use prior step summaries (Discovery, Planning) and the plan document (e.g. in `docs/plans/`) as context.
-
-## Implementing work
-
-- Follow `execute.md`: implement precisely as planned.
-- Update the plan document with emoji status as you progress.
-- Adhere to project rules (Design, coding-patterns, UX).
-- **Do not** create a branch, commit, or open a PR in this step.
-
-## When implementation is done
-
-- Post the summary via `post_ticket_message`, then call `update_ticket` with `phase=implement` and `phase_state=done`. Do not run git commit or advance the ticket to the next step.
-
-## Summary example (for post_ticket_message)
-
-```
-## Implementing done
-- Changes: [brief list of files/areas touched]
-```

package/.cursor/commands/lfq04-review.md

@@ -1,85 +0,0 @@
-# lfq04-review — Review step
-
-**Requirement:** Ticket key or URL may be in the command; if omitted, infer from conversation context (see lfq-ticket-workflow.md §1). Ask only if no ticket can be inferred or if multiple tickets are referenced and the intended one is unclear.
-
-**When asking questions:** Use an interactive CLI style — ask one question at a time, wait for the user's answer, then ask the next. This makes it easier to answer.
-
-**Ticket workflow:** For resolve ticket ID, load ticket and context, and when-done steps, follow **lfq-ticket-workflow.md**. This step uses Review typed transitions: start with `phase=review`, `phase_state=in_progress`, finish with `phase=review`, `phase_state=done` via `update_ticket`. Use prior step summaries (Implementing done) as context.
-
----
-
-## 1. Perform code review
-
-Follow the same checks and output structure as **review.md**:
-
-**Check for:**
-
-- **Logging** — No console.log, use proper logger with context
-- **Error handling** — Try-catch for async, centralized handlers, helpful messages
-- **TypeScript** — No `any`, proper interfaces, no @ts-ignore
-- **Production readiness** — No debug statements, no TODOs, no hardcoded secrets
-- **React/Hooks** — Effects have cleanup, dependencies complete, no infinite loops
-- **Performance** — No unnecessary re-renders, expensive calcs memoized
-- **Security** — Auth checked, inputs validated, RLS in place
-- **Architecture** — Follows existing patterns, code in correct directory
-
-**Severity levels:** CRITICAL (security, data loss, crashes), HIGH (bugs, performance, bad UX), MEDIUM (code quality, maintainability), LOW (style, minor).
-
----
-
-## 2. Fix all issues, then re-review
-
-- If **any issues** are found (Critical, High, Medium, or Low):
-  1. **Fix every issue** (apply suggested fixes or equivalent).
-  2. **Re-run the review** on the changed code until there are no remaining issues, or you explicitly document why a finding is not fixed (e.g. deferred, out of scope).
-- Only after all issues are fixed or documented do you post the review and mark the step done.
-
----
-
-## 3. Store review in ticket chat (no .review files)
-
-- **Do not** write the review to `.review/<ticket-key>.md` or any file under `.review/`.
-- Post the **full review** as a single ticket message using **`post_ticket_message`** so the review lives in the ticket chat.
-
-**Message content format** (use this exact structure in the posted message):
-
-```markdown
-## Code review
-
-### ✅ Looks Good
-
-- [Item 1]
-- [Item 2]
-
-### ⚠️ Issues Found
-
-- **[Severity]** [File:line] - [Issue description]
-  - Fix: [Suggested fix]
-    (If none: "None.")
-
-### 📊 Summary
-
-- Files reviewed: X
-- Critical issues: 0 (after fixes)
-- Warnings: 0 (after fixes)
-
-**Outcome:** Passed. [One line: e.g. "Changes are minimal and follow existing patterns." / "All issues fixed and re-verified."]
-```
-
-Then add the step-done line:
-
-```markdown
-## Review done
-
-- Outcome: [passed / issues fixed and re-verified]
-- Critical issues: 0
-```
-
-(You may combine the "Code review" and "Review done" blocks into one `post_ticket_message` call.)
-
----
-
-## 4. Mark step done
-
-- Call **`update_ticket`** with `ticket`, `phase`: `review`, `phase_state`: `done` (legacy `status` should stay compatible).
-- Confirm to the user that the review step is complete and the ticket is ready for the next step (e.g. testing).

package/.cursor/commands/lfq05-testing.md

@@ -1,55 +0,0 @@
-# lfq05-testing — Testing step
-
-**Requirement:** Ticket key or URL may be in the command; if omitted, infer from conversation context (see lfq-ticket-workflow.md §1). Ask only if no ticket can be inferred or if multiple tickets are referenced and the intended one is unclear.
-
-**When asking questions:** Use an interactive CLI style — ask one question at a time, wait for the user's answer, then ask the next. This makes it easier to answer.
-
-**Ticket workflow:** For resolve ticket ID, load ticket and context, and when-done steps, follow **lfq-ticket-workflow.md**. This step validates release readiness and keeps ticket in close-stage execution (`phase=close`, typically `phase_state=in_progress`). Use prior step summaries (Implementing, Review) as context.
-
-**Do not:** Create a PR or push commits in this step. Commit, push, and PR creation belong to the Shipping step (lfq06-shipping).
-
-## Understand ticket and acceptance criteria
-
-1. **Ticket description** — Read and understand the full ticket description. Ensure you know what the ticket is asking for.
-2. **Acceptance criteria** — If the ticket has acceptance criteria (e.g. in the description or as a list), treat them as the source of truth for "done."
-3. **Validate implementation** — Go through each acceptance criterion and confirm it is implemented in code or behavior. If any are missing, implement or fix before considering testing complete.
-4. **Validate docs** — If the change affects architecture, behavior, or features, ensure the appropriate docs are updated (e.g. ADRs in `docs/adr/`, feature docs in `docs/`, READMEs). Documentation should match the current implementation.
-
-## Testing work
-
-1. **Clean debug code** — Before running the linter, remove all debug code:
-   - Remove all `console.log` statements (except browser `console.log` relevant to users in production)
-   - Remove any debug logs calling `127.0.0.1` or `localhost`
-   - Clean up any temporary debug code
-
-2. **Run linter** — Execute `npm run lint` to check code quality and catch any linting issues in **all projects** in `apps/` (e.g. webapp and website).
-
-3. **Test build** — Run `npm run build` to ensure **all projects** build successfully without errors.
-
-4. **Run tests** — Execute `npm run test` to run all test suites in **all projects** and ensure everything passes.
-
-5. **Manual verification** — If applicable, run the dev server and smoke-test the change (e.g. key flows, UI, or APIs).
-
-6. **Address issues** — Fix any failures or issues found during lint, build, tests, or manual verification.
-
-## Checklist
-
-- [ ] Ticket description understood; acceptance criteria (if any) identified
-- [ ] All acceptance criteria validated as implemented
-- [ ] Appropriate docs updated (ADRs, feature docs in `docs/`, etc.) and match implementation
-- [ ] Debug code cleaned up (console.log, 127.0.0.1 calls, etc.)
-- [ ] Linter passes with no errors for **all projects** in `apps/`
-- [ ] Build completes successfully for **all projects** in `apps/`
-- [ ] All tests pass for **all projects** in `apps/`
-- [ ] Manual verification done if applicable
-
-## Summary example (for post_ticket_message)
-
-```
-## Testing done
-- Ticket/AC: [brief note that description and acceptance criteria were checked and met]
-- Docs: [updated / N/A]
-- Tests: passing
-- Build: passing
-- Notes: [any manual verification]
-```

package/.cursor/commands/lfq06-shipping.md

@@ -1,61 +0,0 @@
-# lfq06-shipping — Shipping step
-
-**Requirement:** Ticket key or URL may be in the command; if omitted, infer from conversation context (see lfq-ticket-workflow.md §1). Ask only if no ticket can be inferred or if multiple tickets are referenced and the intended one is unclear.
-
-**When asking questions:** Use an interactive CLI style — ask one question at a time, wait for the user's answer, then ask the next. This makes it easier to answer.
-
-**Ticket workflow:** For resolve ticket ID, load ticket and context, and when-done steps, follow **lfq-ticket-workflow.md**. This step executes close/shipping work: keep `phase=close`, move from `phase_state=in_progress` to `phase_state=done` when shipping is complete. Use prior step summaries (PR link, branch) as context.
-
-## 1. Ensure we are not on main with uncommitted changes
-
-If `git branch --show-current` is `main` **and** `git status --porcelain` is non-empty:
-
-1. **Derive branch name from uncommitted files** (see create-branch.md as inspiration):
-   - Run `git status --porcelain` to inspect changed files
-   - Infer type from paths: `docs/` → docs, `*.test.*` or `__tests__/` → test, config files → chore, `.github/` → ci, CSS → style, bug-fix cues → fix, new components/features → feat, refactors → refactor, perf cues → perf
-   - Suggest branch name: `<type>/short-description` (e.g. `feat/LOOPF-30-substate-icons`). Ask user if unclear
-2. **Move uncommitted changes onto a new branch** (same flow as create-branch.md):
-   - `git stash push -u -m "cursor-ship"`
-   - `git fetch origin main` && `git pull origin main`
-   - `git checkout -b <branch-name>`
-   - `git stash pop`
-
-If already on a feature branch with uncommitted changes, skip to step 2. If on main with no changes and no existing PR, ask the user what to ship.
-
-## 2. Commit and push
-
-- Stage changes: `git add .` (or stage selectively)
-- **Commit message:** Follow Conventional Commits (commitlint / husky). Format: `type(scope): subject` with optional body bullets. Types: `feat`, `fix`, `chore`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `revert`. Scope: `web`, `api`, `mcp`, `deps`, `ci`, `docs`. Subject: imperative, lowercase.
-- Commit: `git commit -m "..."` (use `-F` with temp file if multi-line)
-- Push: `git push -u origin <branch>`
-
-## 3. Prepare a PR
-
-- Create PR targeting `main`
-- **PR title:** Use same Conventional Commits format as the commit (e.g. `feat(web): add substate icons`) — release-please parses PR titles and merge commits for changelog
-- **PR body:** Reference ticket(s), e.g. `Closes LOOPF-30` or `Related to LOOPF-30`
-- Do **not** merge the PR unless the user explicitly asks to merge
-
-### PR title gating (required)
-
-- **Husky only checks local commit messages**, not PR titles.
-- Add a PR title check in CI so merges are blocked unless the title is Conventional Commits:
-  - Recommended: use `amannn/action-semantic-pull-request` in `.github/workflows/pr-title.yml` and require it in branch protection.
-  - If a PR title fails, fix the title before merge so the merge commit is parseable by release-please.
-
-## 4. Post-PR shipping work (when PR exists)
-
-- Merge the PR to `main` **only if the user explicitly requests it**
-
-## 5. Mark tickets done
-
-When shipping work is complete (PR created and, if requested, merged): call `update_ticket` with `phase=close`, `phase_state=done` (and compatible legacy `status`). Post summary via `post_ticket_message`.
-
-## Summary example (for post_ticket_message)
-
-```
-## Shipping done
-- Branch: [branch name]
-- PR: [PR link]
-- Merged: [yes/no, PR link if merged]
-```

package/.cursor/commands/lfq07-learning.md

@@ -1,22 +0,0 @@
-# lfq07-learning — Learning step
-
-**Requirement:** Ticket key or URL may be in the command; if omitted, infer from conversation context (see lfq-ticket-workflow.md §1). Ask only if no ticket can be inferred or if multiple tickets are referenced and the intended one is unclear.
-
-**When asking questions:** Use an interactive CLI style — ask one question at a time, wait for the user's answer, then ask the next. This makes it easier to answer.
-
-**Ticket workflow:** For resolve ticket ID, load ticket and context, and when-done steps, follow **lfq-ticket-workflow.md**. This step is a post-delivery analysis step; it usually does not require a phase change and should keep typed workflow coherent for the ticket type. Use prior step summaries (what was shipped, outcomes) as context.
-
-## Learning work
-
-- Reflect on what was delivered: outcomes, metrics, user feedback if available.
-- Document lessons learned, surprises, or improvements for next time.
-- Identify any adjustments to process or scope.
-
-## Summary example (for post_ticket_message)
-
-```
-## Learning done
-- Outcomes: [what we observed]
-- Lessons: [key takeaways]
-- Adjustments: [if any]
-```

package/.cursor/commands/lfq08-adjusting.md

@@ -1,22 +0,0 @@
-# lfq08-adjusting — Adjusting step
-
-**Requirement:** Ticket key or URL may be in the command; if omitted, infer from conversation context (see lfq-ticket-workflow.md §1). Ask only if no ticket can be inferred or if multiple tickets are referenced and the intended one is unclear.
-
-**When asking questions:** Use an interactive CLI style — ask one question at a time, wait for the user's answer, then ask the next. This makes it easier to answer.
-
-**Ticket workflow:** For resolve ticket ID, load ticket and context, and when-done steps, follow **lfq-ticket-workflow.md**. This step applies post-delivery adjustments (often via followup tickets) and should keep typed workflow coherent with the ticket type. Use prior step summaries (Learning done, lessons) as context.
-
-## Adjusting work
-
-- Based on Learning outcomes: apply process or scope adjustments.
-- Create follow-up tickets if needed.
-- Update documentation or runbooks.
-- Decide if ticket can move to Done.
-
-## Summary example (for post_ticket_message)
-
-```
-## Adjusting done
-- Adjustments: [what was done]
-- Follow-ups: [ticket keys if any]
-```