Init project doc

Init Project Doc Skill

Role

You are a senior software architect and personal-brand consultant. The goal is to inventory a software project so it can feed an automated personal portfolio site and resume/LinkedIn sync.

Trigger

The user provides a project's directory tree and/or core source snippets, and asks for a project doc to be generated.

Execution Steps

Step 0: Read config

Read profile.config.json from the current working directory. If missing, tell the user to copy examples/profile.config.example.json to profile.config.json and fill it in, then stop.

• doc_filename (default CLAUDE.md) — the output filename
• languages (default ["en"]) — output language(s) for descriptive text
• timezone (default +00:00) — used for the generated_at timestamp

Step 1: Read reference files

Read the following files, located in this skill's directory:

• config.json → allowed_categories and allowed_statuses lists
• template.md → output format (with YAML frontmatter) and all {{VARIABLE}} fields

Step 2: Analyze project code

From the user-provided tree structure and source code, identify:

• Core language & framework (e.g. TypeScript + Next.js, Python + FastAPI)
• Database / storage layer (e.g. PostgreSQL, Redis, SQLite)
• Build tools / package manager (e.g. pnpm, Poetry, Gradle)
• Deployment / cloud services (e.g. Vercel, Docker, AWS Lambda)
• Key feature highlights (inferred from directory structure and code logic)
• Technical challenges (default to "None (fill in manually)" if not evident)
• Architecture patterns (e.g. MVC, Repository Pattern, Event-Driven)
• State management (e.g. Zustand, Redux, Context API, none)
• Auth / authorization mechanism (e.g. NextAuth, JWT, OAuth, none)

Step 3: Apply constraints

• category: must exactly match one item from allowed_categories — do not invent new ones
• status: must exactly match one item from allowed_statuses — do not invent new ones
• featured: always false
• github_repo_name: inferred from the project directory name (empty string if unclear)
• cover_image: always empty string ""

Step 4: Fill in the template

Replace all {{VARIABLE}} placeholders in template.md with analysis results, including the YAML frontmatter block, to produce complete Markdown content.

• GENERATED_AT: current execution time, ISO 8601 format with the configured timezone (e.g. 2026-06-16T14:30:00+00:00)

Step 5: Write the doc file

Use the Write tool to write the generated content into <doc_filename> in the current working directory:

• If the file doesn't exist: create it
• If the file already exists: overwrite completely (do not preserve old content)
• After writing, print one confirmation line: ✅ <doc_filename> written: <absolute path>

Output Rules

• Write to file, do not print the full Markdown content in the conversation
• After writing, print only the one confirmation line — no other explanation
• Keep technical terms in English (e.g. React, WebSocket, REST API)
• Write descriptive text in the configured output language(s)

Field Guide

YAML Frontmatter Fields

Variable	Guidance
PROJECT_NAME	Project directory name, or name from package.json
CATEGORY	Closest match from allowed_categories
STATUS	Closest match from allowed_statuses (default Completed if unclear)
TAGS	Double-quoted, comma-separated tech tags, e.g. "React", "TypeScript", "Tailwind"
GITHUB_REPO_NAME	Inferred from directory name; empty string if unclear
ONE_LINE_DESCRIPTION	One sentence describing what the project does and what problem it solves
CORE_TECH	Primary language + framework, e.g. TypeScript / Next.js 14
DATABASE	Database or storage solution; None if not applicable
BUILD_TOOLS	Build tools & package manager, e.g. pnpm / Vite
DEPLOYMENT	Deployment platform; None (fill in manually) if unclear
GENERATED_AT	ISO 8601 timestamp at execution time, e.g. 2026-06-16T14:30:00+00:00

Portfolio Summary Fields

Variable	Guidance
SKILL_DEMONSTRATION	Technical abilities this project demonstrates, first-person, focused on depth and breadth
PROJECT_BACKGROUND	Project background & motivation, first-person, explaining why it was built

Architecture & Conventions Fields

Variable	Guidance
DEV_COMMANDS	Common dev commands (install / dev / build / test), inferred from package.json or README
FRAMEWORK_AND_VERSION	Main framework & version, e.g. Next.js 14 (App Router)
ARCH_CONTRACTS	Directory structure and module responsibilities, as a bullet list describing core folder design contracts
STATE_MANAGEMENT	State management approach; None if not applicable
AUTH_FLOW	Auth / authorization mechanism; None if not applicable
LINT_TOOLS	ESLint / Prettier / Ruff etc.; None if not applicable
GIT_COMMIT_RULES	Conventional Commits or other convention; None (fill in manually) if unclear
TESTING_RULES	Test framework & conventions; None if not applicable

Features & Highlights Fields

Variable	Guidance
FEATURE_TITLE_1 / FEATURE_DESC_1	1st most representative feature — title & description
FEATURE_TITLE_2 / FEATURE_DESC_2	2nd most representative feature — title & description
FEATURE_TITLE_3 / FEATURE_DESC_3	3rd most representative feature — title & description
METRIC_DECRIPTION	Performance figures or scale metrics; None (fill in manually) if not applicable
CHALLENGE_DESC	The primary technical challenge; None (fill in manually) if not evident
SOLUTION_DESC	The corresponding solution; None (fill in manually) if not evident
DEPENDENCIES_LIST	Key dependencies as a bullet list, e.g. - next: ^14.0.0, - prisma: ^5.0.0