| name | technical-design |
| description | Review and create technical design documents or technical blogs for the Moni Assistant project. Use this skill when: - Creating new technical design documents in docs/technical-design/ - Creating technical blog posts in blog/ - Reviewing existing technical designs or blogs for completeness and quality - Ensuring documents follow the project's documentation standards - Writing architecture overviews, system designs, or feature specifications |
| allowed-tools | Read, Write, Edit, Glob, Grep |
Technical Design Skill
This skill helps create and review technical design documents and technical blogs following the Moni Assistant documentation standards.
Document Types
| Type | Location | Purpose |
|---|---|---|
| Technical Design Document | docs/technical-design/ |
Formal specification for system implementation |
| Technical Blog | blog/ |
Share knowledge, architecture decisions, lessons learned |
Part 1: Technical Design Document
Document Structure
All technical design documents must follow this structure:
1. Title & Introduction
- Clear, descriptive title using
#heading - Problem statement explaining why this design is needed
- Core problems being solved (bullet points)
2. Requirements Section
## 1. Requirements
### 1.1. Functional Requirements
* List of what the system must do
### 1.2. Non-Functional Requirements
* **Performance**: Latency, throughput requirements
* **Accuracy**: Quality metrics and targets
* **Scalability**: Resource optimization considerations
3. Architecture Overview
- High-level system diagram (use
<div style={{textAlign: 'center'}}>for centering images) - Description of main components and their responsibilities
- Data flow between components
4. Detailed Design
- Subsections for each major component or flow
- Sequence diagrams or flow charts where appropriate
- Data models and schemas (use code blocks)
- API designs if applicable
5. Related Resources
- Links to external documentation
- References to related internal docs
6. Appendix
- Glossary of terms used in the document
- Use table format for term definitions
Language Guidelines
- Write in Vietnamese for consistency with existing docs
- Use technical English terms for concepts (e.g., "Memory Fragment", "Vector Database")
- Include English translations in parentheses where helpful
Image References
Use this format for images:
<div style={{textAlign: 'center'}}>
<img src={require('@site/docs/img/technical-design/[folder]/[image].png').default} height="500" />
<p style={{fontSize: 'small', fontStyle: 'italic', marginTop: '8px'}}>Caption here</p>
</div>
Code Examples
- Use fenced code blocks with language specification
- Include realistic examples with comments
- For database schemas, show CREATE TABLE statements
- For data models, show Python/TypeScript type definitions
Quality Checklist
When reviewing or creating technical designs, ensure:
- Problem statement is clear and well-defined
- Requirements are specific and measurable
- Architecture diagram is included
- All components are described with their responsibilities
- Data models/schemas are documented
- Error handling approach is mentioned (even if TBD)
- Related resources are linked
- Glossary includes all domain-specific terms
File Location
Technical design documents go in: docs/technical-design/[feature-name].md
After creating a document:
- Add entry to
technicalDesignSidebar.ts - Update
CHANGELOG.mdwith the addition
Part 2: Technical Blog
Technical blogs do not require a fixed structure. Authors are free to choose the format that best suits their content.
Required Elements
1. Frontmatter
---
slug: feature-name
title: "Descriptive Title"
authors: [author-id]
tags: [relevant, tags, for, discovery]
jira: https://jira-link (optional)
---
2. Truncate Marker
Place <!-- truncate --> after the introduction to show preview on the blog list page.
Review Criteria
When reviewing technical blogs, check the following:
Technical Content
- Technical problem is clearly presented
- Solution/architecture is adequately described
- Code blocks have language specification
Consistency
- Component names are consistent between diagrams and tables
- Information across diagrams does not contradict
- Components shown in diagrams are described in tables/text
Knowledge Base
- Diagrams, Mermaidjs →
references/mermaidjs.md - Mermaidjs Best Practices →
references/mermaidjs-best-practices.md
Mermaid Diagram Rendering
Rendering Script
Use scripts/render_mermaid_diagram.py to convert Mermaid diagrams in markdown files to PNG/SVG images.
Usage
# Render first diagram to PNG (default)
uv run .claude/skills/technical-design/scripts/render_mermaid_diagram.py blog/my-post.md
# Render to specific output file
uv run .claude/skills/technical-design/scripts/render_mermaid_diagram.py blog/my-post.md -o blog/diagram.png
# Render to SVG format
uv run .claude/skills/technical-design/scripts/render_mermaid_diagram.py blog/my-post.md -f svg
# Render all diagrams in file (adds index suffix: _1.png, _2.png, etc.)
uv run .claude/skills/technical-design/scripts/render_mermaid_diagram.py blog/my-post.md --all
Features
- Extracts all Mermaid code blocks from markdown files
- Renders using mermaid.ink service (no local dependencies)
- Supports PNG and SVG output formats
- Can render single or all diagrams in a file
- Auto-generates filenames for multiple diagrams
When to Use
- Generating static images for documentation
- Creating diagrams for external sharing
- Converting architecture-beta diagrams that use Iconify icons
- Producing high-resolution images for presentations
Notes
- The script uses mermaid.ink service, so internet connection is required
- For architecture-beta diagrams with Iconify icons, PNG format is recommended
- Output files are saved in the same directory as input by default
File Location
Technical blogs go in: blog/YYYY-MM-DD-feature-name.md