Build your own Compass: the system is now a public build kit

Compass finished its first job when my search ended, but one useful question remained: could someone else build the system without inheriting my data, my assumptions, or the private machinery around it?

I have now packaged the answer as a public repository: Build Your Own Compass.

This is not a copy of my career database and it is not a hosted job-search service. It is a clean build specification for the parts that earned their keep: a deliberate target list, first-party job-board monitoring, evidence-based scoring, verified warm paths, opportunity tracking, next actions, proof points, and a weekly review that changes the system when reality disagrees with it.

The intended interface is an AI coding harness. Give Claude Code, Codex, or another capable harness the GitHub URL, tell it to follow the repository instructions, and build a private implementation around your own rubric and workflow.

Change summary

This release adds a public, reusable version of the Compass method rather than publishing the original application.

• A phased build log explains the product decisions in the order they should be made.
• Numbered prompts give an AI harness enough context, constraints, examples, and acceptance checks to implement each phase.
• AGENTS.md and CLAUDE.md tell the harness how to work, where private data may live, and when it must stop for a decision.
• Synthetic examples and templates make the data model concrete without exposing a real search.
• First-party job-board ingestion is part of the core build, with provider failures isolated and source history preserved.
• A release check scans tracked files for common privacy mistakes before anything is made public.

The public repository contains the specification and safe scaffolding. The person using it creates a separate private data directory for resumes, contacts, messages, notes, job records, databases, and credentials. That boundary is established before the harness sees real career information.

Why this is useful

Most job-search tools start with volume. They collect more listings, encourage more applications, and turn activity into the closest available substitute for progress. Compass starts with a smaller question: what deserves attention next, and what evidence supports that decision?

That changes the order of the build.

The first phase is not a dashboard. It is a personal rubric with hard constraints, preferences, confidence, and explicit unknowns. The second phase establishes the privacy boundary. A hand-curated target universe comes before automated ingestion because the software should monitor companies you deliberately chose, not manufacture a convincing list from weak signals.

Once those decisions exist, automation becomes useful. Public first-party job boards can be checked on a schedule. Roles can be normalized and compared without losing the source posting. Known relationships can be connected to target companies without pretending that a shared employer or social-network connection is a warm introduction. Every active opportunity can carry one next action and one date. The weekly review can then ask what changed rather than presenting another pile of stale records.

The result is less like an application tracker and more like an operating system for a finite search. It keeps research, relationships, opportunities, and commitments close enough that the next move is visible without asking a model to invent certainty.

The fastest way to start

Open your preferred AI coding harness and give it this repository:

1https://github.com/projectwong/compass-job-search

Then use this prompt:

1Use this repository as the product specification for my own Compass job-search system.2Clone it, read AGENTS.md, README.md, docs/privacy.md, and docs/build-log.md, then3work through the numbered phases in order. Keep all of my real career data outside4the repository. Start by helping me define my rubric and acceptance checks. Do not5build a dashboard until the file-based daily and weekly workflows work. Treat6first-party job-board ingestion as a core capability, but do not scrape authenticated7sites, send messages, or submit applications. At the end of each phase, run its8checks, show me what changed, and wait for my approval before continuing.

That prompt is intentionally procedural. It makes the harness read the constraints before writing code, separates public scaffolding from private data, and keeps the build in phases that can be tested or discarded independently.

The repository recommends Markdown, YAML, SQLite, and standard-library Python for the first version. Those choices are not sacred. Their advantage is that the records remain inspectable, the workflow works without a server, and there is very little infrastructure to maintain while the product is still proving itself.

What the harness should build

The build log is organized around twelve increments, each with a purpose and an acceptance check.

1. Define the rubric that separates eligibility, fit, confidence, and priority.
2. Put the public-code and private-data boundary in place.
3. Create a small data model with sources and revision history.
4. Build the target universe by hand.
5. Add first-party job-board adapters for those companies.
6. Score evidence without turning missing information into a negative fact.
7. Find verified warm paths through people the user actually knows.
8. Produce a small working set with a real action attached to every company.
9. Track opportunities and conversations without automating communication.
10. Maintain a sourced proof-point library for applications and interviews.
11. Run a weekly review that can change the rubric and archive stale work.
12. Add an interface only after the underlying workflow has survived repeated use, then run the public-release checks.

The ordering matters. Building the interface early produces a polished container for decisions that have not been made. Automating discovery before the target universe exists produces a large list that looks objective because a computer made it. Scoring before source and confidence are modeled turns unknowns into numbers that are easy to trust and hard to defend.

First-party job boards are core

Job-board ingestion belongs in the main path because a deliberately chosen company is only useful if the system can notice when its opportunities change.

Each provider adapter fetches a public first-party feed, stores the source payload or a revision reference, normalizes only published facts, and hands scoring off to a later stage. Request pacing, bounded retries, isolated provider failures, safe closure rules, and revision history are part of the acceptance criteria. One broken provider should not erase the rest of a scan, and a temporarily missing posting should not be treated as proof that the job closed.

The kit explicitly excludes authenticated scraping. It also excludes automatic applications and outreach. Those are not missing features. They preserve the point at which a person should read, decide, and take responsibility for the action.

Validation and privacy

The repository contains only prompts, documentation, schemas, code scaffolding, and synthetic examples. Before publishing it, I checked every tracked file for names, career details, credentials, local paths, and references to private projects. The original system and the data from the search remain private.

The kit also includes a repeatable public-repository check. It cannot replace a human reading the diff, but it gives every release a minimum mechanical gate and makes the privacy boundary part of the product rather than a note added at the end.

What this does not claim

The repository does not claim that Compass found me a job, that its score can decide whether someone should pursue a role, or that another person's search should look like mine. People, conversations, interviews, timing, and judgment did the real work. The system reduced the cost of keeping those things coherent.

It also does not include my target companies, contacts, messages, notes, proof points, application history, or private implementation. A useful starter kit should transfer the method without transferring the person who used it first.

Next steps

The next useful evidence will come from someone other than me building from the repository.

I want to learn where an AI harness still needs hidden context, which phase creates the first genuinely useful daily view, and whether the privacy boundary remains understandable when real data arrives. I also want the first-party adapters to grow from demonstrated demand, one public provider at a time, rather than becoming a speculative catalog.

The public backlog is therefore short:

• Follow the kit from a clean directory with no knowledge of the original Compass.
• Add tests and adapter examples when a real target list requires them.
• Record unclear instructions as repository issues and repair the specification before adding features.
• Keep the Markdown workflow as the reference behavior even if a richer interface is added.
• Revisit the build after two weekly reviews and delete anything that is not changing a decision or making a next action easier to see.

Compass is complete as my job-search project. This repository is the reusable artifact that remains: enough structure for someone else to build deliberately, without turning my private system into their template.

Open the public repository and build your own Compass.