Skip to content

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1 Commit
 
 
 
 
 
 
 
 

Repository files navigation

task-level-guide

An agent skill that classifies every completed task by engineering level, then writes a short block for each level showing how an engineer at that level would have approached the same task.

Works with Claude Code, Codex, Cursor, and any runtime that reads the Agent Skills format.


The idea

You cannot practise a level you cannot see. A title tells you where you are. It does not show you the gap.

So after each task, this writes four blocks:

JUNIOR would have   added the missing line and called it done
MID would have      added the line, then run the suite to check nothing else moved
SENIOR would have   asked why the function still failed its gates afterwards, and
                    found the fix did not make the trained car faster
STAFF would have    asked why a crash on half of every episode was invisible for two
                    years, and concluded the simulator was absorbing the error

Same task. Four levels. The gap is now a thing you can aim at.

Scope is the wrong axis

Most engineering ladders use "area of scope" as the proxy for level. Honeycomb's ladder rejects that, and the reason is convincing: a ladder that conflates advancement with scope only rewards engineers who work on the largest projects. Honeycomb would rather reward engineers who shrink scope by decomposing the problem.

This skill uses their two-axis model, borrowed from the PSHE framework.

Scope — how much surface the work touches.

task -> feature -> project -> product -> company

Ownership — which question you owned.

Ownership The question you owned Also called
Execution "Build this thing." Implementer
Process "Make delivering this repeatable." Implementer
Solution discovery "What should we build to fix this?" Solver
Problem discovery "What is actually wrong here?" Finder

Movement up beats movement right.

The two mis-levelling traps

Big scope, low ownership. A six-week migration where the framework, the deadline, and the approach were all decided by someone else is execution work at project scope. It reads senior on a resume. It is not evidence of judgement.

Small scope, high ownership. A one-line fix found by noticing a benchmark was faster than physically possible is problem discovery at task scope. It reads trivial on a resume. It is the harder skill.

A scope-only ladder makes the second person invisible. That is the trap.

For practice problems

LeetCode, HackerRank, a take-home, a mock interview. The ownership axis is what interviewers actually score.

Level In a practice problem
Junior Reaches a correct solution.
Mid Reaches it, states complexity, handles edge cases.
Senior Clarifies before coding. Names the constraint that decides the approach. Tests the failure case.
Staff Asks what the real input looks like, and whether the stated problem is the one worth solving.

Most candidates fail by solving before clarifying. That is the entire mid-to-senior gap in an interview, and it is drillable.

The problem-discovery drill

The hardest level to practise alone, because nobody hands you a problem.

  1. Pick a repository you have never read, with a public issue tracker.
  2. Do not open the issues.
  3. Thirty minutes: what does this claim to do, and which claim is weakest? Write it down.
  4. Now open the issues. Compare.

Score is one question: did you find something nobody had filed?

What to look for, in order of how often it works:

  • A number that cannot be true — a benchmark faster than the theoretical limit, a cache hit rate above 100 percent.
  • A claim in the README with no test behind it.
  • A check that cannot fail. Break the behaviour on purpose and see if anything turns red.
  • A default nobody chose. A timeout of exactly 30 seconds usually means nobody measured.

With AI assistance the drill gets faster, not easier. An agent reads far more code than you can in thirty minutes. It will not tell you which weak claim matters. That judgement is the level, and it is the part that does not transfer to the tool.

Two facts worth repeating

From Honeycomb's ladder, both unusual and both healthy:

  1. Senior is a terminal level. Many strong engineers stay there because the work is fulfilling. Staying is not failing.
  2. Senior to Staff is a phase shift, not one more step. The job changes kind, not size. That is why "do more of what made you senior" does not produce a staff engineer.

Install

git clone https://github.com/HomenShum/task-level-guide \
  ~/.claude/skills/task-level-guide

Files

File Contents
SKILL.md the classification method, the four blocks, the drill
references/LEVELS.md the grid, worked examples, the honest title mapping

Companion skills

  • before-after-proof — capture evidence before the edit. This skill reads that evidence to decide whether work was verified. Unverified work has no level.
  • easier-to-read-submissions — per-surface changelogs at commit time.

Source

Honeycomb, Engineering Levels at Honeycomb: Avoiding the Scope Trap. The PSHE framework (problem, solution, how, execution) came from YouTube's product team by way of Shishir Mehrotra. The parallel framing of Implementers, Solvers, and Finders is Randall Koutnik's.

Licence

MIT.

About

Classify every task by engineering level using scope AND ownership, then show how each level would have done the same task. Built on Honeycomb's ladder. Agent skill.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors