VonTerraProject501c3/slushpile

# Adversarial Review

Seven agents try to reject the application before a recruiter gets the chance.

The output is deliberately not a single yes or no. The same materials convert at wildly different rates through a cold portal submission than through a referral, and a review that collapses those into one verdict is telling the user something false in a format that sounds authoritative.

**Announce at start:** "Running adversarial review for $ROLE. Extracting materials, launching five specialists in parallel."

**Arguments:**
- `$1` — path to a role folder containing at minimum a resume and `job_description.md`

**Example:**
```
/slushpile:adversarial-review applications/Acme/Engineering/Staff-SRE

# Application Builder

Take a role folder with a job description and a role analysis. Produce a resume and a cover letter that have already survived a seven-agent review.

**Announce at start:** "Building materials for $ROLE. Reading the JD, the role analysis, and the profile."

**Arguments:**
- `$1` — path to a role folder containing `job_description.md` and `role_analysis.md`

**Example:**
```
/slushpile:application-builder applications/Acme/Engineering/Staff-SRE
```

# Explore Experience

Most gaps in a fit assessment are documentation gaps, not experience gaps. The user did the thing; it never made it into `profile.md`, usually because they did not think of it as the thing the posting is asking for.

This skill finds those, by interview, and writes them down.

**Announce at start:** "Exploring undocumented experience for $ROLE. Reading the profile and the role requirements now."

**Arguments:**
- `$1` — a role folder path (containing `role_analysis.md` and/or `job_description.md`), or keywords naming the gap areas to explore

**Examples:**
```
/slushpile:explore-experience applications/Acme/Engineering/Staff-SRE

# Help

Answer the user's actual question from what follows. Do not print this whole file at them — pick the section that matches what they asked and answer from it in a few lines.

If they asked a general "what is this" or "what do I run", give them the Pipeline section and the single next command for their situation. Check the workspace state before recommending anything: if `preferences.yaml` is absent, the answer is always onboarding, whatever they asked.

## What slushpile is

A job application pipeline. Ten skills and eight agents that take a role from a careers-board listing to a resume and cover letter that have already survived an adversarial review.

The idea it rests on: **you are not graded against the job description, you are graded against the other applications in the same queue.** Every scoring step is anchored to that queue rather than to the posting. This is why the output sometimes says a differentiator the user is proud of is median, and why it reports probabilities per submission channel instead of one verdict.

It never submits anything. Every skill writes files. The user reads them and sends them.

# Job Board Search

Search a careers board, extract the postings, and score each one against the **realistic applicant pool** rather than against the posting's own keywords.

Two ways in. Name a company and this skill searches that company. Describe the work instead — a function, a place, a market — and Phase 0 resolves the description into a list of companies and searches each one. Everything after Phase 0 is identical either way, because the second mode's only job is producing the company list the first mode is handed directly.

**Announce at start.** Company mode: "Searching $COMPANY for roles matching the profile. Focus: $KEYWORDS. Scoring: pool-anchored, channel-conditional, contrarian-gated." Query mode: the same sentence with the resolved company count in place of `$COMPANY`, announced only after Phase 0e, so the user is never told a number that a confirmation step might still change.

**Every `templates/...` path in this file is relative to the plugin, not to the workspace.** The working directory is the user's job-search directory and does not contain them, so a bare `templates/role_analysis.md` resolves to nothing. Resolve them against the directory this skill file was itself loaded from — that works on every harness, where a harness-specific plugin-root variable does not.

**Arguments:** one required argument, read as either a company or a query. See Phase 0a for how to tell them apart and what to do when it is genuinely unclear.

- **Company mode** — `$1` is a company name, `$2+` are role keywords. Keywords default to `targeting.functions` in `preferences.yaml`.
- **Query mode** — the whole argument describes the work, the place, or the market. Constraints in the query are read on top of `preferences.yaml`, never instead of it.

# Onboard

Build the workspace every other slushpile skill reads from.

Nothing in this plugin hardcodes a fact about the user. The skills and agents read three files, and this skill writes them:

| File | What it holds | Who reads it |
|---|---|---|
| `profile.md` | Every factual claim about the user's career | Every skill. Nothing may be claimed that is not here. |
| `preferences.yaml` | Constraints: compensation, relocation, authorization, targeting, voice agent | job-board-search, application-builder, status, the pool analyst and the contrarian |
| `stories.md` | Four to eight tellable stories with scene, stakes, arc | application-builder |

A fourth input, the **voice agent**, is not written here — it is generated by a separate tool. See Phase 4.

# Outreach

Find the warm path into one company, grade it honestly, and draft the message that uses it.

Everything upstream of here scores warm referral several times above cold submission, records which channel unlocks the tier, and then builds cold-portal materials anyway. Nothing in the pipeline ever went and found a referrer, so the warm row stayed informational forever and the user got measured against the channel the tool happened to support. This skill is what opens the other one.

**Announce at start:** "Finding a warm path into $COMPANY for $ROLE. Public professional sources only. Nothing is sent from here."

**Arguments:**
- `$1` — path to a role folder containing `role_analysis.md` and `application.yaml`

**Example:**
```
/slushpile:outreach applications/Acme/Engineering/Staff-SRE

# Redesign Templates

Change how the documents look without changing what a machine reads out of them.

`templates/resume.tex` and `templates/cover_letter.tex` ship in one house style. It is a defensible style and it is not the user's. This skill produces a variant they own.

**Every `templates/...` path in this file is relative to the plugin, not to the workspace.** They are read from there and never written back to there; the variant goes in the user's own directory. Resolve them against the directory this skill file was itself loaded from — that works on every harness, where a harness-specific plugin-root variable does not.

**Arguments:**
- `$1` — optional. A direction: a palette, a font family, a reference PDF or image, an adjective. With nothing, interview for it.

**Announce at start:** "Redesigning the resume and letter templates. The ATS rules are fixed; everything visual is open. I'll compile and check the extraction before and after."

## The One Thing That Makes This Skill Dangerous

# Removing AI Tells

Iterative passes over a draft, removing the patterns that make a fatigued reader think "a machine wrote this" before they consciously work out why.

**Announce at start:** "Removing AI tells from $FILE. Working on a copy, three passes maximum."

**Arguments:**
- `$1` — path to the file to clean

**Example:**
```
/slushpile:removing-ai-tells applications/Acme/Engineering/Staff-SRE/cover_letter.txt
```

# Status

Every other skill in this pipeline writes `application.yaml`. This one reads them all back.

Two questions, answered together on purpose:

**Where does the search stand?** What is in flight, what is waiting on the user, what has gone silent past the point of hope, and which of the assessed-not-applied roles is worth the next slot.

**Is the pipeline any good?** The regression of what the review predicted against what actually happened. A pipeline that grades most applications INTERVIEW and converts five percent is not producing signal, it is producing optimism, and nothing else in the system will ever contradict it.

**Announce at start:** "Reading every application.yaml in the workspace. Reporting queue state and pipeline calibration."

**Arguments:**
- `$1` — optional. A company name or a path, to narrow the report. With nothing, the whole workspace.