[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M74YDSJS1JCRC29EF9FD8PDP":3,"skill-same:01M74YDSJS1JCRC29EF9FD8PDP":50},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":28,"commitSha":29,"skillDirectory":30,"forksCount":31,"repositoryHtmlUrl":32,"repositoryHomepageUrl":6,"ownerHtmlUrl":33,"ownerBlogUrl":34,"ownerDescription":35,"updatedAt":36,"install":37,"resources":49},"01M74YDSJS1JCRC29EF9FD8PDP","infer-status",null,"Resolve the canonical application status from signals (triage class + current status + days-since-apply \u002F days-since-last-contact + optional portal state) using the taxonomy decision table. Emits {status, next_action, next_action_due_on, rationale}; optionally updates a flat tracker.json. Honours the offer-accept guardrail and the ghosting rule.","jain777\u002Fjobclaw-skills","jain777","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F57412580?v=4","01M74YCRYXSRMZFKERV6JS8M5D","Jeevesh Jain","01M74YCRZK4C3NNAEDWG5W8YMP",7,"MIT","https:\u002F\u002Fgithub.com\u002Fjain777\u002Fjobclaw-skills\u002Fblob\u002Fmain\u002Fskills\u002Finfer-status\u002FSKILL.md",[],[],"2026-11-11 17:31:23",false,"---\nname: infer-status\ndescription: >\n  Resolve the canonical application status from signals (triage class + current status +\n  days-since-apply \u002F days-since-last-contact + optional portal state) using the taxonomy\n  decision table. Emits {status, next_action, next_action_due_on, rationale}; optionally\n  updates a flat tracker.json. Honours the offer-accept guardrail and the ghosting rule.\nwhen_to_use: >\n  Use after triage-inbox classifies new emails, before draft-reply chooses an intent\n  template, or any time the user wants to refresh the funnel state for one or many\n  applications.\nuser-invocable: true\nallowed-tools: Read, Write\n---\n\n# infer-status\n\nMap signals → status using the **taxonomy decision table** — no invention. **Hard rules:** [`..\u002F_shared\u002FRULES.md`](..\u002F_shared\u002FRULES.md). All enums, the decision table, the ghosting rule, and the offer-accept guardrail live in [`..\u002F..\u002Fknowledge\u002Fstatus\u002Ftaxonomy.md`](..\u002F..\u002Fknowledge\u002Fstatus\u002Ftaxonomy.md).\n\n## Inputs\n\n### Per-application signals (JSON; single or array)\n```jsonc\n{\n  \"job\":                    { \"company\": \"...\", \"role\": \"...\", \"job_id\": \"...\" },\n  \"current_status\":         \"applied | screening | assessment | interview | final-round | offer | accepted | rejected | withdrawn | ghosted\",\n  \"triage_class\":           \"rejection | screen | interview-invite | assessment | offer | recruiter-outbound | info | request-info | spam | other | null\",\n  \"days_since_apply\":       \"number | null\",\n  \"days_since_last_contact\":\"number | null\",\n  \"portal_state\":           \"string | null\",     \u002F\u002F verbatim portal label if scraped, e.g. \"Application Rejected\"\n  \"as_of\":                  \"YYYY-MM-DD\"\n}\n```\n\nOr `--in inbox\u002Ftriage-\u003Cdate>.json` to read triage records directly; the skill joins triage → applications by `(company, role)` or `job_id` and pulls `current_status` from `tracker.json` if present.\n\n### Flags\n- `--ghost-days N` — override the 14-day ghosting threshold.\n- `--update tracker.json` — write the new status back into `tracker.json` (only fields that changed).\n- `--confirm-accept` — **the only way** to transition `offer → accepted`. Without it, an offer stays at `offer`.\n\n## Method\n\n0. **Read the taxonomy** decision table and the ghosting rule.\n\n1. **Resolve `triage_class` if absent** by reading the latest `inbox\u002Ftriage-\u003Cdate>.json` for this job (if present). Otherwise skip the email branch and use only portal + recency signals.\n\n2. **Apply the decision table.** `(triage_class × current_status) → (next_status, suggested_action)`. Terminal email classes (`rejection`, `offer`) trump current status; `info` \u002F `request-info` \u002F `spam` never change status.\n\n3. **Override on portal signal** if present. Portal labels are ground truth when they exist (e.g., `portal_state: \"Application Rejected\"` → `rejected` regardless of email). Record the override in `rationale`.\n\n4. **Apply the ghosting rule.** If current_status is non-terminal AND `days_since_last_contact ≥ ghost_days` (default 14): status → `ghosted`; action depends on funnel position (applied\u002Fscreening → `follow-up`; interview\u002Ffinal-round\u002Foffer → `escalate`).\n\n5. **Apply the offer-accept guardrail.** Never transition to `accepted` automatically. Without `--confirm-accept`, an `offer` stays at `offer` with action `reply-ask`. With `--confirm-accept` *and* current_status `offer`, transition to `accepted`.\n\n6. **Compute `next_action_due_on`** based on the action:\n   - `reply-schedule` \u002F `reply-info` \u002F `reply-ask` → today + 1 business day.\n   - `reply-accept` (assessment) → respect the email's `deadline` if any, else +3 days.\n   - `follow-up` → today + 0 (nudge now).\n   - `acknowledge` \u002F `ignore` → `null`.\n   - `escalate` → today (route to `request-human-input` with the optional JobClaw agent).\n\n7. **Write a rationale.** One sentence per non-trivial decision (which table row fired, what triggered the override, what the ghosting rule did).\n\n## Output\n\n### Per-application result\n```jsonc\n{\n  \"job\":                  { \"company\": \"...\", \"role\": \"...\", \"job_id\": \"...\" },\n  \"prior_status\":         \"applied\",\n  \"status\":               \"screening\",\n  \"next_action\":          \"reply-schedule\",\n  \"next_action_due_on\":   \"YYYY-MM-DD\",\n  \"rationale\":            \"interview-invite × screening → final-round per taxonomy table; deadline 2026-06-02 noted\",\n  \"as_of\":                \"YYYY-MM-DD\"\n}\n```\n\nSingle input → object; batch input → array.\n\n### Stdout\nTight table: `job · prior → next · action · due · rationale (truncated)`. Flag `escalate` rows + any status reverting (e.g., `interview → ghosted`).\n\n### Optional tracker update\nWith `--update tracker.json`: read JSON `{applications: [{job_id, ...}]}`; merge new `status` \u002F `next_action` \u002F `next_action_due_on` \u002F `last_status_change` into the matching record. Don't overwrite fields you didn't compute; preserve user notes.\n\n## Anti-patterns\n- Inventing a status from a noisy thread; default to `unchanged` + `acknowledge` when signals are weak.\n- Treating `recruiter-outbound` (cold inbound, no prior application) as `screening`.\n- Transitioning `offer → accepted` without `--confirm-accept`.\n- Ignoring the portal signal when present.\n- Using more than `--ghost-days` for the ghosting threshold without recording it in `rationale`.\n- Emoji.\n\n## Rubric\n- [ ] Status ∈ taxonomy enum; action ∈ taxonomy action enum.\n- [ ] `rationale` cites the table row or the override that fired.\n- [ ] No `accepted` without `--confirm-accept` *and* a prior `offer`.\n- [ ] `ghosted` only set when `days_since_last_contact ≥ ghost_days` AND current_status is non-terminal.\n- [ ] `next_action_due_on` is set when `next_action` is reply-ish; `null` when not.\n\n## Next steps\nStatus updated. Next: `\u002Fdraft-reply` with the suggested intent (or `\u002Fcoach-negotiation` if it's an offer).\n","# infer-status\n\nMap signals → status using the **taxonomy decision table** — no invention. **Hard rules:** [`..\u002F_shared\u002FRULES.md`](..\u002F_shared\u002FRULES.md). All enums, the decision table, the ghosting rule, and the offer-accept guardrail live in [`..\u002F..\u002Fknowledge\u002Fstatus\u002Ftaxonomy.md`](..\u002F..\u002Fknowledge\u002Fstatus\u002Ftaxonomy.md).\n\n## Inputs\n\n### Per-application signals (JSON; single or array)\n```jsonc\n{\n  \"job\":                    { \"company\": \"...\", \"role\": \"...\", \"job_id\": \"...\" },\n  \"current_status\":         \"applied | screening | assessment | interview | final-round | offer | accepted | rejected | withdrawn | ghosted\",\n  \"triage_class\":           \"rejection | screen | interview-invite | assessment | offer | recruiter-outbound | info | request-info | spam | other | null\",\n  \"days_since_apply\":       \"number | null\",\n  \"days_since_last_contact\":\"number | null\",\n  \"portal_state\":           \"string | null\",     \u002F\u002F verbatim portal label if scraped, e.g. \"Application Rejected\"\n  \"as_of\":                  \"YYYY-MM-DD\"\n}\n```\n\nOr `--in inbox\u002Ftriage-\u003Cdate>.json` to read triage records directly; the skill joins triage → applications by `(company, role)` or `job_id` and pulls `current_status` from `tracker.json` if present.\n\n### Flags\n- `--ghost-days N` — override the 14-day ghosting threshold.\n- `--update tracker.json` — write the new status back into `tracker.json` (only fields that changed).\n- `--confirm-accept` — **the only way** to transition `offer → accepted`. Without it, an offer stays at `offer`.\n\n## Method\n\n0. **Read the taxonomy** decision table and the ghosting rule.\n\n1. **Resolve `triage_class` if absent** by reading the latest `inbox\u002Ftriage-\u003Cdate>.json` for this job (if present). Otherwise skip the email branch and use only portal + recency signals.\n\n2. **Apply the decision table.** `(triage_class × current_status) → (next_status, suggested_action)`. Terminal email classes (`rejection`, `offer`) trump current status; `info` \u002F `request-info` \u002F `spam` never change status.\n\n3. **Override on portal signal** if present. Portal labels are ground truth when they exist (e.g., `portal_state: \"Application Rejected\"` → `rejected` regardless of email). Record the override in `rationale`.\n\n4. **Apply the ghosting rule.** If current_status is non-terminal AND `days_since_last_contact ≥ ghost_days` (default 14): status → `ghosted`; action depends on funnel position (applied\u002Fscreening → `follow-up`; interview\u002Ffinal-round\u002Foffer → `escalate`).\n\n5. **Apply the offer-accept guardrail.** Never transition to `accepted` automatically. Without `--confirm-accept`, an `offer` stays at `offer` with action `reply-ask`. With `--confirm-accept` *and* current_status `offer`, transition to `accepted`.\n\n6. **Compute `next_action_due_on`** based on the action:\n   - `reply-schedule` \u002F `reply-info` \u002F `reply-ask` → today + 1 business day.\n   - `reply-accept` (assessment) → respect the email's `deadline` if any, else +3 days.\n   - `follow-up` → today + 0 (nudge now).\n   - `acknowledge` \u002F `ignore` → `null`.\n   - `escalate` → today (route to `request-human-input` with the optional JobClaw agent).\n\n7. **Write a rationale.** One sentence per non-trivial decision (which table row fired, what triggered the override, what the ghosting rule did).\n\n## Output\n\n### Per-application result\n```jsonc\n{\n  \"job\":                  { \"company\": \"...\", \"role\": \"...\", \"job_id\": \"...\" },\n  \"prior_status\":         \"applied\",\n  \"status\":               \"screening\",\n  \"next_action\":          \"reply-schedule\",\n  \"next_action_due_on\":   \"YYYY-MM-DD\",\n  \"rationale\":            \"interview-invite × screening → final-round per taxonomy table; deadline 2026-06-02 noted\",\n  \"as_of\":                \"YYYY-MM-DD\"\n}\n```\n\nSingle input → object; batch input → array.\n\n### Stdout\nTight table: `job · prior → next · action · due · rationale (truncated)`. Flag `escalate` rows + any status reverting (e.g., `interview → ghosted`).\n\n### Optional tracker update\nWith `--update tracker.json`: read JSON `{applications: [{job_id, ...}]}`; merge new `status` \u002F `next_action` \u002F `next_action_due_on` \u002F `last_status_change` into the matching record. Don't overwrite fields you didn't compute; preserve user notes.\n\n## Anti-patterns\n- Inventing a status from a noisy thread; default to `unchanged` + `acknowledge` when signals are weak.\n- Treating `recruiter-outbound` (cold inbound, no prior application) as `screening`.\n- Transitioning `offer → accepted` without `--confirm-accept`.\n- Ignoring the portal signal when present.\n- Using more than `--ghost-days` for the ghosting threshold without recording it in `rationale`.\n- Emoji.\n\n## Rubric\n- [ ] Status ∈ taxonomy enum; action ∈ taxonomy action enum.\n- [ ] `rationale` cites the table row or the override that fired.\n- [ ] No `accepted` without `--confirm-accept` *and* a prior `offer`.\n- [ ] `ghosted` only set when `days_since_last_contact ≥ ghost_days` AND current_status is non-terminal.\n- [ ] `next_action_due_on` is set when `next_action` is reply-ish; `null` when not.\n\n## Next steps\nStatus updated. Next: `\u002Fdraft-reply` with the suggested intent (or `\u002Fcoach-negotiation` if it's an offer).\n",{"name":5,"description":24,"when_to_use":25,"allowed-tools":26,"user-invocable":27},"Resolve the canonical application status from signals (triage class + current status + days-since-apply \u002F days-since-last-contact + optional portal state) using the taxonomy decision table. Emits {status, next_action, next_action_due_on, rationale}; optionally updates a flat tracker.json. Honours the offer-accept guardrail and the ghosting rule.\n","Use after triage-inbox classifies new emails, before draft-reply chooses an intent template, or any time the user wants to refresh the funnel state for one or many applications.\n","Read, Write",true,"main","68211e04d37044c49c3a91f3a29ce9647fada95f","skills\u002Finfer-status",1,"https:\u002F\u002Fgithub.com\u002Fjain777\u002Fjobclaw-skills","https:\u002F\u002Fgithub.com\u002Fjain777","https:\u002F\u002Fjeevesh.me\u002F","Product Manager | Builder | Claude Coder","2026-06-09 13:47:19",{"source":8,"skillName":5,"commands":38,"prompt":48,"zipAvailable":27},[39,42,45],{"tool":40,"command":41},"npx","npx skills add jain777\u002Fjobclaw-skills --skill infer-status",{"tool":43,"command":44},"bunx","bunx skills add jain777\u002Fjobclaw-skills --skill infer-status",{"tool":46,"command":47},"pnpm","pnpm dlx skills add jain777\u002Fjobclaw-skills --skill infer-status","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjain777\u002Fjobclaw-skills\u002Fblob\u002Fmain\u002Fskills\u002Finfer-status\u002FSKILL.md",[],[51,58,65,72,79,86],{"skillNo":52,"name":53,"nameZh":6,"description":54,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":55,"categories":56,"keywords":57,"publishedAt":19},"01M74YF759275CXY2ZWZBA1PD0","write-outreach","Write a short, profile-grounded cold outreach message to a recruiter, hiring manager, or potential referrer — LinkedIn DM or email — with one clear CTA and no flattery.","https:\u002F\u002Fgithub.com\u002Fjain777\u002Fjobclaw-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-outreach\u002FSKILL.md",[],[],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":19},"01M74YF3WPDQ9D2PJ00XWH29EA","write-cover-letter","Produce a job-specific, profile-grounded cover letter in markdown — ≤ 350 words, ≤ 1 page, three paragraphs (hook → two quantified proofs → fit close). Reuses keywords from a prior tailor-resume sidecar when present. Writes a JSON sidecar reserved for a future \u002Frender-resume --kind cover-letter (rendercv).","https:\u002F\u002Fgithub.com\u002Fjain777\u002Fjobclaw-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-cover-letter\u002FSKILL.md",[],[],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":19},"01M74YF106JXZQ3DMDMVR722YH","triage-inbox","Classify a recruiting email (or a batch) into one of the 10 canonical email classes, extract structured fields (company \u002F role \u002F dates \u002F links \u002F asks \u002F deadline \u002F sentiment), and suggest the next action. Writes inbox\u002Ftriage-\u003CYYYY-MM-DD>.json — consumed by infer-status and draft-reply.","https:\u002F\u002Fgithub.com\u002Fjain777\u002Fjobclaw-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriage-inbox\u002FSKILL.md",[],[],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":19},"01M74YEX348VFDH9FG9C00WKG3","tailor-resume","Produce a job-specific, ATS-optimized resume from the user's master profile and a target job — reordering, reframing, and surfacing the most relevant real experience and keywords. Enforces a content rubric (bullet shape, length, parallel grammar, metric coverage), then renders a polished PDF by default (via render-resume) and visually QAs it. Never fabricates.","https:\u002F\u002Fgithub.com\u002Fjain777\u002Fjobclaw-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftailor-resume\u002FSKILL.md",[],[],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":19},"01M74YESFCVSEG3C0AB8QXVJBR","score-fit","Score how well the user's master profile fits a specific job — an ATS-style match percentage with matched\u002Fmissing keywords, strengths, gaps, and a clear apply-or-skip recommendation. Optionally writes a structured sidecar that tailor-resume consumes.","https:\u002F\u002Fgithub.com\u002Fjain777\u002Fjobclaw-skills\u002Fblob\u002Fmain\u002Fskills\u002Fscore-fit\u002FSKILL.md",[],[],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":19},"01M74YEP224H6Z9Q2K16YZ47K8","review-render","Visually QA a rendered resume PDF and auto-fix layout\u002Fcontent defects in a bounded loop: render → screenshot → deterministic gate → vision rubric → apply one fix → re-render, until it passes or hits a pass cap. Catches widows, under-fill, overflow, orphaned headers, and imbalance that text-only logic can't see.","https:\u002F\u002Fgithub.com\u002Fjain777\u002Fjobclaw-skills\u002Fblob\u002Fmain\u002Fskills\u002Freview-render\u002FSKILL.md",[],[]]