project-guide

/project-guide: project guide + project interview experience

Based on the project repository, project description, tech stack, and job search direction provided by the user, organize a real project into a source code course, or guide and interview experience materials. This skill focuses on "how to learn the project, how to present it, and how it will be probed"; it does not fabricate companies, positions, data, launch results, or personal responsibilities for the user.

Routing boundaries

Need to generate a source code course, accompanying comprehension questions, learning path, project highlights, or a finished project interview experience document from a project repository or project materials: use /project-guide。
Only need to turn experience into resume bullets, position positioning, or an HR opening statement: use /great-resume。
Already have a resume and need to simulate interviews, predict questions, or assess mastery through round-by-round follow-ups: use /interview。
Need to generate an editable HTML/PDF resume: use /make-resume; if no template is specified, the ASu template is used by default, and other templates can also be specified in the request.
Need to find open source contribution candidates, prepare a diff, or submit a PR: use /contributor。

Input contract

Prefer reading project facts from the current workspace, then combine with user materials. First choose the "source code course" or "guide interview experience" mode according to the user's request; if unspecified, use guide interview experience mode. When key information is missing, ask at most 3 high-signal questions; when the user requests a first draft, it is allowed to use 待补 to mark gaps.

Field	Required	Description
Project source code	Required for source code course	Local repository or current workspace; when only a project description is available, a verified function call route cannot be generated
Project description	Required for guide interview experience	Background, goals, responsibilities, difficulties, results; the more specific, the better
Operation	Required for source code course	Course outline, expand specified course, accompanying exercises, or a combination of operations explicitly requested by the user
Course number	Required when expanding or doing exercises	Must be locatable in the existing course file
Abbreviation	Strongly recommended for guide interview experience	Used for file name `导学-{简称}.md`、`面经-{简称}.md`
Tech stack	No	Language, framework, middleware, observability, release method
Job search direction	No	Frontend, backend, AI, data, product, or cross-disciplinary direction

When guide interview experience materials are insufficient, prioritize asking:

What are your personal responsibilities and collaboration boundaries in the project?
What is the technical difficulty in the project that can be expanded on most, and how can the phenomena before and after the solution be verified?
Are there metrics, logs, PRs, screenshots, launch records, or user feedback that can serve as evidence?

Optional scripts:

python3 scripts/project_guide.py check --file description.txt --tech "React, TypeScript" --role "前端"
python3 scripts/project_guide.py build-prompt --short-name "智能BI" --description "..." --tech "..." --role "..."

Source code course mode

Enter this mode when the user asks to split the repository into lessons, expand a specified lesson, or generate lesson exercises. When no specific operation is specified, first generate a course outline, and do not automatically expand all lessons or create exercises.

This mode maintains course files (the file name is formed by concatenating tutorial and .md ) and exercise files (the file name is formed by concatenating practice and .md ).

Course Outline

Read thecourse outline specification；
Inspect the project entry points, main functions, module boundaries, and representative execution flows;
Generate a course outline in the course file, giving for each lesson a reading order of real files and symbols;
Record the source code version, the actual coverage scope, and the modules not yet covered.

Expand a Specified Lesson

Read the existing course file and thesingle-lesson explanation specification；
Confirm the lesson number, topic, preceding and following boundaries, and source code scope;
Expand the lesson along the real call or event order, and conclude by connecting it into a complete flow;
Only update the specified lesson, and preserve other lessons and user notes.

Companion Comprehension Questions

Read the corresponding lesson in the course file and thecompanion exercise specification；
Update the lesson exercises with the same number and title in the exercise file;
By default, generate only the questions and the necessary answer requirements, without standard answers;
Test only content already covered in the lesson, and preserve the exercises and user answers for other lessons.

When the user explicitly requests combined operations or synchronization, execute the operations included in the request in the dependency order of "outline → expand → exercises", and create only the files needed for this session.

Source Code Facts and Local Updates

Organize each lesson around a project scenario that can go from trigger to result, first giving a compact main chain, then numbered reading steps.
Files, functions, methods, events, and configuration locations must be locatable in the current source code. When documentation conflicts with the implementation, the implementation prevails and the discrepancy must be pointed out.
Direct calls and asynchronous events must be explained separately. Queues, callbacks, and dependency injection must be traced to registration, binding, or consumption evidence; runtime targets that cannot be confirmed are marked as 待确认, stopping at the proven interface boundary.
Only explain exception, recovery, and cleanup paths already implemented in the source code. When there is no evidence for design motivation, mark it as analysis; when there is no measurement of performance gains, do not draw conclusions.
Before editing, read the complete target file, and replace only the sections requested by the user. When reordering, merging, or deleting lessons, check the affected numbers, titles, and exercise references.
If the course file or exercise file is already used for other purposes, preserve the original file and explain the conflict, and switch to a file name that will not overwrite the original text.

Resume Bullet Constraints

Generate 面经-{简称}.md Before that, first compare against domain-neutral Bullet few-shot. The few-shot is only for learning the expression structure; the project names, numbers, domain terms, or metrics in it must not be copied.

Resume bullets must first extract 4-6 architectural pillars, and then be drafted. Each first-level bullet must begin with **通用支柱名：** , followed by a clear statement of:

Problem or evolution: why the original form was not good enough.
Mechanism: what general engineering mechanism was adopted, and how it works.
Constraints or boundaries: timeouts, concurrency, idempotency, degradation, observability, extension points, etc.
Outcome: verifiable architectural changes or real metrics; when there is no evidence, write a measurement plan and do not fabricate numbers.

Pillar names must be architectural or engineering capabilities that an external interviewer can understand, such as layered fault tolerance, scalable orchestration, and request reliability governance. Project implementation names cannot directly serve as pillar names;RunManager、Stream Bridge、execution id implementation names of this kind should be rewritten as generic expressions or moved down into the source code evidence index.

Delete unverifiable outcomes such as "improve performance / improve stability / optimize experience"; private functions, paths, internal enums, and business jargon should only go into the source code evidence index.

Hard deliverables

In the target project root directory specified by the user or the current workspace, write the corresponding files according to the selected mode:

Mode	File	Content
Source code course	Course file	Course outline and course content that has already been expanded
Source code course exercises	Exercise file	Comprehension questions corresponding to the course numbers and titles
Study guide interview experience	`导学-{简称}.md`	Project learning path, source code reading order, core principles, design decisions, and verification suggestions
Study guide interview experience	`面经-{简称}.md`	Resume-ready summary, interview questions, first-person STAR spoken script, follow-up questions, and source code evidence index

Only generate both sets of files at the same time when the user explicitly requests a combination of the two modes.{简称} Use the value given by the user; if not given, extract 2-8 characters from the project name or description. Must not contain / \ : * ? " < > | or other path-illegal characters.

If the current environment cannot write files, output an independent Markdown code block in the conversation and indicate the target file name.

Study guide file structure

导学-{简称}.md Output in the following order:

Prerequisite knowledge (marked by interview frequency)
- Table columns: knowledge point / why it is needed / its location in this project / frequency.
Key highlights and learning order (look at this first)
- 3-6 items.
- Table columns: highlight title / why it matters / generic technical keywords / which files to look at first / recommended learning order.
- Highlight titles should preferably use generic engineering expressions, such as state modeling, asynchronous orchestration, cache consistency, performance governance, fault-tolerant degradation, and observability and localization.
Essential knowledge points
- A concise checklist.
Recommended reading (combined with the repository)
- Table columns: topic / generic technical points / recommended reading location / estimated time / what you will be able to answer after reading.
- Each recommended reading location must give a project-relative path; when unknown, write 仓库未提供路径，待补。
Self-study reminder
- Always include: if you cannot understand a certain file or principle, please continue to ask AI follow-up questions; this skill is responsible for providing the learning path and questions, and does not provide line-by-line explanations.
Project technical positioning
- Frontend / backend / AI / data / product / cross-domain + one sentence of basis.
Core principle analysis
- 3-6 items, using "problem -> mechanism -> its landing point in this project".
Key design decisions
- Alternatives / trade-offs / risks / verification.
Quantification and verification (including pending measurement, suggested)
- Explain how to test in a suggestive tone; when there is no data yet, write 待测。

Interview experience file structure

面经-{简称}.md Output in the following order:

Project overview (usable for resume, 1-2 sentences)
- State clearly "what it does + key technology/form + key capabilities".
- Do not stack internal private names.
Resume bullets (4-6 items)
- Each first-level bullet must start with **通用支柱名：** .
- First explain the problem or evolution and personal responsibility, then write the mechanism, constraints or boundaries, and results.
- Each item expresses only one pillar, and contains at least "problem or evolution + mechanism + result".
- When there is no reliable data, write qualitative architecture results or a measurement plan; do not fabricate percentages, user counts, latency, or rankings.
Interview questions (15-25 main questions)
- Main questions are organized from high to low frequency.
- They may be grouped into 3-6 themes, with each theme having at least 1 main question and 2 follow-ups.
- 15-25 counts only main questions; follow-ups are not counted.
- Each main question and follow-up must include a first-person spoken version, and must be no less than 150 Chinese characters.
- The spoken version should cover STAR: situation, task, action, result.
- The recommended narrative order is: scenario phenomenon -> attribution -> action -> result or fallback.
Source code evidence index
- Table columns: theme / key paths and internal symbols / corresponding main text location.
- Specific file names, function names, private fields, tracking points, and internal container names are concentrated here.

Internal terminology constraints

The default reader of an interview experience is an external interviewer. The main text should mainly use general engineering language, and should not directly dump team jargon on the interviewer.

The following content should be actively abstracted in the main text of the interview experience:

Private frameworks, private components, self-developed hooks, internal APIs.
Project-internal function names and utility function names.
Backend underscore fields, private enums, internal status codes.
Tracking event names, dynamic configuration keys, gray-release toggle keys.
Client-side private container names, private JSBridge namespaces.
3-5 character Chinese business code names or team-internal nicknames.

Translation methods:

Private hook/action -> store's read hook / write action.
Layered functions -> first-level routing decisions / second-level view state machine.
Backend fields -> semantic business meanings.
Tracking events -> tracking for a certain type of lifecycle or result metric.
Gray-release toggle -> feature toggle delivered by the configuration center.
Business code name -> a certain campaign, a certain sub-product, a certain business process.

Budget:

In the spoken main questions, blacklisted internal terms may appear at most 2 times, and each time must be immediately followed by a general abstract explanation.
In the spoken follow-ups, blacklisted internal terms may appear at most 1 time.
If the budget is violated, rewrite that question.

Handoff with the ASu workflow

After completing the guided interview experience deliverable, attach two handoff summaries in the final reply:

Project fact summary handed off to /great-resume

Includes:

Project name and target role.
Boundaries of personal responsibility.
Key technical actions.
Verifiable evidence.
Candidate statements that can be written into the resume.
Metrics to be supplemented or facts to be confirmed.

High-risk Claim list handed off to /interview