luckiest-co 1.0.0 → 1.0.3

package/commands/luckiest/go.md

@@ -1,45 +0,0 @@
----
-description: Run your plan, one task at a time, checked as it goes.
----
-
-Read `references/vocabulary.md` first and follow it for all output in this command: plain language, no em dashes, no internal terms, one next-step recommendation at the end.
-
-## Step 1: Load the plan
-
-Call the `status` tool from the luckiest MCP server. This is a zero-context resume, treat its result as the full picture of where things stand: don't assume anything about prior state beyond what it returns.
-
-## Step 2: Execute in-session
-
-Do all task work yourself, in this session, message by message.
-
-- Forbidden: spawning subagents to execute tasks. Never hand off the actual work of a ready task to a subagent.
-- Allowed: spawning subagents for research only (for example, looking something up, exploring the codebase for context). The work itself, writing code, making changes, running commands, stays in this session.
-
-## Step 3: Work through ready tasks, one at a time
-
-Take the ready tasks one at a time, in order. For each one:
-
-1. Do the work using the task's suggested skill. If that skill is installed, invoke it via the Skill tool. If it isn't installed, do the work directly without it.
-2. Check your result against the task's "done means..." line. Don't move on until it's actually met.
-3. If the result is something the user can try themselves (a page, a feature, a flow), ask exactly this: "Try it yourself, does it work? yes / needs fixes." Wait for their answer.
-4. On a pass, call the `apply` tool with `{ taskId }` for that task, then call the `verify` tool with `{ results: [{ taskId, pass: true }] }`.
-5. On a fail, fix the problem before moving on to the next task. Only call `verify` with `pass: false` for that task if the user explicitly chooses to defer the fix instead of having you fix it now.
-
-Only move to the next ready task once the current one is applied and verified (or deferred).
-
-## Step 4: Stop conditions
-
-Pause and ask the user before doing any of the following, even if it seems like the obvious next step:
-
-- Any destructive action (deleting data, dropping tables, force-pushing, overwriting files with no way back).
-- Adding a new dependency.
-- Any schema change.
-
-If the session has to end before the plan is done, call the `pause` tool with `{ reason }`, a one-line reason describing where things were left.
-
-## Step 5: Wrap up
-
-End your response with exactly one line, nothing after it.
-
-- If all tasks are done: `Next: /luckiest finish to wrap up.`
-- Otherwise: `Next: <the next task title>.`

package/commands/luckiest/plan.md

@@ -1,55 +0,0 @@
----
-description: Plan your next piece of work. Guided questions, then a plan Claude can run.
----
-
-Read `references/vocabulary.md` first and follow it for all output in this command: plain language, no em dashes, no internal terms, one next-step recommendation at the end.
-
-## Step 1: Gather context
-
-Check whether `.luckiest/BRIEF.md` exists in the current project. If it exists, read it and use it as context for the interview below (what they're building, who it's for, what winning looks like). If it does not exist, continue without it.
-
-## Step 2: Check for active work
-
-Call the `status` tool from the luckiest MCP server.
-
-- If the returned state's position is active (already in progress), stop here. Tell the user a plan is already active and offer `/luckiest go` to resume it instead. Do not stage a new plan over an active one unless the user explicitly confirms they want to replace it. If they confirm, continue to Step 3.
-- Otherwise, continue to Step 3.
-
-## Step 3: Run the interview
-
-Ask ONE question at a time, waiting for the answer before asking the next:
-
-1. What outcome do you want this week?
-
-Use the answer (plus the brief, if present) to shape a draft task list of 3 to 7 tasks. Each task title must be a single clean line under 200 characters, describing one piece of work. Do not append "done means" text or any acceptance-criteria text to the title.
-
-For each draft task, call the `skill_router` tool from the luckiest MCP server to suggest a matching owned skill for that task. Attach the suggested skill(s) to the task.
-
-For each task, state a one-line "done means..." in chat (not in the title, not stored anywhere) so the user sees what complete looks like for that task.
-
-## Step 4: Present the plan
-
-Show the full draft plan: each task's title, its suggested skill(s), and its "done means..." line. Then ask exactly one approval question, nothing else:
-
-"Here's your plan, good to go?"
-
-Wait for the answer.
-
-- If the user wants changes, revise the plan and ask the same approval question again.
-- If the user says yes, continue to Step 5.
-
-## Step 5: Stage the plan
-
-Call the `plan` tool from the luckiest MCP server with:
-
-```
-{ phase: <short phase name if any>, tasks: [{ title, skills }] }
-```
-
-Include at most 25 tasks. Each title must stay under 200 characters. Do not include acceptance criteria or "done means" text in any task field.
-
-## Step 6: Wrap up
-
-End your response with exactly one line, nothing after it:
-
-Next: /luckiest go to start.