agentleFS
CharleneTStrainCharleneTStrain/product-ops-skills/skills/quarterly-planning-prep/SKILL.md

quarterly-planning-prep

Skill0 starsChanged 19 days agoMITView on GitHub

Gather and organize everything a product team needs before quarterly planning starts — last quarter's results, carried-over work, customer and business inputs, capacity, and the decisions planning must make — into one pre-read. Use when someone is preparing for quarterly or half-year planning, OKR setting, a planning offsite, or asks for a planning pre-read, planning inputs, or a look-back before the next quarter.

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use the numbers and reasons in the source.

    line 28
  2. Distinctive:

    Keep each input to one or two lines with evidence.

    line 41

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Quarterly planning prep

Planning meetings go badly when the first hour is spent figuring out what happened last quarter. The pre-read does that work in advance, so the meeting is spent deciding.

Before you start

If .agents/product-ops-context.md exists (or .claude/product-ops-context.md), read it first. Use the team, owners, tools, meetings, and metric definitions it already has, and only ask for what's missing or specific to this task. If it doesn't exist, go ahead with what you're given, and suggest running product-ops-context once so the next skill doesn't have to ask.

Step 1: Look back

From the source (last quarter's goals, roadmap, metrics, release notes), record:

Goal or commitmentTargetResultMet?Why, if given

Then list:

  • Shipped: the main things that went live
  • Carried over: planned, not finished, with current status
  • Dropped: removed on purpose, and why

Use the numbers and reasons in the source. Don't grade work as a success or failure beyond what the targets show.

Step 2: Gather inputs

Pull together what the team should weigh, each with its source:

  • Business: company goals, revenue targets, commitments leadership has made
  • Customers: top themes from feedback and the VoC digest, escalations, renewal risks
  • Sales: deals blocked on missing capability, with named stakes where given
  • Product health: KPIs that are off track (see the kpi-health-check skill)
  • Tech: debt, reliability, or platform work engineering says can't wait
  • Commitments already made: anything promised to customers, partners, or leadership with a date

Keep each input to one or two lines with evidence. Mark anything that's an opinion as an opinion.

Step 3: Capacity

Record what the source says about people and time: team size, planned leave, hiring, and how much capacity is already committed to carried-over work, support rotation, or keep-the-lights-on work. If capacity isn't given, flag it as missing. Planning without it is guessing.

Step 4: Frame the decisions

List the specific choices planning needs to make, not a list of topics:

  • "Do we finish X before starting Y?"
  • "Which of these three customer asks makes the quarter?"
  • "Does tech debt get a fixed share of capacity?"

Output

# [Quarter] planning pre-read — [Team]
**Planning session:** [date] · **Read by:** [date]

## Last quarter in one paragraph
[What we set out to do and what happened.]

## Results
[Table from Step 1]

## Carrying into next quarter
- [Item] — [status]

## Inputs to weigh
### Business · Customers · Sales · Product health · Tech · Commitments
- [Input] — [evidence / source]

## Capacity
- [What's known] · Missing: [what's not]

## Decisions this planning session needs to make
1. [Decision]

## Open questions before the session
- [Question] — ask [name]

The pre-read informs the plan; it doesn't propose one. Don't rank priorities unless asked.

Related skills

  • kpi-health-check — last quarter's results
  • voice-of-customer-digest — customer input for the pre-read
  • roadmap-hygiene — clean the roadmap before planning
  • cross-team-dependency-map — show what each plan depends on

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.