Personal goal planning

Skill F-e-u-e-r/opus-pack/skills/personal-goal-planning

Distilled operating skills for daily-driver Claude models — few dense rules, executable gates over long prose.

Install

npx -y skills add F-e-u-e-r/opus-pack --skill personal-goal-planning

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Coach-style personal goal planning — a five-step protocol that turns a person's situation into tiered goals (2–4 weeks / 2–3 months / 6–12 months) with one mainline, a small set of executable tasks, a realistic weekly rhythm, and a weekly review loop with a stuck rule. Load when the user asks to plan personal or career goals, a study/fitness/side-project plan, "help me figure out what to focus on", weekly time budgeting, or a progress-tracking cadence. NOT for product or repo planning — use product-roadmap; not therapy, medical, legal, or investment advice.

SKILL.md

3.7 KB, as published. Nobody here has run it

Personal Goal Planning

Run as a coach: intake first, plan second, rhythm third, review loop last. The deliverable is a plan the person can start this week — not an essay.

1. Intake — minimum questions, one at a time

Ask only for what the plan still lacks, from this list and nothing else: identity/role, current state, main pain, goal direction, weekly time actually available, resources, hard constraints. Skip anything the user's message already covers.
One question at a time, short and precise; seven questions is a cap, not a quota. No chitchat, and no advice during intake — advice before the profile exists is guessing.
Do not invent constraints the user did not state. Where an answer is missing, proceed on a declared assumption the user can correct.

2. Three tiers, one mainline

Short = 2–4 weeks, mid = 2–3 months, long = 6–12 months. State each tier's priority and the reason for the ordering.
Pick one mainline; everything else is explicitly parked with a one-line reason and a revisit trigger. The parked list is the plan's immune system — unwritten "laters" silently re-enter scope.
Name the mainline's riskiest assumption — the belief that, if wrong, kills the goal. The short tier's job is to test it as cheaply as possible.

3. Tasks — few and executable

Each task carries: name, purpose (which tier goal it advances), an observable done-criterion ("can run 5 km under 35 min", not "get fitter"), and priority. Few and high-leverage beats complete. A task the user cannot start within one week as written is not concrete enough — split it or rewrite it.

4. Weekly rhythm — real hours, not ideal hours

From the stated available time: total weekly hours, number of sessions, what each session does, the week's mainline task, what may slip, what must not. Plan at ~80% of stated capacity — a schedule that survives a bad week beats one that only works in a perfect one.

5. Weekly review loop

Check done vs. the done-criteria — observable results, not felt progress.
Judge by the metric named in the plan, not by mood.
Stuck rule: the same task stalled two weeks running means the approach is wrong, not the willpower. Shrink the task, change the method, or demote it and promote a parked item — never schedule a third identical week.
End every review with next week's single mainline and any tier adjustment.

Boundaries

Product/repo direction → product-roadmap. This skill plans a person.
General planning only — refer out where stakes are professional (medical, mental-health, legal, financial).
Honesty rules apply: if the goal cannot fit the stated time, say so and cut scope — never make it fit by pretending.

Provenance

Adapted 2026-07 from a five-step goal-coaching protocol by @pro_ai.news (Threads; link in the repo README acknowledgements), tightened with this pack's house rules: observable done-criteria, riskiest-assumption testing, the two-failure rule applied to weekly stalls, and ~80% capacity planning. Stable method; nothing environment-specific to re-verify.