This Skill guides the Agent to, based onthe current project/code repositorygenerate various documents, supporting four types: paper chapters, project overview, key issues, and resume project descriptions.
Step 0: Task Identification
| User statement / keywords | Execution |
|---|---|
| Paper chapters, system design, overall design, detailed design | reference/thesis-chapter.md |
| Project overview, project document structure, organize by format | reference/overview.md |
| Key issues, technical difficulties, unresolved issues, project risks | reference/key-issues.md |
| Resume project description, project experience, by resume format | reference/resume-format.md |
Cases not belonging to these four: what the user wants is project documentation to show new colleagues that they can follow to get started (newcomer docs, architecture docs, code walkthrough, onboarding), use project-docs. What this Skill produces is something written in the format specified by the other party, to be shown to mentors/judges/HR/leaders.
How to read a project
All four types require reading the code first. Do not try to read all source files; do it in three steps:
- Look at the outline — directory tree (excluding
node_modules/build/dist/vendor), build and dependency files (package.json/pom.xml/requirements.txt/go.modetc.), README, to determine what the project does and what tech stack it uses - Look at the skeleton — entry files, route or interface definitions, configuration files, one-sentence responsibility for each top-level directory
- Read more by type
- Paper chapters: deployment-related files, how modules call each other
- Project overview: the parts explicitly requested in the user's format (if it says "core interfaces", go read the route table)
- Key issues:
TODO/FIXME, Known issues / Limitations in the README, exception handling and fallback logic - Resume project description: quantifiable things (number of interfaces, number of modules, test coverage), only write when there is real evidence
Tech stack, module names, and interface names must match the code word for word; do not rewrite from impression.
When to use
- The user needs to generate paper chapters, a project overview, a key issues list, or a resume project description based on the current project
- The user mentions "based on the current project", "based on the code", "follow this format..."
General principles
- Do not fabricate: do not include content that does not appear in the repository
- Evidence-based: extract as much as possible from code, comments, README, and documentation
- Format compliance: when the user provides a format/template, organize the output strictly according to the format