Set goals

One small file, GOALS.md, holds one 6 week goal. This skill writes it, renews it when the cycle ends, and closes the old cycle in a few lines. The point is a plan that never goes stale silently, not a planning ritual.

The file format is fixed. Setup writes it from templates/goals.md in the setup skill and session end reads it, so keep exactly these headings:

# Goals

## Current cycle: <YYYY-MM-DD> to <YYYY-MM-DD>

**Goal:** <one sentence, with the end date>.

**The one number:** <what shows it is working, and its target>.

**Must dos:**

- [ ] <must do>

**Not this cycle:** <what you are deliberately not doing>.

**Gate to the next stage:** <what has to be true before moving on>.

## Past cycles

Closed cycles move here, newest first, each with a few lines on what happened.

Rules

• One question at a time, each with a default, so "yes" or a few words is enough. Same style as setup.
• Read before asking. Read GOALS.md, CURRENT_WORK.md, the rules file and app.json first. Only ask what they do not answer.
• Never nag. Do not raise goals unless the user asked or invoked this skill. If they are behind, say it once, plainly, then help.
• Never mark anything done without the user confirming it.
• Never overwrite GOALS.md without showing the change and getting a yes.
• Dates in YYYY-MM-DD. A cycle is 6 weeks: the end date is the start plus 42 days.
• Plain words. No long dashes in anything you write into the file.

1. Find out where things stand

Read GOALS.md and pick one case:

2. Close the cycle

1. Run git log --since=<cycle start> --oneline and read CURRENT_WORK.md.
2. Ask once, in one block, about work that leaves no commit: store approvals or rejections, testers who actually opted in, account or payment setup, people talked to, the one number's current value. Offer "nothing else" as the default.

3. Draft the closing lines yourself from the commits and the answers. A few lines, no more:

   ### <start> to <end>: <the goal, short>
   
   Met / partly met / not met. The one number: <target>, ended at <actual or "not measured">.
   Done: <must dos finished, in plain words>. Dropped: <open must dos, one reason each>.
   Learned: <one line worth carrying into the next cycle>.

4. Show the draft and ask "Anything to change?" Default: keep it.
5. Move it under Past cycles, below the intro line and above older entries (newest first). Never rewrite or delete older past cycles.

Describe what a person can now do with the app, not code names. "Purchases work on a real phone" beats "fixed the purchase hook".

3. Set the next cycle

Work out the stage from the last gate, the closed cycle and the project state, then confirm it in one line: "Looks like you are at into the stores. Right?" Stages and their default goals are in references/stages.md. If the last gate was not met, the default is to stay on the same stage with a smaller goal, not to move on.

Then ask, one at a time, each with the stage default filled in for this app:

1. The goal. One sentence with the end date. Offer the default, edited to fit the app's own loop.
2. The one number. What shows it works, with a target. One number, not a dashboard. If it cannot be measured yet, measuring it becomes a must do.
3. Must dos. 3 to 5, each small enough to tick. Default: the stage's list plus any dropped must do from the closed cycle that still matters. Order them so the last one is the first to cut on a bad week, and say so.
4. Not this cycle. The things they will be tempted by. Default: the stage's anti goals plus anything from the backlog that looks shiny. Remind them that new ideas go to the backlog, not into this cycle.
5. Gate to the next stage. Default from the stage.

Before writing, check for things that run on the calendar rather than on effort: store review times, tester periods, account verification, a name that blocks the listing. If one applies, the must do that starts that clock goes first. Check the current official rule before stating a store requirement; do not quote numbers from memory.

Write the new Current cycle section, show the whole file change, and write it on a yes. Offer to commit GOALS.md alone.

4. Mid cycle: what to focus on

Do not rewrite anything. Read the current cycle and recent commits, then answer in a few lines:

• Days left, must dos ticked and open.
• The one open must do to do next, and why (calendar clocks first, then whatever unblocks the gate).
• One plain line if they are behind, naming which must do to cut, using the order set in step 3.

If the user wants to change the goal mid cycle, edit the current cycle in place and add one line under it: Changed on <date>: <why>. Changing a goal on purpose is fine. Letting it drift silently is the failure this skill exists to stop.

Finish

One short summary: the cycle closed (one line), the new goal and end date, the first must do. Session end ticks must dos from here on and gives one reminder when the cycle ends; nothing else will chase the user.