What it does

Project2Job is for someone preparing an early-career AI Product Manager, Agent Product Manager, or Applied AI Product application. Its intended workflow starts with one target job description, identifies the stated role requirements, and routes toward one project for deeper evidence inspection. It separates what a résumé claims from what project artifacts actually establish.

The host-native Skill Alpha has a router and six specialists for a brief, evidence audit, company intelligence, answer preparation, a mock interview, and one next build action. It runs inside a compatible agent host and relies on that host for file access, Git, search, fetch, and storage. It is not a standalone service.

The shared evidence contracts distinguish plans, implementation, tests, user validation, and outcomes. Company research can influence how an answer is framed; it cannot strengthen a project fact. Citation validation checks that exported source locations resolve to actual text in permitted evidence, rather than accepting a schema-valid reference alone.

After consent, a local Context Registry retains minimal project/job/run identity, fingerprints, confirmed facts, ownership boundaries, and output references. It reuses compatible work and invalidates affected results when sources change. It does not monitor files or regenerate in the background. Users can refresh, start from scratch, avoid saving, or forget context.

The separate stateful Agent V0 handles a bounded project or job-description update: inspect the change, recheck dependent claims, preserve unrelated outputs, and explain what changed. Its deterministic mechanics and host-mediated paths should not be mistaken for a production autonomous agent runtime.

What I worked on

I worked on the product definition and engineering: the role-backwards workflow, evidence-status rules, shared output contracts, Skill suite, consent boundary, citation gate, and update mechanics. AI-assisted building and host-mediated generation are part of the implementation and dogfood process. The evaluation distinguishes those generated artifacts from deterministic checks and from human judgments that have not yet happened.

What has been checked

The documented repository snapshot at revision c283ad4 records 312 automated tests, including source-resolution regressions, output contracts, routing, and update behavior. That evaluation revision is on the public codex/day5-evaluation-closeout branch; the repository’s default main is older. This is a historical engineering snapshot, not a claim that the full suite was rerun for this record or that 312 users tested the product.

Day 5 compares three Project2Job outputs with three outputs from a strong general-purpose prompt supplied with the same evidence rules and output contract. All six outputs pass the schema. Six of eight deterministic checks tie; each system fails source resolution on a different case. The report does not establish Skill superiority.

One failure exposed an undefined citation convention: a project claim pointed at a blank line because the run counted body lines differently. The resulting fix defines source-location grammar and resolves citations before export. Owner dogfood also exists, but it is not independent target-user validation. Blind reviewer scores remain null.

What remains unproven

Hiring or interview outcomes, independent user benefit, reviewer preference, broad cross-host behavior, and production web-app maturity remain unproven. The local renderer demonstrates report states. Fixture-based evaluation does not establish production retrieval quality or live-model reliability.

The public repository contains the implementation. The Day 5 evaluation record documents the comparison, citation failure, and pending human review.