Initial commit
This commit is contained in:
Zhongwei Li
75
commands/_shared/create-workflow.md
Normal file
75
commands/_shared/create-workflow.md
Normal file
@@ -0,0 +1,75 @@
|
||||
# Shared Create Workflow
|
||||
|
||||
Reference file for `/para:create-*` commands.
|
||||
|
||||
## File Naming Convention (REQUIRED)
|
||||
|
||||
See: `naming-convention.md` in this folder.
|
||||
|
||||
**Standard**: Title Case with Spaces → `Folder/Title Case with Spaces.md`
|
||||
|
||||
| User Input | Filename |
|
||||
|------------|----------|
|
||||
| `"tassie holiday 2025"` | `Tassie Holiday 2025.md` |
|
||||
| `"react best practices"` | `React Best Practices.md` |
|
||||
| `"learn piano"` | `Learn Piano.md` |
|
||||
|
||||
**Always convert user input to Title Case before creating files.**
|
||||
|
||||
## PARA Principle: Don't Over-Organize
|
||||
|
||||
Per Tiago Forte's PARA method:
|
||||
- "Keep it to 4-6 items per level maximum"
|
||||
- "Resources don't need perfect organization. They just need to be findable."
|
||||
|
||||
**Rule**: Let structure emerge naturally. Don't create folders preemptively.
|
||||
|
||||
## Subfolder Logic by Type
|
||||
|
||||
| Type | Subfolder Behavior |
|
||||
|------|-------------------|
|
||||
| **Project** | Always create in `01_Projects/` root |
|
||||
| **Area** | Always create in `02_Areas/` root |
|
||||
| **Resource** | Suggest existing subfolders if they match title |
|
||||
|
||||
## Resource Subfolder Matching
|
||||
|
||||
Only for Resources - if user has existing subfolders:
|
||||
|
||||
1. List subfolders in `03_Resources/` using `mcp__MCP_DOCKER__obsidian_list_files_in_dir`
|
||||
2. If subfolders exist, check if title contextually matches any
|
||||
3. **If match** → Ask user with `AskUserQuestion`:
|
||||
- Matching subfolder(s)
|
||||
- Root folder option
|
||||
4. **If no match or no subfolders** → Create in root silently
|
||||
|
||||
**Never offer "create new folder"** - structure should emerge from repeated use.
|
||||
|
||||
### Matching Examples
|
||||
|
||||
| Title | Existing Subfolders | Action |
|
||||
|-------|---------------------|--------|
|
||||
| "React Best Practices" | Technical/, Work/ | Ask: Technical/ or root? |
|
||||
| "Docker Tutorial" | Technical/, Work/ | Ask: Technical/ or root? |
|
||||
| "Fishing Trip Guide" | Technical/, Work/ | Create in root (no match) |
|
||||
| "TypeScript Patterns" | (none) | Create in root |
|
||||
|
||||
## Argument Parsing
|
||||
|
||||
Use positional arguments: `$1` (title), `$2`, `$3` for optional fields.
|
||||
|
||||
- If arg provided → use it
|
||||
- If arg missing → ask with `AskUserQuestion`
|
||||
|
||||
## Output Format
|
||||
|
||||
```
|
||||
✅ Created: [[Title]]
|
||||
📁 Location: [folder]/[filename].md
|
||||
📋 Type: [project|area|resource]
|
||||
```
|
||||
|
||||
## MCP Tools
|
||||
|
||||
- `mcp__MCP_DOCKER__obsidian_list_files_in_dir` - Check subfolders (Resources only)
|
||||
- `mcp__MCP_DOCKER__obsidian_append_content` - Create note
|
||||
106
commands/_shared/naming-convention.md
Normal file
106
commands/_shared/naming-convention.md
Normal file
@@ -0,0 +1,106 @@
|
||||
# File Naming Convention
|
||||
|
||||
Standard for all para-brain note creation.
|
||||
|
||||
## Convention: Title Case with Spaces
|
||||
|
||||
**Format**: `Title Case with Spaces.md`
|
||||
|
||||
### Rules
|
||||
|
||||
1. **Use spaces** - Not underscores, not hyphens
|
||||
2. **Title Case** - Capitalize first letter of each significant word
|
||||
3. **No special characters** - Avoid `/ \ : * ? " < > |`
|
||||
4. **Dates in ISO format** - Use `YYYY-MM-DD` when dates are part of title
|
||||
5. **Numbers are fine** - `2025 Tassie Holiday.md`
|
||||
|
||||
### Examples
|
||||
|
||||
| User Input | Filename |
|
||||
|------------|----------|
|
||||
| "tassie holiday 2025" | `Tassie Holiday 2025.md` |
|
||||
| "react best practices" | `React Best Practices.md` |
|
||||
| "learn piano" | `Learn Piano.md` |
|
||||
| "Q1 2025 goals" | `Q1 2025 Goals.md` |
|
||||
| "nathan's birthday" | `Nathans Birthday.md` |
|
||||
|
||||
### Title Case Rules
|
||||
|
||||
- Capitalize: First word, nouns, verbs, adjectives, adverbs
|
||||
- Lowercase: Articles (a, an, the), prepositions (in, on, at), conjunctions (and, but, or)
|
||||
- Exception: Always capitalize first and last word
|
||||
|
||||
### Why This Convention
|
||||
|
||||
1. **Most readable** - Natural language, easy to scan
|
||||
2. **Obsidian-friendly** - Handles spaces perfectly in wikilinks `[[Title Case]]`
|
||||
3. **No cognitive load** - Write titles naturally
|
||||
4. **Consistent** - Same format across all note types
|
||||
5. **Unique names prevent conflicts** - Descriptive names avoid wikilink resolution issues
|
||||
|
||||
### Conversion Function (Pseudocode)
|
||||
|
||||
```
|
||||
function toTitleCaseFilename(input):
|
||||
1. Trim whitespace
|
||||
2. Remove special characters: / \ : * ? " < > |
|
||||
3. Replace apostrophes with nothing (nathan's → nathans)
|
||||
4. Convert to Title Case
|
||||
5. Append .md
|
||||
return filename
|
||||
```
|
||||
|
||||
### What NOT to Do
|
||||
|
||||
| Wrong | Right |
|
||||
|-------|-------|
|
||||
| `tassie_holiday_2025.md` | `Tassie Holiday 2025.md` |
|
||||
| `tassie-holiday-2025.md` | `Tassie Holiday 2025.md` |
|
||||
| `TASSIE HOLIDAY 2025.md` | `Tassie Holiday 2025.md` |
|
||||
| `tassie holiday 2025.md` | `Tassie Holiday 2025.md` |
|
||||
|
||||
---
|
||||
|
||||
## Critical: Avoid Duplicate Filenames
|
||||
|
||||
### Why This Matters
|
||||
|
||||
Obsidian wikilinks `[[Note Name]]` search **the entire vault** by filename. If two files have the same name in different folders, wikilinks will resolve to the wrong file.
|
||||
|
||||
### Generic Names to Avoid
|
||||
|
||||
❌ **Never use these generic names:**
|
||||
- `Overview.md`
|
||||
- `README.md`
|
||||
- `Index.md`
|
||||
- `Notes.md`
|
||||
- `Project.md`
|
||||
- `Ideas.md`
|
||||
|
||||
✅ **Instead, use descriptive, specific names:**
|
||||
- `2025 Tasmania Holiday.md` (not `Overview.md`)
|
||||
- `React Best Practices.md` (not `Notes.md`)
|
||||
- `Levi School Term 1.md` (not `Project.md`)
|
||||
|
||||
### Example: Project Overview Files
|
||||
|
||||
```
|
||||
❌ BAD - Causes wikilink conflicts:
|
||||
/01_Projects/Tassie Holiday/Overview.md
|
||||
/01_Projects/Home Renovation/Overview.md
|
||||
/01_Projects/Learn Piano/Overview.md
|
||||
|
||||
✅ GOOD - Unique, descriptive names:
|
||||
/01_Projects/2025 Tassie Holiday/2025 Tasmania Holiday.md
|
||||
/01_Projects/Home Renovation/Home Renovation Project.md
|
||||
/01_Projects/Learn Piano/Learn Piano Journey.md
|
||||
```
|
||||
|
||||
### Rule of Thumb
|
||||
|
||||
**Include the project/area name in the filename:**
|
||||
- Project folder: `My Project/`
|
||||
- Main note: `My Project.md` or `My Project Overview.md`
|
||||
- Never just: `Overview.md`
|
||||
|
||||
This ensures wikilinks `[[My Project]]` work correctly across your entire vault.
|
||||
138
commands/_shared/validate-note.md
Normal file
138
commands/_shared/validate-note.md
Normal file
@@ -0,0 +1,138 @@
|
||||
# Note Validation
|
||||
|
||||
Validates frontmatter against PARA schemas. Call this when reading a note to detect outdated formats.
|
||||
|
||||
## Schemas by Type
|
||||
|
||||
### Project Schema (Required Fields)
|
||||
|
||||
```yaml
|
||||
title: string # Required
|
||||
created: date # Required
|
||||
type: project # Required
|
||||
status: string # Required: active, on-hold, completed, archived
|
||||
start_date: date # Required
|
||||
target_completion: date # Required
|
||||
area: "[[Link]]" # Required
|
||||
reviewed: date # Required
|
||||
review_period: string # Optional, default 7d
|
||||
tags: [project] # Required
|
||||
```
|
||||
|
||||
### Area Schema (Required Fields)
|
||||
|
||||
```yaml
|
||||
title: string # Required
|
||||
created: date # Required
|
||||
type: area # Required
|
||||
status: string # Required: active
|
||||
reviewed: date # Required
|
||||
review_period: string # Optional, default 14d
|
||||
tags: [area] # Required
|
||||
```
|
||||
|
||||
### Resource Schema (Required Fields)
|
||||
|
||||
```yaml
|
||||
title: string # Required
|
||||
created: date # Required
|
||||
type: resource # Required
|
||||
source: string # Required: book, article, video, course, podcast, paper, web
|
||||
areas: ["[[Link]]"] # Required - array of area links (NEW)
|
||||
reviewed: date # Required (NEW)
|
||||
tags: [resource] # Required
|
||||
```
|
||||
|
||||
### Task Schema (Required Fields)
|
||||
|
||||
```yaml
|
||||
title: string # Required
|
||||
created: date # Required
|
||||
type: task # Required
|
||||
task_type: string # Required: task, reminder, habit, chore
|
||||
status: string # Required: not-started, in-progress, blocked, done, cancelled
|
||||
priority: string # Required: low, medium, high, urgent
|
||||
effort: string # Required: small, medium, large
|
||||
reviewed: date # Required
|
||||
tags: [task] # Required
|
||||
```
|
||||
|
||||
## Validation Function
|
||||
|
||||
When a command reads a note:
|
||||
|
||||
1. **Check `type:` field exists** - If missing, note is unformatted
|
||||
2. **Look up schema for that type**
|
||||
3. **Compare frontmatter to schema**
|
||||
4. **Return missing/outdated fields**
|
||||
|
||||
## Validation Response Format
|
||||
|
||||
```markdown
|
||||
### Note Validation: [[Note Title]]
|
||||
|
||||
**Type**: resource
|
||||
**Status**: ⚠️ Needs update
|
||||
|
||||
**Missing fields**:
|
||||
- `areas` - Required array of linked areas
|
||||
- `reviewed` - Last review date
|
||||
|
||||
**Would you like to update this note?**
|
||||
```
|
||||
|
||||
## Update Prompt
|
||||
|
||||
When validation finds issues, offer to fix:
|
||||
|
||||
```markdown
|
||||
I can add the missing fields:
|
||||
- `areas`: Which area(s) does this relate to?
|
||||
- `reviewed`: I'll set to today's date
|
||||
|
||||
Update now? (y/n)
|
||||
```
|
||||
|
||||
## How Commands Use This
|
||||
|
||||
```markdown
|
||||
### In search.md, process.md, review.md:
|
||||
|
||||
After reading a note with `obsidian_get_file_contents`:
|
||||
|
||||
1. Parse frontmatter
|
||||
2. Check against schema (see above)
|
||||
3. If missing required fields:
|
||||
- Show validation warning
|
||||
- Ask if user wants to update
|
||||
4. If user says yes:
|
||||
- Prompt for missing values
|
||||
- Use `obsidian_patch_content` to update frontmatter
|
||||
5. Continue with original command purpose
|
||||
```
|
||||
|
||||
## Common Migration Patterns
|
||||
|
||||
### Old Resource → New Resource
|
||||
|
||||
**Missing**: `areas`, `reviewed`
|
||||
|
||||
**Fix**:
|
||||
1. Ask "Which area(s) does this resource relate to?"
|
||||
2. Set `reviewed: [today]`
|
||||
3. Patch frontmatter
|
||||
|
||||
### Unformatted Note → Typed Note
|
||||
|
||||
**Missing**: Everything
|
||||
|
||||
**Fix**:
|
||||
1. Ask "What type is this? (project/area/resource/task)"
|
||||
2. Apply appropriate template schema
|
||||
3. Prompt for required fields by type
|
||||
|
||||
## Token Efficiency
|
||||
|
||||
- Only validate when note is already being read
|
||||
- Don't re-validate if `reviewed` date is recent (< 7 days)
|
||||
- Batch field prompts into single question when possible
|
||||
Reference in New Issue
Block a user