You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
314 lines
6.4 KiB
314 lines
6.4 KiB
# Markdown Templates & Examples
|
|
|
|
> **Agent role**: Reference this file for document templates, structure,
|
|
> and examples when creating new documentation.
|
|
>
|
|
> **Focus**: Create educational content that increases human competence,
|
|
> not just technical descriptions.
|
|
|
|
## Document Templates
|
|
|
|
### Standard Document Template
|
|
|
|
```markdown
|
|
# Document Title
|
|
|
|
**Author**: Matthew Raymer
|
|
**Date**: YYYY-MM-DD
|
|
**Status**: 🎯 **STATUS** - Brief description
|
|
|
|
## Overview
|
|
|
|
Brief description of the document's purpose and scope.
|
|
|
|
**Educational Goal**: What will the reader learn and how will it increase
|
|
their competence?
|
|
|
|
## Current State
|
|
|
|
Description of current situation or problem.
|
|
|
|
**Why This Matters**: Explain the business value and user benefit of
|
|
addressing this situation.
|
|
|
|
## Implementation Plan
|
|
|
|
### Phase 1: Foundation
|
|
|
|
- [ ] Task 1
|
|
- [ ] Task 2
|
|
|
|
**Learning Context**: What concepts should the reader understand before
|
|
proceeding with implementation?
|
|
|
|
## Next Steps
|
|
|
|
1. **Review and approve plan**
|
|
2. **Begin implementation**
|
|
3. **Test and validate**
|
|
|
|
**Continued Learning**: Where can the reader go next to deepen their
|
|
understanding?
|
|
|
|
---
|
|
|
|
**Status**: Ready for implementation
|
|
**Priority**: Medium
|
|
**Estimated Effort**: X days
|
|
**Dependencies**: None
|
|
**Stakeholders**: Development team
|
|
```
|
|
|
|
### Technical Specification Template
|
|
|
|
```markdown
|
|
# Technical Specification: [Feature Name]
|
|
|
|
**Author**: Matthew Raymer
|
|
**Date**: YYYY-MM-DD
|
|
**Status**: 🎯 **DRAFT** - Under Review
|
|
|
|
## Overview
|
|
|
|
Brief description of the technical specification.
|
|
|
|
**Business Context**: Why is this specification needed and what problem
|
|
does it solve for users?
|
|
|
|
## Requirements
|
|
|
|
### Functional Requirements
|
|
|
|
- [ ] Requirement 1
|
|
- [ ] Requirement 2
|
|
|
|
### Non-Functional Requirements
|
|
|
|
- [ ] Performance requirement
|
|
- [ ] Security requirement
|
|
|
|
## Technical Design
|
|
|
|
### Architecture
|
|
|
|
Description of the technical architecture.
|
|
|
|
**Design Rationale**: Why was this architecture chosen over alternatives?
|
|
What are the trade-offs and benefits?
|
|
|
|
### Data Models
|
|
|
|
```typescript
|
|
interface ExampleModel {
|
|
id: string;
|
|
name: string;
|
|
createdAt: Date;
|
|
}
|
|
```
|
|
|
|
### API Design
|
|
|
|
```typescript
|
|
interface APIResponse<T> {
|
|
success: boolean;
|
|
data: T;
|
|
error?: string;
|
|
}
|
|
```
|
|
|
|
## Testing Strategy
|
|
|
|
- [ ] Unit tests
|
|
|
|
**Learning from Testing**: What insights does testing provide about the
|
|
system's behavior and design?
|
|
|
|
---
|
|
|
|
## Educational Documentation Template
|
|
|
|
### **Concept Explanation Template**
|
|
|
|
```markdown
|
|
## What is [Concept Name]?
|
|
|
|
Brief, clear definition of the concept.
|
|
|
|
## Why Does [Concept Name] Matter?
|
|
|
|
Explain the business value and user benefit.
|
|
|
|
## How Does [Concept Name] Work?
|
|
|
|
High-level explanation of the mechanism.
|
|
|
|
## When Would You Use [Concept Name]?
|
|
|
|
Real-world scenarios and use cases.
|
|
|
|
## Common Misconceptions
|
|
|
|
Address typical misunderstandings.
|
|
|
|
## Examples
|
|
|
|
Concrete examples that illustrate the concept.
|
|
|
|
## Next Steps
|
|
|
|
Where to learn more about related concepts.
|
|
```
|
|
|
|
### **Tutorial Template**
|
|
|
|
```markdown
|
|
## Learning Objective
|
|
|
|
What the reader will accomplish by the end.
|
|
|
|
## Prerequisites
|
|
|
|
What the reader should know before starting.
|
|
|
|
## Step-by-Step Guide
|
|
|
|
1. **Step 1**: What to do and why
|
|
2. **Step 2**: What to do and why
|
|
3. **Step 3**: What to do and why
|
|
|
|
## Verification
|
|
|
|
How to confirm the tutorial was successful.
|
|
|
|
## Troubleshooting
|
|
|
|
Common issues and how to resolve them.
|
|
|
|
## What You've Learned
|
|
|
|
Summary of key concepts and skills.
|
|
|
|
## Next Steps
|
|
|
|
Where to apply this knowledge next.
|
|
```
|
|
- [ ] Integration tests
|
|
- [ ] E2E tests
|
|
|
|
---
|
|
|
|
**Status**: Draft
|
|
**Priority**: High
|
|
**Estimated Effort**: X days
|
|
**Dependencies**: None
|
|
**Stakeholders**: Development team
|
|
|
|
```
|
|
|
|
## Content Examples
|
|
|
|
### JSON Examples
|
|
|
|
```json
|
|
{
|
|
"property": "value",
|
|
"nested": {
|
|
"property": "value"
|
|
}
|
|
}
|
|
```
|
|
|
|
### Shell Commands
|
|
|
|
```bash
|
|
# Command with comment
|
|
npm run build:web
|
|
|
|
# Multi-line command
|
|
VITE_GIT_HASH=`git log -1 --pretty=format:%h` \
|
|
vite build --config vite.config.web.mts
|
|
```
|
|
|
|
### TypeScript Examples
|
|
|
|
```typescript
|
|
// Function with JSDoc
|
|
const getEnvironmentConfig = (env: string) => {
|
|
switch (env) {
|
|
case 'prod':
|
|
return { /* production settings */ };
|
|
default:
|
|
return { /* development settings */ };
|
|
}
|
|
};
|
|
```
|
|
|
|
## File Structure Standards
|
|
|
|
### Document Header
|
|
|
|
```markdown
|
|
# Document Title
|
|
|
|
**Author**: Matthew Raymer
|
|
**Date**: YYYY-MM-DD
|
|
**Status**: 🎯 **STATUS** - Brief description
|
|
|
|
## Overview
|
|
|
|
Brief description of the document's purpose and scope.
|
|
```
|
|
|
|
### Section Organization
|
|
|
|
Standard sections: Overview, Current State, Implementation Plan,
|
|
Technical Details, Testing & Validation, Next Steps
|
|
|
|
## Common Patterns
|
|
|
|
Standard implementation plans follow Phase 1 (Foundation), Phase 2
|
|
(Features), Phase 3 (Testing & Polish) structure.
|
|
|
|
## Model Implementation Checklist
|
|
|
|
### Before Using Templates
|
|
|
|
- [ ] **Template Selection**: Choose appropriate template for document type
|
|
- [ ] **Structure Review**: Understand required sections and organization
|
|
- [ ] **Content Planning**: Plan what information goes in each section
|
|
- [ ] **Audience Analysis**: Ensure template matches target audience needs
|
|
|
|
### During Template Usage
|
|
|
|
- [ ] **Section Completion**: Fill in all required sections completely
|
|
- [ ] **Example Integration**: Include relevant code examples and patterns
|
|
- [ ] **Formatting Consistency**: Apply markdown standards from core rules
|
|
- [ ] **Cross-references**: Link to related documentation and resources
|
|
|
|
### After Template Usage
|
|
|
|
- [ ] **Content Review**: Verify all sections contain appropriate content
|
|
- [ ] **Formatting Check**: Run `npm run markdown:check` for compliance
|
|
- [ ] **Template Validation**: Confirm document follows template structure
|
|
- [ ] **Quality Assessment**: Ensure content meets project standards
|
|
|
|
### Template-Specific Requirements
|
|
|
|
- [ ] **Standard Documents**: Include all required metadata and sections
|
|
- [ ] **Technical Specs**: Complete all requirement and design sections
|
|
- [ ] **Implementation Plans**: Define clear phases and milestones
|
|
- [ ] **Examples**: Provide relevant, working code examples
|
|
|
|
---
|
|
|
|
**See also**:
|
|
|
|
- `.cursor/rules/meta_documentation.mdc` for comprehensive documentation workflow
|
|
- `.cursor/rules/docs/markdown_core.mdc` for core formatting standards
|
|
- `.cursor/rules/docs/markdown_workflow.mdc` for validation workflows
|
|
|
|
**Status**: Active templates and examples
|
|
**Priority**: Medium
|
|
**Estimated Effort**: Ongoing reference
|
|
**Dependencies**: markdown_core.mdc
|
|
**Stakeholders**: Documentation team, Development team
|
|
|