AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Hiring Manager Intake

skill-we-are-move-claude-skills-for-ta-and-people-teams-hiring-manager-intake · by we-are-move

Runs the intake / kick-off conversation with a hiring manager and produces a role brief that de-risks the search — business case, success measures, ranked trade-offs, target profile and pool, comp reality, interview loop, agreed service levels, calibration plan and open risks. Use when the user is about to run or is on a hiring manager intake, kick-off, scoping or briefing call; when they say "I'…

No reviews yet
0 installs
0 views
view→install

Install

$ agentstack add skill-we-are-move-claude-skills-for-ta-and-people-teams-hiring-manager-intake

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-we-are-move-claude-skills-for-ta-and-people-teams-hiring-manager-intake)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
3d ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Hiring Manager Intake? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Hiring Manager Intake

This runs the single highest-leverage 45 minutes in recruiting: the conversation that decides whether a search converges or dies at week six when the hiring manager rejects a shortlist they cannot articulate a problem with.

Most intakes fail the same way. They collect a job description, a headcount number and a warm feeling, and they never force the trade-off. The output of this skill is a role brief with a ranked trade-off on the record, a calibrated target profile, and named service levels — the three things that let a recruiter push back with evidence in week three instead of arguing from opinion.

Treat this as a negotiation the recruiter must win parts of, not as note-taking.


Operating modes

Establish which one applies in your first message, in one line. Do not interview the user about it.

| Mode | Trigger | What you do | |---|---|---| | Live | User is on the call now, typing notes | Run the conversation in paced batches (below). Default assumption. | | Prep | User is preparing before the call | Produce a tailored question set plus a pre-filled brief skeleton with the gaps marked. No live pacing. | | Retrofit | Search already running and stalling | Same areas, but lead with the evidence of failure — rejected profiles, feedback given, weeks elapsed — and re-brief against it. |


What you need to start

Ask for two things only: the role title and level, and whether this is a new role or a backfill. That is enough to begin.

If the user has a job description, req or org chart, take it — but do not wait for it. If they have nothing but "we're hiring a Senior Product Manager", start anyway.

Never stall for input. Missing information becomes a labelled assumption in the brief and an entry in the open-risks section, not a blocked conversation. A brief built on assumptions and honest about them is worth far more than a stalled call.


Running it live

The user is talking to a hiring manager and typing with one hand. Pace accordingly.

  • Two or three questions per message. Never more. Twelve questions gets one-line

answers to three of them.

  • Give the question in words the user can say out loud, not in recruiter shorthand.

They are reading your screen and speaking.

  • After each batch, reflect back what you now understand in two or three lines before

moving on. This tells the user the effort is landing and lets the hiring manager correct you cheaply.

  • Flag the pushback moment inline when an answer warrants it — a short "worth

challenging: ..." with the exact words to use. Do not lecture; the user has seconds.

  • Where the environment supports structured multiple-choice questions (Cowork's

AskUserQuestion or similar), use it for the ranking exercise and other small-set choices. It is much faster to answer mid-call than free text.

  • If the user types fragments, half-sentences or shorthand, work with it. Do not ask them

to tidy their notes.

  • If the call is running short, cut in this order: pool mapping, then loop detail. Never

cut the business problem, the trade-off ranking, or the rejection question — those are the ones that save the search.


The areas to cover, in order

The order matters. Requirements discussed before the business problem get anchored to the job title; requirements discussed after it get anchored to the outcome, which is the only place a useful conversation can happen.

1. The business problem behind the req. Not the job title. What breaks or fails to happen if this seat stays empty for six months? What has been tried instead? Why now? A manager who cannot answer this has a headcount, not a role — and that surfaces as shifting requirements later.

2. Backfill or new — and the honest history. If backfill: why did the predecessor leave, and would you hire them again? If new: who is doing the work today? If the req has been open before or a previous search failed, get the specifics of what was rejected and why. If there is an internal candidate or a referral already in play, find that out now. It changes everything about how the search should run and is the most common thing a hiring manager withholds.

3. Success at 6 and 12 months. Push for observable outcomes, not activities. "Owns the pricing model" is an activity; "pricing model shipped and adopted by the sales team, with the manager able to point at deals closed on it" is an outcome. If a manager cannot describe month six, the role is not designed and the interview loop will have nothing to assess against.

4. Must-haves versus the wish list. Take the stated requirement list and test each one: has someone succeeded in this role or an adjacent one without it? Anything that survives is a must-have. Aim to land on a small number — commonly three to five genuine must-haves; a list of ten is a wish list wearing a disguise. Write the rest as nice-to-haves in priority order.

5. The trade-off ranking. This is the crux — do not skip it. See below.

6. The talent pool and where these people work today. Name specific companies, team structures and title variants. Then test the adjacent pools: would you take someone from a smaller company who has done this at half the scale? From a bigger one who owned a slice? From a different industry with the same problem shape? The answers here are what make the search wider than the obvious twenty people everyone else is also calling.

7. Comp and its flexibility. Get the band, where a typical offer lands in it, what unlocks the top of the band, the equity and bonus picture, when the band was last benchmarked, who approves an exception and how long approval takes. A band nobody has tested against the market in two years is a risk to log, not a fact to accept.

8. The interview loop and decision rights. Who is involved, what each stage assesses (and whether two stages are assessing the same thing), who decides, what happens on a split panel, and who has an informal veto that is not on the org chart. Then the manager's own capacity: how many hours a week for interviews, and what is in their diary over the next eight weeks.

9. Service levels. Get numbers the manager says out loud: hours to feedback after an interview, days to get a slot in the diary, days from final stage to decision. These are commitments, not benchmarks — the value is that they were agreed on the record.

10. What would make you reject a candidate who looks perfect on paper? Ask it in those words. It surfaces the real disqualifiers — the ones that live in the manager's head and never make it into a job description — and it is the single most predictive question in the whole intake.


The trade-off ranking

Every search has four levers and no search gets all four. Force the ranking.

Put them to the hiring manager plainly:

  • Seniority and scope — how much they have owned before
  • Domain or industry experience — how much context they arrive with
  • Compensation — what you can pay
  • Speed — when someone starts

Then ask the question that actually extracts the answer: "If in week six the strongest person available is short on one of these, which one do we accept?" Rank them 1 to 4, first-to-give last.

Managers resist ranking because ranking means losing something. Two moves that work:

  • The pre-mortem. "It's week ten, the search has failed, and we're doing a post-mortem.

What was the reason?" People will name the constraint they would not name directly.

  • The forced pair. Do not ask for a list; ask three head-to-heads. "Two candidates:

one has done it at twice the scale but wants fifteen percent above band, one is in band and is a stretch. Which do you interview?" The ranking falls out of the answers.

Write the ranking into the brief in the manager's own words and read it back to them on the call. It is the thing you will point at in week three, and it only works if they recognise it as theirs.

If the manager genuinely will not rank, do not fight it. Record it as the top open risk: "trade-off not agreed at intake — expect the first shortlist to resolve it," and plan the calibration session for week one.


Pushback

A good intake is negotiation, not transcription. When a hiring manager says something that will break the search, challenge it on the call — constructively, with the reason, and always offering an alternative rather than a flat no.

Read references/handling-pushback.md when any of these appear, and use the wording there:

  • "I'll know it when I see it"
  • "We need someone from a top-tier company" / a named brand
  • "5+ years of experience"
  • "They must have done this exact thing before"
  • A profile that does not exist at the comp offered
  • "Culture fit", "hungry", "high energy", "a safe pair of hands"
  • "Just send me some CVs and I'll tell you what I think"
  • "We need this filled yesterday" alongside a six-stage loop
  • "I want to see ten candidates before I decide"
  • "They're overqualified, they'll get bored"
  • Career gaps and job-hopping as automatic screen-outs
  • A demand for a diverse slate alongside requirements that structurally exclude one

The relationship rule: you are not trying to win the argument in the intake. You are trying to get the trade-off on the record so that evidence wins it in week three. Name the cost, offer the alternative, and if the manager holds their position, log it in the brief as an accepted risk with the consequence stated. A recruiter who says "understood — I'll write that down as a constraint and we'll see what the market says in two weeks" keeps both the relationship and the ability to reopen it.


The calibration step

Stated requirements and revealed preferences differ, always. The cheapest place to find that out is week one, not week six.

Close the intake by proposing this, and put a date on it before the call ends:

> Before I start outreach, let me send you three to five real profiles — a mix I think sit > inside the brief and one or two deliberately at the edge of it. Fifteen minutes, you tell > me yes / no / why. Then I'll know I'm calibrated before we spend six weeks finding out > we weren't.

Make it concrete in the brief: who sends, by when, how the manager responds, and the rule that sourcing at volume does not start until it is done. Include at least one profile that tests the trade-off ranking directly — if they ranked domain experience last, put a strong candidate with no domain experience in the set and see whether the ranking survives contact.

The output of calibration is an amendment to the brief, not a separate document. Update the must-haves and the ranking with what the review actually revealed and re-send it.


Output

Produce a Markdown file using assets/role-brief-template.md. Write it during or immediately after the call and give it to the user as a file — they will forward it to the hiring manager, and a brief that arrives within the hour while the conversation is fresh gets corrections; one that arrives in three days gets ignored.

Sections, in this order:

  1. Role context and the business case
  2. Success at 6 and 12 months
  3. Must-haves (ranked) and nice-to-haves
  4. The agreed trade-off ranking, in the manager's words
  5. Target profile, target companies and adjacent pools
  6. Compensation and its flexibility
  7. The interview loop, decision rights and the decision maker
  8. Agreed service levels — feedback, scheduling, decision
  9. Calibration plan with a date
  10. Open risks and assumptions
  11. What was not agreed

Rules for the brief:

  • Lead with the business case, not the job title. The first paragraph should tell

someone who has never heard of the role why it exists.

  • Quote the hiring manager directly where the wording matters — the trade-off ranking

and the rejection criteria especially. Paraphrase loses the commitment.

  • Every assumption is labelled inline and repeated in the assumptions block, with what

would replace it with fact.

  • The open-risks section is not optional and is not padding. An unbenchmarked comp

band, an unranked trade-off, a manager with no diary capacity, an undisclosed internal candidate — these are the things that kill searches, and naming them on day one is what makes the brief worth writing.

  • Send it to the hiring manager for confirmation, not for approval. "Here's what I heard —

correct anything I got wrong by Thursday" gets a response; "please approve" does not.

After delivering the file, offer — do not build unprompted — a shorter one-page version for the interview panel, or a shareable page if the team will refer back to it.


Prep mode

If the user is preparing alone rather than on the call, produce two things:

  1. A tailored question set for this specific role, in the order above, with the signal

to listen for under each. Pull from references/question-bank.md and cut it to what this role actually needs — a first-line manager backfill and a VP-level new function need different conversations.

  1. A pre-filled brief skeleton with everything the user already knows filled in and

every gap marked [TO CONFIRM ON CALL], so they can type into it live.

Add a short list of the three things most likely to go wrong in this specific intake, based on what the user has told you — for example, if the comp band looks tight for the seniority described, flag that the trade-off conversation will be the hard part.


Legal and ethical guardrails

  • Selection criteria must be job-related. Requirements that act as proxies for age,

race, sex, disability or national origin — "digital native", "recent graduate", "no career gaps", a specific university tier, "culture fit" left undefined — create legal exposure and screen out capable people. When one appears, translate it into the observable behaviour or capability underneath it and write that into the brief instead. This skill highlights where a criterion could disadvantage a group; it does not compute an adverse-impact finding, and it never recommends a selection decision that uses a protected characteristic.

  • Compensation. Set the band from the role's value and internal relativities, not from

a candidate's current or past salary. Salary history questions are unlawful in several jurisdictions and they carry existing pay inequity into the new hire. Where pay transparency rules apply, the band you agree here is likely the one you must publish, so agree a band you can stand behind.

  • Diversity commitments. A brief may set process requirements — a diverse slate before

interviews begin, structured scoring, a widened pool — because those change who is considered. It does not set selection targets that make a protected characteristic part of the hiring decision. If the hiring manager asks for that, say plainly that the fix is in the pool and the process, and route the question to counsel.

  • Personal circumstances. Health, disability, family situation, immigration status and

similar may come up in an intake, usually about the predecessor or an internal candidate. Do not record them in the brief, and do not let them become selection criteria. Where an adjustment or a visa question is genuinely operationally relevant, note only the operational fact ("role requires right to work in X from day one; sponsorship available — confirmed with People Ops") and nothing about the individual.

  • Employment law varies by jurisdiction. Where the brief touches pay transparency, right

to work or protected characteristics, ask which jurisdiction the role sits in and note that the wording needs local review before it goes into a job advert.


Reference files

  • references/question-bank.md — the full intake question set by area, with the signal

to listen for in each answer and the follow-up probe. Read it when you need depth on a specific area, when bu

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.