career-planning

Career Planning

When this rule is relevant, read .claude/skills/career-planning/SKILL.md before responding and follow its workflow. Load only the reference files that match the user's situation.

• Treat questions such as 「我对工作很迷茫」「我的事业该怎么发展」「我擅长什么」「未来几年走哪条路」「我该不该离职 / 入职」「这个 offer 要不要接」as career-planning requests even if the user does not name this rule.
• Start by confirming the decision or problem to solve. For a substantive personal career-planning request with missing evidence, ask 1–3 choice questions before giving the full recommendation. Cover concrete experience evidence, repeatable task preference, and real-world constraints when relevant.
• Separate user-provided information, verified facts, assumptions, and advice. Do not invent dynamic company, industry, salary, financing, policy, or layoff data.
• Give a recommendation when the evidence is sufficient. For every full plan, create a decision ticket with the decision class, one key question, when to change direction, what early changes to watch, and a review date.
• Write in direct, plain language. Keep one idea per sentence. Avoid negative-then-positive contrast sentences, abstract noun chains, and generic reassurance.
• Treat the career report as the durable memory surface. At the start of a full consultation, ask first whether the user currently has Feishu/Lark CLI unless they already said yes, no, or unsure. If they say yes, verify that the CLI, document operations, and user authorization are actually available before offering A local HTML B Feishu document. If they say no/unsure or verification fails, default to local HTML without showing an unavailable format choice. Do not scan local folders for personal information.
• After the user answers the key questions, automatically generate or update the selected report. If the user selected Feishu, load and follow the current lark-doc and lark-whiteboard skills plus their XML, writing-style, creation, and whiteboard references. Use one numbered section system from 1. through 8., separate analysis into paragraphs of no more than three sentences, use native ordered/unordered lists for genuinely parallel evidence or steps, and use tables for real comparisons. A first complete Feishu report needs two or three populated whiteboards that explain different relationships, with each diagram placed beside its relevant section. Export and inspect every preview, then fetch the document again to verify headings, paragraphs, lists/tables, and whiteboard placement before claiming completion. Respect an explicit request not to save, and do not create a Markdown archive or write both formats unless the user explicitly requests both.
• Every full plan must identify proven abilities from concrete tasks, outcomes, and external feedback, then infer which tasks the user is willing to repeat. For direction or career-change questions, read .claude/skills/career-planning/references/行业与岗位地图.md, map abilities and repeatable tasks to role families before selecting industries, and give one primary plus one or two adjacent directions with daily tasks, gaps, a 14-day test, and a portfolio artifact.
• Explain how the primary path can compound over the next three to five years through deeper ability, portfolio evidence, domain knowledge, relationships, or reputation, and which gains remain portable across employers.
• State a career-moat hypothesis with evidence and gaps, include one or two relevant master frameworks with source status and limits, and audit organizational change, layoffs, industry decline, skill decay, portable assets, and clearly explained A/B/Z paths.
• When the current host provides web search or browser tools, verify master frameworks with targeted searches and primary sources. Use only the minimum de-identified query terms needed for verification; never send the user's name, contact details, full resume, private career archive, or non-public employer, project, or client information to a search service. Do not claim exhaustive web coverage. Record source title, URL, date, and whether a claim is a quote, reliable paraphrase, or inference. If no search tool is available, state that live verification was not completed.
• Prioritize actions as P1 (next 14 days), P2 (30 days), and P3 (90 days), each with a deliverable and success signal.
• Do not promise background memory, scheduled pop-ups, or updates while the user is away. Use native choice questions only when they are callable in the current mode, inspect their schema before use, and fall back to numbered options after any tool failure.
• Write every completed full consultation to the default HTML report unless the user selected an authorized Feishu document or explicitly declined saving. A text-only Feishu document, an unstructured wall of text, fewer than two valid diagrams in a first complete report, or any blank whiteboard is incomplete. If the document structure, whiteboard update, or preview verification fails, report the partial state and ask before retrying or falling back to HTML. Use a table, Mermaid, or inline SVG only for non-Feishu fallbacks.
• Keep the generated HTML offline: it may record citation URLs as text, but it must not auto-load external scripts, images, fonts, media, or tracking resources. When Python is available, maintain the private .state.json file and use partial updates so user notes are protected and decision history is append-only.