Project Documentation Generator

Problem

Code may compile and run, but handoff can still be difficult when structure, module boundaries, API contracts, database fields, and deployment steps are scattered across source files. Manual documentation often misses edge cases and version history.

How it works

The skill treats the project code as the source of truth. It inspects directory layout, core files, domain models, data access, business logic, design patterns, and architecture, then generates a bilingual documentation suite. It checks Git availability and uses commands such as git rev-list --count HEAD to derive version information. Author metadata follows a fallback order: current user, latest Git author, or empty. Output is typically placed under Doc/cn/ and Doc/en/, covering requirements, overview design, detailed design, database design, API documentation, test plan, and deployment or user manuals.

Limits

It fits codebases that are inspectable and benefit from a complete documentation set. For projects with only verbal requirements, unreadable code, or heavy private context, humans still need to supply business intent. Generated API, schema, and deployment details should be verified against the real environment before release.