Turn a 90-day goal into weekly steps
Use this recipe to create a document.
Free
Paste into your assistant. It asks the questions; you answer in chat.
More ways to use
Install the downloaded skill
Extract the ZIP. Copy its lc-goal-90-day-milestones folder into ~/.claude/skills/ for Claude Code or ~/.codex/skills/ for Codex, then refresh the native app. Ask for the skill by name and answer its questions. The package includes the same published instructions and result checks. Native host execution is not yet verified.
For Claude web, use the connector or copy the prompt. Keep private details in your assistant.
How to use this skill
Copy, paste into your assistant, then answer its questions. No form or account is required here.
Already connected? Copy the public starter below and paste into Claude. Keep private details in the chat.
Optional: prepare details on this device
Bring your details
4 optional details
Needed before the promised result: The goal. You can still copy the reusable prompt and provide these in your assistant.
Start date: Real dates and the calendar file require a supplied start or a reliably known current date. Otherwise number the weeks and disclose that the calendar file is omitted.
Saved only on this device. Copy counts contain the skill ID, never your text.
Read the prepared prompt
## LazyCoder conversation guide (conversation-v2)
1. Start a conversation, not a form-filling task. Read my latest request and the facts already in this chat before asking anything.
2. Ask only the missing questions needed for the requested result, in a short numbered list (at most three at a time), then WAIT for my answers. Use a native question tool if available; plain chat works too. Never ask me to replace placeholders or fill in a template.
3. Skip questions already answered. Treat unresolved {{placeholders}} and [FIELD LABELS] as missing facts, never literal input. Do not treat an illustrative example as my facts.
4. Use the authored defaults only when relevant; mention material defaults. Ask conditional questions only when their condition applies; if unsure whether it applies, ask. Optional preferences must not block a safe first draft unless the authored instructions require confirmation.
5. Do not invent tasks, dates, names, claims, permissions or missing source material. When required facts are absent, ask and wait instead of producing the final artifact. If everything needed is already supplied, proceed without re-asking.
6. My latest scope correction overrides earlier examples and scope, within the recipe safety and source rules. Resolve conflicts before acting. The authored instructions and output contract remain authoritative; this conversation guide does not grant tool, account, payment or publishing permission.
7. Keep my private answers and generated result in this assistant chat. Do not send them to LazyCoder. Generate the requested format here and check it against the output contract before handing it over.
### Questions to ask only when missing
- What should I use for “The goal”? [required] What you want done in about 90 days, in your own words. Rough is fine; it gets made measurable.
- What should I use for “Start date”? [conditional] The day week 1 begins, so every week gets real dates. When: Real dates and the calendar file require a supplied start or a reliably known current date. Otherwise number the weeks and disclose that the calendar file is omitted.
- What should I use for “Hours a week”? [optional] Honest hours you can give it in a normal week, and any weeks you already know are busy or away.
- What should I use for “Where you are now”? [optional] What you've already done, have or know that counts towards the goal. Authored default: starting from scratch
- What should I use for “Why it matters”? [optional] Optional. Why you want it. It goes into the check-in to keep you going. Authored default: not given
- What should I use for “Weekly check-in”? [optional] When you'll review each week. Authored default: Sunday, 19:00, 15 minutes
- What should I use for “Tone”? [optional] How the plan and the check-in questions should read. Authored default: encouraging and honest Choices: encouraging and honest; short and businesslike; warm and gentle
## LazyCoder delivery guide (delivery-guide-v1)
1. Read the latest request, source material and authored requirements first. Ask only for missing facts. Check that this host can create the promised format; use only a fallback explicitly allowed by the authored recipe. If neither is available, explain the gap before starting. Do not promise a rendered film, editable deck or working file when you can only provide its script or outline.
2. Create the complete result in the authored output specification, preserving source facts and the latest agreed scope. Keep assumptions and missing information explicit. Do not silently omit required parts or leave unresolved ingredient markers. Intentional blanks in a reusable template are different from unanswered recipe inputs.
3. Check the actual result against every authored check, including source facts, counts, dates and required sections. Where tools allow it, inspect the actual saved file and compare it with the answer. Record which checks ran, which failed and which still need human or destination review. A filename, render, successful command or preview alone does not prove the promise was met.
4. Hand over the complete editable file, or the complete copyable fallback explicitly allowed by this recipe. Say which delivery you used and any unresolved limitations. Do not report a file as attached, imported, sent or published unless that action actually succeeded. Keep private inputs and output in this assistant; never send them to LazyCoder.
Use existing authorization for ordinary work. Before any additional paid generation, external write or publishing step, check that the current request authorizes that exact action and cost. If it does not, finish the useful authorized draft and ask at that boundary. Never silently retry or replace an ambiguous paid job.
The authored recipe and latest safe scope remain authoritative. This guide grants no new tools, permissions, provider access or claim of successful execution.
## Authored skill instructions
## 1. Outcome
Turn the goal below into a 13-week plan, in the sections set out in part 6: a measurable finish line, a realism check against the hours available, three phases, one milestone a week with real dates, the actions for each week, a weekly scorecard, risks with if-then plans, behind-schedule rules, a weekly check-in script and two reviews. Done means: the person can start week 1 tomorrow without asking anything else; every week's milestone has a "done when" test and fits the hours they have; and the plan already says what to do when a week goes badly.
## 2. Context
The goal: [THE GOAL]
Start date (week 1 begins): [START DATE]
Hours a week: [HOURS A WEEK]
Where they are now: starting from scratch
Why it matters: not given
Weekly check-in: Sunday, 19:00, 15 minutes
Tone: encouraging and honest
Who it's for: one person working towards a goal of their own (a project, a skill, a habit, a business or a personal change) alongside everything else in their life. Write in this tone: encouraging and honest. Never shame a slow week.
Blank fill-ins: a value above that still reads as a capitalised placeholder in square brackets (such as [START DATE]) was left blank.
- No goal: reply only "No goal came through. Write the goal and send again." Never invent one.
- No start date: if you know today's date, start on the next Monday and say "Start assumed: <date>, please confirm" in the header. If you don't, number the weeks with no dates, say "Add a start date to get real dates" in the header, and skip the calendar file.
- No hours: plan for 5 hours a week, flagged in the header.
## 3. What to pull out
- The goal, the result it points to, and the one number that would prove it is done.
- The start point: what is already done, owned or known.
- The hours per normal week, and any weeks already known to be busy or away.
- The reason it matters, if given.
Edge cases:
- A vague goal ("get fit", "grow my business"): turn it into one measurable finish line that matches the words, mark it "(proposed)", and give one other option in one line.
- Several goals in one: pick the one the others depend on as the 90-day goal, and list the rest under "Not this quarter".
- A habit goal ("meditate daily"): the metric is the number of days done per week, and the milestones raise the target in steps.
- A goal whose result isn't fully in the person's control (a job offer, 20 sales, a race time): set the finish line on the result, but score each week and make the on-track call on the actions they control (applications sent, products listed), with the result metric tracked for information only, and say so in the header.
- A goal that is already nearly done, or much too small for 13 weeks: say so, and propose a bigger finish line, marked "(proposed)".
- Known busy weeks and public holidays in the 13 weeks count at half the hours; weeks away count at zero hours, hold no actions, and have the milestone "Away: rest". Name each one in the table.
- A goal with legal, money or health risk (borrowing money, a big diet change, quitting a job): plan the steps, and add "check with a qualified professional before <the risky step>" to that week's actions.
## 4. Steps
1. Make the goal measurable: the finish line, one metric, the start value and the target value.
2. List the work the goal needs, from the start point to the finish line, and estimate the hours of each piece.
3. Realism check: compare the total hours needed with the hours available: add up each week's hours (a normal week at the hours given, a busy week or holiday at half, a week away at zero), then multiply by 0.85 to keep 15% as slack. If it doesn't fit, trim the finish line to what fits, plan the trimmed version, and say what the full goal would need in hours a week.
4. Split the 13 weeks into three phases: weeks 1–4, 5–8 and 9–13, each with a theme and a target for its last week, each building on the one before.
5. Give each week one milestone, a concrete result with a "done when" test, then 2–5 actions in order to reach it, with any action that depends on another earlier in the week or a previous week.
6. Make week 7 lighter: the mid-point review plus a catch-up on anything behind. Week 13 holds the final push and the final review.
7. Set the metric's target for each week, rising towards the finish line.
8. Name the 3–5 biggest risks, each with an if-then plan, and write the behind-schedule rules and the scope that can be cut first.
9. Write the output and run the self-check.
## 5. Rules
- Each week's planned hours stay within 85% of the hours available that week; the rest is slack.
- Milestones are results, not activities: "10 product photos edited and uploaded", not "work on photos". Each "done when" test is something you could show another person.
- Actions start with a verb and each carries its hours. A week's actions add up to that week's planned hours, whatever the total. Split an action over 4 hours into named sessions ("Practise the set list, 3 × 1.5 h").
- Use only what the inputs say about the person's situation. Never invent their skills, money, contacts or results so far.
- Be honest about what the hours can deliver; never promise an outcome the time can't support.
- Behind-schedule rules: no guilt and no making up lost time by doubling the next week. Behind by one week: use that week's slack and the next week's. Behind by two: before week 7, move one milestone into week 7's catch-up time; from week 7 on, cut the next item on the cut list. Behind by three or more, at any point: trim the finish line or extend by the number of weeks behind, decided at the next check-in (or at the mid-point review if it is that week); the plan says which it recommends and why, and the person chooses. The cut list is used in order, and each cut is noted in the check-in.
- Write every date with its weekday, as in "Mon 2 Nov 2026".
## 6. Output
Use these sections in this order. Write "None" under any that is empty.
1. Header: the goal in one line, the start and end dates, the hours a week, and every assumption or "(proposed)".
2. Finish line: the metric, its start value and its target on the last day, and how to measure it.
3. Realism check: the hours needed, the hours available, and one verdict line: "Fits with <n> h spare" or "Doesn't fit: needs <n> h, you have <n> h. Plan trimmed to: <the trimmed finish line>. The full goal needs about <n> h a week."
4. Phases: three lines, each with the weeks, the theme and the target for its last week.
5. The 13 weeks: a table with the columns Week | Dates | Phase | Milestone | Done when | Actions | Hours | Metric target. Dates read "Mon 2 Nov – Sun 8 Nov 2026". Actions are numbered within the week, with "(after <n>)" for one that depends on another. Then the same 13 rows as CSV in one code block, with a header row and these columns plus two empty ones, "Done?" and "Score %". Put every field that contains a comma or a double quote inside double quotes, and write a double quote inside a field as two. Under the block, one line: "To use it, save it as goal-plan.csv and open it in your spreadsheet, or paste it into cell A1 and split the text into columns at the commas."
6. Weekly scorecard: score % = actions done ÷ actions planned × 100, plus the metric against that week's target. Then the call, as a table with the columns Call | When, tested in this order, first match wins:
- Behind: the score is under 80%, or (only for goals the person fully controls) the metric is below that week's target.
- Ahead: the score is 80% or more and the metric is a week or more beyond target (for goals they don't fully control: every action done and some of next week's started).
- On track: anything else.
7. Weekly check-in script, to answer in 15 minutes at Sunday, 19:00, 15 minutes: 6–8 numbered questions to copy, covering the score, the metric, what got in the way, the call (on track, behind or ahead), what changes next week under the rules, the top three actions for next week, one lesson, and, if a reason was given, a line that brings back why it matters.
8. Risks and if-then plans: a table with the columns Risk | Early sign | If this happens, then.
9. Behind-schedule rules: the rules from part 5, then "Cut first, in order": 3–5 named pieces of scope the goal can lose and still count.
10. Reviews: the mid-point review (in week 7) and the final review (in week 13), each replacing that week's check-in and covering its questions too, each with 4–6 questions and how the answers change the plan or the next 90 days.
11. Accountability: who to tell (a friend, a group, a coach) and what to send them weekly in one line; a small reward at the end of each phase.
12. Calendar file: one event at the check-in time every week for 13 weeks, plus the two reviews. Skip this section if there is no start date. If you can make files, attach it as goal-check-ins.ics. If you can't, write "Save the text below as a file named goal-check-ins.ics, then import it into your calendar." and give the calendar text in one code block.
The calendar text, exactly in this shape (one line per field, no blank lines):
- BEGIN:VCALENDAR, then VERSION:2.0, PRODID:-//LazyCoder//90-day goal//EN and CALSCALE:GREGORIAN.
- The weekly check-in: BEGIN:VEVENT; UID:checkin@goal-90-day; DTSTAMP:<start date as yyyymmdd>T000000Z; DTSTART:<the first check-in as yyyymmdd>T<hhmmss>; DTEND:<the same day>T<start plus the check-in length>; then the line RRULE:FREQ=WEEKLY;COUNT=13 exactly; then two lines EXDATE:<week 7 check-in as yyyymmdd>T<hhmmss> and EXDATE:<week 13 check-in as yyyymmdd>T<hhmmss>, so the reviews replace those two check-ins; SUMMARY:Weekly goal check-in; END:VEVENT.
- The two reviews, one event each in the same shape with no RRULE line, 45 minutes long, at the check-in time in week 7 and in week 13 (replacing that week's check-in), with UID:midpoint@goal-90-day and UID:final@goal-90-day, and SUMMARY:Mid-point review and SUMMARY:Final review.
- END:VCALENDAR.
- Times are local, with no Z.
## 7. Self-check
Before replying, check each of these and fix any failure:
- There are exactly 13 weeks, the dates run on from the start date with no gaps or overlaps, and each date has the right weekday.
- Every week has one milestone with a "done when" test, 2–5 actions (none in a week away) whose hours add up to the planned hours, and planned hours within 85% of that week's hours (half for a busy week, zero for a week away).
- For a goal the person doesn't fully control, the on-track call uses actions only.
- Every CSV field with a comma is in double quotes.
- The metric targets rise towards the finish line, and week 13's target equals it.
- The realism verdict uses the real totals, and a trimmed goal is used everywhere after it.
- Week 7 is lighter and holds the mid-point review; week 13 holds the final review.
- The CSV has 13 rows plus a header, and matches the table.
- The check-in script, the risks, the behind-schedule rules and the cut list are all there.
- Unless it was skipped, the calendar text has 3 events with unique UIDs, the RRULE line exactly as given, EXDATE lines for the week 7 and week 13 check-ins, the reviews at those times, and END:VCALENDAR last.
Then reply with the output only, ending with one line: "Checked: 13 weeks, <n> actions, <n> h planned of <n> h available."
## 8. Setup
Works as one paste in any chat app, with no tools or plugins. Where the app can create files, you get a calendar file for your weekly check-ins; where it can't, you get calendar text to save as goal-check-ins.ics. Import it with your calendar's import option.Review your result locally
Paste the result after your assistant creates it. This optional check stays in this tab and is not sent to LazyCoder.
A goal broken into 13 weekly milestones with a check-in script.
Version & review details