π λ¬Έμν μ€μνΈ (Dev Doc Suite)
μ΄ μν¬νλ‘μ°λ dev-doc-suite μ€ν¬μ μ¬μ©νμ¬ νλ‘μ νΈ λ¬Έμλ₯Ό μ½λλ νμ 'μ§μ€(Truth)'μ΄λΌλ μμΉ νμ μ΅μ μνλ‘ μ μ§ν©λλ€.
1. μ΄κΈ°ν (Initialization)
- μ€ν¬ λ‘λ:
this documentλ₯Ό μ½μ΄ λ¬Έμν μμΉ(Core Principles)μ νμ ν©λλ€. - λμ νμΈ: μ¬μ©μμκ² λ¬Έμνν λμ(μ 체 νλ‘μ νΈ, νΉμ λͺ¨λ, λλ νΉμ νμΌ)μ 묻μ΅λλ€.
2. λΆμ (Analysis - Phase 1)
"μ½λκ° κ³§ λ¬Έμμ μμ²μ λλ€."
- ꡬ쑰 νμ
: λμ κ²½λ‘μ λν΄
list_dirλ₯Ό μννμ¬ νμΌ κ΅¬μ‘°λ₯Ό νμ ν©λλ€. - λ΄μ© μ€μΊ: μ£Όμ νμΌ(μ§μ
μ , ν΅μ¬ λͺ¨λ)μ λν΄
view_file_outlineλλread_fileμ μ¬μ©νμ¬ ν΄λμ€, ν¨μ μκ·Έλμ², λ μ€νΈλ§(Docstring)μ μΆμΆν©λλ€. - μμ‘΄μ± λΆμ: μ£Όμ νμΌλ€μ΄ μλ‘ μ΄λ»κ² μ°κ²°λμ΄ μλμ§ νμ ν©λλ€.
3. μμ± (Drafting - Phase 2)
"λ μλ₯Ό λ¨Όμ μκ°νμΈμ (κ°λ°μ vs μ¬μ©μ)."
- μ΄μ μμ±: λΆμλ λ΄μ©μ λ°νμΌλ‘ λ¬Έμ μ νμ μ ννμ¬ μμ±ν©λλ€. (SKILL.md μ°Έμ‘°)
- Code Docs (Docstrings): ν¨μ/ν΄λμ€ λ¨μμ μμΈ μ€λͺ (Python/JS).
- API Docs: REST API μλν¬μΈνΈ λͺ μΈ (Request/Response).
- Architecture: Mermaid λ€μ΄μ΄κ·Έλ¨μ ν¬ν¨ν μμ€ν ꡬ쑰λ.
- README: νλ‘μ νΈ λͺ©μ , μ€μΉ, μ¬μ©λ²μ ν¬ν¨ν λλ¬Έ.
- Explanations: 볡μ‘ν λΉμ¦λμ€ λ‘μ§μ λν "How it works" μ¬μΈ΅ ν΄μ€.
- ν¬λ§·ν
μ μ©:
SKILL.mdμ "Standardized Format"μ λ°λΌ λ§ν¬λ€μ΄μ μ λν©λλ€.
4. κ²μ¦ λ° μλ£ (Verification - Phase 3)
- μ ν©μ± νμΈ: μμ±λ μ€λͺ μ΄ μ€μ μ½λ λμκ³Ό μΌμΉνλμ§ μ¬νμΈν©λλ€.
- μ μ₯:
docs/λλ ν 리 λλ ν΄λΉ νμΌ μμΉ(README.md λ±)μ λ¬Έμλ₯Ό μ μ₯ν©λλ€. - μ¬μ©μ μλ¦Ό:
notify_userλ₯Ό ν΅ν΄ μμ±λ λ¬Έμμ μμΉμ μμ½μ μλ¦¬κ³ λ¦¬λ·°λ₯Ό μμ²ν©λλ€.
Standards & Rules
Documentation Suite (Dev Doc Suite)
Core Principles
- Code as Truth: Documentation must always be derived from the actual code implementation, not assumptions.
- Living Documents: Documentation is NOT a post-mortem artifact; it must evolve with every commit.
- Audience-Centric: Clearly distinguish between User Docs (Ease of use) and Developer Docs (Implementation details).
- Standardized Format: Follow the "3-Tier Language Strategy" (Korean for high-level structure, English for technical details).
Documentation Types & Templates (Source: document-suite-skills)
1. Code Documentation (Docstrings)
Goal: Clear, comprehensive function/class documentation
Example Format:
def function_name(param1: Type, param2: Type) -> ReturnType:
"""
Brief one-line description.
Detailed explanation of purpose, behavior, and context.
Args:
param1: Description with type and example values
param2: Description with constraints
Returns:
Description of return value and meaning
Example:
>>> function_name(example_value1, example_value2)
expected_output
Raises:
ErrorType: When and why this error occurs
Note:
Important details, gotchas, performance considerations
"""
2. API Documentation
Goal: Complete API reference for endpoints
REST API Example:
## Authentication API
### POST /api/auth/login
Authenticate user and return JWT access token.
**Request:**
```json
{
"email": "user@example.com",
"password": "SecureP@ss123"
}
Response (200 OK):
{
"success": true,
"data": {
"accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"expiresIn": 3600
}
}
### 3. Architecture Documentation
**Goal:** Clear system overview and component relationships
**Example:**
```markdown
# System Architecture
## System Diagram
```mermaid
graph TD
Client[Frontend] -->|HTTPS| Gateway[API Gateway]
Gateway --> Auth[Auth Service]
Gateway --> Trade[Trading Service]
Trade --> DB[(Database)]
Core Components
1. API Gateway
Responsibility: Entry point for all client requests
- Request routing
- Rate limiting
2. Auth Service
Responsibility: User authentication
- JWT generation
- Session management
### 4. README Generation
**Goal:** Comprehensive project README
**Essential Sections:**
```markdown
# [Project Name]
[One-line description] - [What problem it solves]
## Features
- Key feature 1
- Key feature 2
## Installation
\`\`\`bash
npm install
npm run dev
\`\`\`
## Configuration
| Variable | Description | Required |
|----------|-------------|----------|
| `DATABASE_URL` | DB connection string | Yes |
5. Code Explanations
Goal: Clear explanations of complex code
Process:
- High-Level Purpose: What problem does this solve?
- Step-by-Step Logic: Break down into phases.
- Key Algorithms: Identify important patterns.
- Edge Cases: validation and error handling.
Quality Standards
- Freshness: All generated docs must be verified against the current codebase state.
- Completeness: Every public function/class must have at least a summary description.
- Readability: Use clear formatting, bullet points, and code blocks.
- Safe YAML: Frontmatter descriptions with special characters must be quoted.
Checklist
- [ ] Analysis: Did you read all relevant code files before writing?
- [ ] Verification: Does the documentation accurately reflect the code behavior?
- [ ] Formatting: Is the markdown syntax correct and consistent?
- [ ] Language: Is the appropriate language (Korean/English) used for the target audience?