agentsclimarketplace

Parkinsons law

Skill The-Artificer-of-Ciphers-LLC/skills-from-the-artificer/parkinsons-law

29 drop-in Claude Code skills: cost-tier model routing, debugging (rubber-duck, test-first-bugfix, trust-but-verify), and 24 laws-of-software reference skills. Install with: npx skills add The-Artificer-of-Ciphers-LLC/skills-from-the-artificer --all

Install
npx -y skills add The-Artificer-of-Ciphers-LLC/skills-from-the-artificer --skill parkinsons-law

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

  • 3 stars3 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

Apply Parkinson's Law when discussing project planning, sprint duration, deadline setting, scope creep, or why work seems to expand no matter how much time is allocated. Trigger on phrases like "we always use up all the time we're given", "if we give the team a month they'll take a month", "why does scope keep growing?", "should we set tighter deadlines?", or any discussion about the relationship between available time and how long work takes. Parkinson's Law is a universal phenomenon in project management.

SKILL.md

3.8 KB, as published. Nobody here has run it

Parkinson's Law

"Work expands so as to fill the time available for its completion." — Cyril Parkinson, 1955

The core idea

Given more time to complete a task, people use it — through more elaborate solutions, more polishing, more scope, more second-guessing, or simply slower pace. The work doesn't have a fixed duration; it stretches to fill whatever container you give it.

Parkinson observed this originally in bureaucracies (a report that could be done in one day takes three when three are allocated), but the pattern is universal in knowledge work.

Why it happens

Effort adjusts to perceived time available. If you have a week, you approach a problem as a week-long problem. If you have a day, you find the 80% solution that matters.

Scope expands with available time. Extra time rarely stays empty — people find adjacent improvements, additional polish, more edge cases to handle, more documentation to write. This isn't laziness; it's often genuine value-adding activity. But the result is that the task always ends up using the time.

Perfectionism is proportional to deadline pressure. "Good enough" requires a definition of "good." When there's abundant time, "good enough" ratchets upward.

Meetings expand too. A meeting scheduled for an hour takes an hour. The same discussion, if you must resolve it in 30 minutes, usually resolves in 30 minutes.

How to use this for good

Set tighter deadlines intentionally. When you want a decision made, a design drafted, or a prototype built, giving less time forces prioritization. Parkinson's Law is a productivity tool when you use it deliberately.

Time-box rather than scope-box. Instead of "deliver feature X completely," try "spend two weeks on X and ship whatever is done." Time-boxing forces prioritization within the available time.

Use short sprints. Two-week sprints create more focus and delivery rhythm than month-long ones. Shorter cycles mean more frequent accountability and less opportunity for scope drift.

Define done clearly before you start. Without a clear definition of done, work expands into all available time because it's never technically "finished." Clear, minimal acceptance criteria prevent this.

Separate required from optional. Explicitly categorize work into "must have for this to be useful" vs. "nice to have." Required work gets done; nice-to-haves get deferred when time is short.

The flip side: don't over-apply it

Parkinson's Law is not a license to give unrealistically short deadlines. Genuine work has genuine lower bounds. Rushed work produces bugs, debt, and burnout. The goal is to find the right allocation — not the minimum — for the outcomes you need.

The question to ask is not "how can we do this faster?" but "what is the minimum time in which this work can be done well?"

Key questions to surface

  1. Have we defined "done" clearly enough that we'll know when to stop?
  2. If we cut the deadline in half, what would we cut from scope? Is that trade-off worth making?
  3. Are we spending time on things that are genuinely necessary, or things that are comfortable because time permits?
  4. Is this meeting really a 60-minute meeting, or could it be 30?
  5. Are our sprint lengths creating focus, or too much room for drift?

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.