brainstorming
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).
hire-or-passTurn a hiring debrief into a typed decision — hire, hire at a different level, get more signal, or pass — from rubric evidence only, with probabilities and confidence. Use when asked should we hire this candidate, run the debrief, hire or no-hire, or when interviewers disagree and the manager has to call it. Produces the evidence state per competency, the f…
Independent GitHub snapshot · Automated classification · Original documentation governs
Debriefs go wrong when the loudest interviewer wins or when everyone waits to see what the manager thinks. This skill forces the evidence into a fixed shape — per competency, strongest example and strongest counter-example, from whom — and defines the four possible outcomes before the discussion starts. The output is a distribution over those outcomes and, when it is close, the specific extra signal to go get.
Boundary. This is decision support. A person makes and owns the hiring decision, applies the company's process and the law where they are, and is accountable for it. Never let a distribution replace that.
After hiring-rubric (which defines the competencies) and engineering-hiring-rubric, and after the interviews. This one runs the debrief decision.
hire / hire_at_different_level / more_signal / pass with probabilities and confidencemore_signal by definitionAsk for these; do not infer from "vibes" or an interviewer's overall thumbs:
| Option | It applies when |
|---|---|
hire | Every must-have competency has positive evidence from at least two interviewers, and no red flag has evidence behind it |
hire_at_different_level | The evidence supports the competencies at a different level than the role was opened at |
more_signal | A must-have was untested, or the evidence is split between interviewers — one targeted extra conversation decides it |
pass | A must-have competency has negative evidence, or a red flag is substantiated |
Thresholds. Act when confidence ≥ 0.65 and the winning option's probability ≥ 0.7. A close hire / pass is a more_signal outcome: name the competency and who tests it. Never decide on the distribution alone.
Evidence, not impressions. "Strong communicator" is an impression. "Explained the outage timeline to a non-engineer in the panel without being asked — seen by R." is evidence. Only evidence enters the state.
Getting probabilities. Any calibrated decision model that returns a probability per defined option serves this contract; the repo ships an adapter (node integrations/jev/decide.mjs hire-or-pass --state state.json, contract in integrations/jev/decisions/). Without one, the assistant estimates and labels it. Either way the decision is the hiring manager's.
Evidence by competency
| Competency | Strongest example (who) | Strongest counter (who) | Scores |
|---|---|---|---|
| … | … | … | … |
Decision
| Option | Probability |
|---|---|
| hire | 0.xx |
| hire_at_different_level | 0.xx |
| more_signal | 0.xx |
| pass | 0.xx |
Confidence: 0.xx · Source: [model / estimate]
Verdict: [act: option] or [hold → more_signal: competency, format, owner, by when] Debrief record: [one paragraph — evidence summary, the decision, who made it]
more_signalmore_signal, always