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 `` 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: ✅ written:

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 |

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: jasonChen0604
• Source: jasonChen0604/codebase-to-portfolio
• License: MIT

Install and usage instructions live in the source repository linked above.