Application Builder

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

Prerequisites

Read all of these before writing anything:

• profile.md — the source of truth for every factual claim. Nothing goes on a resume that is not in here.
• stories.md — the shortlist the cover letter's story comes from
• preferences.yaml — constraints, claimed differentiators, and voice.agent
• The definition of the agent named in voice.agent — how this person writes
• The role's job_description.md
• The role's role_analysis.md

Check voice.is_mine in preferences.yaml before drafting the cover letter. If it is false, the user has not yet generated a voice agent from their own writing and the pipeline is about to write in a stranger's voice. Say so once, plainly, and point them at https://github.com/aaddrick/written-voice-replication. Then continue if they want to — a placeholder voice is fine for seeing the pipeline work, and it is not fine for a letter they actually send. They cannot make that call if nobody tells them.

If role_analysis.md does not exist, stop and run /slushpile:job-board-search for this company first, or write the analysis by hand. Building materials without a pool assessment means targeting the posting instead of the queue, and the queue is what decides.

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/cover_letter.tex 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.

Phase 1: Angle

1a. Pick a base resume

Look at resumes already in the workspace. Choose the closest starting point by, in order: same company, similar function, similar level, most recent. Recency matters more than it looks — the newest resume carries every formatting and content fix made since the older ones.

With no close match, start from templates/resume.tex in the plugin directory, or from the most recent resume in the workspace.

templates/resume.tex and templates/cover_letter.tex are a matched pair: same palette, same fonts, same header treatment. When you start either one from the plugin templates, start both from them. The resume and the letter are the only two documents in the application a screener sees side by side, and a letter in a different typeface than the resume reads as two documents assembled from two sources.

Both templates build under XeLaTeX and fall back to DejaVu when the house fonts are absent, so a missing font changes how they look and never whether they compile. If xelatex is not installed at all, say so once and write both documents in Markdown instead — every skill downstream of here works on extracted text and none of them require .tex. Silently producing a .tex file the user cannot build is the failure worth avoiding.

1b. Extract the angle from the role analysis

Pull out:

• Pool position and tier — this calibrates how aggressive to be. A p40 candidate and a p85 candidate write different letters.
• Highest-EV channel — a cold submission and a referral want different documents. A referral letter can assume a sympathetic reader.
• Top strengths — what to lead with
• Top gaps — what the materials must not draw attention to
• Narrative angle, if the analysis has one

1c. Find the thesis

The thesis is not "I am qualified for this role." It is one argument that makes this person interesting for this specific seat.

Ask: what does this candidate bring that most applicants for this role will not? What combination creates value that the pool does not already have? What is the single strongest reason to interview them despite the gaps?

Expressible in one sentence. Proven across the whole letter.

The thesis must be company-dependent. The test: swap the company name for a direct competitor. If the thesis still works, it is not specific enough and the hiring manager's swap test will catch it.

A thesis that passes reads like: "Most capacity planning candidates come from one side of the business. This company's dual identity as manufacturer and cloud provider is the rare case where running both is the qualification." Swap in a pure cloud provider and it collapses. That is the property you want.

A thesis that fails reads like: "I have deep experience in infrastructure program management and a track record of delivery." True of everyone in the queue.

1d. Design the hook

The hook is the first line. It presents the angle, not the background.

Never open with background. "I have spent twelve years doing X" is the most common opening in the bottom half of the pile, and a fatigued reader has seen it forty times that day before reaching this one.

Draft three hooks. Pick the strongest. It must be unique to this letter — check the "Used in" lines in stories.md and any recent cover letters in the workspace.

A hook lands when it makes the reader curious about someone they would not otherwise interview. It leads with a concrete detail, a reframe, or a provocation. Not a credential.

Strong: "We started with seven assumed defect categories. We found hundreds." — "Everyone applying to this role knows data platforms. Almost nobody has delivered under production SLAs written into law." — "I am not a developer educator who has read the docs. I am a practitioner who writes."

Weak: "I have spent the last decade running infrastructure programs." — "Every responsibility in this posting maps to something I do now." The first is background. The second is a claim, not a hook.

1e. Pick the story

One story, from stories.md. It must prove the thesis.

Check the "Used in" field. Reusing a story across two applications to the same company is the specific failure this field exists to prevent.

One vivid story with room to breathe beats three summary paragraphs. Give it the space.

Phase 2: Resume, First Draft

2a. Adapt the base

Header. Update the tagline to match the role's function. Add location targeting if the role is site-specific and the candidate would relocate. Keep contact details in the document body, never in a \header — roughly a quarter of ATS drop header content.

Summary. Rewrite in two or three sentences for this specific role. Lead with the strongest match to the core function.

Do not paste phrases from the posting. If a sentence in the summary could be copied out of the JD, rewrite it in the candidate's own words. A screener reading their own posting back at them stops reading, and the ATS gains nothing the Skills section is not already providing.

Skills. Audit against the JD. Every explicit requirement and preference the candidate legitimately has should appear as a keyword, weighted into this section where ATS scoring is highest.

Add JD-specific terms the candidate can claim — check profile.md for the evidence. Add bridging vocabulary where the role analysis identified a domain gap that the candidate's experience maps to by analogy.

Do not add a keyword the candidate cannot defend in an interview. The requirements analyst checks Skills entries against the work history and will flag anything unsupported.

Experience bullets. Reorder to lead with what this JD cares about. Every bullet passes the "So What?" test: baseline, action, significance. Expand any role that profile.md shows is under-developed relative to this posting. Add quantified outcomes where the profile has numbers the current resume drops.

Vary bullet length deliberately. Bullets all within five words of each other is a tell the fatigued reader catches before consciously noticing why.

Section order. It is a per-application decision. Move open-source and writing above experience when the role weights public technical credibility over tenure.

2b. Compile and verify

Build the PDF. For LaTeX: latexmk -xelatex .tex && latexmk -c.

Check page count. One to three pages is fine — do not force it onto fewer pages by cutting substance. A two-page resume that keeps the evidence beats a one-page resume that keeps the layout.

Check for new overfull-hbox warnings. Extract with pdftotext .pdf - and read the result. That extraction is what an ATS sees and what every review agent will be handed. If it reads badly, fix the document, not the review.

Phase 3: Cover Letter, First Draft

3a. Draft

The letter's container is templates/cover_letter.tex, or the letter from whichever application you took the base resume from in 1a. Take the container first and draft into it, rather than drafting loose prose and formatting it afterwards. The template's header carries the requisition ID and the exact role title, which large employers route on, and a letter assembled at the end is where that line gets dropped.

Copy the contact line from the resume character for character. A phone number or a city that differs between the two documents is the kind of small inconsistency a fatigued reader notices, and the next thing they do is start looking for more of them.

Then dispatch the voice agent named in preferences.yaml under voice.agent:

Write a cover letter for [role] at [company].

Thesis: [from 1c]
Hook:   [from 1d]
Story:  [full story text from stories.md]

Required, in order:
1. Open with the hook. The first sentence presents the angle, not the background.
2. Tell the story with scene, stakes, and resolution. Give it room. Do not
   compress it to a sentence.
3. No gap paragraph. Do not name what the candidate lacks.

Include if the thesis allows:
- Company-specific content framed as "I have built what your tools formalize",
  never as "here is what your product does"
- Mapping from the candidate's operational patterns to this company's systems

Structure: 4-6 paragraphs, roughly 350-500 words. Length serves the thesis,
not a target.

Close on a concrete detail or a reframe. Never "happy to discuss further".

Profile context:
[the relevant sections of profile.md for the experience being referenced]

The no-gap-paragraph rule is worth understanding rather than just following. A gap paragraph becomes the loudest sentence in the letter, and it hands a preferred qualification more weight than the hiring manager would have given it unprompted. The resume already shows the gap honestly. The letter's job is to argue for an interview. Gaps get addressed in the interview, if they come up at all.

3b. Voice pass

Dispatch the voice agent a second time, on the draft:

Tighten this cover letter to the voice profile. The thesis, structure, and
content are correct. Only the voice needs work.

[draft]

Keep the thesis, structure, and every factual claim exactly as they are.

Preserve all company-specific details, proper nouns, product names, team names,
and role-specific framing. Do not generalize for style. Company specificity is
load-bearing and it is the first thing a style pass destroys.

3c. Quality gate

Every item passes before the letter goes to review.

Structure. No two paragraphs make the same point in different words. Every paragraph serves the thesis. Count the distinct topics — more than three or four means cut the weakest.

Hook. Paragraph one opens with something other than background. The hook is unique to this letter.

Story. Exactly one, told with scene and stakes and resolution, not compressed.

Gaps. No gap paragraph exists.

Company specificity. The thesis collapses under a company swap. The company-specific details are concrete — product names, team names, mission — not "your platform".

Density. No paragraph carries more than about three claims or metrics. A dense metric paragraph means the reader retains none of them. Keep the three strongest, move the rest to the resume.

Anchored metrics. "101 issues through the pipeline" with no timeframe and no outcome is noise. Anchor it or cut it.

Closing. The final line lands on a concrete detail or a reframe.

Company name. It appears at least once in the body, beyond the header. Without this the swap test fails on a technicality.

3d. Ground every company reference

Every company-specific claim gets verified against a real source. The drafting process hallucinates product names, team structures, and strategic context confidently, and a single wrong product name kills credibility faster than any other error in the document.

Verify: product and platform names, spelling and current branding, what the product actually does; team names and org structure; mission statements, not paraphrased from memory; technical claims about their stack; any recent news or funding referenced.

How: check job_description.md first — most of it is in the posting. Then role_analysis.md. Anything in neither gets verified by web search or the company's own site before it stays. If it cannot be verified, cut it or replace it with something from the JD that can.

The failure modes worth knowing by name: attributing one company's product to a competitor; attributing a feature to the wrong product inside a multi-product company; using a description that predates a rename or an acquisition; inventing a team name that sounds plausible; describing what a product does by reasoning from its name.

3e. Screening questions, when the form has them

Check the Notes section of job_description.md. /slushpile:job-board-search records the application form's structure there: free-text screening questions, years-of-experience dropdowns, whether a cover letter field exists at all.

If the form has free-text questions, answer them here. Write them to form_answers.md in the role folder.

This is not optional polish. Many application forms never accept a cover letter, and on those the screening answers are the only prose a human reads — the entire argument for the candidate, in three boxes of 200 words. Materials that stop at a resume and a letter leave the actual submission to be improvised at 11pm in a browser tab, which is where the voice work, the grounding, and the thesis all get discarded.

Dispatch the voice agent named in voice.agent, once, with every question at the same time:

Answer these application form questions for [role] at [company].

Questions, verbatim from the form:
[each question, with its stated word or character limit]

Thesis: [from 1c]
Story already used in the cover letter: [one line — do not retell it]

Profile context:
[the relevant sections of profile.md]

Rules:
1. Answer the question that was asked. A form answer that pivots to a prepared
   pitch reads as evasion, and the reader has the question in front of them.
2. Respect the stated limit. Where a limit is given in characters, count them.
3. Do not retell the cover letter's story. Reach for a different one, or answer
   without a story.
4. Concrete over comprehensive. One specific answer beats three hedged ones.
5. No gap paragraphs, same as the letter.

Answer the asked question, not the adjacent one you have better material for. These are read directly beside the question text, which is exactly the position where a pivot is most visible. It is a different failure mode from the cover letter, where there is no prompt on the page to answer to.

Respect the limits literally. A form that truncates at 200 characters truncates mid-word, and the reader sees an answer that stops in the middle of a sentence. Count, do not estimate.

…

Source & license

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

• Author: aaddrick
• Source: aaddrick/slushpile
• License: MIT
• Homepage: https://github.com/aaddrick/slushpile#readme

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