Skip to content

docs: how to be listed as a candidate, and how to post a job - #45

Merged
ralyodio merged 1 commit into
masterfrom
worktree-docs-profile-and-posting
Sep 9, 2026
Merged

docs: how to be listed as a candidate, and how to post a job#45
ralyodio merged 1 commit into
masterfrom
worktree-docs-profile-and-posting

Conversation

@ralyodio

@ralyodio ralyodio commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

/docs covered reading the board and applying to a listing, and left the two other things a visitor arrives wanting to do — get found, and hire — as one muted aside under "Using it". Someone who wanted to be listed as a candidate, or to post a job, had to read the source or guess.

Two new sections on the page, and the same two on llms.txt so an agent gets them in the fetch it already makes.

A candidate profile

There is no profile to fill in here: a profile is a resume you published. The section says that, then covers the part that is genuinely easy to miss — saving a resume and listing it are separate decisions, so visibility is named along with what private, link and public each do, and where the address comes from.

It also documents that the directory row is read out of the Markdown rather than asked for again: the # heading is the name, the first plain line before any ## is the headline, the - **Location**: bullet is what location filters match, and the bullets under ## Skills are the tags every badge link browses by. A resume with no Skills section is invisible to all of those links, which is worth knowing before publishing rather than after.

And it states plainly that contact channels are withheld from anonymous readers and shown to signed-in ones, since that is the question a candidate has before publishing an address.

Post a job

The employer comes first and is the step easiest to miss, so it is step one rather than an aside. The front-matter example carries fields that actually exist (including salary_unpaid), the prose says which values each enum takes and that underscores, dashes and camelCase all read the same.

agent_policy gets its own paragraph — it is the field this board exists for, it defaults to disclose, and human-only is stated rather than enforced. So does the refusal to link out to a form somewhere else, with agenticjobs new <url> named as the answer instead of leaving a 400 to explain it.

Finishes with reading applications, decide, edit and close, and the browser and single-request equivalents.

Tests

Two, asserting the step easiest to drop from each: that listing a resume is documented as its own decision (visibility, public, /candidates, ## Skills), and that creating an employer appears before posting a listing.

pnpm run typecheck and pnpm run build clean; 121 tests pass (the API suite skips here, no local Postgres).

🤖 Generated with Claude Code

https://claude.ai/code/session_01D8ai32QMBsKEs1nigijSiJ

/docs explained reading and applying, which is the half the board was built
to show off, and left the other two things a visitor arrives wanting to do
as one muted aside. Somebody who wanted to be found, or to hire, had to read
the source or guess.

Two sections on /docs, and the same two on llms.txt so an agent gets them in
the fetch it already makes:

- **A candidate profile.** There is no profile to fill in: a profile is a
  resume you published. Saving one and listing one are separate decisions,
  so `visibility` is named along with what its three values do, and the
  directory row is documented as being read out of the Markdown - the `#`
  heading, the location bullet, and the `## Skills` section that the tag
  links browse by. Also says plainly that contact channels are withheld from
  anonymous readers, since that is the question a candidate has before
  publishing an address.

- **Post a job.** The employer comes first and is easy to miss, so it is
  step one rather than an aside. The front matter example carries the fields
  that actually exist, including `salary_unpaid`, and the page says which
  values each enum takes. `agent_policy` gets its own paragraph, and so does
  the refusal to link out to a form somewhere else, with the importer named
  as the answer rather than left for a 400 to explain.

The two tests assert the step that is easiest to drop from each: that
listing a resume is documented as its own decision, and that creating an
employer appears before posting a listing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01D8ai32QMBsKEs1nigijSiJ
@ralyodio
ralyodio merged commit f81351b into master Sep 9, 2026
4 checks passed
@ralyodio
ralyodio deleted the worktree-docs-profile-and-posting branch September 9, 2026 16:10
ralyodio added a commit that referenced this pull request Sep 10, 2026
Minor rather than patch because commands and endpoints were added, and
because the reason to cut this at all is that /docs is currently ahead of
the published client: it tells people to run `agenticjobs employer create`
and `agenticjobs resume publish`, and npm still ships 0.10.0, where
neither exists.

Since 0.10.1:

- Employers and resume visibility as CRUD (#48). employer
  list/show/create/update/delete, resume publish/unpublish/visibility/
  delete and --visibility on save and import, with PATCH and DELETE
  /api/v1/orgs/{slug} behind them. A rename keeps the slug; an employer
  that has published cannot be deleted.
- Getting listed and hiring are documented at all (#45), and swarm
  capacity on a candidate profile (#46).
- An address is withheld wherever it is written, and never from cache
  (#47).
- Boolean CLI flags no longer swallow the command after them (#49).
- Salary bounds read correctly in summaries and compare correctly across
  periods in search (#50, #51).
- A JSON parse failure on a 200 is reported rather than swallowed (#52).
- Job and DOCX imports keep titles, structure, tabs and line breaks
  (#53, #54).

Both version files move together: package.json and VERSION in
src/config.ts.


Claude-Session: https://claude.ai/code/session_01D8ai32QMBsKEs1nigijSiJ

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant