@loopflowhq/agent-pack 0.3.0 → 0.5.0

package/loopflowhq/phases/story-implement.md

@@ -0,0 +1,33 @@
+# Ticket Type: Story - Phase: Implement
+
+Goal: make the change in code, with tests and minimal risk.
+
+## Inputs
+
+- LoopFlowHQ ticket ID (pattern: `LOOPF-<number>` / regex: `LOOPF-\\d+`)
+- Approved plan
+- Ticket subtasks (if present)
+
+## Outputs (minimum)
+
+- Code changes
+- 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
+
+- 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

@@ -0,0 +1,35 @@
+# Ticket Type: Story - Phase: Plan
+
+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 + constraints
+- System constraints (tech stack, performance, security, rollout)
+
+## Outputs (minimum)
+
+- 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`).
+- 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

@@ -0,0 +1,40 @@
+# Ticket Type: Story - Phase: Review
+
+Goal: human review of the implemented PR: validate correctness, quality, and alignment with requirements.
+
+## Inputs
+
+- LoopFlowHQ ticket ID (pattern: `LOOPF-<number>` / regex: `LOOPF-\\d+`)
+- PR link (required)
+- Deployed preview URL (if available)
+- Implemented changes (code + tests)
+- Acceptance criteria
+
+## Outputs (minimum)
+
+- 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`).
+- 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

@@ -0,0 +1,32 @@
+# Ticket Type: Task - Phase: Define
+
+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/description (may be vague)
+- Any context from prior messages
+
+## Outputs (minimum)
+
+- 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 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

@@ -0,0 +1,25 @@
+# Ticket Type: Task - Phase: Implement
+
+Goal: make the change in code, with tests and minimal risk.
+
+## Inputs
+
+- LoopFlowHQ ticket ID (pattern: `LOOPF-<number>` / regex: `LOOPF-\\d+`)
+- Defined scope + acceptance criteria (from Define phase or ticket)
+
+## Outputs (minimum)
+
+- Code changes
+- Tests (or explicit justification if not added)
+- Verification evidence (commands run, expected outputs)
+
+## 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.
+- Call out any behavior changes and migrations.
+- 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.3.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]
-```

package/loopflowhq/phases/close.md

@@ -1,21 +0,0 @@
-# Phase: Close
-
-Goal: finish the loop: ship, document, and leave the system clean.
-
-## Inputs
-
-- Approved outcome (or explicit cancellation reason)
-- Any rollout/release constraints
-
-## Outputs (minimum)
-
-- “What shipped” summary
-- Verification steps (and results)
-- Followups created if needed
-
-## Agent checklist
-
-- 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.
-

package/loopflowhq/phases/define.md

@@ -1,21 +0,0 @@
-# Phase: Define
-
-Goal: turn a vague task into an executable shape (what, why, constraints).
-
-## Inputs
-
-- Ticket title (may be vague)
-- Any context from prior messages
-
-## Outputs (minimum)
-
-- Clear problem statement (1-3 sentences)
-- Constraints and non-goals
-- Concrete acceptance criteria (or a proposal to confirm)
-
-## Agent checklist
-
-- Ask the minimum questions needed to remove ambiguity.
-- Propose acceptance criteria if missing; get confirmation.
-- Identify dependencies/risks early (APIs, migrations, permissions, rollout).
-

package/loopflowhq/phases/implement.md

@@ -1,21 +0,0 @@
-# Phase: Implement
-
-Goal: make the change in code, with tests and minimal risk.
-
-## Inputs
-
-- Approved plan
-- Acceptance criteria
-
-## Outputs (minimum)
-
-- Code changes
-- Tests (or explicit justification if not added)
-- Verification evidence (commands run, expected outputs)
-
-## Agent checklist
-
-- Implement in small diffs; keep changes scoped.
-- Run the project’s standard checks (lint/typecheck/test/build) when applicable.
-- Call out any behavior changes and migrations.
-

package/loopflowhq/phases/review.md

@@ -1,20 +0,0 @@
-# Phase: Review
-
-Goal: validate correctness, quality, and alignment with requirements.
-
-## Inputs
-
-- Implemented changes
-- Acceptance criteria
-
-## Outputs (minimum)
-
-- Review notes (bugs, risks, missing tests)
-- Decision: approve or request changes
-
-## Agent checklist
-
-- Prioritize correctness and regressions over style.
-- Ensure acceptance criteria is demonstrably met.
-- If changes are requested, be explicit about what must change and why.
-