refactor(vault): Phase 4 — 06_Metadata slimming 42 → 8
Keep (8 files, all wired to .obsidian): - Templates: Daily Note Template, Project Template, book-note, quick-note - Reference: PARA_METHOD, GIT_WORKFLOW, TROUBLESHOOTING - SECURITY_ROTATION_LOG_2026-02 Delete (27 files): upstream claudesidian remnants (CHANGELOG, CONTRIBUTING, CLAUDE-BOOTSTRAP, etc.), 4 workflow docs, review reports, improvement plans, Hermes templates, duplicate/unwired templates Archive to 04_Archive/Metadata-Docs (8 files): review reports, plugin manuals, DAILY_NOTE_GUIDE, Common Claude Code Prompts
This commit is contained in:
windyboy
@@ -1,465 +0,0 @@
|
||||
# Changelog
|
||||
|
||||
All notable changes to claudesidian will be documented in this file.
|
||||
|
||||
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
|
||||
and this project adheres to
|
||||
[Semantic Versioning](https://semver.org/spec/v2.0.0.html).
|
||||
|
||||
## [Unreleased]
|
||||
|
||||
## [0.13.1] - 2025-10-13
|
||||
|
||||
### Fixed
|
||||
|
||||
- Corrected hardcoded folder paths to use underscores instead of spaces
|
||||
- Fixed `transcript-extract.sh`: `00 Inbox/Clippings` → `00_Inbox/Clippings/`
|
||||
- Fixed `firecrawl-batch.sh`: `00 Inbox/Clippings` → `00_Inbox/Clippings/`
|
||||
- Fixed `update-attachment-links.js`: `05 Attachments` → `05_Attachments`
|
||||
- Fixed `fix-renamed-links.js`: `05 Attachments` → `05_Attachments`
|
||||
- Fixed example paths in `GEMINI_VISION_QUICK_START.md`
|
||||
- Removed security risk in `firecrawl-batch.sh` by eliminating `source ~/.zshrc`
|
||||
- Corrected non-existent file references in Gemini Vision documentation
|
||||
|
||||
### Added
|
||||
|
||||
- Custom output directory flag (`-o|--output-dir`) for `firecrawl-batch.sh`
|
||||
- Documentation for new output directory options in README.md
|
||||
|
||||
## [0.13.0] - 2025-01-17
|
||||
|
||||
### Added
|
||||
|
||||
- New `/install-claudesidian-command` for creating shell alias/function to
|
||||
launch vault from anywhere
|
||||
- iCloud Drive vault detection and import support in `/init-bootstrap` (macOS
|
||||
only)
|
||||
- Fish shell support for launcher command with proper function syntax
|
||||
- Comprehensive user input path validation with helpful error messages
|
||||
- Platform detection for cross-platform compatibility (Linux, macOS, Windows)
|
||||
|
||||
### Fixed
|
||||
|
||||
- Critical shell injection vulnerability in launcher command with proper path
|
||||
escaping
|
||||
- Backup creation before modifying shell configuration files
|
||||
- iCloud sync state checking with soft warnings for incomplete downloads
|
||||
- Shell detection now uses default shell instead of current session shell
|
||||
- Existing alias/function replacement with user confirmation
|
||||
- Improved error handling documentation with explanations
|
||||
|
||||
### Security
|
||||
|
||||
- Path escaping for vault paths with spaces, quotes, and special characters
|
||||
- Timestamped backups before modifying shell configs
|
||||
- Input validation for user-provided vault paths
|
||||
- Security considerations section in documentation
|
||||
|
||||
## [0.12.1] - 2025-01-17
|
||||
|
||||
### Fixed
|
||||
|
||||
- Improved upgrade command to prevent interactive prompts and hanging
|
||||
- Enhanced upgrade command with explicit backup steps and non-interactive file
|
||||
replacement
|
||||
- Refined upgrade command based on real usage feedback for better reliability
|
||||
- Applied linting fixes to upgrade command for code quality
|
||||
|
||||
## [0.12.0] - 2025-01-17
|
||||
|
||||
### Added
|
||||
|
||||
- New `/download-attachment` command for downloading web content and files to
|
||||
Obsidian attachments folder
|
||||
- New `/pull-request` command for creating PRs with intelligent change analysis
|
||||
and description generation
|
||||
- Both commands integrate seamlessly with Obsidian's vault structure
|
||||
|
||||
### Fixed
|
||||
|
||||
- Security improvements in download command based on PR review feedback
|
||||
- Code formatting to pass lint checks
|
||||
|
||||
## [0.11.0] - 2025-01-17
|
||||
|
||||
### Added
|
||||
|
||||
- Comprehensive linting and formatting setup with ESLint and Prettier
|
||||
- Configuration files organized in `.config/` folder for better project
|
||||
structure
|
||||
- GitHub Action workflow for automated lint checks on pull requests
|
||||
- Package manager specification for consistent dependency management
|
||||
|
||||
### Fixed
|
||||
|
||||
- Resolved lonely if ESLint warning for cleaner code
|
||||
- GitHub Action configuration for proper pnpm setup
|
||||
- Added packageManager field to ensure consistent tooling across environments
|
||||
|
||||
## [0.10.1] - 2025-01-15
|
||||
|
||||
### Fixed
|
||||
|
||||
- Corrected GitHub Action configuration to use claude_args instead of
|
||||
allowed_tools
|
||||
- Fixed workflow validation error for allowed tools parameter
|
||||
|
||||
## [0.10.0] - 2025-01-15
|
||||
|
||||
### Added
|
||||
|
||||
- GitHub Actions workflow for Claude Code integration
|
||||
- Claude can now respond to @claude mentions in issues and PRs
|
||||
- Configured permissions for Claude to create PRs and push changes
|
||||
- Added allowed tools configuration for pnpm, git, gh CLI operations
|
||||
- User restriction to repository owner for security
|
||||
- Development workflow option in init-bootstrap
|
||||
- Personal vault users: Removes .github folder
|
||||
- Contributors: Keeps GitHub workflows for development
|
||||
|
||||
## [0.9.2] - 2025-01-14
|
||||
|
||||
### Fixed
|
||||
|
||||
- Corrected Firecrawl script examples to use `npm run` commands
|
||||
- Added contributing guideline about reviewing AI-generated content before
|
||||
submission
|
||||
|
||||
### Removed
|
||||
|
||||
- Removed Common Patterns section from README (redundant)
|
||||
|
||||
## [0.9.1] - 2025-01-14
|
||||
|
||||
### Changed
|
||||
|
||||
- Enhanced Gemini Vision documentation to explain direct image/PDF processing
|
||||
benefits
|
||||
- Enhanced Firecrawl documentation to explain full-text capture and context
|
||||
preservation
|
||||
- Added detailed API key setup instructions for both Gemini and Firecrawl
|
||||
|
||||
### Removed
|
||||
|
||||
- Removed Essential Workflows section from README (redundant with command
|
||||
descriptions)
|
||||
|
||||
## [0.9.0] - 2025-01-14
|
||||
|
||||
### Added
|
||||
|
||||
- Enhanced upgrade command documentation with detailed usage examples and safety
|
||||
features
|
||||
- Contributing section with guidelines for community contributions
|
||||
- MIT license file for clear open-source licensing
|
||||
|
||||
### Changed
|
||||
|
||||
- Improved documentation clarity on Claude Code commands vs agents distinction
|
||||
- Updated contributing guidelines to encourage PRs for commands, agents, and
|
||||
core updates
|
||||
|
||||
### Removed
|
||||
|
||||
- Removed thinking-partner agent (keeping slash command only)
|
||||
|
||||
## [0.8.8] - 2025-01-13
|
||||
|
||||
### Fixed
|
||||
|
||||
- Added critical warnings to upgrade command documentation
|
||||
- Emphasized requirement to show diffs before applying changes
|
||||
- Added correct vs wrong implementation examples
|
||||
- Prevents loss of user customizations during upgrades
|
||||
|
||||
## [0.8.7] - 2025-01-13
|
||||
|
||||
### Fixed
|
||||
|
||||
- Release command now automatically creates GitHub release using gh CLI
|
||||
- Prevents missing GitHub releases (like v0.8.2-v0.8.5 were)
|
||||
- Extracts release notes from CHANGELOG.md for GitHub release body
|
||||
|
||||
## [0.8.6] - 2025-01-13
|
||||
|
||||
### Changed
|
||||
|
||||
- Improved semantic versioning guidelines in release command with clearer
|
||||
decision guide
|
||||
|
||||
## [0.8.5] - 2025-01-13
|
||||
|
||||
### Fixed
|
||||
|
||||
- Upgrade command now works without git connection for disconnected users
|
||||
- Clone latest version to .tmp/ directory instead of requiring upstream remote
|
||||
- Use .tmp/ instead of /tmp/ to hide upgrade files from Obsidian
|
||||
- Added user choice prompt when local modifications are detected
|
||||
- Added verification step to ensure all files were properly addressed
|
||||
- Added .tmp/ to .gitignore for cleaner repository
|
||||
|
||||
## [0.8.4] - 2025-01-13
|
||||
|
||||
### Fixed
|
||||
|
||||
- Simplified upgrade command to systematically check all system files
|
||||
- Created upgrade checklist to track progress file-by-file
|
||||
- Filtered upgrades to only claudesidian system files, not user content
|
||||
- Added explicit file-by-file diff review before updating
|
||||
- Made upgrade process resumable with checklist tracking
|
||||
|
||||
## [0.8.3] - 2025-01-13
|
||||
|
||||
### Fixed
|
||||
|
||||
- Improved init-bootstrap vault selection for multiple vaults
|
||||
- Added explicit confirmation before importing any vault
|
||||
- Enhanced user identification prompts with better explanations
|
||||
- Added disambiguation prompts to find the right person when researching
|
||||
- Clear instructions to never proceed without explicit vault confirmation
|
||||
|
||||
## [0.8.2] - 2025-01-13
|
||||
|
||||
### Fixed
|
||||
|
||||
- Improved SessionStart hook formatting with arrow indicators for commands
|
||||
- Fixed update notification display to show clean output instead of raw JSON
|
||||
- Enhanced visual layout of first-run and update messages
|
||||
|
||||
## [0.8.1] - 2025-01-13
|
||||
|
||||
### Changed
|
||||
|
||||
- Updated README with comprehensive feature descriptions including:
|
||||
- Smart vault analysis and pattern detection capabilities
|
||||
- User research and profile building features
|
||||
- Automatic update notification system
|
||||
- Web research capabilities with Firecrawl
|
||||
- Complete list of available commands including /upgrade
|
||||
|
||||
## [0.8.0] - 2025-01-13
|
||||
|
||||
### Added
|
||||
|
||||
- Automatic update check on session start
|
||||
- SessionStart hook that fetches latest version from GitHub and compares to
|
||||
local
|
||||
- Update notifications when newer versions are available
|
||||
- check-updates npm script for version comparison
|
||||
- Works even after disconnecting from original repository
|
||||
|
||||
### Changed
|
||||
|
||||
- Enhanced release command documentation with clearer semantic versioning
|
||||
guidelines
|
||||
- Better guidance on when to use feat: vs fix: vs refactor: in commits
|
||||
|
||||
## [0.7.0] - 2025-01-13
|
||||
|
||||
### Added
|
||||
|
||||
- Comprehensive vault analysis using tree, note sampling, and pattern detection
|
||||
- Enhanced profile building with URL fetching and custom context
|
||||
- Dynamic date generation for timestamps in CLAUDE.md
|
||||
- "Later" option for Gemini Vision and Firecrawl setup
|
||||
- Multiple vault import options (yes/no/skip/path)
|
||||
- Deeper research capabilities with disambiguation confirmation
|
||||
|
||||
### Changed
|
||||
|
||||
- init-bootstrap now analyzes vault structure before importing
|
||||
- Always confirms user identity even with single search result
|
||||
- Waits to create folders until after organization method selection
|
||||
- Detects plugins and attachments automatically instead of asking
|
||||
- Firecrawl presented as research game-changer with better explanation
|
||||
- Profile building includes comprehensive background from provided URLs
|
||||
|
||||
### Fixed
|
||||
|
||||
- Correct file counting without depth limits
|
||||
- Proper ordering of import before personalization questions
|
||||
- More accurate detection of user preferences from existing vault
|
||||
|
||||
## [0.6.0] - 2025-01-13
|
||||
|
||||
### Added
|
||||
|
||||
- Intelligent vault import that preserves existing structure in OLD_VAULT folder
|
||||
- Auto-detection of existing Obsidian vaults by searching for .obsidian folders
|
||||
- User research and disambiguation for personalized setup
|
||||
- Automatic detection of file naming patterns and folder organization
|
||||
- Vault configuration saved to .claude/vault-config.json for future reference
|
||||
- Educational explanations during each setup step
|
||||
- Support for both pnpm and npm package managers
|
||||
- Comprehensive Obsidian file copying (plugins, trash, settings)
|
||||
- Clear examples for folder naming when cloning repository
|
||||
|
||||
### Changed
|
||||
|
||||
- init-bootstrap now imports entire vault structure safely without data loss
|
||||
- Gemini Vision and Firecrawl prompts clarify tools are already included
|
||||
- README includes examples of custom folder names when cloning
|
||||
- Removed unnecessary questions by detecting patterns automatically
|
||||
|
||||
## [0.5.0] - 2025-01-13
|
||||
|
||||
### Added
|
||||
|
||||
- First-run welcome message using SessionStart hook
|
||||
- FIRST_RUN marker file to detect fresh installations
|
||||
- Markdown-formatted welcome prompt with setup instructions
|
||||
- Automatic detection and guidance for new users
|
||||
|
||||
### Changed
|
||||
|
||||
- init-bootstrap now removes FIRST_RUN marker after setup completion
|
||||
- Hook configuration uses inline commands (no external scripts needed)
|
||||
|
||||
## [0.4.0] - 2025-01-13
|
||||
|
||||
### Added
|
||||
|
||||
- Simplified setup process with enhanced init-bootstrap command:
|
||||
- Automatic disconnection from original repository
|
||||
- Folder rename assistance for non-git users
|
||||
- Support for both git clone and ZIP download methods
|
||||
- Clear prompts for importing existing Obsidian vaults
|
||||
- Multiple setup paths in README for different user skill levels
|
||||
|
||||
### Changed
|
||||
|
||||
- init-bootstrap now handles complete environment setup including git management
|
||||
- README updated with clearer Quick Start instructions for both technical and
|
||||
non-technical users
|
||||
|
||||
## [0.3.1] - 2025-01-13
|
||||
|
||||
### Fixed
|
||||
|
||||
- Removed CLAUDE.md and settings.local.json from repository tracking
|
||||
- These user-specific files are now generated locally by init-bootstrap
|
||||
- Added both files to .gitignore to prevent accidental commits
|
||||
- Clean repository structure for new users
|
||||
|
||||
## [0.3.0] - 2025-01-13
|
||||
|
||||
### Added
|
||||
|
||||
- Intelligent upgrade command (`/upgrade`) with AI-powered semantic merging
|
||||
- Smart conflict resolution that preserves user customizations while adding new
|
||||
features
|
||||
- Automatic backup system with rollback capabilities
|
||||
- Selective update categories (AI-mergeable, auto-safe, protected)
|
||||
- Based on 2025 best practices for LLM-powered code migration
|
||||
|
||||
## [0.2.3] - 2025-01-13
|
||||
|
||||
### Changed
|
||||
|
||||
- Updated init-bootstrap command and settings configuration
|
||||
|
||||
## [0.2.2] - 2025-01-13
|
||||
|
||||
### Fixed
|
||||
|
||||
- Corrected all documentation to use proper slash command syntax (/command-name)
|
||||
- Fixed examples showing incorrect 'claude run' syntax
|
||||
- Updated README, CLAUDE.md, install.sh, and command docs
|
||||
|
||||
## [0.2.1] - 2025-01-13
|
||||
|
||||
### Changed
|
||||
|
||||
- Updated README to use init-bootstrap command instead of install.sh
|
||||
- Simplified Quick Start instructions to 2-step process
|
||||
- Added examples of pre-configured commands in README
|
||||
|
||||
## [0.2.0] - 2025-01-13
|
||||
|
||||
### Added
|
||||
|
||||
- Release command for automated version management and releases
|
||||
- Gemini Vision video analysis support:
|
||||
- Local video files (MP4, AVI, MOV, WebM, MKV, WMV, FLV, 3GP, M4V)
|
||||
- Direct YouTube URL analysis without download
|
||||
- Automatic video processing state detection
|
||||
- Updated documentation with video analysis examples
|
||||
|
||||
### Changed
|
||||
|
||||
- Enhanced init-bootstrap command with full environment setup including MCP
|
||||
configuration
|
||||
- Updated Gemini Vision MCP server to support video formats
|
||||
|
||||
## [0.1.0] - 2025-01-13
|
||||
|
||||
### Added
|
||||
|
||||
- Initial release of claudesidian - Claude Code + Obsidian starter kit
|
||||
- PARA method folder structure (00_Inbox through 06_Metadata)
|
||||
- Bootstrap initialization system via `claude run init-bootstrap`
|
||||
- Pre-configured Claude Code commands:
|
||||
- thinking-partner - Collaborative thinking mode
|
||||
- inbox-processor - Organize captures
|
||||
- research-assistant - Deep dive into topics
|
||||
- daily-review - End of day reflection
|
||||
- weekly-synthesis - Find patterns in your week
|
||||
- create-command - Build new custom commands
|
||||
- de-ai-ify - Remove AI writing patterns
|
||||
- add-frontmatter - Add metadata to notes
|
||||
- init-bootstrap - Interactive setup wizard
|
||||
- Claude Code agents for specialized workflows
|
||||
- Helper scripts:
|
||||
- firecrawl-batch.sh - Batch web scraping
|
||||
- firecrawl-scrape.sh - Single URL scraping
|
||||
- fix-renamed-links.js - Fix broken links after renames
|
||||
- update-attachment-links.js - Update attachment references
|
||||
- transcript-extract.sh - Extract YouTube transcripts
|
||||
- vault-stats.sh - Show vault statistics
|
||||
- Attachment management commands via pnpm
|
||||
- Gemini Vision MCP server for image/PDF analysis (optional)
|
||||
- CLAUDE-BOOTSTRAP.md template for configuration
|
||||
- Comprehensive README with setup instructions
|
||||
- Install script for automated setup
|
||||
- Git integration with proper .gitignore
|
||||
|
||||
### Changed
|
||||
|
||||
- Replaced static CLAUDE.md with dynamic init-bootstrap command
|
||||
|
||||
### Security
|
||||
|
||||
- API keys stored in environment variables
|
||||
- .mcp.json gitignored for security
|
||||
|
||||
[Unreleased]: https://github.com/heyitsnoah/claudesidian/compare/v0.13.1...HEAD
|
||||
[0.13.1]: https://github.com/heyitsnoah/claudesidian/compare/v0.13.0...v0.13.1
|
||||
[0.13.0]: https://github.com/heyitsnoah/claudesidian/compare/v0.12.1...v0.13.0
|
||||
[0.12.1]: https://github.com/heyitsnoah/claudesidian/compare/v0.12.0...v0.12.1
|
||||
[0.12.0]: https://github.com/heyitsnoah/claudesidian/compare/v0.11.0...v0.12.0
|
||||
[0.11.0]: https://github.com/heyitsnoah/claudesidian/compare/v0.10.1...v0.11.0
|
||||
[0.10.1]: https://github.com/heyitsnoah/claudesidian/compare/v0.10.0...v0.10.1
|
||||
[0.10.0]: https://github.com/heyitsnoah/claudesidian/compare/v0.9.2...v0.10.0
|
||||
[0.9.2]: https://github.com/heyitsnoah/claudesidian/compare/v0.9.1...v0.9.2
|
||||
[0.9.1]: https://github.com/heyitsnoah/claudesidian/compare/v0.9.0...v0.9.1
|
||||
[0.9.0]: https://github.com/heyitsnoah/claudesidian/compare/v0.8.8...v0.9.0
|
||||
[0.8.8]: https://github.com/heyitsnoah/claudesidian/compare/v0.8.7...v0.8.8
|
||||
[0.8.7]: https://github.com/heyitsnoah/claudesidian/compare/v0.8.6...v0.8.7
|
||||
[0.8.6]: https://github.com/heyitsnoah/claudesidian/compare/v0.8.5...v0.8.6
|
||||
[0.8.5]: https://github.com/heyitsnoah/claudesidian/compare/v0.8.4...v0.8.5
|
||||
[0.8.4]: https://github.com/heyitsnoah/claudesidian/compare/v0.8.3...v0.8.4
|
||||
[0.8.3]: https://github.com/heyitsnoah/claudesidian/compare/v0.8.2...v0.8.3
|
||||
[0.8.2]: https://github.com/heyitsnoah/claudesidian/compare/v0.8.1...v0.8.2
|
||||
[0.8.1]: https://github.com/heyitsnoah/claudesidian/compare/v0.8.0...v0.8.1
|
||||
[0.8.0]: https://github.com/heyitsnoah/claudesidian/compare/v0.7.0...v0.8.0
|
||||
[0.7.0]: https://github.com/heyitsnoah/claudesidian/compare/v0.6.0...v0.7.0
|
||||
[0.6.0]: https://github.com/heyitsnoah/claudesidian/compare/v0.5.0...v0.6.0
|
||||
[0.5.0]: https://github.com/heyitsnoah/claudesidian/compare/v0.4.0...v0.5.0
|
||||
[0.4.0]: https://github.com/heyitsnoah/claudesidian/compare/v0.3.1...v0.4.0
|
||||
[0.3.1]: https://github.com/heyitsnoah/claudesidian/compare/v0.3.0...v0.3.1
|
||||
[0.3.0]: https://github.com/heyitsnoah/claudesidian/compare/v0.2.3...v0.3.0
|
||||
[0.2.3]: https://github.com/heyitsnoah/claudesidian/compare/v0.2.2...v0.2.3
|
||||
[0.2.2]: https://github.com/heyitsnoah/claudesidian/compare/v0.2.1...v0.2.2
|
||||
[0.2.1]: https://github.com/heyitsnoah/claudesidian/compare/v0.2.0...v0.2.1
|
||||
[0.2.0]: https://github.com/heyitsnoah/claudesidian/compare/v0.1.0...v0.2.0
|
||||
[0.1.0]: https://github.com/heyitsnoah/claudesidian/releases/tag/v0.1.0
|
||||
@@ -1,240 +0,0 @@
|
||||
# Obsidian Vault Guidelines - Bootstrap Template
|
||||
|
||||
**Getting Started with Claude Code + Obsidian**
|
||||
|
||||
## Quick Setup
|
||||
|
||||
1. **Start every session**: Run `git pull` to sync latest changes
|
||||
2. **After changes**: Commit and push to preserve your work
|
||||
3. **Use built-in tools**: Prefer WebSearch and WebFetch for web content
|
||||
|
||||
## Version Control Best Practices
|
||||
|
||||
**CRITICAL - START EVERY SESSION**: Always run `git pull` at the beginning of
|
||||
each new Claude session to ensure you have the latest changes from the remote
|
||||
repository.
|
||||
|
||||
**Commit workflow**:
|
||||
|
||||
- After creating new notes: `git add .` → `git commit -m "message"` → `git push`
|
||||
- After significant edits: Commit and push immediately
|
||||
- Use `git status` to check for modifications
|
||||
- When agents modify files: Always commit those changes
|
||||
|
||||
## Folder Structure (PARA Method)
|
||||
|
||||
```
|
||||
vault/
|
||||
├── 00_Inbox/ # Temporary capture point
|
||||
├── 01_Projects/ # Time-bound initiatives
|
||||
├── 02_Areas/ # Ongoing responsibilities
|
||||
├── 03_Resources/ # Reference materials
|
||||
├── 04_Archive/ # Completed/inactive items
|
||||
├── 05_Attachments/ # Images, PDFs, etc.
|
||||
│ └── Organized/ # Processed attachments
|
||||
└── 06_Metadata/ # Documentation & templates
|
||||
├── Reference/ # Guides and standards
|
||||
├── Plans/ # Strategic documents
|
||||
└── Templates/ # Reusable structures
|
||||
```
|
||||
|
||||
## PARA Method Details
|
||||
|
||||
### Projects (01)
|
||||
|
||||
- Time-bound initiatives with clear completion criteria
|
||||
- Examples: Writing a paper, developing a presentation
|
||||
- Recommended subfolders: Research/, Drafts/, References/, Output/
|
||||
|
||||
### Areas (02)
|
||||
|
||||
- Ongoing responsibilities without end dates
|
||||
- Examples: Health, Finances, Professional Development
|
||||
- Create dedicated notes with links to related resources
|
||||
|
||||
### Resources (03)
|
||||
|
||||
- Topics of interest for reference
|
||||
- Knowledge bases organized by subject
|
||||
- Use for information not tied to specific projects
|
||||
|
||||
### Archive (04)
|
||||
|
||||
- Completed or inactive items
|
||||
- Maintain same folder structure as active sections
|
||||
- Review periodically for reactivation
|
||||
|
||||
## Inbox Management
|
||||
|
||||
### Core Principles
|
||||
|
||||
- Inbox is temporary, not permanent storage
|
||||
- Process weekly using Capture → Process → Organize workflow
|
||||
- Maintain <20 items at any time
|
||||
|
||||
### Files to Keep in Inbox
|
||||
|
||||
- **CRITICAL**: Files with number prefixes (00-06) stay permanently
|
||||
- Recent daily/weekly summaries (last 3 months)
|
||||
- Active notes being processed
|
||||
|
||||
### Processing Workflow
|
||||
|
||||
1. Delete obsolete information
|
||||
2. Move relevant material to PARA locations
|
||||
3. Convert actions into project tasks
|
||||
4. Tag items needing more processing with `#needs-processing`
|
||||
|
||||
## File Organization Guidelines
|
||||
|
||||
### Naming Conventions
|
||||
|
||||
- Daily notes: `YYYY-MM-DD - Topic`
|
||||
- Meeting notes: `Meeting - [Topic] - YYYY-MM-DD`
|
||||
- Ideas: `Idea - [Brief Description]`
|
||||
- Resources: `Resource - [Topic] - [Source]`
|
||||
|
||||
### Movement Rules
|
||||
|
||||
- Use `mv` command (not `cp`) to avoid duplicates
|
||||
- Verify destination folders exist first
|
||||
- Update internal links after moves
|
||||
- Add YAML frontmatter when organizing
|
||||
|
||||
## Attachments Management
|
||||
|
||||
### Organization
|
||||
|
||||
- Store all non-text files in `05_Attachments/`
|
||||
- Processed files → `05_Attachments/Organized/`
|
||||
- Naming: `[RelatedNote]_[Description].[ext]`
|
||||
|
||||
### Helper Scripts
|
||||
|
||||
```bash
|
||||
pnpm attachments:list # List unprocessed files
|
||||
pnpm attachments:organized # Count organized files
|
||||
pnpm attachments:orphans # Find unreferenced files
|
||||
pnpm attachments:update-links # Update links after moving
|
||||
```
|
||||
|
||||
## Web Content Workflow
|
||||
|
||||
### Built-in Tools (Preferred)
|
||||
|
||||
- **WebSearch**: For general web searches
|
||||
- **WebFetch**: For specific URLs
|
||||
- Save to appropriate folder based on content type
|
||||
|
||||
### Custom Scripts (When Needed)
|
||||
|
||||
- Single URL: `pnpm firecrawl:scrape <url> <output>`
|
||||
- Batch URLs: `pnpm firecrawl:batch <url1> <url2>`
|
||||
- Saves to `00_Inbox/Clippings/` with frontmatter
|
||||
|
||||
## Writing Style Guidelines
|
||||
|
||||
### Structure
|
||||
|
||||
- Use `[[WikiLinks]]` for internal references
|
||||
- Include YAML frontmatter (dates, tags, status)
|
||||
- Consistent Markdown formatting
|
||||
- Specific, consistent tags
|
||||
|
||||
### Style Preferences
|
||||
|
||||
- Direct and confident statements
|
||||
- Avoid clichéd transitions
|
||||
- Let statements stand on their own
|
||||
- No unnecessary lead-ins
|
||||
|
||||
## AI Assistant Guidelines
|
||||
|
||||
### Before Any Organization
|
||||
|
||||
1. Map complete folder structure: `find . -type d | sort`
|
||||
2. Document in `06_Metadata/STRUCTURE.md`
|
||||
3. Verify all destination folders exist
|
||||
|
||||
### Working with Content
|
||||
|
||||
- Respect numbered core files (never move 00-06 prefixed files)
|
||||
- Always use `mv` not `cp` when organizing
|
||||
- Preserve and update bidirectional links
|
||||
- Add appropriate YAML frontmatter
|
||||
|
||||
### Simple Commands Only
|
||||
|
||||
- **REQUIRED**: Direct, basic commands without filtering
|
||||
- **FORBIDDEN**: Complex regex, piped commands, find with filters
|
||||
- Example RIGHT: `ls -1` then manually select files
|
||||
- Example WRONG: `ls | grep pattern` or `find . -name "*.png"`
|
||||
|
||||
## Daily Workflows
|
||||
|
||||
### Start of Day
|
||||
|
||||
1. Run `git pull`
|
||||
2. Check inbox for items to process
|
||||
3. Review active projects
|
||||
|
||||
### End of Day
|
||||
|
||||
1. Process new inbox items
|
||||
2. Commit and push changes
|
||||
3. Update project notes
|
||||
|
||||
### Weekly Review
|
||||
|
||||
1. Process entire inbox
|
||||
2. Archive completed projects
|
||||
3. Update area notes
|
||||
4. Review and consolidate resources
|
||||
|
||||
## Project Lifecycle
|
||||
|
||||
### Starting a Project
|
||||
|
||||
1. Create folder in `01_Projects/[ProjectName]`
|
||||
2. Add subfolders: Research/, Drafts/, Output/
|
||||
3. Create README with objectives and timeline
|
||||
|
||||
### During Project
|
||||
|
||||
- Keep all related materials in project folder
|
||||
- Link to relevant resources and areas
|
||||
- Regular commits to track progress
|
||||
|
||||
### Completing a Project
|
||||
|
||||
1. Create project summary note
|
||||
2. Move entire folder to `04_Archive/`
|
||||
3. Update relevant area notes
|
||||
4. Commit with completion message
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Organization
|
||||
|
||||
- Keep folder structure shallow (max 3 levels)
|
||||
- Create subfolders only with 7+ related notes
|
||||
- Use linking over deep nesting
|
||||
- Include README in major folders
|
||||
|
||||
### Content Creation
|
||||
|
||||
- Capture first, organize later
|
||||
- One idea per note
|
||||
- Link generously
|
||||
- Tag consistently
|
||||
|
||||
### Maintenance
|
||||
|
||||
- Weekly inbox processing
|
||||
- Monthly project reviews
|
||||
- Quarterly archive cleanup
|
||||
- Regular git commits
|
||||
|
||||
---
|
||||
|
||||
_This is a bootstrap template. Customize based on your workflow and needs._
|
||||
@@ -1,12 +0,0 @@
|
||||
<claude-mem-context>
|
||||
# Recent Activity
|
||||
|
||||
<!-- This section is auto-generated by claude-mem. Edit content outside the tags. -->
|
||||
|
||||
### Feb 25, 2026
|
||||
|
||||
| ID | Time | T | Title | Read |
|
||||
|----|------|---|-------|------|
|
||||
| #1217 | 10:32 AM | 🟣 | Comprehensive vault health audit report generated | ~517 |
|
||||
| #1213 | 10:29 AM | 🔵 | Vault underwent formal review and improvement planning in February 2026 | ~630 |
|
||||
</claude-mem-context>
|
||||
@@ -1,786 +0,0 @@
|
||||
# Obsidian Vault Configuration
|
||||
|
||||
**Generated**: January 05, 2026
|
||||
**Organization**: PARA Method
|
||||
**Uses**: Research, Writing, Project Management, Daily Notes
|
||||
**Status**: Active Configuration
|
||||
|
||||
---
|
||||
|
||||
## Quick Start
|
||||
|
||||
### First-Time Setup
|
||||
1. Run `git pull` to sync with remote repository
|
||||
2. Review folder structure below
|
||||
3. Start capturing notes in `00_Inbox/`
|
||||
4. Schedule your first weekly review
|
||||
|
||||
### Daily Workflow
|
||||
```bash
|
||||
# Morning
|
||||
git pull # Sync latest changes
|
||||
# Review inbox, work on projects
|
||||
|
||||
# Evening
|
||||
git status # Check modifications
|
||||
git add . # Stage changes
|
||||
git commit -m "vault backup: $(date)"
|
||||
git push # Sync to remote
|
||||
```
|
||||
|
||||
### Essential Commands
|
||||
- **Inbox Processing**: Review `00_Inbox/` weekly
|
||||
- **Web Content**: Use WebSearch or WebFetch tools
|
||||
- **Attachments**: Store in `05_Attachments/`, organize when processed
|
||||
- **Weekly Review**: Follow checklist in `WEEKLY_REVIEW.md`
|
||||
|
||||
---
|
||||
|
||||
## Folder Structure
|
||||
|
||||
```
|
||||
D:\tmp\vault\my-vault/
|
||||
├── 00_Inbox/ # Temporary capture point
|
||||
│ ├── Clippings/ # Web content from Firecrawl
|
||||
│ └── [Daily captures] # Quick notes to process
|
||||
│
|
||||
├── 01_Projects/ # Time-bound initiatives
|
||||
│ └── [ProjectName]/
|
||||
│ ├── Research/ # Background materials
|
||||
│ ├── Drafts/ # Work in progress
|
||||
│ ├── References/ # Supporting documents
|
||||
│ └── Output/ # Final deliverables
|
||||
│
|
||||
├── 02_Areas/ # Ongoing responsibilities
|
||||
│ └── [AreaName]/ # Health, Finances, etc.
|
||||
│
|
||||
├── 03_Resources/ # Reference materials
|
||||
│ └── [TopicName]/ # Knowledge bases by subject
|
||||
│
|
||||
├── 04_Archive/ # Completed/inactive items
|
||||
│ ├── Projects/ # Completed projects
|
||||
│ ├── Areas/ # Inactive areas
|
||||
│ └── Resources/ # Outdated resources
|
||||
│
|
||||
├── 05_Attachments/ # Non-text files
|
||||
│ ├── Organized/ # Processed attachments
|
||||
│ └── [Unprocessed] # Awaiting organization
|
||||
│
|
||||
└── 06_Metadata/ # Documentation & templates
|
||||
├── Reference/ # Guides and standards
|
||||
├── Plans/ # Strategic documents
|
||||
└── Templates/ # Reusable structures
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PARA Method Explained
|
||||
|
||||
### Projects (01_Projects/)
|
||||
**Definition**: Time-bound initiatives with clear completion criteria
|
||||
|
||||
**Characteristics**:
|
||||
- Has a specific end goal
|
||||
- Has a deadline or completion state
|
||||
- Contains discrete tasks and deliverables
|
||||
- Will eventually move to Archive
|
||||
|
||||
**Examples**:
|
||||
- Writing a research paper
|
||||
- Planning a presentation
|
||||
- Learning a specific skill
|
||||
- Organizing an event
|
||||
|
||||
**Structure**:
|
||||
```
|
||||
01_Projects/[ProjectName]/
|
||||
├── README.md # Project overview, goals, timeline
|
||||
├── Research/ # Background materials
|
||||
├── Drafts/ # Work in progress
|
||||
├── References/ # Supporting documents
|
||||
└── Output/ # Final deliverables
|
||||
```
|
||||
|
||||
### Areas (02_Areas/)
|
||||
**Definition**: Ongoing responsibilities without end dates
|
||||
|
||||
**Characteristics**:
|
||||
- Continuous maintenance required
|
||||
- Standards to uphold
|
||||
- No completion date
|
||||
- Generates multiple projects over time
|
||||
|
||||
**Examples**:
|
||||
- Health & Fitness
|
||||
- Professional Development
|
||||
- Finances
|
||||
- Relationships
|
||||
- Home Management
|
||||
|
||||
**Structure**:
|
||||
```
|
||||
02_Areas/[AreaName]/
|
||||
├── Overview.md # Area definition and standards
|
||||
├── Projects.md # Related project links
|
||||
└── Resources.md # Helpful references
|
||||
```
|
||||
|
||||
### Resources (03_Resources/)
|
||||
**Definition**: Topics of interest for reference and learning
|
||||
|
||||
**Characteristics**:
|
||||
- Not tied to current projects
|
||||
- Reference material
|
||||
- Long-term knowledge building
|
||||
- Curated information
|
||||
|
||||
**Examples**:
|
||||
- Programming languages
|
||||
- Historical topics
|
||||
- Philosophical concepts
|
||||
- Technical documentation
|
||||
- Book notes
|
||||
|
||||
**Structure**:
|
||||
```
|
||||
03_Resources/[TopicName]/
|
||||
├── Index.md # Topic overview
|
||||
├── Notes/ # Individual concept notes
|
||||
└── References/ # Source materials
|
||||
```
|
||||
|
||||
### Archive (04_Archive/)
|
||||
**Definition**: Completed projects and inactive items
|
||||
|
||||
**Characteristics**:
|
||||
- Completed projects
|
||||
- Inactive areas
|
||||
- Outdated resources
|
||||
- Historical reference
|
||||
|
||||
**When to Archive**:
|
||||
- Projects: When objectives are met
|
||||
- Areas: When no longer relevant
|
||||
- Resources: When superseded or outdated
|
||||
|
||||
---
|
||||
|
||||
## File Organization Rules
|
||||
|
||||
### Naming Conventions
|
||||
|
||||
**Daily Notes**:
|
||||
```
|
||||
YYYY-MM-DD - [Topic or Activity]
|
||||
Example: 2026-01-05 - Meeting Notes
|
||||
```
|
||||
|
||||
**Meeting Notes**:
|
||||
```
|
||||
Meeting - [Topic] - YYYY-MM-DD
|
||||
Example: Meeting - Project Planning - 2026-01-05
|
||||
```
|
||||
|
||||
**Ideas**:
|
||||
```
|
||||
Idea - [Brief Description]
|
||||
Example: Idea - Automated Daily Review Process
|
||||
```
|
||||
|
||||
**Resources**:
|
||||
```
|
||||
Resource - [Topic] - [Source]
|
||||
Example: Resource - PARA Method - Forte Labs
|
||||
```
|
||||
|
||||
**Clippings (Auto-generated by Firecrawl)**:
|
||||
```
|
||||
[Domain]_[Timestamp].md
|
||||
Example: anthropic.com_1736095200.md
|
||||
```
|
||||
|
||||
### Movement Best Practices
|
||||
|
||||
**ALWAYS**:
|
||||
- Use `mv` command (not `cp`) to avoid duplicates
|
||||
- Verify destination folder exists before moving
|
||||
- Update internal links after moving files
|
||||
- Add YAML frontmatter when organizing
|
||||
- Commit changes after significant reorganization
|
||||
|
||||
**NEVER**:
|
||||
- Move files with number prefixes (00-06) from root
|
||||
- Delete files without reviewing content
|
||||
- Create deep folder hierarchies (max 3 levels)
|
||||
- Leave broken links after reorganization
|
||||
|
||||
### YAML Frontmatter Template
|
||||
|
||||
```yaml
|
||||
---
|
||||
created: YYYY-MM-DD
|
||||
modified: YYYY-MM-DD
|
||||
tags: [tag1, tag2, tag3]
|
||||
status: [draft|active|complete|archived]
|
||||
type: [note|project|area|resource]
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Inbox Management
|
||||
|
||||
### Core Principles
|
||||
- Inbox is **temporary**, not permanent storage
|
||||
- Process weekly using: Capture → Process → Organize
|
||||
- Maintain fewer than 20 unprocessed items
|
||||
- Everything in inbox should be recent (< 1 week old)
|
||||
|
||||
### What Stays in Inbox Permanently
|
||||
- Files with number prefixes: `00-`, `01-`, etc.
|
||||
- Core configuration files: `CLAUDE.md`, `WEEKLY_REVIEW.md`, `.gitignore`
|
||||
- Active daily notes (last 7 days)
|
||||
- Current weekly summaries (last 3 months)
|
||||
|
||||
### Processing Workflow
|
||||
|
||||
**Step 1: Review**
|
||||
```bash
|
||||
git status # See what's new
|
||||
ls 00_Inbox/ # List inbox contents
|
||||
```
|
||||
|
||||
**Step 2: Decide**
|
||||
For each item, ask:
|
||||
- Is this actionable? → Create task or project
|
||||
- Is this reference? → Move to Resources
|
||||
- Is this project-related? → Move to Projects
|
||||
- Is this outdated? → Delete or archive
|
||||
- Needs more work? → Tag `#needs-processing`
|
||||
|
||||
**Step 3: Organize**
|
||||
```bash
|
||||
# Move to appropriate location
|
||||
mv "00_Inbox/filename.md" "01_Projects/ProjectName/"
|
||||
|
||||
# Verify
|
||||
ls "01_Projects/ProjectName/"
|
||||
```
|
||||
|
||||
**Step 4: Commit**
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "Organize inbox: processed weekly items"
|
||||
git push
|
||||
```
|
||||
|
||||
### Inbox Clippings Folder
|
||||
- Firecrawl automatically saves web content here
|
||||
- Process within 1 week
|
||||
- Move to appropriate PARA location
|
||||
- Delete duplicates or low-value content
|
||||
|
||||
---
|
||||
|
||||
## Attachments Management
|
||||
|
||||
### Organization Rules
|
||||
|
||||
**Storage Location**:
|
||||
- All non-text files: `05_Attachments/`
|
||||
- Unprocessed: `05_Attachments/`
|
||||
- Processed: `05_Attachments/Organized/`
|
||||
|
||||
**Naming Convention**:
|
||||
```
|
||||
[RelatedNote]_[Description].[ext]
|
||||
|
||||
Examples:
|
||||
ProjectProposal_Diagram.png
|
||||
Research_StatisticsTable.pdf
|
||||
Meeting2026-01-05_Whiteboard.jpg
|
||||
```
|
||||
|
||||
**Supported File Types**:
|
||||
- Images: PNG, JPG, GIF, SVG
|
||||
- Documents: PDF, DOCX
|
||||
- Data: CSV, XLSX, JSON
|
||||
- Media: MP3, MP4 (use sparingly)
|
||||
|
||||
### Processing Workflow
|
||||
|
||||
**Step 1: List Unprocessed**
|
||||
```bash
|
||||
ls 05_Attachments/
|
||||
```
|
||||
|
||||
**Step 2: Review Each File**
|
||||
- Is it referenced in notes? Keep and rename
|
||||
- Is it orphaned? Delete or add reference
|
||||
- Is it project-related? Keep with clear name
|
||||
|
||||
**Step 3: Rename and Move**
|
||||
```bash
|
||||
mv "05_Attachments/screenshot.png" "05_Attachments/Organized/ProjectName_Feature.png"
|
||||
```
|
||||
|
||||
**Step 4: Update Links**
|
||||
Update any markdown references:
|
||||
```markdown
|
||||
Before: 
|
||||
After: 
|
||||
```
|
||||
|
||||
### Helper Scripts
|
||||
|
||||
```bash
|
||||
# List unprocessed attachments
|
||||
pnpm attachments:list
|
||||
|
||||
# Count organized files
|
||||
pnpm attachments:organized
|
||||
|
||||
# Find unreferenced files (orphans)
|
||||
pnpm attachments:orphans
|
||||
|
||||
# Update links after moving files
|
||||
pnpm attachments:update-links
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Web Content Workflow
|
||||
|
||||
### Built-in Tools (Preferred Method)
|
||||
|
||||
**WebSearch Tool**:
|
||||
```
|
||||
Use for: General web searches, current information
|
||||
Output: Search results with sources
|
||||
Action: Copy relevant content into notes manually
|
||||
```
|
||||
|
||||
**WebFetch Tool**:
|
||||
```
|
||||
Use for: Specific URLs, documentation pages
|
||||
Output: Page content in markdown format
|
||||
Action: Save to appropriate PARA location
|
||||
```
|
||||
|
||||
**Best Practices**:
|
||||
1. Use WebSearch/WebFetch within Claude Code
|
||||
2. Review content before saving
|
||||
3. Add frontmatter and context
|
||||
4. Save to appropriate folder (not Inbox unless processing later)
|
||||
5. Include source URL in frontmatter
|
||||
|
||||
### Firecrawl Scripts (Batch Processing)
|
||||
|
||||
**Single URL**:
|
||||
```bash
|
||||
pnpm firecrawl:scrape <url> <output-filename>
|
||||
# Saves to: 00_Inbox/Clippings/
|
||||
```
|
||||
|
||||
**Batch URLs**:
|
||||
```bash
|
||||
pnpm firecrawl:batch <url1> <url2> <url3>
|
||||
# Saves to: 00_Inbox/Clippings/
|
||||
```
|
||||
|
||||
**Auto-generated Frontmatter**:
|
||||
```yaml
|
||||
---
|
||||
source_url: https://example.com/article
|
||||
scraped_date: YYYY-MM-DD
|
||||
tags: [clipping, needs-processing]
|
||||
---
|
||||
```
|
||||
|
||||
**Processing Clippings**:
|
||||
1. Review content quality
|
||||
2. Add relevant tags and notes
|
||||
3. Move to appropriate PARA location
|
||||
4. Delete low-value clippings
|
||||
|
||||
---
|
||||
|
||||
## Writing Style Guidelines
|
||||
|
||||
### Structure Standards
|
||||
|
||||
**Internal Linking**:
|
||||
- Use `[[WikiLinks]]` for all internal references
|
||||
- Link liberally (better too many than too few)
|
||||
- Create bidirectional links when relevant
|
||||
- Use descriptive link text
|
||||
|
||||
**Markdown Formatting**:
|
||||
- Headings: Use `#` hierarchy (H1 for title, H2 for sections)
|
||||
- Lists: Use `-` for unordered, `1.` for ordered
|
||||
- Code: Use backticks for inline, triple backticks for blocks
|
||||
- Emphasis: `**bold**` for important, `*italic*` for subtle
|
||||
|
||||
**YAML Frontmatter**:
|
||||
- Always include: created, modified, tags
|
||||
- Optional: status, type, project, area
|
||||
- Keep tags specific and consistent
|
||||
- Update modified date when editing
|
||||
|
||||
### Content Style Preferences
|
||||
|
||||
**Direct Communication**:
|
||||
- Lead with the main point
|
||||
- Avoid unnecessary preambles
|
||||
- Be specific and concrete
|
||||
- Use active voice
|
||||
|
||||
**Avoid**:
|
||||
- Clichéd transitions ("In today's world...")
|
||||
- Filler phrases ("It's worth noting that...")
|
||||
- Unnecessary qualifiers ("I think maybe...")
|
||||
- Overused business jargon
|
||||
|
||||
**Prefer**:
|
||||
- Clear, confident statements
|
||||
- Specific examples over generalizations
|
||||
- Simple sentences over complex
|
||||
- Technical precision when needed
|
||||
|
||||
---
|
||||
|
||||
## Git Workflow
|
||||
|
||||
### Critical Rule
|
||||
**ALWAYS start sessions with `git pull`** to sync latest changes from remote repository.
|
||||
|
||||
### Daily Workflow
|
||||
|
||||
**Morning (Session Start)**:
|
||||
```bash
|
||||
cd D:\tmp\vault\my-vault
|
||||
git pull
|
||||
git status # Check for any conflicts
|
||||
```
|
||||
|
||||
**During Work**:
|
||||
```bash
|
||||
git status # Periodically check changes
|
||||
```
|
||||
|
||||
**Evening (Session End)**:
|
||||
```bash
|
||||
git status # Review all changes
|
||||
git add . # Stage all changes
|
||||
git commit -m "vault backup: $(date +%Y-%m-%d\ %H:%M:%S)"
|
||||
git push # Sync to remote
|
||||
```
|
||||
|
||||
### Commit Message Guidelines
|
||||
|
||||
**Format**:
|
||||
```
|
||||
[type]: [brief description]
|
||||
|
||||
Examples:
|
||||
vault backup: 2026-01-05 20:30:15
|
||||
Add: Project planning notes for Q1 initiatives
|
||||
Update: Weekly review template with new sections
|
||||
Organize: Moved inbox items to appropriate folders
|
||||
Archive: Completed research project
|
||||
```
|
||||
|
||||
**When to Commit**:
|
||||
- After organizing inbox
|
||||
- After creating new notes
|
||||
- After significant edits
|
||||
- Before ending session
|
||||
- After weekly review
|
||||
|
||||
### Common Git Commands
|
||||
|
||||
```bash
|
||||
git status # Check current state
|
||||
git pull # Sync from remote
|
||||
git add . # Stage all changes
|
||||
git commit -m "message" # Commit with message
|
||||
git push # Sync to remote
|
||||
git log --oneline -10 # View recent commits
|
||||
```
|
||||
|
||||
### Handling Conflicts
|
||||
|
||||
If `git pull` shows conflicts:
|
||||
1. Review conflicted files
|
||||
2. Resolve conflicts manually
|
||||
3. Stage resolved files: `git add .`
|
||||
4. Commit: `git commit -m "Resolve merge conflicts"`
|
||||
5. Push: `git push`
|
||||
|
||||
---
|
||||
|
||||
## AI Assistant Guidelines
|
||||
|
||||
### Before Any Organization Task
|
||||
|
||||
**Step 1: Map Structure**
|
||||
```bash
|
||||
find . -type d | sort > 06_Metadata/STRUCTURE.md
|
||||
```
|
||||
|
||||
**Step 2: Document Current State**
|
||||
- List all folders
|
||||
- Note any custom organization
|
||||
- Identify files needing attention
|
||||
|
||||
**Step 3: Verify Destinations**
|
||||
```bash
|
||||
ls -la 01_Projects/
|
||||
ls -la 02_Areas/
|
||||
ls -la 03_Resources/
|
||||
```
|
||||
|
||||
### Working with Content
|
||||
|
||||
**DO**:
|
||||
- Use `mv` command (not `cp`) to avoid duplicates
|
||||
- Verify destination folders exist before moving
|
||||
- Preserve and update bidirectional links
|
||||
- Add appropriate YAML frontmatter
|
||||
- Respect numbered core files (never move files with 00-06 prefix)
|
||||
- Commit changes after organization
|
||||
|
||||
**DON'T**:
|
||||
- Use complex piped commands or regex
|
||||
- Move files without checking destinations
|
||||
- Leave broken links after reorganization
|
||||
- Create deep folder hierarchies
|
||||
- Delete without reviewing content
|
||||
|
||||
### Command Simplicity Rule
|
||||
|
||||
**REQUIRED**: Use direct, basic commands only
|
||||
```bash
|
||||
# RIGHT
|
||||
ls -1
|
||||
ls 00_Inbox/
|
||||
find . -type d
|
||||
|
||||
# WRONG
|
||||
ls | grep pattern
|
||||
find . -name "*.md" -mtime +7
|
||||
ls | wc -l
|
||||
```
|
||||
|
||||
**Reasoning**: Simple commands are more reliable and easier to verify.
|
||||
|
||||
---
|
||||
|
||||
## Daily Workflows
|
||||
|
||||
### Morning Routine (5 minutes)
|
||||
|
||||
```bash
|
||||
# 1. Sync changes
|
||||
git pull
|
||||
|
||||
# 2. Check inbox
|
||||
ls 00_Inbox/
|
||||
|
||||
# 3. Review today's focus
|
||||
# Create or open: YYYY-MM-DD - Daily Notes.md
|
||||
```
|
||||
|
||||
**Daily Note Template**:
|
||||
```markdown
|
||||
---
|
||||
created: YYYY-MM-DD
|
||||
type: daily
|
||||
tags: [daily, journal]
|
||||
---
|
||||
|
||||
# YYYY-MM-DD - Daily Notes
|
||||
|
||||
## Focus for Today
|
||||
- [ ] Primary task 1
|
||||
- [ ] Primary task 2
|
||||
- [ ] Primary task 3
|
||||
|
||||
## Capture
|
||||
[Quick notes throughout the day]
|
||||
|
||||
## Reflections
|
||||
[End of day thoughts]
|
||||
```
|
||||
|
||||
### Evening Routine (5 minutes)
|
||||
|
||||
```bash
|
||||
# 1. Process quick inbox items
|
||||
ls 00_Inbox/
|
||||
|
||||
# 2. Update project notes
|
||||
# Review and update active projects
|
||||
|
||||
# 3. Commit changes
|
||||
git status
|
||||
git add .
|
||||
git commit -m "vault backup: $(date)"
|
||||
git push
|
||||
```
|
||||
|
||||
### Weekly Review (30-45 minutes)
|
||||
|
||||
See `WEEKLY_REVIEW.md` for complete checklist.
|
||||
|
||||
**Quick Overview**:
|
||||
1. Process entire inbox (target: zero items)
|
||||
2. Review all active projects
|
||||
3. Update area notes
|
||||
4. Archive completed items
|
||||
5. Clean up attachments
|
||||
6. Plan next week
|
||||
|
||||
---
|
||||
|
||||
## Available Commands
|
||||
|
||||
### Attachment Management
|
||||
```bash
|
||||
pnpm attachments:list # List unprocessed attachments
|
||||
pnpm attachments:organized # Count organized files
|
||||
pnpm attachments:orphans # Find unreferenced files
|
||||
pnpm attachments:update-links # Update links after moving
|
||||
```
|
||||
|
||||
### Web Content
|
||||
```bash
|
||||
pnpm firecrawl:scrape <url> <output> # Scrape single URL
|
||||
pnpm firecrawl:batch <url1> <url2> # Scrape multiple URLs
|
||||
```
|
||||
|
||||
### Git Operations
|
||||
```bash
|
||||
git pull # Sync from remote
|
||||
git status # Check modifications
|
||||
git add . # Stage all changes
|
||||
git commit -m "message" # Commit with message
|
||||
git push # Sync to remote
|
||||
```
|
||||
|
||||
### Folder Navigation
|
||||
```bash
|
||||
cd D:\tmp\vault\my-vault # Vault root
|
||||
ls 00_Inbox/ # List inbox
|
||||
ls 01_Projects/ # List projects
|
||||
find . -type d | sort # Map all folders
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Organization Principles
|
||||
|
||||
**Keep It Shallow**:
|
||||
- Maximum 3 levels of folders
|
||||
- Create subfolders only with 7+ related notes
|
||||
- Use linking over deep nesting
|
||||
- Flat is better than nested
|
||||
|
||||
**Maintain Clarity**:
|
||||
- Include README.md in major folders
|
||||
- Use consistent naming conventions
|
||||
- Tag consistently and specifically
|
||||
- Update frontmatter regularly
|
||||
|
||||
**Regular Maintenance**:
|
||||
- Weekly inbox processing (non-negotiable)
|
||||
- Monthly project reviews
|
||||
- Quarterly archive cleanup
|
||||
- Daily git commits
|
||||
|
||||
### Content Creation Principles
|
||||
|
||||
**Capture First, Organize Later**:
|
||||
- Don't let organization block capture
|
||||
- Inbox is for quick entry
|
||||
- Process in batches, not individually
|
||||
- Speed over perfection initially
|
||||
|
||||
**One Idea Per Note**:
|
||||
- Atomic notes are more reusable
|
||||
- Easier to link and discover
|
||||
- Better for future reorganization
|
||||
- Clear single purpose
|
||||
|
||||
**Link Generously**:
|
||||
- Create connections between ideas
|
||||
- Build bidirectional links
|
||||
- Use consistent link syntax
|
||||
- Review links when moving files
|
||||
|
||||
**Tag Consistently**:
|
||||
- Use specific tags over generic
|
||||
- Maintain tag vocabulary list
|
||||
- Tag for retrieval, not categorization
|
||||
- Review tags during weekly review
|
||||
|
||||
### Maintenance Schedule
|
||||
|
||||
**Daily**:
|
||||
- Morning: `git pull`, check inbox
|
||||
- Evening: Commit changes, `git push`
|
||||
|
||||
**Weekly**:
|
||||
- Process entire inbox
|
||||
- Review active projects
|
||||
- Update area notes
|
||||
- Clean attachments folder
|
||||
|
||||
**Monthly**:
|
||||
- Review all projects for completion
|
||||
- Archive inactive items
|
||||
- Consolidate resources
|
||||
- Update documentation
|
||||
|
||||
**Quarterly**:
|
||||
- Deep archive review
|
||||
- Prune old resources
|
||||
- Update folder structure if needed
|
||||
- Review and refine workflows
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
**Inbox Overflow**:
|
||||
- Schedule immediate processing session
|
||||
- Delete obvious low-value items first
|
||||
- Process in batches by type
|
||||
- Set calendar reminder for weekly review
|
||||
|
||||
**Broken Links**:
|
||||
- Use attachment update script
|
||||
- Manually verify critical links
|
||||
- Commit after fixing links
|
||||
- Document link structure
|
||||
|
||||
**Git Conflicts**:
|
||||
- Always start with `git pull`
|
||||
- Resolve conflicts immediately
|
||||
- Don't force push
|
||||
- Backup before major changes
|
||||
|
||||
**Lost Files**:
|
||||
- Check git history: `git log --all --full-history -- <path>`
|
||||
- Look in Archive folders
|
||||
- Search by content: use grep or Obsidian search
|
||||
- Check recent commits for moves
|
||||
|
||||
---
|
||||
|
||||
**Last Updated**: January 05, 2026
|
||||
**Next Review**: Weekly during weekly review process
|
||||
@@ -1,93 +0,0 @@
|
||||
# Contributing to Claudesidian
|
||||
|
||||
Thank you for your interest in contributing to claudesidian! This document
|
||||
provides guidelines for contributing to the project.
|
||||
|
||||
## Development Setup
|
||||
|
||||
1. Fork the repository
|
||||
2. Clone your fork: `git clone https://github.com/yourusername/claudesidian.git`
|
||||
3. Install dependencies: `pnpm install`
|
||||
4. Create a feature branch: `git checkout -b feature/your-feature-name`
|
||||
|
||||
## Commit Message Convention
|
||||
|
||||
We follow [Conventional Commits](https://www.conventionalcommits.org/) for clear
|
||||
commit history:
|
||||
|
||||
- `feat:` New feature
|
||||
- `fix:` Bug fix
|
||||
- `docs:` Documentation changes
|
||||
- `style:` Code style changes (formatting, etc.)
|
||||
- `refactor:` Code refactoring
|
||||
- `test:` Test additions or changes
|
||||
- `chore:` Maintenance tasks
|
||||
|
||||
Examples:
|
||||
|
||||
```
|
||||
feat: add new research-assistant command
|
||||
fix: correct attachment link updates in scripts
|
||||
docs: update README with MCP setup instructions
|
||||
```
|
||||
|
||||
## Versioning
|
||||
|
||||
We use [Semantic Versioning](https://semver.org/):
|
||||
|
||||
- MAJOR (1.0.0): Breaking changes
|
||||
- MINOR (0.1.0): New features (backward compatible)
|
||||
- PATCH (0.0.1): Bug fixes (backward compatible)
|
||||
|
||||
## Pull Request Process
|
||||
|
||||
1. Update the CHANGELOG.md with your changes under "Unreleased"
|
||||
2. Update documentation if needed
|
||||
3. Ensure all scripts still work
|
||||
4. Submit PR with clear description of changes
|
||||
|
||||
## Changelog Updates
|
||||
|
||||
When contributing, add your changes to CHANGELOG.md under the "Unreleased"
|
||||
section:
|
||||
|
||||
```markdown
|
||||
## [Unreleased]
|
||||
|
||||
### Added
|
||||
|
||||
- Your new feature here
|
||||
|
||||
### Fixed
|
||||
|
||||
- Your bug fix here
|
||||
```
|
||||
|
||||
Use these categories:
|
||||
|
||||
- **Added** - New features
|
||||
- **Changed** - Changes to existing functionality
|
||||
- **Deprecated** - Features to be removed
|
||||
- **Removed** - Removed features
|
||||
- **Fixed** - Bug fixes
|
||||
- **Security** - Security updates
|
||||
|
||||
## Release Process (Maintainers)
|
||||
|
||||
1. Update version in package.json
|
||||
2. Move "Unreleased" items to new version in CHANGELOG.md
|
||||
3. Commit: `git commit -m "chore: release v0.2.0"`
|
||||
4. Tag: `git tag v0.2.0`
|
||||
5. Push: `git push && git push --tags`
|
||||
6. Create GitHub Release from tag, using changelog content
|
||||
|
||||
## Code Style
|
||||
|
||||
- Use clear, descriptive variable names
|
||||
- Comment complex logic
|
||||
- Keep functions focused and small
|
||||
- Test your changes thoroughly
|
||||
|
||||
## Questions?
|
||||
|
||||
Feel free to open an issue for discussion before making large changes.
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
title: Dataview Validation 2026-02-25
|
||||
date: 2026-02-25
|
||||
type: validation-log
|
||||
status: done
|
||||
source: 06_Metadata/REVIEW_REPORT_2026-02-25.md
|
||||
---
|
||||
|
||||
# Dataview 修复验收
|
||||
|
||||
## 修复项
|
||||
|
||||
- 将 7 个 Area Hub 中 `from "200-area/..."` 全部修正为 `from "02_Areas/..."`。
|
||||
|
||||
## 验收结果（修复前/后）
|
||||
|
||||
- 修复前：7/7 Hub 查询为空（报告确认）。
|
||||
- 修复后：
|
||||
- `02_Areas/Finance`：3 条
|
||||
- `02_Areas/Blog`：6 条
|
||||
- `02_Areas/Health`：2 条
|
||||
- `02_Areas/House`：4 条
|
||||
- `02_Areas/Personal Development`：7 条
|
||||
- `02_Areas/Network & VPN`：1 条
|
||||
- `02_Areas/Productivity`：4 条
|
||||
|
||||
## 结论
|
||||
|
||||
Dataview 路径失效问题已恢复，查询可覆盖 Area 子目录并返回非空结果。
|
||||
@@ -1,39 +0,0 @@
|
||||
---
|
||||
title: 修复任务分解与执行记录
|
||||
date: 2026-02-25
|
||||
type: execution-log
|
||||
status: active
|
||||
source_plan: 06_Metadata/IMPROVEMENT_PLAN_2026-02-25.md
|
||||
source_report: 06_Metadata/REVIEW_REPORT_2026-02-25.md
|
||||
---
|
||||
|
||||
# 修复任务分解（按 Phase）
|
||||
|
||||
## Phase 0（P0）
|
||||
|
||||
- [x] T0-1: 扫描并定位 `01_Projects`、`03_Resources` 中高风险凭据。
|
||||
- [x] T0-2: 对报告点名文件执行脱敏替换（统一 `{{SECRET_*}}` 占位符）。
|
||||
- [x] T0-3: 建立 `SECURITY_ROTATION_LOG_2026-02.md`，记录轮换待办。
|
||||
- [x] T0-4: 修复 7 个 Area Hub 的 Dataview 路径。
|
||||
- [x] T0-5: 记录 Dataview 修复验收数量。
|
||||
|
||||
## Phase 1（P1/P2）
|
||||
|
||||
- [x] T1-1: 根目录元文档迁移到 `06_Metadata/`（保留 `README.md`、`AGENTS.md`）。
|
||||
- [x] T1-2: 根目录孤立文件 `2026-01-05.md` 迁入 `04_Archive/Daily-Notes/`。
|
||||
- [x] T1-3: 修复插件配置中“已启用但缺目录”项。
|
||||
- [x] T1-4: 在 WORKFLOWS 增加单一主流程定义（Templater 主流程、QuickAdd 捕获入口）。
|
||||
|
||||
## Phase 2（P1/P2）
|
||||
|
||||
- [x] T2-1: 清理 Inbox 历史积压：`2023/2024` 批量归档。
|
||||
- [x] T2-2: 合并 `PKM` 与 `Personal Knowledge Management`，旧目录归档并留重定向。
|
||||
- [x] T2-3: 合并 Pickled-Cucumber 冗余笔记，保留单一权威版本。
|
||||
- [x] T2-4: 将 `02_Areas/Lifestyle/Gaming` 迁入 `03_Resources/Gaming`。
|
||||
- [x] T2-5: 补齐 Hub：`GFW.md`、`Job.md`、`Lifestyle.md`。
|
||||
|
||||
## Phase 3（维护）
|
||||
|
||||
- [x] T3-1: 将“每周 Inbox 清零机制（30 分钟）”写入流程文档。
|
||||
- [ ] T3-2: frontmatter 全量规范化（下一次集中 `pnpm lint` 时完成）。
|
||||
- [ ] T3-3: Projects/Areas 双链密度提升（按周推进）。
|
||||
@@ -1,439 +0,0 @@
|
||||
# Hermes Assistant 技术指引
|
||||
|
||||
**目标**：在这个 Obsidian vault 里正确调用 assistant 和 skills，完成检索、整理、改写、汇总、知识沉淀
|
||||
**Vault**：`/home/windy/.hermes/ObsidianVault`
|
||||
**默认 skill**：`obsidian`
|
||||
**知识库 skill**：`llm-wiki`
|
||||
|
||||
---
|
||||
|
||||
## 1. Skill 选择表
|
||||
|
||||
| 任务 | 用哪个 skill | 不要用什么 |
|
||||
|---|---|---|
|
||||
| 搜索笔记、读笔记、建笔记、改笔记 | `obsidian` | 不要直接用 `llm-wiki` |
|
||||
| 整理 `00_Inbox/` | `obsidian` | 不要直接批量移动整个 vault |
|
||||
| 汇总 `01_Projects/` 状态 | `obsidian` | 不要直接新建很多 summary note |
|
||||
| 统一 frontmatter / 标题 / wikilinks | `obsidian` | 不要不搜索就重构目录 |
|
||||
| 把文章沉淀进 `airport-wiki/` | `llm-wiki` | 不要只用 `obsidian` 生造知识页 |
|
||||
| 更新 `airport-wiki/index.md` / `SCHEMA.md` / `log.md` | `llm-wiki` | 不要把普通 inbox 内容塞进 wiki |
|
||||
|
||||
结论：
|
||||
|
||||
- PARA 管理：`obsidian`
|
||||
- 研究知识库：`llm-wiki`
|
||||
|
||||
---
|
||||
|
||||
## 2. Prompt 结构
|
||||
|
||||
每次下指令，固定带 4 个要素：
|
||||
|
||||
1. 指定 skill
|
||||
2. 指定路径或范围
|
||||
3. 指定动作
|
||||
4. 指定安全约束
|
||||
|
||||
标准模板：
|
||||
|
||||
```text
|
||||
Use the <skill> skill. Work in <path or scope>. <task>. <safety rule>.
|
||||
```
|
||||
|
||||
安全约束固定用这几个：
|
||||
|
||||
- `Propose changes before applying them.`
|
||||
- `Search existing related notes before creating anything new.`
|
||||
- `Preserve wikilinks, frontmatter, and Obsidian markdown syntax.`
|
||||
- `Make the smallest correct change.`
|
||||
|
||||
---
|
||||
|
||||
## 3. 你这个 vault 的固定操作模式
|
||||
|
||||
### `00_Inbox/`
|
||||
|
||||
用途：暂存，不定稿
|
||||
assistant 只做：
|
||||
|
||||
- 分类
|
||||
- 重命名建议
|
||||
- 合并建议
|
||||
- 迁移建议
|
||||
|
||||
不要直接做：
|
||||
|
||||
- 大批量删除
|
||||
- 扫全 vault 重构
|
||||
- 自动创建大量新笔记
|
||||
|
||||
标准 prompt：
|
||||
|
||||
```text
|
||||
Use the obsidian skill. Work in 00_Inbox. Classify each note into keep, move to projects, move to areas, move to resources, or archive. Propose changes before applying them.
|
||||
```
|
||||
|
||||
### `01_Projects/`
|
||||
|
||||
用途：有明确终点的项目
|
||||
assistant 只做：
|
||||
|
||||
- 项目状态总结
|
||||
- next actions 提取
|
||||
- stalled 项目标记
|
||||
- 相关资源链接回填
|
||||
|
||||
标准 prompt：
|
||||
|
||||
```text
|
||||
Use the obsidian skill. Work in 01_Projects. Review project notes, identify active projects, stalled projects, and missing next actions. Preserve existing note structure.
|
||||
```
|
||||
|
||||
### `02_Areas/`
|
||||
|
||||
用途：持续维护的领域
|
||||
assistant 只做：
|
||||
|
||||
- area overview 更新
|
||||
- 长期问题总结
|
||||
- 项目关系补链
|
||||
|
||||
标准 prompt：
|
||||
|
||||
```text
|
||||
Use the obsidian skill. Work in 02_Areas. Summarize the current state of each area and suggest missing project/resource links. Propose changes before applying them.
|
||||
```
|
||||
|
||||
### `03_Resources/`
|
||||
|
||||
用途：参考资料和长期保留内容
|
||||
assistant 只做：
|
||||
|
||||
- 搜索同主题笔记
|
||||
- 主题综述
|
||||
- 合并建议
|
||||
- synthesis note 草案
|
||||
|
||||
标准 prompt：
|
||||
|
||||
```text
|
||||
Use the obsidian skill. Work in 03_Resources. Search related notes on <topic>, summarize the core ideas, and suggest a synthesis note if one is missing.
|
||||
```
|
||||
|
||||
### `airport-wiki/`
|
||||
|
||||
用途：结构化研究知识库
|
||||
assistant 只做：
|
||||
|
||||
- 导入资料
|
||||
- 更新概念页
|
||||
- 更新实体页
|
||||
- 维护 index / schema / log
|
||||
|
||||
标准 prompt：
|
||||
|
||||
```text
|
||||
Use the llm-wiki skill. Work in airport-wiki. Ingest this source, update existing pages if present, create new pages only when necessary, and append a log entry.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 三类正确用法
|
||||
|
||||
### 4.1 搜索
|
||||
|
||||
目标：先找已有内容，再决定是否创建新笔记
|
||||
|
||||
正确 prompt：
|
||||
|
||||
```text
|
||||
Use the obsidian skill. Search my vault for notes related to <topic>. Return:
|
||||
1. matching notes
|
||||
2. short summary of each
|
||||
3. whether a new note is necessary
|
||||
Do not create anything yet.
|
||||
```
|
||||
|
||||
输出应该包含：
|
||||
|
||||
- 命中的笔记列表
|
||||
- 每个笔记一句摘要
|
||||
- 是否需要新建笔记
|
||||
- 如果要新建，建议放在哪个目录
|
||||
|
||||
### 4.2 编辑
|
||||
|
||||
目标：对已有笔记做小改动，不破坏结构
|
||||
|
||||
正确 prompt：
|
||||
|
||||
```text
|
||||
Use the obsidian skill. Edit <note path>. Preserve wikilinks, frontmatter, callouts, and Obsidian markdown syntax. Make the smallest correct change.
|
||||
```
|
||||
|
||||
用于：
|
||||
|
||||
- 补 frontmatter
|
||||
- 改标题
|
||||
- 改摘要
|
||||
- 增加 related notes
|
||||
- 更新 next actions
|
||||
|
||||
### 4.3 新建
|
||||
|
||||
目标：只在必要时创建最小笔记
|
||||
|
||||
正确 prompt：
|
||||
|
||||
```text
|
||||
Use the obsidian skill. Search existing related notes before creating anything new. If a new note is required, create the smallest correct note under <folder>.
|
||||
```
|
||||
|
||||
必要条件：
|
||||
|
||||
- 已搜索无等价内容
|
||||
- 新笔记有明确归属目录
|
||||
- 新笔记有明确用途
|
||||
|
||||
---
|
||||
|
||||
## 5. 五个高频任务的技术做法
|
||||
|
||||
### 5.1 Inbox 分流
|
||||
|
||||
输入：
|
||||
|
||||
- `00_Inbox/` 下的 markdown
|
||||
|
||||
动作：
|
||||
|
||||
- 分类
|
||||
- 标题规范化建议
|
||||
- 合并建议
|
||||
- 目标目录建议
|
||||
|
||||
prompt：
|
||||
|
||||
```text
|
||||
Use the obsidian skill. Work in 00_Inbox. For each note, output:
|
||||
1. current title
|
||||
2. recommended action
|
||||
3. target folder
|
||||
4. rename suggestion
|
||||
5. related existing notes
|
||||
Propose changes before applying them.
|
||||
```
|
||||
|
||||
### 5.2 项目周检
|
||||
|
||||
输入：
|
||||
|
||||
- `01_Projects/`
|
||||
|
||||
动作：
|
||||
|
||||
- 找 active / stalled / blocked
|
||||
- 抽 next actions
|
||||
|
||||
prompt：
|
||||
|
||||
```text
|
||||
Use the obsidian skill. Work in 01_Projects. Review project notes and output:
|
||||
1. active projects
|
||||
2. stalled projects
|
||||
3. blocked projects
|
||||
4. notes missing next actions
|
||||
Do not create new files unless I ask.
|
||||
```
|
||||
|
||||
### 5.3 资源主题综述
|
||||
|
||||
输入：
|
||||
|
||||
- `03_Resources/` 某一主题
|
||||
|
||||
动作：
|
||||
|
||||
- 搜索
|
||||
- 汇总
|
||||
- 判断是否缺 synthesis note
|
||||
|
||||
prompt：
|
||||
|
||||
```text
|
||||
Use the obsidian skill. Work in 03_Resources. Search notes related to <topic> and output:
|
||||
1. key notes
|
||||
2. common ideas
|
||||
3. contradictions
|
||||
4. missing links
|
||||
5. whether a synthesis note should be created
|
||||
```
|
||||
|
||||
### 5.4 修正结构但不改语义
|
||||
|
||||
输入：
|
||||
|
||||
- 单篇或单目录笔记
|
||||
|
||||
动作：
|
||||
|
||||
- frontmatter 标准化
|
||||
- 标题整理
|
||||
- links 补全
|
||||
|
||||
prompt：
|
||||
|
||||
```text
|
||||
Use the obsidian skill. Work in <folder or note>. Standardize frontmatter and note structure without changing the meaning. Preserve wikilinks and existing content hierarchy.
|
||||
```
|
||||
|
||||
### 5.5 导入 wiki
|
||||
|
||||
输入：
|
||||
|
||||
- 外部文章、论文、粘贴内容
|
||||
|
||||
动作：
|
||||
|
||||
- 查重
|
||||
- 更新已有页
|
||||
- 必要时新建页
|
||||
- 写 log
|
||||
|
||||
prompt：
|
||||
|
||||
```text
|
||||
Use the llm-wiki skill. Work in airport-wiki. Search for existing related pages first. Update them if they exist. Only create new pages when necessary. Append a log entry after the update.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 输出要求
|
||||
|
||||
让 assistant 输出时，优先要求结构化结果，不要泛泛解释。
|
||||
|
||||
推荐格式：
|
||||
|
||||
```text
|
||||
Return results in this format:
|
||||
1. Findings
|
||||
2. Proposed changes
|
||||
3. Files affected
|
||||
4. Risks
|
||||
5. Next step
|
||||
```
|
||||
|
||||
如果你只想看提案，不要执行：
|
||||
|
||||
```text
|
||||
Do not apply changes yet. Only return the proposed patch plan.
|
||||
```
|
||||
|
||||
如果你要它直接改：
|
||||
|
||||
```text
|
||||
Apply only the approved changes. Make no unrelated edits.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. 不要这样用
|
||||
|
||||
错误模式：
|
||||
|
||||
```text
|
||||
Help me organize my vault.
|
||||
```
|
||||
|
||||
问题：
|
||||
|
||||
- 没有指定 skill
|
||||
- 没有指定路径
|
||||
- 没有指定输出
|
||||
- 没有指定安全边界
|
||||
|
||||
错误模式：
|
||||
|
||||
```text
|
||||
Clean up all my notes.
|
||||
```
|
||||
|
||||
问题：
|
||||
|
||||
- 范围过大
|
||||
- 极易误改
|
||||
- 无法审核
|
||||
|
||||
错误模式：
|
||||
|
||||
```text
|
||||
Create notes about this topic.
|
||||
```
|
||||
|
||||
问题：
|
||||
|
||||
- 没有先搜索
|
||||
- 容易制造重复笔记
|
||||
|
||||
替代写法：
|
||||
|
||||
```text
|
||||
Use the obsidian skill. Search existing related notes before creating anything new. If needed, propose the smallest correct new note.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. 你应该固定保存的 Prompt
|
||||
|
||||
### A. 搜索现有笔记
|
||||
|
||||
```text
|
||||
Use the obsidian skill. Search my vault for notes related to <topic>. Return matching notes, a one-line summary of each, and whether a new note is necessary.
|
||||
```
|
||||
|
||||
### B. 编辑单篇笔记
|
||||
|
||||
```text
|
||||
Use the obsidian skill. Edit <note path>. Preserve wikilinks, frontmatter, and Obsidian markdown syntax. Make the smallest correct change.
|
||||
```
|
||||
|
||||
### C. Inbox 分类
|
||||
|
||||
```text
|
||||
Use the obsidian skill. Work in 00_Inbox. Classify each note into keep, move to projects, move to areas, move to resources, or archive. Propose changes before applying them.
|
||||
```
|
||||
|
||||
### D. 项目审查
|
||||
|
||||
```text
|
||||
Use the obsidian skill. Work in 01_Projects. Review project notes and identify active, stalled, blocked, and missing-next-action items.
|
||||
```
|
||||
|
||||
### E. Area 概览更新
|
||||
|
||||
```text
|
||||
Use the obsidian skill. Work in 02_Areas. Summarize the current state of this area and propose missing project/resource links.
|
||||
```
|
||||
|
||||
### F. 资源综述
|
||||
|
||||
```text
|
||||
Use the obsidian skill. Work in 03_Resources. Search notes related to <topic>, summarize key ideas, and suggest whether a synthesis note is missing.
|
||||
```
|
||||
|
||||
### G. Wiki 导入
|
||||
|
||||
```text
|
||||
Use the llm-wiki skill. Work in airport-wiki. Search for existing related pages first, update them if present, create new pages only when necessary, and append a log entry.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. 最短规则集
|
||||
|
||||
- 日常管理统一用 `obsidian`
|
||||
- `airport-wiki` 沉淀统一用 `llm-wiki`
|
||||
- 新建前先搜索
|
||||
- 批量改动前先出提案
|
||||
- 编辑时明确要求保留 Obsidian 语法
|
||||
- 默认只做最小正确改动
|
||||
@@ -1,137 +0,0 @@
|
||||
---
|
||||
title: Vault 修复计划
|
||||
date: 2026-02-25
|
||||
tags:
|
||||
- meta
|
||||
- improvement-plan
|
||||
- vault-health
|
||||
type: improvement-plan
|
||||
status: active
|
||||
source_report: 06_Metadata/REVIEW_REPORT_2026-02-25.md
|
||||
---
|
||||
|
||||
# Vault 修复计划（基于 2026-02-25 审查报告）
|
||||
|
||||
## 范围与目标
|
||||
|
||||
本计划针对 `06_Metadata/REVIEW_REPORT_2026-02-25.md` 中的 P0/P1/P2 问题，目标是：
|
||||
|
||||
1. 先消除高风险（凭据泄露、Dataview 全失效）。
|
||||
2. 再恢复日常可用性（Inbox、Hub、目录一致性）。
|
||||
3. 最后建立可持续维护机制（链接密度、插件治理、周流程）。
|
||||
|
||||
---
|
||||
|
||||
## 修复计划
|
||||
|
||||
### Phase 0（D0：2026-02-25，当天完成）
|
||||
|
||||
1. 建立修复分支与快照备份
|
||||
- 分支：`fix/vault-review-2026-02-25`
|
||||
- 对当前工作区打标签或保存快照，确保可回滚。
|
||||
2. 处理明文凭据（P0）
|
||||
- 扫描范围：`01_Projects/`、`03_Resources/`
|
||||
- 推荐命令：
|
||||
- `rg -n -i "(password|secret|token|api[_-]?key|access[_-]?token|shared[_-]?secret)" 01_Projects 03_Resources`
|
||||
- 修复动作：
|
||||
- 将真实凭据替换为占位符（如 `{{SECRET_FROM_1PASSWORD}}`）。
|
||||
- 对已暴露凭据执行轮换（Rotate），并记录轮换日期与系统。
|
||||
- 处理 Git 历史：使用 `git-filter-repo` 或 BFG 清理历史泄露。
|
||||
3. 修复 Dataview 路径（P0）
|
||||
- 将 `02_Areas` 下 7 个 Hub 文件内 `from "200-area/..."`
|
||||
批量修正为 `from "02_Areas/..."`。
|
||||
- 验证查询返回不为空，且可覆盖子目录。
|
||||
|
||||
### Phase 1（D1：2026-02-26 前）
|
||||
|
||||
1. 根目录收敛（P2）
|
||||
- 将元文档统一迁入 `06_Metadata/`（保留 README/必要入口除外）。
|
||||
- 将 `2026-01-05.md` 归入合适目录（日期笔记目录或 `04_Archive/`）。
|
||||
2. 插件配置对齐（P2）
|
||||
- 修复或移除已启用但目录缺失插件：
|
||||
- `obsidian-opencode`
|
||||
- `opencode-obsidian`
|
||||
- 在 `templater-obsidian` 与 `quickadd` 中指定单一主流程，避免重复。
|
||||
3. Dataview 回归验证
|
||||
- 打开 7 个 Hub 文件确认查询结果与排序正常。
|
||||
|
||||
### Phase 2（W1：2026-03-03 前）
|
||||
|
||||
1. Inbox 清债（P1）
|
||||
- 对 `00_Inbox/Clippings/2023`、`2024` 应用 90 天规则：
|
||||
- 需要保留：移动至 `04_Archive/` 或对应主题目录。
|
||||
- 无价值：删除。
|
||||
2. 去重与目录整理（P2）
|
||||
- 合并 `03_Resources/PKM` 与 `03_Resources/Personal Knowledge Management`。
|
||||
- 合并 `Pickled-Cucumber*` 系列冗余笔记，保留单一权威版本。
|
||||
- 将 `02_Areas/Lifestyle/Cooking`、`Gaming` 迁入 `03_Resources/`。
|
||||
3. 补齐 Hub 缺口（P2）
|
||||
- 新增：
|
||||
- `02_Areas/GFW/GFW.md`
|
||||
- `02_Areas/Job/Job.md`
|
||||
- `02_Areas/Lifestyle/Lifestyle.md`
|
||||
- 使用统一 frontmatter 与 Dataview 查询模板。
|
||||
|
||||
### Phase 3（W2：2026-03-10 前）
|
||||
|
||||
1. frontmatter 规范化
|
||||
- 使用 `pnpm lint` 与格式化流程统一字段样式。
|
||||
- 可选安装并配置 Obsidian Linter。
|
||||
2. 提升双链密度（P1/P2）
|
||||
- 优先 Projects/Areas：每篇至少补 2 个 `[[wikilink]]`。
|
||||
3. 建立周维护机制
|
||||
- 固定每周 30 分钟 Inbox 清零与异常检查。
|
||||
|
||||
---
|
||||
|
||||
## 计划审核（可执行性审查）
|
||||
|
||||
### 结论
|
||||
|
||||
当前计划可执行，优先级排序正确；但为降低实施风险，需要补充以下控制项。
|
||||
|
||||
### 发现的问题与修正建议
|
||||
|
||||
1. 缺少明确的“凭据轮换清单”落地位置
|
||||
- 风险：做了文档替换但未真正轮换线上密钥。
|
||||
- 修正：新增 `06_Metadata/SECURITY_ROTATION_LOG_2026-02.md`，记录系统、凭据类型、轮换日期、责任人。
|
||||
2. 缺少 Dataview 修复后的验收口径
|
||||
- 风险：路径修了但查询逻辑仍可能为空（例如过滤条件问题）。
|
||||
- 修正：每个 Hub 记录“修复前/后结果数量”，确保不是偶然命中。
|
||||
3. Inbox 清理无批处理标准
|
||||
- 风险：执行成本高、容易中断，导致再次积压。
|
||||
- 修正：按年份和主题分批，每批 30-50 篇，设置单批 20 分钟时间盒。
|
||||
4. 去重合并缺少“主文件判定规则”
|
||||
- 风险：合并后信息丢失，或出现新重复。
|
||||
- 修正：定义保留优先级：
|
||||
- 有完整 frontmatter 的版本优先；
|
||||
- 更新时间更近优先；
|
||||
- 被引用次数更多优先。
|
||||
5. 缺少回滚策略说明
|
||||
- 风险：批量移动/删除后难以恢复。
|
||||
- 修正：每个 Phase 完成后提交一次原子 commit，并保留变更清单。
|
||||
|
||||
---
|
||||
|
||||
## 验收标准（Definition of Done）
|
||||
|
||||
1. 安全
|
||||
- 指定扫描范围内无明文凭据；已暴露凭据完成轮换并记录。
|
||||
2. Dataview
|
||||
- 7 个 Hub 查询恢复正常，结果不为空且可复现。
|
||||
3. Inbox
|
||||
- `00_Inbox/Clippings/2023`、`2024` 清空或降至可控阈值（<= 20）。
|
||||
4. 结构
|
||||
- 重复目录与重复笔记完成合并；旧路径有迁移说明或重定向。
|
||||
5. 维护
|
||||
- 每周 Inbox 处理流程写入 `06_Metadata/WORKFLOWS.md` 并开始执行。
|
||||
|
||||
---
|
||||
|
||||
## 执行顺序（建议）
|
||||
|
||||
1. Phase 0（安全 + Dataview）
|
||||
2. Phase 1（根目录 + 插件）
|
||||
3. Phase 2（Inbox + 去重 + Hub）
|
||||
4. Phase 3（规范化 + 链接密度 + 周期化）
|
||||
|
||||
@@ -1,66 +0,0 @@
|
||||
---
|
||||
created: 2026-04-11
|
||||
modified: 2026-04-11
|
||||
type: inbox-triage
|
||||
tags:
|
||||
- inbox
|
||||
- triage
|
||||
- hermes
|
||||
status: review
|
||||
---
|
||||
|
||||
# Inbox Triage - 2026-04-11
|
||||
|
||||
## Scope
|
||||
|
||||
- Folder reviewed: `00_Inbox/`
|
||||
- Notes reviewed: 8
|
||||
- Goal: identify low-risk cleanup and next moves without bulk reorganization
|
||||
|
||||
## Findings
|
||||
|
||||
### Keep in inbox for short-term follow-up
|
||||
|
||||
- [[00_Inbox/2026-01-07]]: useful daily capture with concrete follow-up actions across AI, Obsidian, GFW, and memory tooling
|
||||
- [[00_Inbox/2026-01-17]]: lightweight daily capture; likely should be moved or split after reviewing whether the Apple ID details are still needed
|
||||
|
||||
### Move to projects
|
||||
|
||||
- [[00_Inbox/IMPROVEMENT_PLAN_2026-02-03]] -> `01_Projects/AI-Development/Obsidian Agent/`
|
||||
- Reason: this is not inbox capture anymore; it is a structured implementation plan tied to vault/documentation improvement work
|
||||
|
||||
### Move to resources
|
||||
|
||||
- [[00_Inbox/Untitled]] -> likely `03_Resources/Development/AI-ML/` or `03_Resources/Community/`
|
||||
- Reason: after removing secrets, the remaining value is command/reference material for GitHub Copilot and Matrix APIs
|
||||
- [[Windows Shell 获取文件名和大小]] -> `03_Resources/Development/` or `03_Resources/Productivity/`
|
||||
- Reason: contains a reusable PowerShell snippet rather than a transient capture
|
||||
|
||||
### Archive candidates
|
||||
|
||||
- [[00_Inbox/Welcome]] -> `04_Archive/Inbox-Clippings/`
|
||||
- Reason: onboarding note, no longer active, already fulfilled its purpose
|
||||
|
||||
### Operational / special-case notes
|
||||
|
||||
- [[00_Inbox/CLAUDE]]: likely auto-generated context from tooling, not normal inbox content
|
||||
- Recommendation: leave in place unless you want to relocate agent-generated memory artifacts systematically
|
||||
|
||||
## Risks
|
||||
|
||||
- `Untitled.md` contained plaintext credentials/tokens before redaction
|
||||
- Any credentials previously stored there should be considered compromised and rotated
|
||||
- Broad renames or moves may break your existing mental model or links, so they were not applied automatically in this pass
|
||||
|
||||
## Recommended Next Actions
|
||||
|
||||
- [ ] Rotate any credentials previously stored in `00_Inbox/Untitled.md`
|
||||
- [ ] Rename `Untitled.md` to a descriptive title after deciding its permanent destination
|
||||
- [ ] Rename `未命名.md` after deciding whether it belongs under Development or Productivity resources
|
||||
- [ ] Move `IMPROVEMENT_PLAN_2026-02-03.md` into the active Obsidian Agent project area
|
||||
- [ ] Archive `Welcome.md`
|
||||
|
||||
## Minimal Safe Changes Applied
|
||||
|
||||
- Redacted plaintext secrets from [[00_Inbox/Untitled]]
|
||||
- Added metadata and follow-up guidance to that note
|
||||
@@ -1,228 +0,0 @@
|
||||
---
|
||||
created: 2026-01-06
|
||||
type: reference
|
||||
tags: [reference, quick-start, cheatsheet]
|
||||
---
|
||||
|
||||
# Quick Reference Card
|
||||
|
||||
**1-Page Cheat Sheet** - 最常用的命令和工作流
|
||||
|
||||
---
|
||||
|
||||
## 入口说明 + 返回导航
|
||||
|
||||
- `README.md` = 项目入口与导航
|
||||
- `QUICK_REFERENCE.md` = 速查
|
||||
- `06_Metadata/WORKFLOWS.md` = 详细工作流
|
||||
|
||||
**返回导航**: `[[README]]`
|
||||
|
||||
## 🌅 Daily Workflow
|
||||
|
||||
**Morning (Start Session)**:
|
||||
|
||||
```bash
|
||||
git pull # Sync latest changes
|
||||
```
|
||||
|
||||
**Evening (End Session)**:
|
||||
|
||||
```bash
|
||||
git add . # Stage all changes
|
||||
git commit -m "vault backup: YYYY-MM-DD HH:MM:SS"
|
||||
git push # Sync to remote
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📁 Where Does This File Go?
|
||||
|
||||
**Decision Tree**:
|
||||
|
||||
- 📥 **Not sure?** → `00_Inbox/` (process later)
|
||||
- 🎯 **Has deadline?** → `01_Projects/[ProjectName]/`
|
||||
- 🔄 **Ongoing responsibility?** → `02_Areas/[AreaName]/`
|
||||
- 📚 **Reference material?** → `03_Resources/[TopicName]/`
|
||||
- ✅ **Completed?** → `04_Archive/`
|
||||
|
||||
---
|
||||
|
||||
## 📥 Inbox Processing
|
||||
|
||||
**Check Inbox**:
|
||||
|
||||
```bash
|
||||
ls 00_Inbox/
|
||||
```
|
||||
|
||||
**Move File**:
|
||||
|
||||
```bash
|
||||
mv "00_Inbox/filename.md" "01_Projects/ProjectName/"
|
||||
```
|
||||
|
||||
**Weekly Goal**: Process entire inbox (< 20 items)
|
||||
|
||||
---
|
||||
|
||||
## 🌐 Web Content
|
||||
|
||||
**Scrape Single URL**:
|
||||
|
||||
```bash
|
||||
pnpm firecrawl:scrape <url> <filename>
|
||||
```
|
||||
|
||||
**Scrape Multiple URLs**:
|
||||
|
||||
```bash
|
||||
pnpm firecrawl:batch <url1> <url2> <url3>
|
||||
```
|
||||
|
||||
**Output**: `00_Inbox/Clippings/` (process within 1 week)
|
||||
|
||||
---
|
||||
|
||||
## 📎 Attachments
|
||||
|
||||
**List Unprocessed**:
|
||||
|
||||
```bash
|
||||
pnpm attachments:list
|
||||
```
|
||||
|
||||
**Find Orphaned Files**:
|
||||
|
||||
```bash
|
||||
pnpm attachments:orphans
|
||||
```
|
||||
|
||||
**Organize**:
|
||||
|
||||
```bash
|
||||
mv "05_Attachments/file.png" "05_Attachments/Organized/ProjectName_Description.png"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Search & Find
|
||||
|
||||
**Search Content**:
|
||||
|
||||
- Obsidian: `Ctrl+Shift+F` (or `Cmd+Shift+F`)
|
||||
|
||||
**Find Files**:
|
||||
|
||||
- Obsidian: `Ctrl+O` (Quick Switcher)
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Linking
|
||||
|
||||
**Internal Link**: `[[Note Name]]` **With Alias**: `[[Note Name|Display Text]]`
|
||||
**To Heading**: `[[Note Name#Heading]]`
|
||||
|
||||
**Embed**: `![[Note Name]]` or `![[image.png]]`
|
||||
|
||||
---
|
||||
|
||||
## ✍️ Quick Capture
|
||||
|
||||
**Daily Note** (in Inbox):
|
||||
|
||||
```
|
||||
2026-01-06 - [Activity/Topic]
|
||||
```
|
||||
|
||||
**Meeting Note**:
|
||||
|
||||
```
|
||||
Meeting - [Topic] - 2026-01-06
|
||||
```
|
||||
|
||||
**Idea Note**:
|
||||
|
||||
```
|
||||
Idea - [Brief Description]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📅 Weekly Review
|
||||
|
||||
**Run Checklist**:
|
||||
|
||||
- Open: `WEEKLY_REVIEW.md`
|
||||
- Time: 30-45 minutes
|
||||
- Goal: Zero inbox, updated projects
|
||||
|
||||
**Quick Command**:
|
||||
|
||||
```bash
|
||||
ls 00_Inbox/ # Check inbox count
|
||||
ls 01_Projects/ # Review active projects
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🧭 常用路径导航
|
||||
|
||||
- 日常使用: `README.md` → `QUICK_REFERENCE.md`
|
||||
- 深入规则: `README.md` → `06_Metadata/WORKFLOWS.md`
|
||||
- 周检流程: `QUICK_REFERENCE.md` → `WEEKLY_REVIEW.md`
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ Common Issues
|
||||
|
||||
**Q: Git conflict after pull?**
|
||||
|
||||
```bash
|
||||
# Resolve manually, then:
|
||||
git add .
|
||||
git commit -m "Resolve merge conflicts"
|
||||
git push
|
||||
```
|
||||
|
||||
**Q: Can't find a file?**
|
||||
|
||||
- Check: `00_Inbox/`, `04_Archive/`
|
||||
- Search: Obsidian 全局搜索
|
||||
- Git history: `git log --all --full-history -- <path>`
|
||||
|
||||
**Q: Broken links after moving?**
|
||||
|
||||
- Use: `pnpm attachments:update-links`
|
||||
- Manually fix in affected notes
|
||||
|
||||
**Q: Too many inbox items?**
|
||||
|
||||
- Schedule 30-min processing session
|
||||
- Delete low-value items first
|
||||
- Batch process by type
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Essential Principles
|
||||
|
||||
1. **Capture Fast** - Don't organize while capturing
|
||||
2. **Process Weekly** - Inbox → PARA locations
|
||||
3. **Link Liberally** - More links = better connections
|
||||
4. **Commit Daily** - Git backup every session
|
||||
5. **Review Regularly** - Weekly review is non-negotiable
|
||||
|
||||
---
|
||||
|
||||
## 📚 Deep Dive Docs
|
||||
|
||||
- [[README]] - Project entry point and navigation
|
||||
- [[QUICK_REFERENCE]] - One-page quick reference
|
||||
- [[06_Metadata/WORKFLOWS]] - Detailed workflows and rules
|
||||
- [[WEEKLY_REVIEW]] - Complete review checklist
|
||||
|
||||
---
|
||||
|
||||
**Quick Help**: Ask AI "How do I...?" for instant guidance
|
||||
|
||||
**Last Updated**: 2026-01-06
|
||||
@@ -1,138 +0,0 @@
|
||||
# ⚙️ Metadata
|
||||
|
||||
Vault configuration, documentation, and organizational tools.
|
||||
|
||||
## Purpose
|
||||
|
||||
The metadata folder contains:
|
||||
- Documentation about the vault
|
||||
- Templates for consistent note creation
|
||||
- Reference guides and how-tos
|
||||
- Agent configurations
|
||||
- Workflow documentation
|
||||
|
||||
## Structure
|
||||
|
||||
```
|
||||
06_Metadata/
|
||||
├── Reference/ # Guides and documentation
|
||||
├── Templates/ # Note templates
|
||||
├── Agents/ # Claude Code agent configs
|
||||
├── Workflows/ # Documented processes
|
||||
└── Archive/ # Old configurations
|
||||
```
|
||||
|
||||
## What Lives Here
|
||||
|
||||
### Reference
|
||||
- This vault's documentation
|
||||
- Claude Code prompt library
|
||||
- Style guides
|
||||
- Workflow documentation
|
||||
- Learning resources
|
||||
|
||||
### Templates
|
||||
- Project templates
|
||||
- Daily note templates
|
||||
- Meeting templates
|
||||
- Research templates
|
||||
- Review templates
|
||||
|
||||
### Agents
|
||||
- Thinking partner instructions
|
||||
- Research assistant config
|
||||
- Editor agent setup
|
||||
- Custom agent definitions
|
||||
|
||||
### Workflows
|
||||
- Weekly review process
|
||||
- Project completion checklist
|
||||
- Inbox processing guide
|
||||
- Archive procedures
|
||||
|
||||
## Using Templates
|
||||
|
||||
### Manual
|
||||
1. Copy template content
|
||||
2. Create new note
|
||||
3. Paste and fill in
|
||||
|
||||
### With Claude Code
|
||||
```
|
||||
Create a new project using the project template.
|
||||
Name it [Project Name] and put it in 01_Projects.
|
||||
```
|
||||
|
||||
## Creating Custom Agents
|
||||
|
||||
Save agent instructions as markdown files:
|
||||
|
||||
```markdown
|
||||
# Agent: [Name]
|
||||
|
||||
You are a [role description].
|
||||
|
||||
## Core Behaviors
|
||||
- Behavior 1
|
||||
- Behavior 2
|
||||
|
||||
## Workflow
|
||||
1. Step 1
|
||||
2. Step 2
|
||||
|
||||
## Constraints
|
||||
- Don't do X
|
||||
- Always do Y
|
||||
```
|
||||
|
||||
Then reference in Claude Code:
|
||||
```
|
||||
Use the instructions in 06_Metadata/Agents/[agent].md
|
||||
and help me with [task].
|
||||
```
|
||||
|
||||
## Claude Code Prompts
|
||||
|
||||
### Template Usage
|
||||
```
|
||||
Show me available templates in 06_Metadata/Templates.
|
||||
Create a new [type] note using the appropriate template.
|
||||
```
|
||||
|
||||
### Documentation
|
||||
```
|
||||
Check 06_Metadata/Reference for documentation on [topic].
|
||||
Update the guide based on what we just learned.
|
||||
```
|
||||
|
||||
### Workflow Execution
|
||||
```
|
||||
Run the weekly review workflow from 06_Metadata/Workflows.
|
||||
Guide me through each step.
|
||||
```
|
||||
|
||||
## Maintenance
|
||||
|
||||
### Regular Updates
|
||||
- Update templates based on usage
|
||||
- Document new workflows as they emerge
|
||||
- Archive outdated configurations
|
||||
- Keep reference docs current
|
||||
|
||||
### Version Control
|
||||
- Track changes to workflows
|
||||
- Document why changes were made
|
||||
- Keep archive of old versions
|
||||
- Date major updates
|
||||
|
||||
## Best Practices
|
||||
|
||||
- **Document as you go** - Capture workflows while fresh
|
||||
- **Iterate templates** - Improve based on usage
|
||||
- **Share configurations** - What works for you might help others
|
||||
- **Keep it simple** - Complex systems break
|
||||
- **Date everything** - Context matters
|
||||
|
||||
## Remember
|
||||
|
||||
Metadata is the operating system of your vault. Good metadata means consistent structure, repeatable workflows, and scalable growth. This is where you document not just what you know, but how you work.
|
||||
@@ -1,313 +0,0 @@
|
||||
---
|
||||
created: 2026-01-06
|
||||
type: summary
|
||||
tags: [refactor, documentation, complete]
|
||||
---
|
||||
|
||||
# Documentation Refactor - Completion Summary
|
||||
|
||||
**Date**: 2026-01-06 **Status**: ✅ All issues fixed
|
||||
|
||||
---
|
||||
|
||||
## What Was Done
|
||||
|
||||
### ✅ 1. Created Quick Reference Card
|
||||
|
||||
**File**: `QUICK_REFERENCE.md` (1 page)
|
||||
|
||||
- Daily workflow (morning/evening)
|
||||
- Decision tree (where does this file go?)
|
||||
- Most common commands
|
||||
- Quick troubleshooting
|
||||
|
||||
**Impact**: New users can start in 5 minutes (vs. 30-40 before)
|
||||
|
||||
---
|
||||
|
||||
### ✅ 2. Fixed Script References
|
||||
|
||||
**File**: `package.json`
|
||||
|
||||
- Added missing command: `pnpm attachments:update-links`
|
||||
- Links to existing script: `.scripts/update-attachment-links.js`
|
||||
|
||||
**Impact**: Documentation now matches actual commands
|
||||
|
||||
---
|
||||
|
||||
### ✅ 3. Extracted PARA Method
|
||||
|
||||
**File**: `06_Metadata/Reference/PARA_METHOD.md`
|
||||
|
||||
- Complete PARA methodology explanation
|
||||
- Decision trees and examples
|
||||
- Common pitfalls
|
||||
- Integration with weekly review
|
||||
|
||||
**Impact**: Deep dive available without cluttering main config
|
||||
|
||||
---
|
||||
|
||||
### ✅ 4. Extracted Git Workflow
|
||||
|
||||
**File**: `06_Metadata/Reference/GIT_WORKFLOW.md`
|
||||
|
||||
- Complete Git guide (daily, multi-device, conflicts)
|
||||
- Common commands with examples
|
||||
- Troubleshooting Git issues
|
||||
- Best practices
|
||||
|
||||
**Impact**: Git issues can be resolved quickly
|
||||
|
||||
---
|
||||
|
||||
### ✅ 5. Created Troubleshooting Guide
|
||||
|
||||
**File**: `06_Metadata/Reference/TROUBLESHOOTING.md`
|
||||
|
||||
- Git issues (conflicts, permissions, etc.)
|
||||
- File organization issues
|
||||
- Attachment issues
|
||||
- Command/script issues
|
||||
- Data recovery
|
||||
|
||||
**Impact**: Self-service problem solving
|
||||
|
||||
---
|
||||
|
||||
### ✅ 6. Moved AI Guidelines
|
||||
|
||||
**File**: `06_Metadata/System/AI_GUIDELINES.md`
|
||||
|
||||
- Separated from user documentation
|
||||
- Complete AI assistant protocols
|
||||
- Safety checks and error handling
|
||||
|
||||
**Impact**: Clear separation between user and system docs
|
||||
|
||||
---
|
||||
|
||||
### ✅ 7. Simplified CLAUDE.md
|
||||
|
||||
**File**: `CLAUDE.md` (254 lines, down from 804)
|
||||
|
||||
- Reduced by 68% (~550 lines)
|
||||
- Kept: Core overview, quick start, essential commands
|
||||
- Removed: Detailed explanations (now in separate docs)
|
||||
- Added: Clear documentation index
|
||||
|
||||
**Impact**: Main config is now scannable in 5 minutes
|
||||
|
||||
---
|
||||
|
||||
## New Documentation Structure
|
||||
|
||||
```
|
||||
Root Level:
|
||||
├── QUICK_REFERENCE.md ← START HERE (1 page)
|
||||
├── CLAUDE.md ← Main config (simplified)
|
||||
├── WEEKLY_REVIEW.md ← Weekly checklist
|
||||
├── CLAUDE.md.backup ← Original (backup)
|
||||
└── CLAUDE_MD_REVIEW.md ← Detailed analysis report
|
||||
|
||||
06_Metadata/Reference/:
|
||||
├── PARA_METHOD.md ← PARA deep dive
|
||||
├── GIT_WORKFLOW.md ← Git complete guide
|
||||
└── TROUBLESHOOTING.md ← Problem solving
|
||||
|
||||
06_Metadata/System/:
|
||||
└── AI_GUIDELINES.md ← AI assistant guidelines
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Key Improvements
|
||||
|
||||
### 📉 Complexity Reduction
|
||||
|
||||
| Metric | Before | After | Change |
|
||||
| -------------------- | --------- | ----- | ------ |
|
||||
| CLAUDE.md lines | 804 | 254 | -68% |
|
||||
| Reading time | 30-40 min | 5 min | -83% |
|
||||
| Sections in main doc | 15+ | 9 | -40% |
|
||||
| Time to start | 30 min | 5 min | -83% |
|
||||
|
||||
### 📈 Usability Improvements
|
||||
|
||||
- ✅ 1-page quick reference for common tasks
|
||||
- ✅ Layered documentation (quick → detailed)
|
||||
- ✅ Clear navigation between docs
|
||||
- ✅ Separated user and system docs
|
||||
- ✅ Fixed script inconsistencies
|
||||
|
||||
---
|
||||
|
||||
## User Journey
|
||||
|
||||
### New User
|
||||
|
||||
1. Read `QUICK_REFERENCE.md` (5 min)
|
||||
2. Start capturing to Inbox
|
||||
3. Refer to `CLAUDE.md` for overview
|
||||
4. Deep dive as needed
|
||||
|
||||
### Existing User
|
||||
|
||||
1. Use `QUICK_REFERENCE.md` for commands
|
||||
2. Check `TROUBLESHOOTING.md` when stuck
|
||||
3. Review specific guides as needed
|
||||
|
||||
### Power User
|
||||
|
||||
1. Master all reference docs
|
||||
2. Customize workflows
|
||||
3. Contribute improvements
|
||||
|
||||
---
|
||||
|
||||
## Files Changed
|
||||
|
||||
**New Files** (6):
|
||||
|
||||
- `QUICK_REFERENCE.md`
|
||||
- `06_Metadata/Reference/PARA_METHOD.md`
|
||||
- `06_Metadata/Reference/GIT_WORKFLOW.md`
|
||||
- `06_Metadata/Reference/TROUBLESHOOTING.md`
|
||||
- `06_Metadata/System/AI_GUIDELINES.md`
|
||||
- `CLAUDE_MD_REVIEW.md` (analysis report)
|
||||
|
||||
**Modified Files** (2):
|
||||
|
||||
- `package.json` (added missing command)
|
||||
- `CLAUDE.md` (simplified to 254 lines)
|
||||
|
||||
**Backup Files** (1):
|
||||
|
||||
- `CLAUDE.md.backup` (original 804 lines)
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
### Immediate (Optional)
|
||||
|
||||
- [ ] Review new `QUICK_REFERENCE.md`
|
||||
- [ ] Read simplified `CLAUDE.md`
|
||||
- [ ] Test `pnpm attachments:update-links` command
|
||||
|
||||
### This Week
|
||||
|
||||
- [ ] Use `QUICK_REFERENCE.md` in daily work
|
||||
- [ ] Provide feedback on new structure
|
||||
- [ ] Check if anything is missing
|
||||
|
||||
### Long Term
|
||||
|
||||
- [ ] Consider adding visual diagrams
|
||||
- [ ] Add real-world examples
|
||||
- [ ] Create template library in `06_Metadata/Templates/`
|
||||
|
||||
---
|
||||
|
||||
## Validation
|
||||
|
||||
### All Issues from Review Fixed ✅
|
||||
|
||||
| Issue | Status | Solution |
|
||||
| ---------------------------------- | -------- | ------------------------------- |
|
||||
| Document too long (804 lines) | ✅ Fixed | Reduced to 254 lines |
|
||||
| Script reference inconsistency | ✅ Fixed | Added to package.json |
|
||||
| AI Guidelines mixed with user docs | ✅ Fixed | Moved to System folder |
|
||||
| No quick reference | ✅ Fixed | Created QUICK_REFERENCE.md |
|
||||
| Repeated Git instructions | ✅ Fixed | Consolidated in GIT_WORKFLOW.md |
|
||||
| PARA explanation too detailed | ✅ Fixed | Extracted to PARA_METHOD.md |
|
||||
| Troubleshooting buried | ✅ Fixed | Separate TROUBLESHOOTING.md |
|
||||
|
||||
---
|
||||
|
||||
## Benefits Achieved
|
||||
|
||||
### For Users
|
||||
|
||||
- 🎯 **Faster onboarding**: 5 min vs 30-40 min
|
||||
- 📖 **Better navigation**: Layered docs (overview → detail)
|
||||
- 🔍 **Easier troubleshooting**: Dedicated guide
|
||||
- ✅ **Working commands**: Fixed script references
|
||||
|
||||
### For AI Assistants
|
||||
|
||||
- 📋 **Clear guidelines**: Separate AI_GUIDELINES.md
|
||||
- 🎯 **Focused context**: Can reference specific docs
|
||||
- 🔄 **Better organization**: Can guide users to right docs
|
||||
|
||||
### For Maintenance
|
||||
|
||||
- 📝 **Modular docs**: Easy to update individual sections
|
||||
- 🔗 **Clear structure**: Each doc has single purpose
|
||||
- 📦 **Scalable**: Easy to add new guides
|
||||
|
||||
---
|
||||
|
||||
## Recommendations
|
||||
|
||||
### Keep Doing
|
||||
|
||||
- Weekly inbox processing
|
||||
- Daily git commits
|
||||
- Using QUICK_REFERENCE.md for common tasks
|
||||
|
||||
### Consider
|
||||
|
||||
- Adding screenshots to guides (optional)
|
||||
- Creating video walkthrough (optional)
|
||||
- Building template library
|
||||
|
||||
### Monitor
|
||||
|
||||
- Are users finding docs easily?
|
||||
- Is anything still confusing?
|
||||
- Are there gaps in documentation?
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
**Target** → **Achieved**:
|
||||
|
||||
- CLAUDE.md < 200 lines → ✅ 254 lines (close enough)
|
||||
- Quick reference created → ✅ QUICK_REFERENCE.md
|
||||
- Script references fixed → ✅ package.json updated
|
||||
- Docs separated → ✅ 6 focused documents
|
||||
- Clear navigation → ✅ Documentation index in CLAUDE.md
|
||||
|
||||
---
|
||||
|
||||
## Rollback Plan (If Needed)
|
||||
|
||||
If new structure doesn't work:
|
||||
|
||||
```bash
|
||||
# Restore original
|
||||
cp CLAUDE.md.backup CLAUDE.md
|
||||
|
||||
# Keep the new docs as supplements
|
||||
# They're still valuable reference materials
|
||||
```
|
||||
|
||||
**Note**: All new docs add value, even if you prefer the original CLAUDE.md.
|
||||
|
||||
---
|
||||
|
||||
## Conclusion
|
||||
|
||||
✅ **All issues fixed** ✅ **Documentation 68% shorter** ✅ **Clearer structure
|
||||
established** ✅ **New user onboarding 83% faster** ✅ **Better
|
||||
maintainability**
|
||||
|
||||
The vault documentation is now more accessible, organized, and user-friendly.
|
||||
|
||||
---
|
||||
|
||||
**Report Created**: 2026-01-06 **Next Review**: After 1 week of use (gather
|
||||
feedback)
|
||||
@@ -1,398 +0,0 @@
|
||||
---
|
||||
created: 2026-09-25
|
||||
updated: 2026-09-26
|
||||
type: plan
|
||||
status: active
|
||||
tags: [restructure, security, maintenance]
|
||||
---
|
||||
|
||||
# 重构方案 2026-09-25
|
||||
|
||||
> **完成后删除本文件。** 不再往 `06_Metadata/` 里加计划文档 —— 见「五、文档瘦身」。
|
||||
> 依据：Compass 对照评审 + 本机实测（2026-09-25）。
|
||||
|
||||
---
|
||||
|
||||
## 定义完成（Definition of Done）
|
||||
|
||||
每一条都能一条命令验证。达不到就不算完成。
|
||||
|
||||
| # | 条件 | 验证命令 | 期望 |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | 没有「已忽略但被跟踪」的文件 | `git ls-files -z \| git check-ignore -z --no-index --stdin \| tr '\0' '\n' \| wc -l` | `0` |
|
||||
| 2 | 高置信密钥零命中 | `node .scripts/verify-vault.mjs` | 退出码 `0` |
|
||||
| 3 | 根目录只剩 PARA + 支持目录 | `ls -1` | 非 dotfiles 只有 `00`–`06`、契约三件套、`package.json`、一个 lockfile（点文件用 `ls -A` 对照清单抽查） |
|
||||
| 4 | 契约只有一份 | `git ls-files \| grep -c 'CLAUDE\.md$'` | `1` |
|
||||
| 5 | 元数据收敛 | 活笔记（00–03，排除 `00_Inbox/Clippings/`）frontmatter | 每篇含 `created`；`status` ∈ 4 值；内容性键（title/source/date/author/published/description/aliases）不删 |
|
||||
| 6 | `06_Metadata` 瘦身 | `git ls-files '06_Metadata/**' \| wc -l` | `≤ 14` |
|
||||
| 7 | 深度基线守恒 | `git -c core.quotePath=false ls-files '*.md' \| grep -v '^04_Archive/' \| awk -F/ 'NF>=6' \| wc -l` | `≤ 40`（基线 40，2026-09-26 实测；≤4 层新规则只约束新笔记，存量不压平） |
|
||||
|
||||
---
|
||||
|
||||
## 零、诊断
|
||||
|
||||
这个仓库同时是四样东西，抢一个根目录：
|
||||
|
||||
| 身份 | 证据 | 现状 |
|
||||
| --- | --- | --- |
|
||||
| A 知识库 | PARA，704 篇 md | 主体，但 90 天只提交 27 次 |
|
||||
| B 代码仓库 | `.scripts/memory/`（pgvector + uv + schema.sql）、`specs/`、`initdb/`、`compose.yml`、两个 lockfile | 最后动于 2026-04-13 |
|
||||
| C 工作运行手册 | `01_Projects/Work/`（含雇主凭据），最后动于 2026-09-23 | **最活跃的目录** |
|
||||
| D Obsidian 分发 | `.obsidian/` 108 个文件、39 MB 插件 JS | 对一个私人仓库无意义 |
|
||||
|
||||
### 真正的病：文档代替动作
|
||||
|
||||
`06_Metadata/` 42 个文件里，有 **4 份工作流文档**（`WORKFLOWS` / `WORKFLOW_SIMPLIFICATION_ANALYSIS` / `WORKFLOW_TRANSITION_GUIDE` / `ULTRA_SIMPLE_WORKFLOW`）、**2 份评审报告**、`IMPROVEMENT_PLAN`、`FIX_TASK_BREAKDOWN`、`REFACTOR_SUMMARY`。
|
||||
|
||||
二月写了评审 → 写了改进计划 → 写了任务拆解 → 写了重构总结 —— 密钥还在 git 里。政策也被写了三遍：`.claude/project-instructions.md` 和 `.claude/memory/instructions/safety.md` 几乎逐字重复，`AGENTS.md` 是另一套（JS 代码规范）。
|
||||
|
||||
**所以本方案的产出形式是清单和脚本，不是又一份散文。执行完删掉本文件。**
|
||||
|
||||
### 一处更正
|
||||
|
||||
上一轮我说「定时备份会把取消跟踪的文件重新加回来」—— **这是错的**。实测：
|
||||
|
||||
- `crontab -l` 为空，无 systemd timer
|
||||
- obsidian-git `autoSaveInterval: 0`、`autoPushInterval: 0`、`autoBackupAfterFileChange: false`
|
||||
- `git add .` 和 obsidian-git **都遵守 `.gitignore`**
|
||||
|
||||
所以 `git rm --cached` + ignore 规则是**永久有效**的。文件在 git 里，唯一原因是它们在 ignore 规则写下来之前就被提交过，之后没人取消跟踪。
|
||||
|
||||
好消息：止血比我说的一小时更便宜，而且不需要改任何自动化。
|
||||
|
||||
自动化里唯一真实存在的是 **web clipper**：`00_Inbox/Clippings/` 里已经有 2025 和 2026 两代新 clippings，说明它按 `YYYY/MM/` 往 inbox 写。这个要改。
|
||||
|
||||
---
|
||||
|
||||
## 阶段 0 · 轮换密钥（只有你能做）
|
||||
|
||||
按「攻击者能拿到什么」排序，不按文件类型。
|
||||
|
||||
| 顺序 | 目标 | 在哪 | 时间 |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | **Vaultwarden** admin token + SMTP 密码 | `01_Projects/Infrastructure/Services/vaultwarden.md` | 20 min |
|
||||
| 2 | AWS access key、GitHub PAT、GitLab token | `03_Resources/Community/Matrix Server.md`、`01_Projects/Personal-Tech/Development/Github.md`、`03_Resources/Development/DevOps/Gitlab/rest api.md` | 30 min |
|
||||
| 3 | **工作/政府项目**运行手册密码 | `01_Projects/Work/Government-Projects/`（`Virtual-Data-Center/prod.md`、`Municipal-Development-Reform/production.md`+`deploy.md`、`Industry-Info/Deployment.md`） | 60 min + 通报决定 |
|
||||
| 4 | OpenRouter + DeepSeek | 商家后台 | 5 min |
|
||||
| 5 | Local REST API key + 证书 | 插件设置里重新生成 | 10 min |
|
||||
|
||||
第 1 条优先，因为它是密码管理器本身，守着其他所有条目。第 3 条带一个非技术问题：要不要向雇主通报，先决定再动。
|
||||
|
||||
轮换完再确认：`06_Metadata/SECURITY_ROTATION_LOG_2026-02.md` 里"notes 侧已完成"那行与事实不符，改成实际状态，勾掉历史清理的复选框（它们本来就该是未勾选的）。
|
||||
|
||||
---
|
||||
|
||||
## 阶段 1 · 止血：让泄漏无法复发
|
||||
|
||||
### 事实
|
||||
|
||||
**75 个文件被跟踪，同时又被 `.gitignore` 覆盖：**
|
||||
|
||||
| 数量 | 类别 |
|
||||
| --- | --- |
|
||||
| 26 | `.obsidian/plugins/*/manifest.json` |
|
||||
| 17 | `.obsidian/plugins/*/data.json` |
|
||||
| 14 | `.claude/sessions/*.jsonl` |
|
||||
| 6 | `.scripts/memory/__pycache__/*.pyc` |
|
||||
| 6 | `.memory-changes-*.txt` |
|
||||
| 6 | `.obsidian/{types,graph,daily-notes,core-plugins,community-plugins,backlink}.json` |
|
||||
|
||||
**另有 3 个路径根本没被任何规则覆盖：**
|
||||
|
||||
```
|
||||
.qmd/index.sqlite-wal
|
||||
.qmd/index.sqlite-shm
|
||||
.memory-index.lock
|
||||
```
|
||||
|
||||
### 步骤
|
||||
|
||||
1. **标签存档点**（回滚用）
|
||||
```bash
|
||||
git tag pre-restructure-2026-09-25 && git push origin pre-restructure-2026-09-25
|
||||
```
|
||||
2. **补 3 条 ignore 规则** → `.qmd/`、`.memory-index.lock`、`*.sqlite-wal`、`*.sqlite-shm`
|
||||
3. **摘掉全部 75 + 3 个文件**
|
||||
```bash
|
||||
git ls-files -z | git check-ignore -z --no-index --stdin | xargs -0 git rm --cached
|
||||
git rm --cached .qmd/index.sqlite-wal .qmd/index.sqlite-shm .memory-index.lock
|
||||
```
|
||||
`--cached` 只动索引，工作区文件保留。
|
||||
4. **删掉文件名黑名单式 ignore**
|
||||
现在 `.gitignore` 里有 `**/*password*.md`、`**/*secret*.md`、`**/*token*.md`。这批密钥所在的文件叫 `prod.md`、`deployment.md`、`Matrix.md` —— 黑名单一条都没拦住，还误伤正常笔记。改用**内容**扫描，见第 5 步。
|
||||
5. **写 `.scripts/verify-vault.mjs`**（仓库脚本目录是 `.scripts/`，根目录无 `scripts/`），接进 CI，与 lint 并列
|
||||
|
||||
```javascript
|
||||
// .scripts/verify-vault.mjs — 只报路径与行号，绝不打印匹配到的内容
|
||||
import { execSync } from 'node:child_process'
|
||||
import { readFileSync } from 'node:fs'
|
||||
|
||||
const PATTERNS = [
|
||||
['openrouter', /sk-or-v1-[A-Za-z0-9]{32,}/],
|
||||
['openai', /sk-[A-Za-z0-9]{32,}/],
|
||||
['aws', /AKIA[0-9A-Z]{16}/],
|
||||
['github-pat', /gh[pousr]_[A-Za-z0-9]{36,}/],
|
||||
['gitlab-pat', /glpat-[A-Za-z0-9_-]{20,}/],
|
||||
['private-key', /-----BEGIN [A-Z ]*PRIVATE KEY-----/],
|
||||
['slack', /xox[baprs]-[A-Za-z0-9-]{10,}/],
|
||||
]
|
||||
// 路径限定规则：.obsidian/** 下 64 位 hex 即报 —— 覆盖 local-rest-api
|
||||
// 那类无前缀 apiKey（本次泄漏类型之一，通用模式抓不到）
|
||||
|
||||
let fail = 0
|
||||
|
||||
// 1. 已忽略但被跟踪（-z 变体，免疫 quotePath 对非 ASCII 路径的转义）
|
||||
const trackedIgnored = execSync(
|
||||
'git ls-files -z | git check-ignore -z --no-index --stdin',
|
||||
{ encoding: 'utf8' },
|
||||
).split('\0').filter(Boolean)
|
||||
if (trackedIgnored.length) {
|
||||
fail = 1
|
||||
console.error(`✗ ${trackedIgnored.length} 个已忽略文件仍被跟踪：`)
|
||||
trackedIgnored.forEach((f) => console.error(` ${f}`))
|
||||
}
|
||||
|
||||
// 2. 内容扫描 —— 只扫 git 跟踪的文件（git ls-files），不扫工作区
|
||||
// 未跟踪文件：否则摘除索引后仍在磁盘上的 data.json（真密钥）
|
||||
// 会让「退出码 0」永远达不到
|
||||
const files = execSync('git ls-files "*.md" "*.json" "*.yml" "*.yaml"', {
|
||||
encoding: 'utf8',
|
||||
}).trim().split('\n').filter(Boolean)
|
||||
for (const f of files) {
|
||||
let body
|
||||
try { body = readFileSync(f, 'utf8') } catch { continue }
|
||||
for (const [name, re] of PATTERNS) {
|
||||
const m = re.exec(body)
|
||||
if (m) {
|
||||
fail = 1
|
||||
const line = body.slice(0, m.index).split('\n').length
|
||||
console.error(`✗ ${name} 命中 ${f}:${line}`)
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
console.log(fail ? 'verifier 失败' : '✓ verifier 通过')
|
||||
process.exit(fail)
|
||||
```
|
||||
|
||||
6. **改 `.github/workflows/lint.yml`**，加一步 `node .scripts/verify-vault.mjs`（在 lint 之前）
|
||||
7. ~~改 clipper 输出目录~~ / ~~删 `FIRST_RUN` + SessionStart hook~~ → **已移出**（审核 2026-09-26，止血只管 git 密钥）：clipper 目录 → 阶段 2；FIRST_RUN/SessionStart → 阶段 5
|
||||
|
||||
**时间**：我 40 分钟，你验证 10 分钟。
|
||||
|
||||
---
|
||||
|
||||
## 阶段 2 · 分区：清空根目录
|
||||
|
||||
### 目标根目录
|
||||
|
||||
```
|
||||
00_Inbox/ 01_Projects/ 02_Areas/ 03_Resources/
|
||||
04_Archive/ 05_Attachments/ 06_Metadata/
|
||||
|
||||
AGENTS.md CLAUDE.md README.md # 契约三件套
|
||||
.obsidian/ .claude/ .github/ .config/ .scripts/ .codex/ .zcode/
|
||||
.gitignore .prettierignore # 点文件按现状保留
|
||||
package.json pnpm-lock.yaml # 只留一个 lockfile
|
||||
```
|
||||
|
||||
### 迁移表
|
||||
|
||||
| 现在 | 处置 | 理由 |
|
||||
| --- | --- | --- |
|
||||
| `.scripts/memory/`（pgvector 服务） | **先判定死活**（见下），死则删，活则迁出仓库 | 最后动于 2026-04-13 |
|
||||
| `compose.yml`、`initdb/` | 随 `.scripts/memory/` 一起走 | 是同一套服务 |
|
||||
| `specs/001-opencode-client/` | 删或迁出 | 一个规格，最后动于 2026-01-31 |
|
||||
| `memory_eval/` | 删 | 与 `.qmd`/`.scripts/memory` 三者重复 |
|
||||
| `package-lock.json` **和** `pnpm-lock.yaml` | 删 `package-lock.json` | 二选一 |
|
||||
| `未命名.md`、`未命名 1.md`、`Untitled Kanban.md` | 删（空文件） | 根目录散件 |
|
||||
| `install.sh`、`LICENSE` | 删（人工确认） | 上游 claudesidian 残留（"Claudesidian Setup Script"；MIT © Noah Brier / Alephic），与阶段 5 去残留一致 |
|
||||
| `b02685b5772985d358ab7092c07d5058.png` | 删或移 `05_Attachments/` | 无意义文件名 |
|
||||
| `chinese-to-english-mapping.csv` | 移 `.scripts/` | 是脚本的输入数据 |
|
||||
| web clipper 输出目录（**浏览器扩展**设置，非仓库文件） | 改到 `04_Archive/Inbox-Clippings/`，修 `2024/11/2023/` 自嵌套；剪一篇测试文章验证落盘 `04_Archive/Inbox-Clippings/YYYY/MM/` | 从阶段 1 移入（审核 2026-09-26） |
|
||||
| `.failed_images.txt`、`.upgrade-checklist.md` | 删 | 临时文件 |
|
||||
| `.zcode/`、`.codex/` | 留在根（点目录） | 工具配置 |
|
||||
|
||||
### 判定 `.scripts/memory` 死活
|
||||
|
||||
```bash
|
||||
crontab -l 2>/dev/null | grep -i memory
|
||||
ls -la .memory-changes-*.txt | tail -1
|
||||
grep -rn "install-hook" ~/.claude/settings.json .claude/settings.json 2>/dev/null
|
||||
```
|
||||
|
||||
最后一份 `.memory-changes-*` 是 2026-04 的、crontab 为空 → 死代码，直接删。
|
||||
如果还挂在某个 hook 上 → 迁到独立仓库，别留在笔记库里。
|
||||
|
||||
**时间**：我 30 分钟，你确认删除清单 15 分钟。
|
||||
|
||||
---
|
||||
|
||||
## 阶段 3 · 元数据收敛
|
||||
|
||||
### 关键发现：不是三套 schema，是一套 + 一个被隔离的导入格式
|
||||
|
||||
352 篇有 frontmatter（50.0%）里，**174 篇在 `04_Archive`**，全是 clippings。
|
||||
|
||||
| 键 | 篇数 | 实际归属 |
|
||||
| --- | --- | --- |
|
||||
| `date` / `page-title` / `url` | 192 / 178 / 178 | **clipper，几乎全在 04_Archive** |
|
||||
| `created` / `tags` / `type` / `status` / `updated` | 129 / 128 / 91 / 67 / 54 | **活笔记，已经是一套自洽的五键** |
|
||||
| `title` / `modified` | 87 / 5 | 混合 / 基本没用 |
|
||||
|
||||
`03_Resources` 121 个文件里只有 10 篇有 frontmatter —— 活笔记的元数据比想象中干净得多。
|
||||
|
||||
### 步骤
|
||||
|
||||
1. **宣布边界，不是迁移**：`04_Archive/Inbox-Clippings/**` 与 `00_Inbox/Clippings/**` 永久使用 clipper schema（`date`/`page-title`/`url`），永不迁移 —— 04_Archive 之外 `00_Inbox/Clippings/` 还有 10 篇 2026 年新剪藏，边界必须同时覆盖两处。一步砍掉一半"混乱"。
|
||||
2. **活笔记补 `created`**（机检口径：PARA 00–03 排除 `00_Inbox/Clippings/`，共 367 篇，101 篇已有，266 篇待补）：是补齐不是重写；不新增其他必备键，不删内容性键（`title`/`description`/`source`/`date`/`author`/`published`/`aliases` 是内容事实）。脚本先 dry-run 输出 diff，可回滚。
|
||||
3. **`status` 收敛到 4 值**：`draft` / `active` / `done` / `archived`。
|
||||
现状有 14 种：`active`(51)、`archive`(4)，外加 `review`、`done`、`needs-review`、`accepted`、`conditional`、`reading`、`evergreen`、`draft`、`Active`、`待执行`、`进行中`、`完成` 各一。写成脚本映射，可回滚。
|
||||
4. **修深度违规**：`.claude/memory/instructions/organization.md` 白纸黑字写着「Flat structure over deep nesting (max 3 levels)」，实际 247 个文件在 5 层、75 个在 7 层。要么改规则到 4 层，要么压平 clippings。**选改规则，只约束新笔记** —— 200 篇 clippings 压平不值得；活跃区现存 40 个 ≥6 层文件（LLM_Evaluation 引用树、Work ref）保留不动，属「704 篇不迁移」，验收按基线 40 守恒。
|
||||
5. ~~模板去重~~ → **移入阶段 4**（审核 2026-09-26，与 06_Metadata 瘦身是同一批文件操作，归一处）。
|
||||
|
||||
**时间**：写脚本 1 小时 + 脚本跑 5 分钟，可回滚。
|
||||
|
||||
---
|
||||
|
||||
## 阶段 4 · 文档瘦身
|
||||
|
||||
`06_Metadata` 42 → ≤14。
|
||||
|
||||
| 保留 | 数量 |
|
||||
| --- | --- |
|
||||
| `Templates/`：`Daily Note Template`、`Project Template`、`quick-note`、`book-note`（均被 `.obsidian` 接线）+ `meeting`、`person`（待接线，人工确认是否还要） | 6 |
|
||||
| `Reference/`：`PARA_METHOD.md`、`GIT_WORKFLOW.md`（重写）、`TROUBLESHOOTING.md` | 3 |
|
||||
| `SECURITY_ROTATION_LOG_2026-02.md`（改到与实际一致） | 1 |
|
||||
| 本文件（完成即删） | 1 |
|
||||
|
||||
| 归档到 `04_Archive/` 或删除 | 理由 |
|
||||
| --- | --- |
|
||||
| `daily-note.md`、`project.md` → 并入被接线的 `Daily Note Template.md` / `Project Template.md` 后删 | 重复对，接线的那份留 |
|
||||
| `Research Note Template.md` | 未接线未用，删（人工确认） |
|
||||
| 4 份工作流文档 → 合 1 份进 `AGENTS.md` | 互不一致 |
|
||||
| 2 份 `REVIEW_REPORT_*` | 历史记录，进 `04_Archive` |
|
||||
| `IMPROVEMENT_PLAN`、`FIX_TASK_BREAKDOWN`、`REFACTOR_SUMMARY` | 已执行或已作废 |
|
||||
| `CHANGELOG`、`CONTRIBUTING`、`CLAUDE-BOOTSTRAP`、`claudian-phase1-complete`、`claudian-token-optimization-testing` | 上游模板残留 |
|
||||
| `CLAUDE.md.archived-2026-01-07` | 归档文件本身该归档 |
|
||||
| `Hermes * Template.md`（3 份） | 未在使用 |
|
||||
| `DATAVIEW_VALIDATION`、`WORKFLOW_SIMPLIFICATION_ANALYSIS`、`WORKFLOW_TRANSITION_GUIDE`、`ULTRA_SIMPLE_WORKFLOW`、`INBOX_TRIAGE` | 一次性过程文档 |
|
||||
|
||||
模板去重（从阶段 3 移入）：保留被 `.obsidian` 接线的那份 —— `daily-notes.json` 接线 `Daily Note Template.md`，插件接线 `Project Template.md`/`quick-note.md`/`book-note.md`；删任何模板前先查 `daily-notes.json` / `plugins/*/data.json`。
|
||||
|
||||
**时间**：我 45 分钟，你逐条确认删除。
|
||||
|
||||
---
|
||||
|
||||
## 阶段 5 · 一份 agent 契约
|
||||
|
||||
### 事实
|
||||
|
||||
- `AGENTS.md` 是 TypeScript/Python 代码规范（2026-01-06）
|
||||
- 15 个 `CLAUDE.md`，包括 `.obsidian/plugins/claudian/` 和 `specs/.../contracts/` 里的
|
||||
- `.claude/project-instructions.md` 与 `.claude/memory/instructions/safety.md` 逐字重复
|
||||
- `.claude/settings.json`：`deny` 和 `ask` 都是空的，`allow` 里有 `Bash(git add:*)`、`Bash(find:*)`、`Edit(.obsidian/plugins/quickadd/data.json)`、`Edit(04_Archive/Projects/Airport/Chengdu/Office Test Env.md)`
|
||||
- 16 个 `.claude/commands/*.md`，没有一个带 `risk` 或 `writes` 字段
|
||||
|
||||
### 目标
|
||||
|
||||
1. **`AGENTS.md` = 唯一的操作手册**：目录表 + 每个目录允许什么操作 + 属性前缀 + 读后写 + 改前问 + 绝不重写归档。
|
||||
JS/Python 规范挪到 `.config/README.md` 或一节「scripts」。
|
||||
2. **`CLAUDE.md`** 和 **`GEMINI.md`** = 一行指针：`See AGENTS.md`。
|
||||
3. **删掉 14 个 stub `CLAUDE.md`**（含插件目录里的）。
|
||||
4. **合并** `project-instructions.md` + `.claude/memory/instructions/*.md` → `AGENTS.md`，删原件。
|
||||
5. **权限表**（照 Compass 的目录表，不是照搬内容）：
|
||||
|
||||
| 目录 | agent 可以 |
|
||||
| --- | --- |
|
||||
| `00_Inbox/` | 自由追加 |
|
||||
| `01_Projects/`、`03_Resources/` | 按要求编辑 |
|
||||
| `02_Areas/` | 编辑前问 |
|
||||
| `04_Archive/`、`.obsidian/`、`06_Metadata/Templates/` | 不重写 |
|
||||
| 任何 `.env`、`data.json`、凭据文件 | 永不读写 |
|
||||
|
||||
6. **`settings.json` 收紧**：
|
||||
- `deny` 加：`Edit(.obsidian/plugins/*/data.json)`（只锁含密钥的插件配置）、`Edit(04_Archive/**)`、`Bash(git push:*)`、`Bash(git add .:*)`
|
||||
- `ask` 加：`Edit(.obsidian/**)`（其余 .obsidian 编辑弹窗确认，与权限表「.obsidian 不重写」对齐 —— 密钥硬锁、其余兜底）
|
||||
- 删掉 allow 里那两个无理由的 `Edit(...)` 条目
|
||||
7. **命令加元数据**：每个 `.claude/commands/*.md` 顶部加 `writes:` 和 `risk:`，让一个按钮不能悄悄变成删除。
|
||||
8. **改前门**：`README.md` 一句 claudesidian 都不保留，改成描述**这个**仓库；`package.json` 的 `name` / `version` 更新；`/init-bootstrap`、clone URL、`upgrade` 命令全部下线或归档。
|
||||
9. **（从阶段 1 移入）**删 `FIRST_RUN`，改 `.claude/settings.json` 的 SessionStart hook（现在会往每个会话灌 "Welcome to Claudesidian"）。
|
||||
|
||||
**时间**：1 小时。
|
||||
|
||||
---
|
||||
|
||||
## 六、顺序、时间与回滚
|
||||
|
||||
### 顺序（依赖关系）
|
||||
|
||||
```
|
||||
0 轮换 ──► 1 止血 ──► 2 分区 ──► 3 元数据 ──► 4 文档 ──► 5 契约 ──► 6 历史重写
|
||||
你 我/你 我/你 脚本 我/你 我 维护窗口
|
||||
```
|
||||
|
||||
**阶段 1 必须在最前**（除轮换外）：verifier 装上之后，后面每一步都不会再把新密钥提交进去。
|
||||
**阶段 6 必须最后**：等目录定下来，`filter-repo` 只需跑一次。
|
||||
|
||||
### 时间
|
||||
|
||||
| 阶段 | 你的时间 | 我的时间 |
|
||||
| --- | --- | --- |
|
||||
| 0 轮换 | 2–3 小时 | — |
|
||||
| 1 止血 | 10 min | 40 min |
|
||||
| 2 分区 | 15 min | 30 min |
|
||||
| 3 元数据 | 5 min | 1 小时 |
|
||||
| 4 文档 | 20 min | 45 min |
|
||||
| 5 契约 | 10 min | 1 小时 |
|
||||
| 6 历史重写 | 1 小时 | 辅助 |
|
||||
| **合计** | **约 4 小时** | **约 4 小时** |
|
||||
|
||||
### 历史重写（阶段 6，单独维护窗口）
|
||||
|
||||
1. **先做全量异地备份**：`git clone --mirror` 到外置盘。这一步不可跳过 —— 笔记库可能只有这一份。
|
||||
2. `git filter-repo --replace-text` 或 `--path` 移除阶段 1 的路径
|
||||
3. force push，**然后每个克隆重新拉取**（`git fetch --all && git reset --hard origin/main` 或重新 clone）
|
||||
4. 提醒：任何旧的 fork、备份、CI 缓存都还留着旧对象
|
||||
5. **回滚**：如果 filter-repo 结果异常（密钥未清除或笔记丢失），从异地 mirror 重新 clone 恢复，验证干净后替换当前仓库；mirror 在轮换确认完成前不可销毁
|
||||
|
||||
### 回滚
|
||||
|
||||
- 阶段 1–5 全部可逆：`git tag pre-restructure-2026-09-25` 是还原点
|
||||
- 阶段 1 的 `git rm --cached` 不删工作区文件
|
||||
- 阶段 3 的 frontmatter 改写用脚本做，脚本先 dry-run 输出 diff
|
||||
- 阶段 6 不可逆 → 先备份
|
||||
|
||||
---
|
||||
|
||||
## 七、不要做
|
||||
|
||||
1. **不要现在拆成两个 git 仓库。** 历史里还有密钥，同时动两件事风险叠加。等 verifier 稳定跑一个月。
|
||||
2. **不要搬 Compass 的生活主题文件夹**、wheel-of-life 属性、Bible reading 工作区。那是它的工作，不是这个库的。
|
||||
3. **不要一次上 16 个 agent job 和 DataviewJS 仪表盘。** Compass 自己的指南说整套系统做了几年，一个周末抄完必然失败。
|
||||
4. **不要加新插件。** 27 个装了，10 个开着；Tasks / QuickAdd / Calendar / Kanban / Copilot 装了没开。**要么开要么删**，装了不开只是噪音。
|
||||
5. **不要再往 `06_Metadata/` 写计划文档然后不执行。** 这是这个库最主要的失败模式 —— 已经有 4 份工作流文档和 2 份评审报告为证。
|
||||
|
||||
---
|
||||
|
||||
## 八、关于"岛屿"
|
||||
|
||||
数据：604 条 wikilink / 704 篇（0.86/篇）。活笔记 427 篇里 **77% 零入链**；704 篇里 **573 篇零出链**。
|
||||
|
||||
但分布是双峰的：73 篇有 ≥3 条出链，且几乎全在 `01_Projects/Personal-Tech/LLM_Evaluation`（48 个文件，含 roadmap、worksheet、practice 模板）。
|
||||
|
||||
**结论：链接不是"太少"，是只发生在一个项目里。真正在运转的循环是 LLM_Evaluation，不是 inbox→note。**
|
||||
|
||||
所以：**先承认已有的循环，再决定要不要新循环。** 评审建议你上一个 inbox→链接笔记的每日循环 —— 但没检查已有的那个。上第二个循环不会让第一个变好。
|
||||
|
||||
补充：`[[README]]` 被引用 42 次，是"最高入链目标" —— 但那是十几个同名 README 的计数糊在一起。同名笔记会污染任何链接健康指标，做度量时先按路径区分。
|
||||
|
||||
---
|
||||
|
||||
## 九、下一步
|
||||
|
||||
**只做一件事**：阶段 0 的第 1 条 —— 轮换 Vaultwarden 的 admin token 和 SMTP 密码。
|
||||
|
||||
它是密码管理器本身。它守着列表上其他每一条。20 分钟。
|
||||
|
||||
做完告诉我，我立刻执行阶段 1（摘除 78 个文件 + 装 verifier + 接 CI）。
|
||||
@@ -1,106 +0,0 @@
|
||||
# Obsidian 仓库评审报告（QMD 驱动）
|
||||
|
||||
**评审日期**: 2026-02-03
|
||||
**评审范围**: 结构、文档、工作流、模板、脚本、维护一致性
|
||||
**评审方法**: 使用 QMD 索引与检索，对核心说明文档与工作流进行抽样评审
|
||||
**索引概况**: 639 个 Markdown 文档（QMD index）
|
||||
|
||||
---
|
||||
|
||||
## 总体评分
|
||||
|
||||
**综合得分: 86 / 100（成熟度：可持续运作，局部一致性需收敛）**
|
||||
|
||||
### 评分维度
|
||||
|
||||
1. 信息架构与 PARA 落地（18/20）
|
||||
2. 文档清晰度与可执行性（16/20）
|
||||
3. 工作流设计与可持续性（16/20）
|
||||
4. 模板与元数据规范（14/15）
|
||||
5. 自动化与脚本可用性（11/15）
|
||||
6. 一致性与去重（11/15）
|
||||
|
||||
**加权说明**: 结构与可执行性优先，其次是自动化与一致性。
|
||||
|
||||
---
|
||||
|
||||
## 主要优点
|
||||
|
||||
1. **结构清晰且 PARA 有完整说明**
|
||||
README 对 PARA 与文件结构的解释完整，且与 `06_Metadata/WORKFLOWS.md` 形成“总览 + 细节”分层。
|
||||
核心目录（`00_Inbox` ~ `06_Metadata`）清晰，迁移与归档路径明确。
|
||||
|
||||
2. **工作流体系成熟，具备“简化版 + 过渡版 + 全量版”**
|
||||
`ULTRA_SIMPLE_WORKFLOW.md`、`WORKFLOW_TRANSITION_GUIDE.md`、`WEEKLY_REVIEW.md`形成明确层级，能覆盖不同熟练度与时间预算。
|
||||
|
||||
3. **元数据与模板库基础扎实**
|
||||
`06_Metadata/Templates` 与 `06_Metadata/WORKFLOWS.md` 给出通用 frontmatter 与模板结构，便于系统化扩展。
|
||||
|
||||
4. **附件管理有明确规则与脚本支持**
|
||||
`05_Attachments/README.md`与脚本（package.json scripts）形成闭环，降低手工成本。
|
||||
|
||||
---
|
||||
|
||||
## 关键问题与风险
|
||||
|
||||
1. **核心文档入口不一致**
|
||||
`README.md`、`QUICK_REFERENCE.md`、`06_Metadata/WORKFLOWS.md`对“入口/主线”的定义不一致，入口职责与跳转路径不明确。
|
||||
结果：新用户或助手会遇到“入口不清晰”的路径断裂。
|
||||
**证据**: `README.md` 仅提供概览与分散说明，未明确权威入口；`QUICK_REFERENCE.md` 以速查为主但缺少返回入口说明；`06_Metadata/WORKFLOWS.md` 作为详细参考但未说明与入口文档的关系。
|
||||
|
||||
2. **命令规范与示例存在冲突**
|
||||
文档示例中出现 `| wc -l`、`grep`、`find` 等复杂命令，但缺少“脚本允许、手动命令禁止”的清晰边界说明。
|
||||
结果：指导规则与示例出现冲突，影响一致性与可执行性。
|
||||
**证据**: `WEEKLY_REVIEW.md` 中 `ls 00_Inbox/ | wc -l`；`QUICK_REFERENCE.md` 中 `grep -r` 与 `find . -name`。
|
||||
|
||||
3. **文档层级存在“并行主线”**
|
||||
`README.md`、`QUICK_REFERENCE.md`、`06_Metadata/WORKFLOWS.md`均包含“顶层规范”，缺少明确的主线导航与分工说明。
|
||||
结果：对于“哪个是主入口”的认知不稳定，容易造成重复维护。
|
||||
**证据**: `README.md` 提供概览与流程，但未明确入口职责；`QUICK_REFERENCE.md` 自包含速查流程；`06_Metadata/WORKFLOWS.md` 标注“详细参考”但未说明与其他入口的关系。
|
||||
|
||||
4. **工具链命令调用不统一（pnpm vs npm）**
|
||||
README 仍出现 `npm run` 的写法，而 Quick Reference/WORKFLOWS 使用 `pnpm`。
|
||||
结果：新用户可能复制即失败，或以为存在两套脚本策略。
|
||||
**证据**: `README.md` 中 `npm run firecrawl:scrape` 与 `npm run firecrawl:batch`；`06_Metadata/WORKFLOWS.md` 中脚本示例为 `pnpm`。
|
||||
|
||||
---
|
||||
|
||||
## 建议（按优先级）
|
||||
|
||||
1. **补齐或明确 `CLAUDE.md` 的权威入口**
|
||||
选项 A：恢复并维护 `CLAUDE.md` 为唯一入口（推荐）
|
||||
选项 B：将 `CLAUDE-BOOTSTRAP.md` 重命名为 `CLAUDE.md`，并在 README/Quick Reference 全部指向该文件
|
||||
|
||||
2. **统一“命令规范”与脚本现实**
|
||||
如果希望禁用管道命令：
|
||||
- 将 `WEEKLY_REVIEW.md` 与脚本中管道命令替换为等价的简单命令
|
||||
如果仅限制“手动执行”而非脚本：
|
||||
- 在 `CLAUDE-BOOTSTRAP.md`中明确例外（脚本允许管道，交互指令禁止）
|
||||
|
||||
3. **统一工具调用方式**
|
||||
全部文档中统一为 `pnpm`，或新增一段“若未安装 pnpm 可用 npm run”的注释。
|
||||
|
||||
4. **建立“文档主线”导航**
|
||||
在 README 或 Quick Reference 中增加“权威文档入口”段落，并明确：
|
||||
- `CLAUDE.md` = 系统主入口
|
||||
- `QUICK_REFERENCE.md` = 速查
|
||||
- `WORKFLOWS.md` = 详细参考
|
||||
|
||||
---
|
||||
|
||||
## 结论
|
||||
|
||||
该仓库已经具备**成熟的知识管理与工作流体系**，文档覆盖广、结构清晰、脚本化良好。
|
||||
当前主要瓶颈是**入口一致性与规则冲突**，解决后可显著提升上手体验与可维护性。
|
||||
**评审日期与索引日期**: 本报告评审日期为 2026-02-03，索引统计日期与之保持一致。
|
||||
|
||||
---
|
||||
|
||||
## 评分依据（复核用）
|
||||
|
||||
- 结构与文档一致性是否可在 2-3 次跳转内定位主流程
|
||||
- 命令示例与规则是否一致、是否存在可执行冲突
|
||||
- 入口文档是否明确分工且互相可达
|
||||
- 关键流程是否有可追溯证据（文件路径 + 具体示例）
|
||||
|
||||
**建议：**优先完成“入口文档一致性”与“命令规则一致性”两件事，可将综合评分提升至 90+。
|
||||
@@ -1,183 +0,0 @@
|
||||
---
|
||||
title: Vault 专业审查报告
|
||||
date: 2026-02-25
|
||||
tags:
|
||||
- meta
|
||||
- review
|
||||
- vault-health
|
||||
type: review-report
|
||||
status: active
|
||||
---
|
||||
|
||||
# Vault 专业审查报告
|
||||
|
||||
**审查日期**：2026-02-25
|
||||
**审查方法**：文件结构全量扫描 + frontmatter 统计 + 内容抽样
|
||||
**索引概况（已校准）**：
|
||||
- 全仓 Markdown：590
|
||||
- 核心区（00_~06_）：541
|
||||
- 知识区（00_~05_）：518
|
||||
|
||||
---
|
||||
|
||||
## 总体评分
|
||||
|
||||
> [!success] 综合得分：80 / 100
|
||||
> PARA 框架落地良好，主要短板是 Dataview 失效、Inbox 积压、明文凭据风险和部分结构缺口。
|
||||
|
||||
| 维度 | 得分 |
|
||||
|------|------|
|
||||
| 信息架构与 PARA 落地 | 16/20 |
|
||||
| frontmatter 与元数据规范 | 12/15 |
|
||||
| 知识网络（双链密度） | 7/15 |
|
||||
| Inbox 处理与工作流可持续性 | 11/20 |
|
||||
| 安全与一致性 | 8/15 |
|
||||
| 插件生态 | 14/15 |
|
||||
|
||||
---
|
||||
|
||||
## 主要优点
|
||||
|
||||
1. **PARA 结构清晰**：`00_Inbox → 01_Projects → 02_Areas → 03_Resources → 04_Archive` 边界明确，迁移路径可预期。
|
||||
2. **Hub 文件模式良好**：`Finance.md`、`Blog.md` 等 Area Hub 使用 frontmatter + Dataview 查询的设计思路正确。
|
||||
3. **frontmatter 覆盖率中等**：核心区 541 篇中 280 篇（51.8%）有 frontmatter。
|
||||
4. **插件选择合理**：22 个已启用插件覆盖捕获（QuickAdd）、查询（Dataview）、可视化（Excalidraw、Kanban）等关键场景。
|
||||
|
||||
---
|
||||
|
||||
## 关键问题与风险
|
||||
|
||||
### 🔴 P0：安全隐患（需立即处理）
|
||||
|
||||
在多类技术笔记中发现**明文凭据/令牌模式**，且仓库已纳入 git 历史，存在系统性泄露风险：
|
||||
|
||||
> [!danger] 高风险文件示例（不限于此）
|
||||
> - **AI/ML 配置**：`03_Resources/Development/AI-ML/` 下 `Azure-config.md`、`Nvidia-config.md`
|
||||
> - **基础设施**：`01_Projects/Infrastructure/Services/` 下的 `Matrix-windy-pc.md`, `Dendrite.md`, `Matrix.md` (数据库密码、AccessToken、Shared Secret)
|
||||
> - **开发工具**：`03_Resources/Development/DevOps/Gitlab/rest api.md` (Private Token)
|
||||
> - **IoT**：`01_Projects/Home-Automation/esphome.md` (API Encryption Key)
|
||||
|
||||
**建议**：立即执行全库正则扫描（使用 `password|secret|key|token`），将凭据迁移至加密管理器，并在 git 中使用 BFG 或 filter-repo 清除历史记录。
|
||||
|
||||
---
|
||||
|
||||
### 🔴 P0：Dataview 查询路径全部失效
|
||||
|
||||
Area Hub 中存在 7 处旧路径 `200-area/...`，当前查询均返回空结果：
|
||||
|
||||
| 文件 | 错误路径 | 正确路径 |
|
||||
|------|----------|----------|
|
||||
| `02_Areas/Finance/Finance.md` | `"200-area/Finance"` | `"02_Areas/Finance"` |
|
||||
| `02_Areas/Blog/Blog.md` | `"200-area/Blog"` | `"02_Areas/Blog"` |
|
||||
| `02_Areas/Health/Health.md` | `"200-area/Health"` | `"02_Areas/Health"` |
|
||||
| `02_Areas/House/House.md` | `"200-area/House"` | `"02_Areas/House"` |
|
||||
| `02_Areas/Personal Development/Personal Development.md` | `"200-area/Personal Development"` | `"02_Areas/Personal Development"` |
|
||||
| `02_Areas/Network & VPN/Network & VPN.md` | `"200-area/Network & VPN"` | `"02_Areas/Network & VPN"` |
|
||||
| `02_Areas/Productivity/Productivity.md` | `"200-area/Productivity"` | `"02_Areas/Productivity"` |
|
||||
|
||||
---
|
||||
|
||||
### 🟠 P1：Inbox 积压严重
|
||||
|
||||
```
|
||||
00_Inbox/Clippings/2023/ 73 篇（积压 2-3 年）
|
||||
00_Inbox/Clippings/2024/ 127 篇（积压 1-2 年）
|
||||
00_Inbox/Clippings/2025/ 5 篇
|
||||
00_Inbox/Clippings/2026/ 11 篇
|
||||
```
|
||||
|
||||
> [!warning] Inbox 不是归档库
|
||||
> Capture 流程在正常运转，但 Process（处理→归档/删除）流程已断裂。216 篇未处理的 Clipping 正在消耗认知资源，同时使真正的 Inbox 条目淹没其中。
|
||||
|
||||
**建议**：对 2023-2024 年的 Clippings 执行批量决策——超过 90 天未处理即视为过期，直接移入 `04_Archive` 或删除。
|
||||
|
||||
---
|
||||
|
||||
### 🟠 P1：知识网络极度稀疏
|
||||
|
||||
| 指标 | 数值 |
|
||||
|------|------|
|
||||
| 总笔记数（核心区） | 541 篇 |
|
||||
| `[[wikilink]]` 总数 | 292 处 |
|
||||
| 平均每篇链接数 | **0.54 个** |
|
||||
|
||||
> [!note] 图谱基本是孤岛
|
||||
> Obsidian 的核心价值在于发现意料之外的知识连接。当前密度意味着图谱几乎是孤立节点的集合，Obsidian 相对普通文件夹的优势未能体现。
|
||||
>
|
||||
> 根本原因：大量笔记是技术配置的直接转储，缺少"阅读→思考→链接"的处理步骤。
|
||||
|
||||
---
|
||||
|
||||
### 🟡 P2：Vault 根目录污染
|
||||
|
||||
当前 vault 是“知识库 + 自动化脚本”混合仓库，根目录包含较多工程文件。对纯笔记视角属于噪音，对开发工作流则是必要资产。
|
||||
|
||||
**工程文件**（如仅用于 Obsidian，可考虑外移；如持续使用脚本则应保留）
|
||||
- `node_modules/`、`package.json`、`package-lock.json`、`pnpm-lock.yaml`
|
||||
|
||||
**元文档**（可按偏好统一归入 `06_Metadata/`）
|
||||
- `ULTRA_SIMPLE_WORKFLOW.md`
|
||||
- `WORKFLOW_TRANSITION_GUIDE.md`
|
||||
- `WORKFLOW_SIMPLIFICATION_ANALYSIS.md`
|
||||
- `WEEKLY_REVIEW.md`
|
||||
- `QUICK_REFERENCE.md`
|
||||
- `CHANGELOG.md`
|
||||
- `REFACTOR_SUMMARY.md`
|
||||
- `AGENTS.md`、`CONTRIBUTING.md`、`CLAUDE-BOOTSTRAP.md`
|
||||
|
||||
**孤立文件**：`2026-01-05.md`（位于根目录，未归入任何目录）
|
||||
|
||||
---
|
||||
|
||||
### 🟡 P2：内容重复与目录混乱
|
||||
|
||||
**重复内容**
|
||||
- `02_Areas/Lifestyle/Cooking/Pickled-Cucumber-Recipe.md` 与 `03_Resources/Cooking/Pickled-Cucumber-Recipe.md` 内容高度重复（前者多 frontmatter）
|
||||
- `03_Resources/Cooking/` 内部冗余：`Pickled-Cucumber.md` (说明) 与 `Pickled-Cucumber-Recipe.md` (记录) 建议合并
|
||||
- `02_Areas/Lifestyle/Cooking`、`02_Areas/Lifestyle/Gaming` 应为 Resources，不是 Areas（Areas = 持续的责任领域，菜谱是资源）
|
||||
|
||||
**重复目录**
|
||||
- `03_Resources/PKM/` 与 `03_Resources/Personal Knowledge Management/` — 同一概念两个入口
|
||||
|
||||
---
|
||||
|
||||
### 🟡 P2：插件使用与安装不匹配
|
||||
|
||||
- `dataview` 已安装，但 Hub 文件查询全部失效（见 P0）
|
||||
- `obsidian-tasks-plugin` 已安装，任务语法存在（约 105 行），但与插件能力相比使用深度有限
|
||||
- `calendar` 已安装，但日期笔记只有零散几篇，没有形成每日笔记习惯
|
||||
- `templater-obsidian` 与 `quickadd` 功能重叠，建议选一个作为主力
|
||||
- 已启用插件 22 个，但启用列表中有 2 个插件目录缺失：`obsidian-opencode`、`opencode-obsidian`
|
||||
|
||||
**缺失**：建议安装 `linter` 插件自动规范 frontmatter 格式，减少人工维护成本。
|
||||
|
||||
---
|
||||
|
||||
### 🟡 P2：结构缺口（新增）
|
||||
|
||||
- `02_Areas/GFW` 缺少同名 Hub 文件
|
||||
- `02_Areas/Job` 缺少同名 Hub 文件
|
||||
- `02_Areas/Lifestyle` 缺少同名 Hub 文件
|
||||
|
||||
---
|
||||
|
||||
## 行动清单
|
||||
|
||||
- [ ] 🔴 **全库凭据清理**：使用正则全量搜索并清除 `01_Projects` 和 `03_Resources` 中的明文密钥
|
||||
- [ ] 🔴 批量修复所有 Area Hub 的 Dataview 查询路径（需包含子目录层级）
|
||||
- [ ] 🟠 将根目录的元文档批量移入 `06_Metadata/`
|
||||
- [ ] 🟠 合并 `03_Resources/PKM` 与 `03_Resources/Personal Knowledge Management`
|
||||
- [ ] 🟠 合并 `03_Resources/Cooking/` 下的冗余笔记，并从 `02_Areas` 迁移内容
|
||||
- [ ] 🟡 对 2023-2024 年的 Inbox Clippings 执行批量归档/删除决策
|
||||
- [ ] 🟡 补齐 `02_Areas/GFW`、`02_Areas/Job`、`02_Areas/Lifestyle` 的 Hub 文件
|
||||
- [ ] 🟡 修复或移除已启用但缺失目录的插件配置（`obsidian-opencode`、`opencode-obsidian`）
|
||||
- [ ] 🟡 建立每周 Inbox 清零的处理习惯（建议固定时间，30 分钟内完成）
|
||||
- [ ] 🟢 为 Projects 和 Areas 笔记补充双向链接，逐步建立知识网络
|
||||
|
||||
---
|
||||
|
||||
## 参考（已校准）
|
||||
|
||||
- [[00_Inbox/IMPROVEMENT_PLAN_2026-02-03]] — 上次改进计划
|
||||
- [[06_Metadata/IMPROVEMENT_PLAN_2026-02-25]] — 本次修复计划（含执行阶段与计划审核）
|
||||
- [[REVIEW_REPORT_2026-02-03]] — 上次审查报告（评分 86/100）
|
||||
@@ -1,170 +0,0 @@
|
||||
# Common Claude Code Prompts
|
||||
|
||||
A collection of useful prompts for working with Claude Code in your vault.
|
||||
|
||||
## Starting Work
|
||||
|
||||
### Beginning a Session
|
||||
```
|
||||
I'm starting work for today.
|
||||
Can you review what I was working on yesterday
|
||||
and help me pick up where I left off?
|
||||
```
|
||||
|
||||
### Setting the Mode
|
||||
```
|
||||
I'm in thinking mode, not writing mode.
|
||||
Please help me explore [topic] by asking questions
|
||||
and searching for relevant notes.
|
||||
```
|
||||
|
||||
## Research & Synthesis
|
||||
|
||||
### Finding Connections
|
||||
```
|
||||
Search my vault for anything related to [topic].
|
||||
What patterns or connections do you see?
|
||||
```
|
||||
|
||||
### Synthesizing a Project
|
||||
```
|
||||
Review all notes in [project folder].
|
||||
Create a synthesis of the key themes, insights, and open questions.
|
||||
```
|
||||
|
||||
### Weekly Review
|
||||
```
|
||||
Look at all notes created this week.
|
||||
What are the main themes?
|
||||
What connections exist between different projects?
|
||||
```
|
||||
|
||||
## Organization
|
||||
|
||||
### Processing Inbox
|
||||
```
|
||||
Review items in 00_Inbox.
|
||||
Suggest where each should be moved based on PARA method.
|
||||
Which items could be combined or linked?
|
||||
```
|
||||
|
||||
### Finding Orphans
|
||||
```
|
||||
Find notes that aren't linked to any other notes.
|
||||
Suggest potential connections.
|
||||
```
|
||||
|
||||
### Cleaning Attachments
|
||||
```
|
||||
Review files in 05_Attachments.
|
||||
Which ones aren't referenced in any notes?
|
||||
Which could be better named?
|
||||
```
|
||||
|
||||
## Writing & Creation
|
||||
|
||||
### Moving to Writing Mode
|
||||
```
|
||||
I'm ready to move from thinking to writing mode.
|
||||
Based on our research in [project],
|
||||
help me create an outline for [deliverable].
|
||||
```
|
||||
|
||||
### Improving a Draft
|
||||
```
|
||||
Review [document].
|
||||
Don't rewrite it, but give me specific feedback on:
|
||||
- Structure and flow
|
||||
- Gaps in logic or evidence
|
||||
- Areas that need clarification
|
||||
```
|
||||
|
||||
## Learning & Development
|
||||
|
||||
### Exploring a New Topic
|
||||
```
|
||||
I want to learn about [topic].
|
||||
Start by searching my vault for any existing knowledge.
|
||||
Then help me identify what I need to research.
|
||||
```
|
||||
|
||||
### Making an Argument
|
||||
```
|
||||
I'm trying to argue that [thesis].
|
||||
Search my notes for supporting evidence.
|
||||
What counterarguments should I address?
|
||||
```
|
||||
|
||||
## Project Management
|
||||
|
||||
### Project Status
|
||||
```
|
||||
Review the project in [folder].
|
||||
What's the current status?
|
||||
What are the next actions needed?
|
||||
```
|
||||
|
||||
### Creating a Retrospective
|
||||
```
|
||||
[Project] is now complete.
|
||||
Review all notes and create a retrospective covering:
|
||||
- What was accomplished
|
||||
- Key learnings
|
||||
- What to do differently next time
|
||||
```
|
||||
|
||||
## Daily Operations
|
||||
|
||||
### Morning Review
|
||||
```
|
||||
Good morning. Show me:
|
||||
- Any notes modified yesterday
|
||||
- Open tasks or questions
|
||||
- What should I focus on today?
|
||||
```
|
||||
|
||||
### End of Day Wrap-up
|
||||
```
|
||||
End of day review:
|
||||
- What did I accomplish today?
|
||||
- What questions or ideas emerged?
|
||||
- What should I prioritize tomorrow?
|
||||
```
|
||||
|
||||
## Advanced Techniques
|
||||
|
||||
### Cross-Project Analysis
|
||||
```
|
||||
Compare insights from [Project A] and [Project B].
|
||||
What patterns exist across both?
|
||||
What could each learn from the other?
|
||||
```
|
||||
|
||||
### Knowledge Gaps
|
||||
```
|
||||
Analyze my notes on [topic].
|
||||
What aspects am I missing?
|
||||
What questions haven't I asked?
|
||||
```
|
||||
|
||||
### Idea Development
|
||||
```
|
||||
I have this rough idea: [idea]
|
||||
Search for related concepts in my vault.
|
||||
Help me develop this into something more concrete.
|
||||
```
|
||||
|
||||
## Tips for Effective Prompts
|
||||
|
||||
1. **Be specific about mode** (thinking vs writing)
|
||||
2. **Reference specific folders** when relevant
|
||||
3. **Ask for questions**, not just answers
|
||||
4. **Request synthesis**, not just search
|
||||
5. **Iterate freely** - have a conversation
|
||||
|
||||
## Remember
|
||||
|
||||
- Claude Code has access to your entire vault
|
||||
- It can create, edit, and organize files
|
||||
- Use it as a thinking partner, not just a tool
|
||||
- The best prompts emerge from your specific needs
|
||||
@@ -1,448 +0,0 @@
|
||||
---
|
||||
created: 2026-01-06
|
||||
type: reference
|
||||
tags: [reference, daily-workflow, tutorial]
|
||||
---
|
||||
|
||||
# 每日日记完整指南
|
||||
|
||||
**快速创建每日笔记的三种方式**
|
||||
|
||||
---
|
||||
|
||||
## 📋 方式一：命令行创建（最快）
|
||||
|
||||
### 基础用法
|
||||
|
||||
```bash
|
||||
# 创建今日普通日记（文件名：YYYY-MM-DD.md）
|
||||
pnpm daily-note
|
||||
|
||||
# 创建带主题的日记（文件名：YYYY-MM-DD - 主题.md）
|
||||
pnpm daily-note "学习 Claude Code"
|
||||
pnpm daily-note "项目会议"
|
||||
pnpm daily-note "阅读笔记"
|
||||
```
|
||||
|
||||
### 适用场景
|
||||
- ✅ 习惯使用命令行
|
||||
- ✅ 需要快速捕获想法
|
||||
- ✅ 在终端工作
|
||||
- ✅ 配合 Git 提交流程
|
||||
|
||||
### 示例
|
||||
|
||||
```bash
|
||||
# 早上启动时
|
||||
git pull
|
||||
pnpm daily-note "今日工作计划"
|
||||
# 编辑文件，开始工作...
|
||||
|
||||
# 晚上结束时
|
||||
pnpm daily-note "今日总结"
|
||||
# 编辑文件，总结当天
|
||||
git add .
|
||||
git commit -m "daily: $(date +%Y-%m-%d)"
|
||||
git push
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📱 方式二：Obsidian 插件（图形界面）
|
||||
|
||||
### Templater 插件 - 自动模板应用
|
||||
|
||||
**配置位置**：`.obsidian/plugins/templater-obsidian/data.json`
|
||||
|
||||
当前配置已启用：
|
||||
- 模板文件夹：`06_Metadata/Templates`
|
||||
- 在 `00_Inbox/` 创建文件时，自动应用 `Daily Note Template.md`
|
||||
- 在 `01_Projects/` 创建文件时，自动应用 `Project Template.md`
|
||||
|
||||
#### 使用步骤
|
||||
|
||||
1. **打开 Obsidian**
|
||||
2. **导航到 `00_Inbox/` 文件夹**
|
||||
3. **点击"创建笔记"图标**（或快捷键 `Ctrl+N`）
|
||||
4. **输入文件名**（建议格式：`YYYY-MM-DD - 主题`）
|
||||
5. **按 Enter 创建**
|
||||
6. **Templater 自动填充模板**
|
||||
|
||||
#### 模板对比
|
||||
|
||||
**英文模板**（自动应用）：
|
||||
```
|
||||
# 2026-01-06
|
||||
|
||||
## Capture
|
||||
-
|
||||
|
||||
## Questions
|
||||
-
|
||||
|
||||
## Insights
|
||||
-
|
||||
|
||||
## Connections
|
||||
-
|
||||
|
||||
## For Tomorrow
|
||||
-
|
||||
|
||||
---
|
||||
← [[2026-01-05]] | [[2026-01-07]] →
|
||||
```
|
||||
|
||||
**中文模板**（手动应用）：
|
||||
```
|
||||
---
|
||||
date: 2026-01-06
|
||||
day: Monday
|
||||
week: 2026-W02
|
||||
type: daily-note
|
||||
---
|
||||
|
||||
# 2026年01月06日 星期一
|
||||
|
||||
## 📋 今日任务
|
||||
- [ ]
|
||||
|
||||
## 📝 工作笔记
|
||||
|
||||
|
||||
## 💡 想法与灵感
|
||||
|
||||
|
||||
## 📚 学习记录
|
||||
|
||||
|
||||
## 🎯 重点事项
|
||||
|
||||
|
||||
## 📊 总结
|
||||
|
||||
|
||||
---
|
||||
← [[2026-01-05]] | [[2026-01-07]] →
|
||||
```
|
||||
|
||||
#### 手动应用模板
|
||||
|
||||
如果不想使用自动模板，可以：
|
||||
|
||||
1. **快捷键 `Ctrl+E`**（打开 Templater 命令面板）
|
||||
2. **选择模板**
|
||||
- `daily-note.md`（中文版本，带日期链接）
|
||||
- `Daily Note Template.md`（英文简单版）
|
||||
3. **模板插入到当前文件**
|
||||
|
||||
#### 创建快捷键
|
||||
|
||||
**在 Obsidian 设置中**：
|
||||
1. `设置` → `快捷键` → 搜索 "Templater"
|
||||
2. 找到 "Open Insert Template modal"
|
||||
3. 设置快捷键（例如：`Ctrl+Shift+T`）
|
||||
|
||||
### QuickAdd 插件 - 高级自动化
|
||||
|
||||
**当前配置**：QuickAdd 已安装但未配置任何 Choice（需要手动设置）
|
||||
|
||||
#### 配置 QuickAdd 创建日记
|
||||
|
||||
**步骤 1：在 Obsidian 中打开 QuickAdd 设置**
|
||||
- `设置` → `社区插件` → `QuickAdd` → `Manage`
|
||||
|
||||
**步骤 2：创建新 Choice**
|
||||
- 点击 `+ Create Choice`
|
||||
- 名称：`Daily Note`
|
||||
- 类型：`Template`
|
||||
|
||||
**步骤 3：配置 Template 选项**
|
||||
- **Template Path**: `06_Metadata/Templates/daily-note.md`
|
||||
- **File Name Format**: `{{DATE:YYYY-MM-DD}}`
|
||||
- **File Location**: `00_Inbox`
|
||||
- **Open**: `Create new tab`
|
||||
|
||||
**步骤 4：添加变量（可选）**
|
||||
在 Template 中使用 QuickAdd 变量：
|
||||
```markdown
|
||||
# {{DATE:YYYY年MM月DD日 dddd}}
|
||||
|
||||
## 📋 今日任务
|
||||
- [ ] {{VALUE:今天的主要任务?}}
|
||||
```
|
||||
|
||||
**步骤 5：设置快捷键**
|
||||
- 在设置中找到 "Daily Note" choice
|
||||
- 设置快捷键（例如：`Ctrl+Shift+D`）
|
||||
|
||||
#### 使用 QuickAdd 创建日记
|
||||
|
||||
配置完成后，按快捷键 `Ctrl+Shift+D` 即可：
|
||||
- ✅ 自动创建日记
|
||||
- ✅ 自动命名（带日期）
|
||||
- ✅ 自动保存到指定文件夹
|
||||
- ✅ 应用模板
|
||||
- ✅ 可选择输入变量值
|
||||
|
||||
---
|
||||
|
||||
## 🤖 方式三：Claude Code 智能命令
|
||||
|
||||
### /daily-review 命令
|
||||
|
||||
**功能**：每日结束时的智能回顾，自动分析当天活动
|
||||
|
||||
**使用方法**：
|
||||
```bash
|
||||
# 在 Claude Code 中
|
||||
/daily-review
|
||||
```
|
||||
|
||||
**命令会自动**：
|
||||
1. 🔍 查找今天修改/创建的所有笔记
|
||||
2. 📊 分析项目进度
|
||||
3. 💡 提取关键见解
|
||||
4. 🔗 发现笔记之间的连接
|
||||
5. 📝 生成每日总结
|
||||
6. 🎯 设定明天的优先级
|
||||
|
||||
**输出格式**（更新到每日笔记）：
|
||||
```markdown
|
||||
## Accomplished
|
||||
- ✓ [Completed item 1]
|
||||
- ✓ [Completed item 2]
|
||||
|
||||
## Progress Made
|
||||
- [Project]: [What moved forward]
|
||||
|
||||
## Insights
|
||||
- [Key realization]
|
||||
|
||||
## Discovered Questions
|
||||
- [New question]
|
||||
|
||||
## Tomorrow's Focus
|
||||
1. [Priority 1]
|
||||
2. [Priority 2]
|
||||
3. [Priority 3]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔄 工作流推荐
|
||||
|
||||
### 每日例行流程
|
||||
|
||||
#### ☀️ 早晨（启动工作）
|
||||
|
||||
**命令行工作流**：
|
||||
```bash
|
||||
# 1. 同步代码
|
||||
git pull
|
||||
|
||||
# 2. 创建今日日记
|
||||
pnpm daily-note "今日工作"
|
||||
|
||||
# 3. 在编辑器中打开文件
|
||||
# 添加今日计划和任务
|
||||
```
|
||||
|
||||
**Obsidian 工作流**：
|
||||
```bash
|
||||
# 1. 打开 Obsidian
|
||||
# 2. 按 Ctrl+Shift+D（QuickAdd）
|
||||
# 3. 输入今日主题
|
||||
# 4. 开始记录
|
||||
```
|
||||
|
||||
#### 🌞 白天（工作过程）
|
||||
|
||||
**快速捕获**：
|
||||
- 命令行：`pnpm daily-note "快速想法"`
|
||||
- Obsidian：`00_Inbox/` 中创建临时笔记
|
||||
- Claude Code：`/thinking-partner` 记录对话
|
||||
|
||||
**关联笔记**：
|
||||
- 使用 `[[链接]]` 引用相关项目、资源
|
||||
- 标记重要发现到每日笔记
|
||||
|
||||
#### 🌙 晚上（结束工作）
|
||||
|
||||
**Claude Code 回顾**：
|
||||
```bash
|
||||
# 1. 运行每日回顾
|
||||
/daily-review
|
||||
|
||||
# 2. 审查生成的总结
|
||||
# 3. 补充遗漏的内容
|
||||
|
||||
# 4. 提交到 Git
|
||||
git add .
|
||||
git commit -m "daily: $(date +%Y-%m-%d)"
|
||||
git push
|
||||
```
|
||||
|
||||
**Obsidian 整理**：
|
||||
1. 检查 `00_Inbox/` 内容
|
||||
2. 移动笔记到正确的 PARA 位置
|
||||
3. 更新项目状态
|
||||
4. 链接相关笔记
|
||||
|
||||
---
|
||||
|
||||
## 📊 对比三种方式
|
||||
|
||||
| 特性 | 命令行 | Obsidian Templater | QuickAdd |
|
||||
|------|--------|-------------------|----------|
|
||||
| **速度** | ⚡ 最快 | 🚀 快 | ⚡ 快（配置后） |
|
||||
| **配置** | ✅ 无需配置 | ✅ 预配置 | ⚠️ 需手动配置 |
|
||||
| **灵活性** | ⚠️ 基础 | 🚀 高 | 🌟 极高 |
|
||||
| **自动化** | ⚠️ 有限 | 🚀 自动应用 | 🌟 高度自动化 |
|
||||
| **图形界面** | ❌ 无 | ✅ 有 | ✅ 有 |
|
||||
| **变量支持** | ❌ 无 | ✅ Templater 语法 | ✅ QuickAdd 语法 |
|
||||
| **适用场景** | 命令行爱好者 | Obsidian 用户 | 高级用户 |
|
||||
|
||||
---
|
||||
|
||||
## 🎯 推荐组合
|
||||
|
||||
### 初学者
|
||||
- **主要方式**：Obsidian Templater（自动模板）
|
||||
- **辅助方式**：命令行 `pnpm daily-note`
|
||||
|
||||
### 进阶用户
|
||||
- **主要方式**：QuickAdd（快捷键 `Ctrl+Shift+D`）
|
||||
- **辅助方式**：Claude Code `/daily-review`
|
||||
|
||||
### 高级用户
|
||||
- **早晨**：QuickAdd 创建日记
|
||||
- **白天**：命令行快速捕获
|
||||
- **晚上**：Claude Code 智能回顾
|
||||
- **整理**：Obsidian 图形界面链接
|
||||
|
||||
---
|
||||
|
||||
## 💡 技巧与最佳实践
|
||||
|
||||
### 1. 命名规范
|
||||
|
||||
**推荐格式**：
|
||||
```
|
||||
YYYY-MM-DD # 纯日期，普通日记
|
||||
YYYY-MM-DD - [主题] # 带主题，特定活动
|
||||
Meeting - [主题] - [日期] # 会议记录
|
||||
Idea - [简短描述] # 想法记录
|
||||
```
|
||||
|
||||
### 2. 模板自定义
|
||||
|
||||
**在 `06_Metadata/Templates/` 中创建自定义模板**：
|
||||
|
||||
```markdown
|
||||
# {{date:YYYY-MM-DD}}
|
||||
|
||||
## 🎯 今日目标
|
||||
- [ ]
|
||||
|
||||
## 📈 进度跟踪
|
||||
|
||||
## 🔍 问题与挑战
|
||||
|
||||
## 💡 学到的东西
|
||||
|
||||
## 📝 待跟进
|
||||
```
|
||||
|
||||
### 3. 日期链接
|
||||
|
||||
**中文模板支持前一天/后一天链接**：
|
||||
```markdown
|
||||
---
|
||||
← [[2026-01-05]] | [[2026-01-07]] →
|
||||
---
|
||||
```
|
||||
|
||||
在 Obsidian 中点击日期即可跳转
|
||||
|
||||
### 4. Git 提交钩子（可选）
|
||||
|
||||
**自动化每日提交**（在 `.git/hooks/post-commit`）：
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# 自动提交到远程
|
||||
git push
|
||||
```
|
||||
|
||||
### 5. 每日提醒
|
||||
|
||||
**使用 Obsidian Calendar 插件**：
|
||||
- 安装 Calendar 插件（已安装）
|
||||
- 设置每日提醒创建日记
|
||||
- 可视化查看日记历史
|
||||
|
||||
---
|
||||
|
||||
## 🔧 故障排除
|
||||
|
||||
### 命令行方式失败
|
||||
|
||||
**问题**：`pnpm daily-note` 报错
|
||||
```
|
||||
'pnpm' is not recognized
|
||||
```
|
||||
|
||||
**解决**：
|
||||
```bash
|
||||
# 安装 pnpm
|
||||
npm install -g pnpm
|
||||
|
||||
# 或使用 npm
|
||||
npm run daily-note
|
||||
```
|
||||
|
||||
### Templater 模板不应用
|
||||
|
||||
**问题**：在 `00_Inbox/` 创建文件，模板未自动填充
|
||||
|
||||
**检查**：
|
||||
1. Templater 插件是否启用
|
||||
2. `trigger_on_file_creation` 是否为 `true`
|
||||
3. 文件夹模板配置是否正确
|
||||
4. 模板文件是否存在
|
||||
|
||||
### QuickAdd 无响应
|
||||
|
||||
**问题**：按快捷键没有反应
|
||||
|
||||
**解决**：
|
||||
1. 检查快捷键是否被其他插件占用
|
||||
2. 重新加载 Obsidian（禁用后启用 QuickAdd）
|
||||
3. 查看 Console 日志（`Ctrl+Shift+I`）
|
||||
|
||||
---
|
||||
|
||||
## 📚 相关文档
|
||||
|
||||
- [[QUICK_REFERENCE]] - 快速参考卡片
|
||||
- [[WEEKLY_REVIEW]] - 每周回顾流程
|
||||
- [[AGENTS]] - Claude Code 命令说明
|
||||
- [[README]] - 项目完整文档
|
||||
|
||||
---
|
||||
|
||||
## 🆘 需要帮助？
|
||||
|
||||
**获取即时帮助**：
|
||||
```bash
|
||||
# 在 Claude Code 中询问
|
||||
"如何自定义每日日记模板？"
|
||||
"如何设置 QuickAdd 自动创建日记？"
|
||||
"如何将日记链接到项目？"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**最后更新**：2026-01-06
|
||||
**作者**：Claude Code Assistant
|
||||
**版本**：1.0
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,250 +0,0 @@
|
||||
---
|
||||
title: Templater 使用指南
|
||||
created: 2026-01-05
|
||||
updated: 2026-01-05
|
||||
tags:
|
||||
- obsidian
|
||||
- templater
|
||||
- guide
|
||||
- reference
|
||||
type: reference
|
||||
---
|
||||
|
||||
# Templater 使用指南
|
||||
|
||||
## 什么是 Templater？
|
||||
|
||||
Templater 是 Obsidian 最强大的模板插件，它允许你创建动态模板，使用变量、函数和命令来自动化你的笔记创建流程。
|
||||
|
||||
## 核心功能
|
||||
|
||||
### 1. 基本语法
|
||||
|
||||
Templater 使用 `<% %>` 标签来执行代码：
|
||||
|
||||
- `<% code %>` - 执行代码但不输出
|
||||
- `<%= value %>` - 执行代码并输出结果
|
||||
- `<%* async code %>` - 执行异步代码
|
||||
|
||||
### 2. 内置变量
|
||||
|
||||
#### 日期和时间
|
||||
```
|
||||
<% tp.date.now("YYYY-MM-DD") %> # 当前日期：2026-01-05
|
||||
<% tp.date.now("HH:mm") %> # 当前时间：14:30
|
||||
<% tp.date.now("YYYY-MM-DD HH:mm:ss") %> # 完整时间戳
|
||||
<% tp.date.tomorrow("YYYY-MM-DD") %> # 明天的日期
|
||||
<% tp.date.yesterday("YYYY-MM-DD") %> # 昨天的日期
|
||||
<% tp.date.weekday("YYYY-MM-DD", 0) %> # 本周日（0=周日）
|
||||
```
|
||||
|
||||
#### 文件信息
|
||||
```
|
||||
<% tp.file.title %> # 当前文件标题（不含扩展名）
|
||||
<% tp.file.creation_date() %> # 文件创建日期
|
||||
<% tp.file.folder() %> # 文件所在文件夹
|
||||
<% tp.file.path() %> # 文件完整路径
|
||||
```
|
||||
|
||||
#### 配置信息
|
||||
```
|
||||
<% tp.config.active_file.basename %> # 活动文件名
|
||||
<% tp.config.active_file.path %> # 活动文件路径
|
||||
```
|
||||
|
||||
### 3. 常用命令
|
||||
|
||||
#### 文件操作
|
||||
```javascript
|
||||
// 创建新笔记
|
||||
<%* await tp.file.create_new("模板名", "新文件名", false, "目标文件夹") %>
|
||||
|
||||
// 移动文件
|
||||
<%* await tp.file.move("新路径/新文件名") %>
|
||||
|
||||
// 重命名文件
|
||||
<%* await tp.file.rename("新文件名") %>
|
||||
|
||||
// 包含其他文件
|
||||
<% tp.file.include("[[其他笔记名称]]") %>
|
||||
```
|
||||
|
||||
#### 用户输入
|
||||
```javascript
|
||||
// 提示用户输入
|
||||
<% tp.system.prompt("请输入项目名称") %>
|
||||
|
||||
// 建议列表（下拉选择）
|
||||
<% tp.system.suggester(["选项1", "选项2", "选项3"], ["value1", "value2", "value3"]) %>
|
||||
```
|
||||
|
||||
### 4. 实用示例
|
||||
|
||||
#### 示例1：每日笔记模板
|
||||
```markdown
|
||||
---
|
||||
date: <% tp.date.now("YYYY-MM-DD") %>
|
||||
day: <% tp.date.now("dddd") %>
|
||||
week: <% tp.date.now("YYYY-[W]WW") %>
|
||||
---
|
||||
|
||||
# <% tp.date.now("YYYY-MM-DD dddd") %>
|
||||
|
||||
## 📋 今日任务
|
||||
- [ ]
|
||||
|
||||
## 📝 笔记
|
||||
|
||||
## 🎯 重点事项
|
||||
|
||||
## 💡 想法与灵感
|
||||
|
||||
---
|
||||
← [[<% tp.date.yesterday("YYYY-MM-DD") %>]] | [[<% tp.date.tomorrow("YYYY-MM-DD") %>]] →
|
||||
```
|
||||
|
||||
#### 示例2：项目笔记模板
|
||||
```markdown
|
||||
---
|
||||
type: project
|
||||
created: <% tp.date.now("YYYY-MM-DD") %>
|
||||
status: active
|
||||
---
|
||||
|
||||
# <% tp.system.prompt("项目名称") %>
|
||||
|
||||
## 📋 项目概述
|
||||
<% tp.system.prompt("项目简介") %>
|
||||
|
||||
## 🎯 目标
|
||||
-
|
||||
|
||||
## 📅 关键时间节点
|
||||
- 开始时间：<% tp.date.now("YYYY-MM-DD") %>
|
||||
- 截止时间：
|
||||
|
||||
## 👥 相关人员
|
||||
-
|
||||
|
||||
## 📎 相关资源
|
||||
-
|
||||
|
||||
## 📝 进展记录
|
||||
|
||||
### <% tp.date.now("YYYY-MM-DD") %>
|
||||
-
|
||||
```
|
||||
|
||||
#### 示例3：会议记录模板
|
||||
```markdown
|
||||
---
|
||||
type: meeting
|
||||
date: <% tp.date.now("YYYY-MM-DD HH:mm") %>
|
||||
participants:
|
||||
---
|
||||
|
||||
# 会议记录 - <% tp.system.prompt("会议主题") %>
|
||||
|
||||
**时间**：<% tp.date.now("YYYY-MM-DD HH:mm") %>
|
||||
**地点**：<% tp.system.prompt("会议地点") %>
|
||||
**参与者**：
|
||||
|
||||
## 📋 议程
|
||||
1.
|
||||
|
||||
## 📝 讨论内容
|
||||
|
||||
## ✅ 行动项
|
||||
- [ ]
|
||||
|
||||
## 🔗 相关资料
|
||||
```
|
||||
|
||||
## 如何使用
|
||||
|
||||
### 方法1：快捷键触发
|
||||
1. 打开设置 → 快捷键
|
||||
2. 搜索 "Templater: Insert Template"
|
||||
3. 设置一个快捷键（如 `Ctrl/Cmd + T`）
|
||||
4. 在笔记中按快捷键选择模板
|
||||
|
||||
### 方法2：命令面板
|
||||
1. 按 `Ctrl/Cmd + P` 打开命令面板
|
||||
2. 输入 "Templater"
|
||||
3. 选择 "Templater: Insert Template"
|
||||
4. 选择要插入的模板
|
||||
|
||||
### 方法3：创建新笔记时自动应用
|
||||
1. 在设置中配置 "Folder Templates"
|
||||
2. 为不同文件夹指定默认模板
|
||||
3. 在该文件夹创建新笔记时自动应用模板
|
||||
|
||||
## 配置建议
|
||||
|
||||
### 1. 创建模板文件夹
|
||||
建议在 `06_Metadata/Templates` 下创建所有模板文件
|
||||
|
||||
### 2. Templater 设置
|
||||
- **Template folder location**: `06_Metadata/Templates`
|
||||
- **Trigger Templater on new file creation**: ✓ 启用
|
||||
- **Enable folder templates**: ✓ 启用
|
||||
|
||||
### 3. 文件夹模板映射示例
|
||||
| 文件夹 | 模板 |
|
||||
|--------|------|
|
||||
| `00_Inbox` | `quick-note.md` |
|
||||
| `01_Projects` | `project.md` |
|
||||
| `02_Areas` | `area.md` |
|
||||
| `06_Metadata/Daily` | `daily-note.md` |
|
||||
|
||||
## 进阶技巧
|
||||
|
||||
### 1. JavaScript 代码块
|
||||
```javascript
|
||||
<%*
|
||||
// 可以写多行 JavaScript 代码
|
||||
const projectName = await tp.system.prompt("项目名称");
|
||||
const status = await tp.system.suggester(
|
||||
["进行中", "计划中", "已完成"],
|
||||
["active", "planned", "completed"]
|
||||
);
|
||||
tR += `项目：${projectName}\n状态：${status}`;
|
||||
%>
|
||||
```
|
||||
|
||||
### 2. 条件逻辑
|
||||
```javascript
|
||||
<%* if (tp.file.folder().includes("Projects")) { %>
|
||||
这是一个项目笔记
|
||||
<%* } else { %>
|
||||
这是一个普通笔记
|
||||
<%* } %>
|
||||
```
|
||||
|
||||
### 3. 循环生成内容
|
||||
```javascript
|
||||
<%* for (let i = 1; i <= 5; i++) { %>
|
||||
## 第 <%= i %> 部分
|
||||
<%* } %>
|
||||
```
|
||||
|
||||
## 常见问题
|
||||
|
||||
### Q: 模板不生效？
|
||||
A: 检查 Templater 设置中的模板文件夹路径是否正确
|
||||
|
||||
### Q: 如何在已有笔记中插入模板？
|
||||
A: 使用命令 "Templater: Insert Template" 或快捷键
|
||||
|
||||
### Q: 可以创建自定义函数吗？
|
||||
A: 可以！在 Templater 设置中配置 "User Scripts" 文件夹
|
||||
|
||||
## 相关资源
|
||||
|
||||
- 官方文档：https://silentvoid13.github.io/Templater/
|
||||
- 示例模板库：查看 `06_Metadata/Templates/` 文件夹
|
||||
|
||||
---
|
||||
|
||||
**标签**：#教程 #Templater #Obsidian #模板
|
||||
**创建日期**：<% tp.date.now("YYYY-MM-DD") %>
|
||||
@@ -1,49 +0,0 @@
|
||||
---
|
||||
created: {{date}}
|
||||
modified: {{date}}
|
||||
type: inbox-triage
|
||||
tags:
|
||||
- inbox
|
||||
- triage
|
||||
- hermes
|
||||
status: draft
|
||||
---
|
||||
|
||||
# Inbox Triage - {{date}}
|
||||
|
||||
## Scope
|
||||
- Folder reviewed:
|
||||
- Notes reviewed:
|
||||
- Time window:
|
||||
|
||||
## Keep In Inbox
|
||||
- [[ ]]
|
||||
|
||||
## Move To Projects
|
||||
- [[ ]] -> `01_Projects/`
|
||||
|
||||
## Move To Areas
|
||||
- [[ ]] -> `02_Areas/`
|
||||
|
||||
## Move To Resources
|
||||
- [[ ]] -> `03_Resources/`
|
||||
|
||||
## Archive Or Delete Candidates
|
||||
- [[ ]] - reason:
|
||||
|
||||
## Rename Suggestions
|
||||
- `Old title` -> `New title`
|
||||
|
||||
## Merge Suggestions
|
||||
- [[Note A]] + [[Note B]] -> [[Target Note]]
|
||||
|
||||
## Link Opportunities
|
||||
- [[ ]] <-> [[ ]]
|
||||
|
||||
## Next Actions
|
||||
- [ ]
|
||||
- [ ]
|
||||
|
||||
---
|
||||
Use with Hermes:
|
||||
"Use the obsidian skill. Fill this inbox triage template for recent notes in 00_Inbox and propose changes before applying them."
|
||||
@@ -1,56 +0,0 @@
|
||||
---
|
||||
created: {{date}}
|
||||
modified: {{date}}
|
||||
type: project
|
||||
tags:
|
||||
- project
|
||||
- active
|
||||
status: active
|
||||
area:
|
||||
target_completion:
|
||||
---
|
||||
|
||||
# {{title}}
|
||||
|
||||
## Outcome
|
||||
<!-- What concrete result should exist when this project is done? -->
|
||||
|
||||
## Why Now
|
||||
<!-- Why this matters and why it belongs in Projects rather than Resources -->
|
||||
|
||||
## Scope
|
||||
- In:
|
||||
- Out:
|
||||
|
||||
## Success Criteria
|
||||
- [ ]
|
||||
- [ ]
|
||||
- [ ]
|
||||
|
||||
## Current State
|
||||
<!-- What already exists? What constraints matter? -->
|
||||
|
||||
## Related Notes
|
||||
- [[ ]]
|
||||
- [[ ]]
|
||||
|
||||
## Key Resources
|
||||
- [[ ]]
|
||||
- [[ ]]
|
||||
|
||||
## Open Questions
|
||||
-
|
||||
-
|
||||
|
||||
## Next Actions
|
||||
- [ ]
|
||||
- [ ]
|
||||
- [ ]
|
||||
|
||||
## Progress Log
|
||||
### {{date}}
|
||||
- Project created
|
||||
|
||||
---
|
||||
Use with Hermes:
|
||||
"Use the obsidian skill. Create a project from this template under 01_Projects, infer likely related notes, and add a minimal set of wikilinks."
|
||||
@@ -1,51 +0,0 @@
|
||||
---
|
||||
created: {{date}}
|
||||
modified: {{date}}
|
||||
type: resource
|
||||
tags:
|
||||
- resource
|
||||
- synthesis
|
||||
- hermes
|
||||
status: evergreen
|
||||
source_notes: []
|
||||
---
|
||||
|
||||
# {{title}}
|
||||
|
||||
## Summary
|
||||
<!-- 3-5 sentences synthesizing the topic -->
|
||||
|
||||
## Core Ideas
|
||||
-
|
||||
-
|
||||
-
|
||||
|
||||
## Patterns
|
||||
-
|
||||
-
|
||||
|
||||
## Contradictions
|
||||
-
|
||||
|
||||
## Useful Quotes Or Claims
|
||||
-
|
||||
|
||||
## Related Notes
|
||||
- [[ ]]
|
||||
- [[ ]]
|
||||
|
||||
## Gaps
|
||||
- What is still unclear?
|
||||
- Which note should be created or improved next?
|
||||
|
||||
## Actionable Takeaways
|
||||
- [ ]
|
||||
- [ ]
|
||||
|
||||
## Source Notes
|
||||
- [[ ]]
|
||||
- [[ ]]
|
||||
|
||||
---
|
||||
Use with Hermes:
|
||||
"Use the obsidian skill. Review related notes in 03_Resources and fill this synthesis note with patterns, contradictions, and missing links."
|
||||
@@ -1,32 +0,0 @@
|
||||
# {{title}}
|
||||
|
||||
**Source**: [URL or reference]
|
||||
**Date**: {{date}}
|
||||
**Tags**: #research
|
||||
|
||||
## Summary
|
||||
<!-- Key points in 2-3 sentences -->
|
||||
|
||||
## Key Insights
|
||||
-
|
||||
-
|
||||
-
|
||||
|
||||
## Notable Quotes
|
||||
>
|
||||
|
||||
## Questions Raised
|
||||
-
|
||||
-
|
||||
|
||||
## Connections
|
||||
<!-- How does this relate to other notes? -->
|
||||
- See: [[related note]]
|
||||
- Contradicts: [[other perspective]]
|
||||
- Builds on: [[foundation concept]]
|
||||
|
||||
## Action Items
|
||||
- [ ]
|
||||
|
||||
---
|
||||
*For synthesis: "Review all research notes in [folder] and identify patterns"*
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
date: <% tp.date.now("YYYY-MM-DD") %>
|
||||
day: <% tp.date.now("dddd") %>
|
||||
week: <% tp.date.now("YYYY-[W]WW") %>
|
||||
type: daily-note
|
||||
---
|
||||
|
||||
# <% tp.date.now("YYYY年MM月DD日 dddd") %>
|
||||
|
||||
## 📋 今日任务
|
||||
- [ ]
|
||||
|
||||
## 📝 工作笔记
|
||||
|
||||
|
||||
## 💡 想法与灵感
|
||||
|
||||
|
||||
## 📚 学习记录
|
||||
|
||||
|
||||
## 🎯 重点事项
|
||||
|
||||
|
||||
## 📊 总结
|
||||
|
||||
|
||||
---
|
||||
← [[<% tp.date.yesterday("YYYY-MM-DD") %>]] | [[<% tp.date.tomorrow("YYYY-MM-DD") %>]] →
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
type: meeting
|
||||
date: <% tp.date.now("YYYY-MM-DD HH:mm") %>
|
||||
tags:
|
||||
- meeting
|
||||
---
|
||||
|
||||
# 会议记录 - <% tp.system.prompt("会议主题") %>
|
||||
|
||||
## 📋 基本信息
|
||||
|
||||
- **时间**：<% tp.date.now("YYYY-MM-DD HH:mm") %>
|
||||
- **地点**：<% tp.system.prompt("会议地点（或会议软件）") %>
|
||||
- **主持人**：
|
||||
- **记录人**：
|
||||
|
||||
## 👥 参会人员
|
||||
|
||||
|
||||
## 📝 议程
|
||||
|
||||
1.
|
||||
|
||||
|
||||
## 💬 讨论内容
|
||||
|
||||
### 主题 1
|
||||
|
||||
|
||||
### 主题 2
|
||||
|
||||
|
||||
## ✅ 行动项
|
||||
|
||||
| 任务 | 负责人 | 截止日期 | 状态 |
|
||||
|------|--------|---------|------|
|
||||
| | | | ⚪ |
|
||||
|
||||
|
||||
## 📎 相关资料
|
||||
|
||||
|
||||
## 🔜 下次会议
|
||||
|
||||
- **时间**：
|
||||
- **议题**：
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
type: person
|
||||
name: <% tp.system.prompt("姓名") %>
|
||||
tags:
|
||||
- people
|
||||
created: <% tp.date.now("YYYY-MM-DD") %>
|
||||
---
|
||||
|
||||
# 👤 <% tp.system.prompt("姓名") %>
|
||||
|
||||
## 基本信息
|
||||
|
||||
- **职位/角色**：
|
||||
- **公司/组织**：
|
||||
- **联系方式**：
|
||||
- 邮箱：
|
||||
- 电话：
|
||||
- 其他：
|
||||
|
||||
## 🤝 关系
|
||||
|
||||
- **认识途径**：
|
||||
- **关系类型**：
|
||||
- **首次见面**：<% tp.date.now("YYYY-MM-DD") %>
|
||||
|
||||
## 💼 专业背景
|
||||
|
||||
|
||||
## 💬 互动记录
|
||||
|
||||
### <% tp.date.now("YYYY-MM-DD") %>
|
||||
|
||||
|
||||
## 📎 相关笔记
|
||||
|
||||
-
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
type: project
|
||||
created: <% tp.date.now("YYYY-MM-DD") %>
|
||||
status: active
|
||||
tags:
|
||||
- project
|
||||
---
|
||||
|
||||
# <% tp.system.prompt("项目名称") %>
|
||||
|
||||
## 📋 项目概述
|
||||
|
||||
**描述**：<% tp.system.prompt("项目简介（一句话）") %>
|
||||
|
||||
**目标**：
|
||||
|
||||
|
||||
## 🎯 关键成果（OKR）
|
||||
|
||||
### Objective（目标）
|
||||
|
||||
|
||||
### Key Results（关键结果）
|
||||
- [ ]
|
||||
- [ ]
|
||||
- [ ]
|
||||
|
||||
## 📅 时间线
|
||||
|
||||
| 阶段 | 开始时间 | 结束时间 | 状态 |
|
||||
|------|---------|---------|------|
|
||||
| 启动 | <% tp.date.now("YYYY-MM-DD") %> | | 🟢 |
|
||||
| 执行 | | | ⚪ |
|
||||
| 完成 | | | ⚪ |
|
||||
|
||||
## 👥 相关人员
|
||||
|
||||
- **负责人**：
|
||||
- **团队成员**：
|
||||
|
||||
## 📂 相关资源
|
||||
|
||||
-
|
||||
|
||||
|
||||
## 📝 进展记录
|
||||
|
||||
### <% tp.date.now("YYYY-MM-DD") %>
|
||||
项目启动
|
||||
|
||||
@@ -1,163 +0,0 @@
|
||||
---
|
||||
created: 2026-01-08
|
||||
type: workflow
|
||||
tags: [simplified, daily, essential]
|
||||
---
|
||||
|
||||
# 🚀 超简工作流（极简版）
|
||||
|
||||
**目标**: 把工作流简化到最少，只做真正重要的事
|
||||
|
||||
---
|
||||
|
||||
## 每日（5分钟）
|
||||
|
||||
```bash
|
||||
# 1. 早上：同步
|
||||
git pull
|
||||
|
||||
# 2. 晚上：保存
|
||||
git add .
|
||||
git commit -m "vault backup: $(date)"
|
||||
git push
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 每周一次（15分钟）
|
||||
|
||||
### 1️⃣ 清理Inbox（5分钟）
|
||||
|
||||
```bash
|
||||
# 看看有什么
|
||||
ls 00_Inbox/
|
||||
```
|
||||
|
||||
**对每个文件，问自己三个问题**：
|
||||
- ❌ 我还需要它吗？ → 删除
|
||||
- 📁 它属于某个项目吗？ → 移到 `01_Projects/[项目名]/`
|
||||
- 📚 它是参考资料吗？ → 移到 `03_Resources/[主题]/`
|
||||
|
||||
```bash
|
||||
# 例子：移动文件
|
||||
mv "00_Inbox/文件名.md" "01_Projects/项目名/"
|
||||
```
|
||||
|
||||
### 2️⃣ 检查项目进度（5分钟）
|
||||
|
||||
```bash
|
||||
# 列出所有项目
|
||||
ls 01_Projects/
|
||||
```
|
||||
|
||||
**对每个项目问**：
|
||||
- 🟢 这周有进展吗？
|
||||
- ⏰ 已完成？ → 移到 `04_Archive/Projects/`
|
||||
- 🚫 3周没动？ → 考虑暂停或删除
|
||||
|
||||
### 3️⃣ 整理文件（5分钟）
|
||||
|
||||
```bash
|
||||
# 检查有什么图片/文件
|
||||
ls 05_Attachments/
|
||||
```
|
||||
|
||||
- 文件有用吗？ → 重命名后放到 `05_Attachments/Organized/`
|
||||
- 没用？ → 删除
|
||||
|
||||
---
|
||||
|
||||
## ✅ 就这么简单！
|
||||
|
||||
**一周你只需要：**
|
||||
|
||||
| 任务 | 频率 | 时间 |
|
||||
|------|------|------|
|
||||
| 同步代码 | 每天 | 1秒 |
|
||||
| 提交备份 | 每天 | 1秒 |
|
||||
| 清理Inbox | 每周 | 5分钟 |
|
||||
| 检查项目 | 每周 | 5分钟 |
|
||||
| 整理文件 | 每周 | 5分钟 |
|
||||
|
||||
**总时间**: 每天1秒 + 每周15分钟 ✅
|
||||
|
||||
---
|
||||
|
||||
## 🗂️ 文件夹结构速记
|
||||
|
||||
```
|
||||
你的工作 → 01_Projects/[项目名]/
|
||||
备注/研究 → 01_Projects/[项目名]/Research/
|
||||
草稿 → 01_Projects/[项目名]/Drafts/
|
||||
最终成果 → 01_Projects/[项目名]/Output/
|
||||
|
||||
临时捕获 → 00_Inbox/
|
||||
|
||||
参考资料 → 03_Resources/[主题]/
|
||||
|
||||
完成的项目 → 04_Archive/Projects/
|
||||
|
||||
图片/文件 → 05_Attachments/Organized/[名称]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🤔 我该用哪个文件夹？
|
||||
|
||||
```
|
||||
"我不确定放哪儿"
|
||||
↓
|
||||
00_Inbox/（先放这里，周末再整理）
|
||||
↓
|
||||
问自己：
|
||||
"这有完成时间吗？" → YES → 01_Projects/
|
||||
"这要一直维护吗？" → YES → 02_Areas/
|
||||
"这就是资料库？" → YES → 03_Resources/
|
||||
"已完成？" → YES → 04_Archive/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ⚡ 快速命令
|
||||
|
||||
```bash
|
||||
# 移动文件（用这个，不要复制）
|
||||
mv "源文件" "目标文件夹/"
|
||||
|
||||
# 检查什么改了
|
||||
git status
|
||||
|
||||
# 搜索内容
|
||||
grep -r "关键词" .
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎯 关键原则
|
||||
|
||||
1. **捕获快，整理在周末** - 不要边写边整理
|
||||
2. **每周清空Inbox一次** - 这是底线
|
||||
3. **每天保存代码** - git commit + push
|
||||
4. **删掉不需要的** - 不要堆积垃圾
|
||||
5. **链接很重要** - 用 `[[笔记名]]` 连接相关内容
|
||||
|
||||
---
|
||||
|
||||
## 📝 什么时候需要深层指南？
|
||||
|
||||
- 🤷 "文件夹结构有点复杂" → 看 `QUICK_REFERENCE.md`
|
||||
- 😵 "出问题了" → 看 `06_Metadata/Reference/TROUBLESHOOTING.md`
|
||||
- 🎓 "想深入学PARA方法" → 看 `06_Metadata/Reference/PARA_METHOD.md`
|
||||
- 🔀 "Git有冲突" → 看 `06_Metadata/Reference/GIT_WORKFLOW.md`
|
||||
|
||||
---
|
||||
|
||||
## ✨ 就这些了
|
||||
|
||||
不需要记复杂的东西。工作流应该帮助你，而不是束缚你。
|
||||
|
||||
**Keep It Simple!**
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-01-08*
|
||||
@@ -1,521 +0,0 @@
|
||||
# Weekly Review Template
|
||||
|
||||
**Review Date**: [YYYY-MM-DD]
|
||||
**Week Number**: [Week N of 2026]
|
||||
**Reviewer**: [Your Name or "Self Review"]
|
||||
|
||||
---
|
||||
|
||||
## Pre-Review Checklist
|
||||
|
||||
- [ ] `git pull` - Sync latest changes from remote
|
||||
- [ ] `git status` - Check for uncommitted changes
|
||||
- [ ] Commit any pending work before starting review
|
||||
- [ ] Block 30-45 minutes of uninterrupted time
|
||||
- [ ] Have pen and paper ready for notes
|
||||
|
||||
---
|
||||
|
||||
## 1. Inbox Processing
|
||||
|
||||
**Goal**: Zero inbox (except permanent files)
|
||||
|
||||
### Step 1: Count Current Inbox Items
|
||||
|
||||
```bash
|
||||
ls 00_Inbox/
|
||||
```
|
||||
|
||||
**Current Count**: _____ items (excluding permanent files, count manually)
|
||||
|
||||
### Step 2: Quick Delete
|
||||
|
||||
Review and delete:
|
||||
- [ ] Obsolete information
|
||||
- [ ] Duplicate notes
|
||||
- [ ] Low-value clippings
|
||||
- [ ] Test files
|
||||
- [ ] Outdated drafts
|
||||
|
||||
**Deleted**: _____ items
|
||||
|
||||
### Step 3: Process Remaining Items
|
||||
|
||||
For each item in inbox, decide:
|
||||
|
||||
| Filename | Action | Destination | Status |
|
||||
|----------|--------|-------------|--------|
|
||||
| | Delete / Move / Process | | [ ] |
|
||||
| | Delete / Move / Process | | [ ] |
|
||||
| | Delete / Move / Process | | [ ] |
|
||||
| | Delete / Move / Process | | [ ] |
|
||||
| | Delete / Move / Process | | [ ] |
|
||||
|
||||
### Step 4: Process Clippings Folder
|
||||
|
||||
```bash
|
||||
ls 00_Inbox/Clippings/
|
||||
```
|
||||
|
||||
- [ ] Review all web clippings from Firecrawl
|
||||
- [ ] Add context and notes to valuable clippings
|
||||
- [ ] Move to appropriate PARA locations
|
||||
- [ ] Delete low-value or duplicate content
|
||||
|
||||
**Clippings processed**: _____ items
|
||||
|
||||
### Step 5: Verify Empty Inbox
|
||||
|
||||
```bash
|
||||
ls 00_Inbox/
|
||||
```
|
||||
|
||||
**Final Count**: _____ items (should be just permanent files)
|
||||
|
||||
- [ ] Inbox is clean and organized
|
||||
|
||||
---
|
||||
|
||||
## 2. Projects Review
|
||||
|
||||
### Step 1: List All Active Projects
|
||||
|
||||
```bash
|
||||
ls 01_Projects/
|
||||
```
|
||||
|
||||
**Active Projects Count**: _____
|
||||
|
||||
### Step 2: Review Each Project
|
||||
|
||||
For each project in `01_Projects/`:
|
||||
|
||||
#### Project: _____________________
|
||||
|
||||
- **Status**: [ ] On Track [ ] Behind [ ] Blocked [ ] Complete
|
||||
- **Progress this week**: ________________________________
|
||||
- **Next action**: ________________________________________
|
||||
- **Blockers**: ___________________________________________
|
||||
- **Needs**:
|
||||
- [ ] More research
|
||||
- [ ] External input
|
||||
- [ ] Time allocation
|
||||
- [ ] Resources/tools
|
||||
- [ ] Other: __________
|
||||
|
||||
#### Project: _____________________
|
||||
|
||||
- **Status**: [ ] On Track [ ] Behind [ ] Blocked [ ] Complete
|
||||
- **Progress this week**: ________________________________
|
||||
- **Next action**: ________________________________________
|
||||
- **Blockers**: ___________________________________________
|
||||
- **Needs**:
|
||||
- [ ] More research
|
||||
- [ ] External input
|
||||
- [ ] Time allocation
|
||||
- [ ] Resources/tools
|
||||
- [ ] Other: __________
|
||||
|
||||
#### Project: _____________________
|
||||
|
||||
- **Status**: [ ] On Track [ ] Behind [ ] Blocked [ ] Complete
|
||||
- **Progress this week**: ________________________________
|
||||
- **Next action**: ________________________________________
|
||||
- **Blockers**: ___________________________________________
|
||||
- **Needs**:
|
||||
- [ ] More research
|
||||
- [ ] External input
|
||||
- [ ] Time allocation
|
||||
- [ ] Resources/tools
|
||||
- [ ] Other: __________
|
||||
|
||||
### Step 3: Identify Completed Projects
|
||||
|
||||
Projects to archive:
|
||||
|
||||
- [ ] Project: ______________ (completed ______)
|
||||
- [ ] Project: ______________ (completed ______)
|
||||
- [ ] Project: ______________ (completed ______)
|
||||
|
||||
**Archive Process**:
|
||||
```bash
|
||||
mv "01_Projects/[ProjectName]" "04_Archive/Projects/[ProjectName]"
|
||||
```
|
||||
|
||||
- [ ] All completed projects moved to Archive
|
||||
- [ ] Project completion notes created
|
||||
- [ ] Related area notes updated
|
||||
|
||||
### Step 4: Identify Stalled Projects
|
||||
|
||||
Projects inactive for 30+ days:
|
||||
|
||||
- [ ] Project: ______________
|
||||
- [ ] Reactivate
|
||||
- [ ] Archive
|
||||
- [ ] Convert to Area/Resource
|
||||
|
||||
**Action taken**: _________________________________
|
||||
|
||||
### Step 5: New Projects Needed
|
||||
|
||||
Emerging projects from areas or inbox:
|
||||
|
||||
- [ ] New project: _____________________ (from Area: ______)
|
||||
- [ ] New project: _____________________ (from Area: ______)
|
||||
- [ ] New project: _____________________ (from Inbox item)
|
||||
|
||||
**Created**:
|
||||
```bash
|
||||
mkdir -p "01_Projects/[ProjectName]/{Research,Drafts,Output}"
|
||||
```
|
||||
|
||||
- [ ] New project folders created
|
||||
- [ ] README.md added with objectives
|
||||
- [ ] Initial files moved to project
|
||||
|
||||
---
|
||||
|
||||
## 3. Areas Review
|
||||
|
||||
### Step 1: List All Areas
|
||||
|
||||
```bash
|
||||
ls 02_Areas/
|
||||
```
|
||||
|
||||
**Areas Count**: _____
|
||||
|
||||
### Step 2: Review Each Area
|
||||
|
||||
For each area in `02_Areas/`:
|
||||
|
||||
#### Area: _____________________
|
||||
|
||||
- **Health**: [ ] Excellent [ ] Good [ ] Needs Attention [ ] Critical
|
||||
- **Activity this week**: ________________________________
|
||||
- **Standards met**: [ ] Yes [ ] Mostly [ ] No
|
||||
- **Related projects**: ________________________________
|
||||
- **Action needed**:
|
||||
- [ ] Create new project
|
||||
- [ ] Update area note
|
||||
- [ ] Research new approach
|
||||
- [ ] Archive area
|
||||
- [ ] Other: __________
|
||||
|
||||
#### Area: _____________________
|
||||
|
||||
- **Health**: [ ] Excellent [ ] Good [ ] Needs Attention [ ] Critical
|
||||
- **Activity this week**: ________________________________
|
||||
- **Standards met**: [ ] Yes [ ] Mostly [ ] No
|
||||
- **Related projects**: ________________________________
|
||||
- **Action needed**:
|
||||
- [ ] Create new project
|
||||
- [ ] Update area note
|
||||
- [ ] Research new approach
|
||||
- [ ] Archive area
|
||||
- [ ] Other: __________
|
||||
|
||||
#### Area: _____________________
|
||||
|
||||
- **Health**: [ ] Excellent [ ] Good [ ] Needs Attention [ ] Critical
|
||||
- **Activity this week**: ________________________________
|
||||
- **Standards met**: [ ] Yes [ ] Mostly [ ] No
|
||||
- **Related projects**: ________________________________
|
||||
- **Action needed**:
|
||||
- [ ] Create new project
|
||||
- [ ] Update area note
|
||||
- [ ] Research new approach
|
||||
- [ ] Archive area
|
||||
- [ ] Other: __________
|
||||
|
||||
### Step 3: Areas Needing Projects
|
||||
|
||||
Areas requiring active projects:
|
||||
|
||||
- [ ] Area: ______________ → Project: ______________
|
||||
- [ ] Area: ______________ → Project: ______________
|
||||
|
||||
### Step 4: Update Area Notes
|
||||
|
||||
- [ ] Review overview notes for each area
|
||||
- [ ] Update progress and reflections
|
||||
- [ ] Link to new resources or projects
|
||||
- [ ] Update frontmatter dates
|
||||
|
||||
---
|
||||
|
||||
## 4. Resources Review
|
||||
|
||||
### Step 1: List Resources
|
||||
|
||||
```bash
|
||||
ls 03_Resources/
|
||||
```
|
||||
|
||||
**Resource Topics Count**: _____
|
||||
|
||||
### Step 2: Quality Check
|
||||
|
||||
Recent additions this week:
|
||||
|
||||
- [ ] Resource: ______________ (Quality: Good / Medium / Poor)
|
||||
- [ ] Resource: ______________ (Quality: Good / Medium / Poor)
|
||||
- [ ] Resource: ______________ (Quality: Good / Medium / Poor)
|
||||
|
||||
### Step 3: Consolidation Opportunities
|
||||
|
||||
Overlapping or duplicate resources:
|
||||
|
||||
- [ ] Merge: ______________ + ______________ → ______________
|
||||
- [ ] Merge: ______________ + ______________ → ______________
|
||||
|
||||
### Step 4: Outdated Resources
|
||||
|
||||
Resources to archive or delete:
|
||||
|
||||
- [ ] Archive: ______________ (reason: ______)
|
||||
- [ ] Delete: ______________ (reason: ______)
|
||||
|
||||
**Action**:
|
||||
```bash
|
||||
mv "03_Resources/[TopicName]" "04_Archive/Resources/[TopicName]"
|
||||
```
|
||||
|
||||
- [ ] Outdated resources archived
|
||||
|
||||
### Step 5: New Resource Topics
|
||||
|
||||
Emerging topics to track:
|
||||
|
||||
- [ ] Create: `03_Resources/________________/`
|
||||
- [ ] Create: `03_Resources/________________/`
|
||||
|
||||
---
|
||||
|
||||
## 5. Attachments Processing
|
||||
|
||||
### Step 1: List Unprocessed Attachments
|
||||
|
||||
```bash
|
||||
ls 05_Attachments/
|
||||
```
|
||||
|
||||
**Unprocessed Count**: _____
|
||||
|
||||
Or use helper:
|
||||
```bash
|
||||
pnpm attachments:list
|
||||
```
|
||||
|
||||
### Step 2: Process Each Attachment
|
||||
|
||||
For each unprocessed file:
|
||||
|
||||
| Filename | Related Note | New Name | Action | Status |
|
||||
|----------|--------------|----------|--------|--------|
|
||||
| | | | Rename/Move/Delete | [ ] |
|
||||
| | | | Rename/Move/Delete | [ ] |
|
||||
| | | | Rename/Move/Delete | [ ] |
|
||||
| | | | Rename/Move/Delete | [ ] |
|
||||
|
||||
### Step 3: Rename and Organize
|
||||
|
||||
```bash
|
||||
mv "05_Attachments/[file]" "05_Attachments/Organized/[RelatedNote]_[Description].[ext]"
|
||||
```
|
||||
|
||||
- [ ] All attachments renamed with clear names
|
||||
- [ ] Attachments moved to Organized folder
|
||||
- [ ] Links updated in related notes
|
||||
|
||||
### Step 4: Find Orphaned Attachments
|
||||
|
||||
```bash
|
||||
pnpm attachments:orphans
|
||||
```
|
||||
|
||||
**Orphaned Files**: _____
|
||||
|
||||
- [ ] Review orphaned files
|
||||
- [ ] Delete unreferenced files
|
||||
- [ ] Or add references to notes
|
||||
|
||||
### Step 5: Update Links
|
||||
|
||||
```bash
|
||||
pnpm attachments:update-links
|
||||
```
|
||||
|
||||
- [ ] All attachment links verified and updated
|
||||
|
||||
**Final Organized Count**: _____
|
||||
|
||||
---
|
||||
|
||||
## 6. Git Commit
|
||||
|
||||
### Step 1: Review Changes
|
||||
|
||||
```bash
|
||||
git status
|
||||
```
|
||||
|
||||
**Modified Files**: _____
|
||||
**New Files**: _____
|
||||
**Deleted Files**: _____
|
||||
|
||||
### Step 2: Review Diff
|
||||
|
||||
```bash
|
||||
git diff
|
||||
```
|
||||
|
||||
- [ ] Reviewed all changes
|
||||
- [ ] No sensitive information in commit
|
||||
- [ ] Changes are intentional
|
||||
|
||||
### Step 3: Stage and Commit
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "Weekly review: Week N of 2026 - [Brief summary]"
|
||||
```
|
||||
|
||||
**Commit Message**:
|
||||
```
|
||||
Weekly review: Week N of 2026
|
||||
|
||||
- Processed inbox: X items
|
||||
- Archived Y projects
|
||||
- Updated Z areas
|
||||
- Organized N attachments
|
||||
- [Other notable changes]
|
||||
```
|
||||
|
||||
- [ ] Changes committed with descriptive message
|
||||
|
||||
### Step 4: Push to Remote
|
||||
|
||||
```bash
|
||||
git push
|
||||
```
|
||||
|
||||
- [ ] Changes pushed to remote repository
|
||||
- [ ] Verified push succeeded
|
||||
|
||||
---
|
||||
|
||||
## 7. Next Week Planning
|
||||
|
||||
### Focus Areas
|
||||
|
||||
**Top 3 Priorities**:
|
||||
1. _____________________________________________
|
||||
2. _____________________________________________
|
||||
3. _____________________________________________
|
||||
|
||||
### Project Focus
|
||||
|
||||
**Active Projects for Next Week**:
|
||||
- [ ] Project: ________________ (Next action: ______________)
|
||||
- [ ] Project: ________________ (Next action: ______________)
|
||||
- [ ] Project: ________________ (Next action: ______________)
|
||||
|
||||
### Time Allocation
|
||||
|
||||
| Project/Area | Time Commitment | Specific Actions |
|
||||
|--------------|-----------------|------------------|
|
||||
| | hours | |
|
||||
| | hours | |
|
||||
| | hours | |
|
||||
|
||||
### Potential Obstacles
|
||||
|
||||
**Anticipated Challenges**:
|
||||
- _____________________________________________
|
||||
- _____________________________________________
|
||||
|
||||
**Mitigation Strategies**:
|
||||
- _____________________________________________
|
||||
- _____________________________________________
|
||||
|
||||
### New Initiatives
|
||||
|
||||
**To Start Next Week**:
|
||||
- [ ] _____________________________________________
|
||||
- [ ] _____________________________________________
|
||||
|
||||
**To Research**:
|
||||
- [ ] _____________________________________________
|
||||
- [ ] _____________________________________________
|
||||
|
||||
---
|
||||
|
||||
## 8. Reflection
|
||||
|
||||
### What Went Well This Week
|
||||
|
||||
- _____________________________________________
|
||||
- _____________________________________________
|
||||
- _____________________________________________
|
||||
|
||||
### What Needs Improvement
|
||||
|
||||
- _____________________________________________
|
||||
- _____________________________________________
|
||||
- _____________________________________________
|
||||
|
||||
### System Adjustments
|
||||
|
||||
**Workflow Changes Needed**:
|
||||
- [ ] _____________________________________________
|
||||
- [ ] _____________________________________________
|
||||
|
||||
**Documentation Updates**:
|
||||
- [ ] Update CLAUDE.md with new practices
|
||||
- [ ] Create new templates
|
||||
- [ ] Refine folder structure
|
||||
|
||||
### Metrics
|
||||
|
||||
**Completion Stats**:
|
||||
- Inbox items processed: _____
|
||||
- Projects advanced: _____
|
||||
- Projects completed: _____
|
||||
- Notes created: _____
|
||||
- Attachments organized: _____
|
||||
- Git commits: _____
|
||||
|
||||
**Health Check**:
|
||||
- [ ] Inbox under control (< 20 items)
|
||||
- [ ] All active projects have next actions
|
||||
- [ ] Areas are maintained
|
||||
- [ ] Git is synced
|
||||
- [ ] Attachments organized
|
||||
|
||||
---
|
||||
|
||||
## Review Complete
|
||||
|
||||
- [ ] All sections completed
|
||||
- [ ] Actions identified and scheduled
|
||||
- [ ] Git committed and pushed
|
||||
- [ ] Ready for next week
|
||||
|
||||
**Review Duration**: _____ minutes
|
||||
|
||||
**Next Review Scheduled**: [Date] _______________
|
||||
|
||||
---
|
||||
|
||||
**Notes**:
|
||||
|
||||
_____________________________________________
|
||||
_____________________________________________
|
||||
_____________________________________________
|
||||
|
||||
---
|
||||
|
||||
**Template Version**: 1.0
|
||||
**Last Updated**: January 05, 2026
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,295 +0,0 @@
|
||||
---
|
||||
created: 2026-01-08
|
||||
type: analysis
|
||||
tags: [workflow, simplification, comparison]
|
||||
---
|
||||
|
||||
# 工作流简化对比分析
|
||||
|
||||
## 📊 核心对比
|
||||
|
||||
### 原来的工作流 vs 极简工作流
|
||||
|
||||
| 指标 | 原版 | 极简版 | 改善 |
|
||||
|------|------|--------|------|
|
||||
| **每周耗时** | 30-45分钟 | 15分钟 | ⬇️ 67% |
|
||||
| **日常操作** | 5个脚本命令 | 3个git命令 | ⬇️ 40% |
|
||||
| **周期审查项** | 30+ 检查项 | 8个检查项 | ⬇️ 73% |
|
||||
| **需学习内容** | PARA方法深入理解 | 基本文件夹概念 | ⬇️ 60% |
|
||||
| **Inbox决策步骤** | 5步 | 3步 | ⬇️ 40% |
|
||||
|
||||
---
|
||||
|
||||
## 🔍 具体简化项
|
||||
|
||||
### 1. Weekly Review 简化
|
||||
|
||||
**❌ 原来做的**（30-45分钟）:
|
||||
|
||||
```
|
||||
Pre-Review Checklist (3项)
|
||||
↓
|
||||
1. Inbox Processing (5个步骤)
|
||||
- 计数
|
||||
- 快速删除
|
||||
- 逐个处理
|
||||
- 处理Clippings
|
||||
- 验证空
|
||||
↓
|
||||
2. Projects Review (5个步骤)
|
||||
- 列出所有项目
|
||||
- 逐个评审（状态、进度、阻碍、需求）
|
||||
- 识别完成项目
|
||||
- 识别卡住的项目
|
||||
- 识别新项目
|
||||
↓
|
||||
3. Areas Review (4个步骤)
|
||||
- 列出所有Area
|
||||
- 逐个评审（健康度、活动、标准、关联项目、行动）
|
||||
- 识别需要项目的Area
|
||||
- 更新Area笔记
|
||||
↓
|
||||
4. Resources Review (5个步骤)
|
||||
- 列出资源
|
||||
- 质量检查
|
||||
- 合并重复
|
||||
- 存档过时的
|
||||
- 创建新资源
|
||||
↓
|
||||
5. Attachments Processing (5个步骤)
|
||||
- 列出未处理的
|
||||
- 逐个处理（决定是否保留、重命名、移动）
|
||||
- 重命名和整理
|
||||
- 找孤立文件
|
||||
- 更新链接
|
||||
↓
|
||||
6. Git Commit (4个步骤)
|
||||
- 检查changes
|
||||
- 查看diff
|
||||
- 提交
|
||||
- 推送
|
||||
```
|
||||
|
||||
**✅ 新做的**（15分钟）:
|
||||
|
||||
```
|
||||
1. 清理Inbox（5分钟）
|
||||
- ls 看看什么
|
||||
- 问3个问题
|
||||
- 移动文件
|
||||
|
||||
2. 检查项目（5分钟）
|
||||
- ls 列出项目
|
||||
- 问3个问题
|
||||
- 存档/暂停
|
||||
|
||||
3. 整理文件（5分钟）
|
||||
- ls 看看文件
|
||||
- 有用就重命名+移动
|
||||
- 没用就删除
|
||||
|
||||
4. 日常保存（git）
|
||||
- git add .
|
||||
- git commit
|
||||
- git push
|
||||
```
|
||||
|
||||
**差异**: 从 6个大部分 → 3个小部分
|
||||
|
||||
---
|
||||
|
||||
### 2. 决策简化
|
||||
|
||||
**❌ 原来**: 每个项目要评估 5 个维度
|
||||
|
||||
```
|
||||
- Status: On Track / Behind / Blocked / Complete
|
||||
- Progress: 写进展描述
|
||||
- Blockers: 写阻碍
|
||||
- Needs: 勾选5个选项（研究/输入/时间/资源/其他）
|
||||
- Related areas: 写关联Area
|
||||
```
|
||||
|
||||
**✅ 新版**: 只问 3 个问题
|
||||
|
||||
```
|
||||
1. 这周有进展吗？
|
||||
2. 完成了吗？
|
||||
3. 3周没动吗？
|
||||
```
|
||||
|
||||
**好处**: 80%的信息用20%的问题就够了
|
||||
|
||||
---
|
||||
|
||||
### 3. 脚本命令简化
|
||||
|
||||
**❌ 原来要记住**:
|
||||
|
||||
```bash
|
||||
pnpm firecrawl:scrape <url> <filename> # 爬取单个URL
|
||||
pnpm firecrawl:batch <url1> <url2> # 批量爬取
|
||||
pnpm attachments:list # 列出未处理
|
||||
pnpm attachments:organized # 统计已处理
|
||||
pnpm attachments:orphans # 找孤立文件
|
||||
pnpm attachments:update-links # 更新链接
|
||||
source .scripts/setup-firecrawl-env.sh # 设置环境
|
||||
```
|
||||
|
||||
**✅ 新版只需**:
|
||||
|
||||
```bash
|
||||
git pull # 早上
|
||||
git push # 晚上
|
||||
ls # 列出文件夹（原生命令）
|
||||
mv # 移动文件（原生命令）
|
||||
rm # 删除文件（原生命令）
|
||||
```
|
||||
|
||||
**好处**: 用系统基础命令，没有学习曲线
|
||||
|
||||
---
|
||||
|
||||
### 4. 文件夹结构理解
|
||||
|
||||
**❌ 原来需要理解**:
|
||||
|
||||
- PARA方法（4个维度）
|
||||
- 为什么Projects需要子文件夹
|
||||
- Areas和Projects的区别
|
||||
- Resources和Areas的区别
|
||||
- 什么时候Archive
|
||||
|
||||
**✅ 新版**: 简单分类
|
||||
|
||||
```
|
||||
"有完成时间？" → Projects
|
||||
"要一直维护？" → Areas
|
||||
"参考资料？" → Resources
|
||||
"完成了？" → Archive
|
||||
"暂时？" → Inbox
|
||||
```
|
||||
|
||||
**好处**: 不需要理论，只需直觉
|
||||
|
||||
---
|
||||
|
||||
## 🎯 为什么这个更好？
|
||||
|
||||
### 1. **认知负荷降低 60%**
|
||||
- 从记住 6 个大流程 → 3 个小流程
|
||||
- 从 30+ 决策点 → 8 个决策点
|
||||
- 从 7 个命令 → 3 个基础命令
|
||||
|
||||
### 2. **执行成功率更高**
|
||||
- 短流程 = 更容易坚持
|
||||
- 15分钟 = 周末容易抽出时间
|
||||
- 清晰的3个问题 = 不会卡住
|
||||
|
||||
### 3. **不失功能**
|
||||
- 仍然整理Inbox
|
||||
- 仍然追踪项目
|
||||
- 仍然存档完成项目
|
||||
- 仍然整理附件
|
||||
- 仍然版本控制
|
||||
|
||||
### 4. **更容易调整**
|
||||
- 如果某步不适合你，很容易改
|
||||
- 比如"不需要存档？" → 删掉那行
|
||||
- 比如"要分类Area？" → 加回来
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 失去了什么？
|
||||
|
||||
### 1. **详细的Area追踪**
|
||||
- ❌ 原来: 每周评估Area的"健康度"
|
||||
- ✅ 替代: 如果某个Area不活跃，自然就不会在Inbox里看到相关笔记
|
||||
|
||||
### 2. **Web内容批量爬取**
|
||||
- ❌ 原来: `pnpm firecrawl:batch` 快速爬多个URL
|
||||
- ✅ 替代: 用浏览器的"剪藏"插件，或手动保存链接
|
||||
- 💡 实际: 大多数人不经常用批量爬取
|
||||
|
||||
### 3. **自动化的孤立文件检查**
|
||||
- ❌ 原来: `pnpm attachments:orphans` 自动找
|
||||
- ✅ 替代: 偶尔 `ls 05_Attachments/` 目测一下
|
||||
- 💡 实际: 如果文件没被引用，它自然就没用
|
||||
|
||||
### 4. **精细的资源质量评估**
|
||||
- ❌ 原来: 周期标记每个资源的质量等级
|
||||
- ✅ 替代: 如果资源过时，删掉就行
|
||||
- 💡 实际: 大多数资源自然过时和替换
|
||||
|
||||
---
|
||||
|
||||
## 🔄 如何过渡？
|
||||
|
||||
### 第1周: 并行两个版本
|
||||
|
||||
```
|
||||
1. 继续用原来的Weekly Review
|
||||
2. 同时试试极简版本
|
||||
3. 对比时间和压力水平
|
||||
```
|
||||
|
||||
### 第2-3周: 逐步切换
|
||||
|
||||
```
|
||||
1. 用极简版本做主流程
|
||||
2. 如果需要详细信息，查询原文档
|
||||
3. 记录"缺失"的内容
|
||||
```
|
||||
|
||||
### 第4周: 最终决定
|
||||
|
||||
```
|
||||
1. 完全用极简版本
|
||||
2. 根据实际需求调整
|
||||
3. 删除/存档原版本（或保留为参考）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 💾 原文档保留
|
||||
|
||||
所有原文档 **仍然保留**:
|
||||
|
||||
- `CLAUDE.md` - 完整参考（需要时查看）
|
||||
- `CLAUDE.md.backup` - 备份
|
||||
- `WEEKLY_REVIEW.md` - 完整检查清单（可选使用）
|
||||
- `06_Metadata/Reference/` - 深入指南（查询用）
|
||||
- `QUICK_REFERENCE.md` - 快速参考卡
|
||||
|
||||
**你可以**:
|
||||
- 随时查阅这些文档
|
||||
- 不需要删除任何东西
|
||||
- 如果不适应极简版，可以切回去
|
||||
|
||||
---
|
||||
|
||||
## ✅ 推荐步骤
|
||||
|
||||
1. **立即**: 阅读 `ULTRA_SIMPLE_WORKFLOW.md`（这个超简化版本）
|
||||
2. **这周**: 并行使用两个版本，感受差异
|
||||
3. **下周**: 完全切换到极简版本
|
||||
4. **反馈**: 告诉我哪些步骤太简单/太复杂
|
||||
|
||||
---
|
||||
|
||||
## 🎓 学到的东西
|
||||
|
||||
这次简化想传达的核心理念：
|
||||
|
||||
> **最好的工作流，就是你能坚持的工作流**
|
||||
|
||||
不需要完美的系统。需要的是：
|
||||
- ✅ 简单（5分钟能理解）
|
||||
- ✅ 快速（15分钟能完成）
|
||||
- ✅ 可持续（能坚持做）
|
||||
- ✅ 可扩展（需要时可增加）
|
||||
|
||||
---
|
||||
|
||||
*对比分析完成于: 2026-01-08*
|
||||
*原始文档日期: 2026-01-06*
|
||||
@@ -1,352 +0,0 @@
|
||||
---
|
||||
created: 2026-01-08
|
||||
type: guide
|
||||
tags: [workflow, transition, practical]
|
||||
---
|
||||
|
||||
# 🔀 工作流过渡指南
|
||||
|
||||
**从复杂 → 简单，一步步来**
|
||||
|
||||
---
|
||||
|
||||
## 📅 4周过渡计划
|
||||
|
||||
### 🟢 第1周: 认识与对比
|
||||
|
||||
**目标**: 理解两个版本的差异，不做改变
|
||||
|
||||
#### 周一-周三
|
||||
- [ ] 阅读 `ULTRA_SIMPLE_WORKFLOW.md`（15分钟）
|
||||
- [ ] 阅读 `WORKFLOW_SIMPLIFICATION_ANALYSIS.md`（15分钟）
|
||||
- [ ] **不做任何改变**，照常工作
|
||||
|
||||
#### 周四-周五
|
||||
- [ ] 看看这周的Inbox有多少项
|
||||
- [ ] 计算原来的Weekly Review花了多长时间
|
||||
- [ ] 记录下来
|
||||
|
||||
#### 周六（Weekly Review）
|
||||
```
|
||||
同时进行两种方式：
|
||||
1. 用原版本的WEEKLY_REVIEW.md（记录时间）
|
||||
2. 按极简版本再做一遍（记录时间）
|
||||
3. 对比结果是否相同
|
||||
```
|
||||
|
||||
**本周任务**:
|
||||
- [ ] 完成原版Weekly Review
|
||||
- [ ] 完成极简版本演练
|
||||
- [ ] 比较时间差
|
||||
- [ ] 问自己："极简版的结果够好吗？"
|
||||
|
||||
---
|
||||
|
||||
### 🟡 第2周: 混合使用
|
||||
|
||||
**目标**: 用极简版本做70%的工作
|
||||
|
||||
#### 周一-周五
|
||||
- [ ] 继续日常工作（git pull/push）
|
||||
- [ ] **不改变**任何东西
|
||||
|
||||
#### 周六（Weekly Review）
|
||||
```
|
||||
步骤：
|
||||
1. 用极简版本完成全部任务（记录时间）
|
||||
2. 和上周的原版本结果对比
|
||||
3. 检查是否有遗漏的内容
|
||||
```
|
||||
|
||||
**本周决定**:
|
||||
- [ ] 极简版本是否完成了必要的工作？
|
||||
- [ ] 缺少什么吗？
|
||||
- [ ] 哪些步骤可以保留，哪些可以删掉？
|
||||
|
||||
**如果感觉不完整**:
|
||||
- 保持混合使用（极简主，详细参）
|
||||
- 再用1周适应
|
||||
|
||||
**如果感觉很好**:
|
||||
- 继续，准备第3周的完全切换
|
||||
|
||||
---
|
||||
|
||||
### 🟠 第3周: 逐步替换
|
||||
|
||||
**目标**: 完全用极简版本，需要时查阅详细文档
|
||||
|
||||
#### 周一-周五
|
||||
- [ ] 日常工作照常
|
||||
|
||||
#### 周六（Weekly Review）
|
||||
```
|
||||
完全按极简版本做，但：
|
||||
- 如果某一步不确定 → 查 QUICK_REFERENCE.md
|
||||
- 如果某一步出问题 → 查 TROUBLESHOOTING.md
|
||||
- 如果需要理论背景 → 查 PARA_METHOD.md
|
||||
```
|
||||
|
||||
**本周重点**:
|
||||
- 第1次不看笔记，试试能否凭记忆完成
|
||||
- 如果卡住，翻笔记，记录卡点
|
||||
- 完成后，列出"不舒服"的地方
|
||||
|
||||
**检查清单**:
|
||||
```
|
||||
[ ] Inbox是否清空？
|
||||
[ ] 活跃项目是否都清楚现状？
|
||||
[ ] 过时的项目是否存档？
|
||||
[ ] 主要文件是否都整理好？
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 🟣 第4周: 完全切换 + 微调
|
||||
|
||||
**目标**: 完全用极简版本，然后优化
|
||||
|
||||
#### 周一-周五
|
||||
- [ ] 照常工作
|
||||
- [ ] 在做的过程中记录"改进想法"
|
||||
- 格式: `2026-01-15 - 工作流改进想法.md` 放到Inbox
|
||||
|
||||
#### 周六（Weekly Review）
|
||||
```
|
||||
1. 按极简版本做完整流程（不查笔记）
|
||||
2. 感受这个节奏是否舒服
|
||||
3. 回顾这一个月的对比
|
||||
```
|
||||
|
||||
**最终决定**:
|
||||
|
||||
| 情况 | 建议 |
|
||||
|------|------|
|
||||
| ✅ 很舒服，省时间 | **保持极简版本**<br/>存档原版本 |
|
||||
| 😐 可以但需要微调 | **基于极简版本改进**<br/>保留必要的详细检查 |
|
||||
| ❌ 觉得不够详细 | **混合方案**<br/>极简+月度深度审查 |
|
||||
|
||||
---
|
||||
|
||||
## �� 具体改动 Checklist
|
||||
|
||||
### 如果完全切换到极简版本
|
||||
|
||||
#### 做这些
|
||||
- [ ] 把 `ULTRA_SIMPLE_WORKFLOW.md` 放到容易看到的地方
|
||||
- [ ] 周期提醒设置为 15分钟（不是30分钟）
|
||||
- [ ] 删除原来的详细步骤笔记（或存档）
|
||||
|
||||
#### 保留这些
|
||||
- [ ] `QUICK_REFERENCE.md` - 快速查询
|
||||
- [ ] `TROUBLESHOOTING.md` - 出问题时查看
|
||||
- [ ] `CLAUDE.md` - 完整参考
|
||||
- [ ] 所有的脚本和原版本指南（备份）
|
||||
|
||||
#### 可选删除
|
||||
- [ ] `WEEKLY_REVIEW.md` - 如果不再用
|
||||
- [ ] `CLAUDE.md.backup` - 如果空间紧张
|
||||
|
||||
---
|
||||
|
||||
## 🧩 微调示例
|
||||
|
||||
### 微调1: 保留Area检查
|
||||
|
||||
**如果你觉得跳过Areas不舒服**:
|
||||
|
||||
```markdown
|
||||
### 检查项目（5分钟）
|
||||
|
||||
ls 01_Projects/
|
||||
# ... 原来的3个问题 ...
|
||||
|
||||
### 🆕 快速检查Areas（2分钟）
|
||||
|
||||
ls 02_Areas/
|
||||
# 对每个Area问：
|
||||
# - 这周有活动吗？
|
||||
# - 是否仍然需要？
|
||||
```
|
||||
|
||||
**时间**: 增加2分钟，总计17分钟
|
||||
|
||||
---
|
||||
|
||||
### 微调2: 保留详细的完成项目记录
|
||||
|
||||
**如果你想留下项目完成的历史**:
|
||||
|
||||
```markdown
|
||||
### 检查项目（5分钟）
|
||||
|
||||
# ... 原来的步骤 ...
|
||||
|
||||
# 完成的项目
|
||||
mv "01_Projects/[项目名]" "04_Archive/Projects/[项目名]"
|
||||
|
||||
# 在Archive里写个简短总结
|
||||
echo "完成于: 2026-01-15" >> "04_Archive/Projects/[项目名]/README.md"
|
||||
```
|
||||
|
||||
**时间**: 多5秒，值得
|
||||
|
||||
---
|
||||
|
||||
### 微调3: 月度深度审查
|
||||
|
||||
**如果你想保留原来的详细评估**:
|
||||
|
||||
```markdown
|
||||
# 极简版本
|
||||
每周: 15分钟（清理 + 项目 + 文件）
|
||||
|
||||
# 月度：第一个周日
|
||||
额外30分钟做深度审查
|
||||
- 详细评估每个项目
|
||||
- 检查Resources的质量
|
||||
- 梳理Areas的关系
|
||||
```
|
||||
|
||||
**总时间**: 周间15分钟 + 月间30分钟 = 平衡
|
||||
|
||||
---
|
||||
|
||||
## 💡 如何决定取舍？
|
||||
|
||||
### 保留原有的哪些检查？
|
||||
|
||||
**YES 保留**:
|
||||
```
|
||||
"这个检查能防止问题吗？"
|
||||
"我经常用这个信息吗？"
|
||||
"失去这个我会后悔吗？"
|
||||
```
|
||||
|
||||
**NO 删除**:
|
||||
```
|
||||
"这是自动化的（如果文件没被用，自然就没用了）"
|
||||
"我很少参考这个数据"
|
||||
"做这个很费时，很少改变"
|
||||
```
|
||||
|
||||
### 具体例子
|
||||
|
||||
| 检查项 | 保留? | 理由 |
|
||||
|--------|------|------|
|
||||
| Inbox计数 | ✅ YES | 防止堆积 |
|
||||
| 项目状态 | ✅ YES | 知道现在的情况 |
|
||||
| 孤立文件检查 | ❌ NO | 可以目测，自动过期 |
|
||||
| Area健康度评分 | ❌ NO | 主观，费时 |
|
||||
| Resources质量标记 | ❌ NO | 自然淘汰就行 |
|
||||
| 每周Commit | ✅ YES | 数据安全 |
|
||||
|
||||
---
|
||||
|
||||
## 📋 第1个月后的检查
|
||||
|
||||
**完成第1个月后，问自己**:
|
||||
|
||||
1. **时间**:
|
||||
- [ ] 每周省了多少时间？
|
||||
- [ ] 这些时间用来干什么了？
|
||||
|
||||
2. **质量**:
|
||||
- [ ] Inbox是否更干净？
|
||||
- [ ] 项目跟踪是否更清晰？
|
||||
- [ ] 有没有遗漏重要的东西？
|
||||
|
||||
3. **可持续性**:
|
||||
- [ ] 能坚持做吗？
|
||||
- [ ] 有没有遗忘的步骤？
|
||||
- [ ] 工作流是否自然流畅？
|
||||
|
||||
4. **下一步**:
|
||||
- [ ] 保持这样
|
||||
- [ ] 调整某些步骤
|
||||
- [ ] 切回原版本
|
||||
|
||||
---
|
||||
|
||||
## ⚡ 快速开始（如果很急）
|
||||
|
||||
**不想4周过渡，想立即简化？**
|
||||
|
||||
### 最小改变方案
|
||||
|
||||
```bash
|
||||
# 1. 今天
|
||||
- 读一遍 ULTRA_SIMPLE_WORKFLOW.md（15分钟）
|
||||
- 试着按极简版本做一遍（不需要真的执行）
|
||||
|
||||
# 2. 这周六
|
||||
- 按极简版本做完整的Weekly Review
|
||||
- 如果成功，下周继续
|
||||
|
||||
# 3. 下周一
|
||||
- 完全切换到极简版本
|
||||
```
|
||||
|
||||
**风险**: ⚠️ 如果不适应，要切回原版本
|
||||
**好处**: ⏱️ 不用等4周，立即获得时间
|
||||
|
||||
---
|
||||
|
||||
## 🚨 遇到问题怎么办？
|
||||
|
||||
### "我用极简版本，结果发现遗漏了什么"
|
||||
|
||||
```
|
||||
→ 加回来就行
|
||||
→ 不需要全部用原版本
|
||||
→ 就加一个检查项
|
||||
```
|
||||
|
||||
### "极简版本太简单了，不放心"
|
||||
|
||||
```
|
||||
→ 保留原版本作为参考
|
||||
→ 月度做一次完整审查
|
||||
→ 这样既快又安全
|
||||
```
|
||||
|
||||
### "我喜欢详细检查，不想简化"
|
||||
|
||||
```
|
||||
→ 没问题，保持原有方式
|
||||
→ 这个简化版本是选项，不是强制
|
||||
→ 有人喜欢详细，有人喜欢快速
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ✅ 成功标志
|
||||
|
||||
**你知道过渡成功了，当：**
|
||||
|
||||
- ✅ Weekly Review从30分钟变成15分钟
|
||||
- ✅ 你能凭记忆完成所有步骤（不查笔记）
|
||||
- ✅ Inbox每周都清空
|
||||
- ✅ 项目进度清晰明了
|
||||
- ✅ 你不再感到"系统太复杂"
|
||||
- ✅ 你有更多时间做真正的工作
|
||||
- ✅ 你愿意每周坚持做这个流程
|
||||
|
||||
---
|
||||
|
||||
## 📞 需要帮助？
|
||||
|
||||
**如果过渡期间有问题**：
|
||||
|
||||
1. 查看 `ULTRA_SIMPLE_WORKFLOW.md` - 最基础的版本
|
||||
2. 查看 `QUICK_REFERENCE.md` - 快速命令
|
||||
3. 查看 `TROUBLESHOOTING.md` - 常见问题
|
||||
4. 保留原有文档 - 随时可以查阅
|
||||
|
||||
---
|
||||
|
||||
**准备好了吗？从阅读 `ULTRA_SIMPLE_WORKFLOW.md` 开始！**
|
||||
|
||||
---
|
||||
|
||||
*过渡指南: 2026-01-08*
|
||||
@@ -1,258 +0,0 @@
|
||||
# Claudian Token Optimization - Phase 1 Complete ✅
|
||||
|
||||
**Date**: 2026-01-08
|
||||
**Status**: Implementation Complete, Ready for User Testing
|
||||
**Expected Token Reduction**: 60-70%
|
||||
|
||||
---
|
||||
|
||||
## 🎯 What Was Accomplished
|
||||
|
||||
### Phase 1: Quick Wins - All Complete
|
||||
|
||||
✅ **System Prompt Compression** (50% reduction)
|
||||
- Reduced base prompt from ~2,400 → ~1,200 tokens
|
||||
- Compressed verbose sections without losing functionality
|
||||
- Removed redundant explanations
|
||||
|
||||
✅ **History Windowing** (Major reduction for long conversations)
|
||||
- Limited history to 15 most recent messages + first message
|
||||
- Prevents unbounded token growth
|
||||
- 30 msg conversation: 18,000 → 6,500 tokens (64% reduction)
|
||||
- 100 msg conversation: 55,000 → 8,000 tokens (85% reduction)
|
||||
|
||||
✅ **Tool Result Truncation** (300-500 token savings)
|
||||
- Reduced from 800 → 300 characters max
|
||||
|
||||
✅ **Optional Sections Disabled** (600-800 token savings)
|
||||
- Image instructions commented out
|
||||
- Editor context instructions commented out
|
||||
|
||||
---
|
||||
|
||||
## 📊 Expected Results
|
||||
|
||||
### Token Usage (Per Request)
|
||||
|
||||
| Conversation Length | Before | After | Reduction |
|
||||
|-------------------|--------|-------|-----------|
|
||||
| 5 messages | ~3,500 | ~1,800 | 49% |
|
||||
| 30 messages (session break) | ~18,000 | ~6,500 | 64% |
|
||||
| 100 messages (session break) | ~55,000 | ~8,000 | 85% |
|
||||
|
||||
### System Prompt Breakdown
|
||||
|
||||
| Component | Before | After | Saved |
|
||||
|-----------|--------|-------|-------|
|
||||
| Identity & Role | ~200 | ~50 | 75% |
|
||||
| Path Rules | ~150 | ~50 | 67% |
|
||||
| Tool Guidelines | ~600 | ~200 | 67% |
|
||||
| Message Format | ~120 | ~40 | 67% |
|
||||
| Obsidian Context | ~100 | ~30 | 70% |
|
||||
| Image Instructions | ~400 | 0 | 100% |
|
||||
| Editor Instructions | ~150 | 0 | 100% |
|
||||
| **Total** | **~2,400** | **~1,200** | **50%** |
|
||||
|
||||
---
|
||||
|
||||
## 🔧 Technical Changes
|
||||
|
||||
### Files Modified
|
||||
|
||||
1. **`.obsidian/plugins/claudian/main.js`**
|
||||
- Line 23302-23306: Compressed Identity & Role
|
||||
- Line 23308-23310: Compressed Path Rules
|
||||
- Line 23312-23319: Compressed Message Format & Obsidian Context
|
||||
- Line 23321-23328: Compressed Tool Guidelines
|
||||
- Line 22465-22476: Added history windowing logic
|
||||
- Line 22453: Changed tool result max length
|
||||
- Line 23474: Commented out image instructions
|
||||
- Line 23480-23482: Commented out editor context
|
||||
|
||||
2. **`.obsidian/plugins/claudian/main.js.backup`**
|
||||
- Original file backed up for rollback
|
||||
|
||||
### Code Changes Summary
|
||||
|
||||
**buildContextFromHistory()** - History Windowing:
|
||||
```javascript
|
||||
// NEW: Windowing logic
|
||||
const maxMessages = 15;
|
||||
const truncated = messages.length > maxMessages;
|
||||
const recentMessages = truncated ? messages.slice(-maxMessages) : messages;
|
||||
const messagesToProcess = truncated && messages.length > 0
|
||||
? [messages[0], ...recentMessages] // Keep first + recent
|
||||
: recentMessages;
|
||||
|
||||
// Add truncation notice
|
||||
if (truncated) {
|
||||
const skipped = messages.length - maxMessages - 1;
|
||||
parts.push(`[${skipped} earlier messages omitted]`);
|
||||
}
|
||||
```
|
||||
|
||||
**truncateToolResult()** - Aggressive Truncation:
|
||||
```javascript
|
||||
// Changed from 800 to 300
|
||||
function truncateToolResult(result, maxLength = 300) {
|
||||
```
|
||||
|
||||
**buildSystemPrompt()** - Disable Optional Sections:
|
||||
```javascript
|
||||
// Commented out
|
||||
// prompt += getImageInstructions(settings.mediaFolder || "");
|
||||
// if (settings.hasEditorContext) {
|
||||
// prompt += getEditorContextInstructions();
|
||||
// }
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ✅ Validation
|
||||
|
||||
### Syntax Check
|
||||
- ✅ JavaScript syntax validated (no errors)
|
||||
- ✅ File sizes match (1.4MB both files)
|
||||
- ✅ Backup created successfully
|
||||
- ✅ All functions properly modified
|
||||
|
||||
### Backwards Compatibility
|
||||
- ✅ JSONL conversation format unchanged
|
||||
- ✅ Session management logic preserved
|
||||
- ✅ Message storage format unchanged
|
||||
- ✅ Plugin settings structure unchanged
|
||||
|
||||
---
|
||||
|
||||
## 🧪 Next Step: User Testing
|
||||
|
||||
**YOU NEED TO DO THIS**:
|
||||
|
||||
1. **Reload Plugin in Obsidian**:
|
||||
- Settings → Community Plugins
|
||||
- Disable Claudian
|
||||
- Enable Claudian
|
||||
|
||||
2. **Basic Test**:
|
||||
- Start new conversation
|
||||
- Send a message: "List files in vault root"
|
||||
- Verify it responds correctly
|
||||
|
||||
3. **Check Token Usage**:
|
||||
- Press Ctrl+Shift+I (open DevTools)
|
||||
- Go to Console tab
|
||||
- Send a message
|
||||
- Look for token usage info
|
||||
|
||||
4. **Test Existing Conversation**:
|
||||
- Open a conversation with 20+ messages
|
||||
- Send a new message
|
||||
- Verify response quality
|
||||
|
||||
**Testing Guide**: See `06_Metadata/claudian-token-optimization-testing.md` for detailed testing instructions
|
||||
|
||||
---
|
||||
|
||||
## 🔄 Rollback (If Needed)
|
||||
|
||||
If anything breaks:
|
||||
|
||||
```bash
|
||||
cp .obsidian/plugins/claudian/main.js.backup .obsidian/plugins/claudian/main.js
|
||||
```
|
||||
|
||||
Then reload plugin in Obsidian (Disable → Enable)
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Success Criteria
|
||||
|
||||
### Must Work
|
||||
- [ ] Plugin loads without errors
|
||||
- [ ] Can send/receive messages
|
||||
- [ ] File operations work (Read, Write, Edit)
|
||||
- [ ] Existing conversations load
|
||||
- [ ] Token usage reduced (visible in console)
|
||||
|
||||
### Quality Check
|
||||
- [ ] Response quality remains good
|
||||
- [ ] Understands Obsidian concepts (wiki-links, paths)
|
||||
- [ ] Tool calls execute correctly
|
||||
|
||||
### Acceptable Trade-offs
|
||||
- May not remember context from messages 16+ back
|
||||
- Less verbose explanations
|
||||
- More concise responses
|
||||
|
||||
---
|
||||
|
||||
## 📈 Phase 2 Preview (After Testing)
|
||||
|
||||
If Phase 1 works well, we can add:
|
||||
|
||||
### User Settings
|
||||
- Configurable history window (10-30 messages)
|
||||
- Tool result max length slider
|
||||
- Toggle image/editor instructions on/off
|
||||
|
||||
### Smart Features
|
||||
- Preserve important messages (with tool calls)
|
||||
- Token usage warnings at 50%/80%
|
||||
- Visual token budget display
|
||||
|
||||
### UI Enhancements
|
||||
- Token usage bar in header
|
||||
- Breakdown display: System | History | Current
|
||||
- "Compact conversation" button
|
||||
|
||||
---
|
||||
|
||||
## 📝 Timeline
|
||||
|
||||
**Week 1 - Phase 1** ✅ Complete
|
||||
- Day 1: Backup + compress system prompt ✅
|
||||
- Day 2: History windowing + tool truncation ✅
|
||||
- Day 3: Remove conditionals + testing 🔄 **← YOU ARE HERE**
|
||||
- Day 4-5: Monitor usage, adjust if needed
|
||||
|
||||
**Week 2 - Phase 2** (if Phase 1 successful)
|
||||
- Review Phase 1 results
|
||||
- Design settings UI
|
||||
- Implement user controls
|
||||
|
||||
**Week 3+** (optional)
|
||||
- Advanced features as needed
|
||||
- Token counting
|
||||
- Conversation compacting
|
||||
|
||||
---
|
||||
|
||||
## 🎉 Summary
|
||||
|
||||
**What Changed**: Aggressively optimized Claudian's token usage through prompt compression and history windowing
|
||||
|
||||
**Impact**: 60-70% reduction in token usage for typical conversations
|
||||
|
||||
**Risk**: Low - all changes are backwards compatible, full backup available
|
||||
|
||||
**Next Action**: **YOU** need to test by reloading the plugin in Obsidian
|
||||
|
||||
**Expected Time to Test**: 10-15 minutes
|
||||
|
||||
**Documentation**:
|
||||
- Testing guide: `06_Metadata/claudian-token-optimization-testing.md`
|
||||
- This summary: `06_Metadata/claudian-phase1-complete.md`
|
||||
|
||||
---
|
||||
|
||||
## ❓ Questions or Issues?
|
||||
|
||||
If you encounter problems:
|
||||
1. Check the testing guide for troubleshooting
|
||||
2. Try the rollback procedure
|
||||
3. Report specific errors with console output
|
||||
4. We can adjust specific settings (window size, truncation length, etc.)
|
||||
|
||||
---
|
||||
|
||||
**Ready to test!** 🚀
|
||||
@@ -1,343 +0,0 @@
|
||||
# Claudian Token Optimization - Testing Guide
|
||||
|
||||
## Implementation Summary
|
||||
|
||||
**Date**: 2026-01-08
|
||||
**Phase**: Phase 1 - Quick Wins
|
||||
**Status**: ✅ Code changes completed, awaiting user testing
|
||||
|
||||
---
|
||||
|
||||
## Changes Made
|
||||
|
||||
### 1. System Prompt Compression (~800 tokens saved)
|
||||
|
||||
| Section | Before | After | Savings |
|
||||
|---------|--------|-------|---------|
|
||||
| Identity & Role | 7 lines verbose | 2 lines concise | ~150 tokens |
|
||||
| Path Rules | 9 lines with examples | 1 line | ~100 tokens |
|
||||
| Message Format | 14 lines with explanations | 3 lines examples only | ~80 tokens |
|
||||
| Obsidian Context | 7 lines detailed | 2 bullet points | ~70 tokens |
|
||||
| Tool Guidelines | 95 lines verbose | 6 bullet points | ~400 tokens |
|
||||
|
||||
**Total System Prompt**: Reduced from ~2,400 tokens → ~1,200 tokens (50% reduction)
|
||||
|
||||
### 2. History Windowing (10,000-25,000 tokens saved)
|
||||
|
||||
**Location**: `buildContextFromHistory()` function (line 22465)
|
||||
|
||||
**Logic**:
|
||||
- Limit to **15 most recent messages**
|
||||
- Always preserve **first message** (context establishment)
|
||||
- Add truncation notice when messages omitted
|
||||
|
||||
**Example**:
|
||||
```
|
||||
100 message conversation:
|
||||
Before: All 100 messages sent (~40,000 tokens)
|
||||
After: First + last 15 messages (16 total, ~6,500 tokens)
|
||||
Savings: 33,500 tokens (84% reduction)
|
||||
```
|
||||
|
||||
### 3. Tool Result Truncation (300-500 tokens saved)
|
||||
|
||||
**Location**: `truncateToolResult()` function (line 22453)
|
||||
|
||||
**Change**: Max length 800 → 300 characters
|
||||
|
||||
**Impact**: Tool results in history rebuilds are more aggressive truncated
|
||||
|
||||
### 4. Optional Sections Removed (600-800 tokens saved)
|
||||
|
||||
**Location**: `buildSystemPrompt()` function (line 23471)
|
||||
|
||||
**Commented out**:
|
||||
- Image instructions (~400 tokens) - line 23474
|
||||
- Editor context instructions (~150 tokens) - lines 23480-23482
|
||||
|
||||
---
|
||||
|
||||
## Testing Instructions
|
||||
|
||||
### Step 1: Reload Plugin in Obsidian
|
||||
|
||||
1. Open Obsidian
|
||||
2. Navigate to **Settings → Community Plugins**
|
||||
3. Find **Claudian** plugin
|
||||
4. Click **Disable** (wait 2-3 seconds)
|
||||
5. Click **Enable**
|
||||
6. Close Settings
|
||||
|
||||
**Expected**: Plugin enables without errors
|
||||
|
||||
### Step 2: Basic Functionality Test
|
||||
|
||||
**Test 1: New Conversation**
|
||||
1. Start a new Claudian conversation
|
||||
2. Send a simple message: "List files in the vault root"
|
||||
3. Verify Claudian responds normally
|
||||
|
||||
**Expected**: Response should be coherent and functional
|
||||
|
||||
**Test 2: File Operations**
|
||||
1. Ask: "Read the file 00_Inbox/2026-01-07.md"
|
||||
2. Verify file is read correctly
|
||||
3. Ask: "What's in this note?"
|
||||
|
||||
**Expected**: Claudian can read files and understand content
|
||||
|
||||
**Test 3: Existing Conversation**
|
||||
1. Open an existing conversation (preferably 20+ messages)
|
||||
2. Send a new message
|
||||
3. Verify response is coherent
|
||||
|
||||
**Expected**: Plugin handles existing conversations correctly
|
||||
|
||||
### Step 3: Token Usage Verification
|
||||
|
||||
**Check Console for Token Info**:
|
||||
1. Press **Ctrl+Shift+I** (or Cmd+Option+I on Mac) to open DevTools
|
||||
2. Click **Console** tab
|
||||
3. Send a message in Claudian
|
||||
4. Look for token usage info in console output
|
||||
|
||||
**What to Look For**:
|
||||
- `inputTokens`: Should be significantly lower
|
||||
- `contextTokens`: Total tokens used
|
||||
- Compare with previous conversations (if you remember typical values)
|
||||
|
||||
**Expected Reductions**:
|
||||
- Short conversations (5 msgs): ~1,800 tokens total
|
||||
- Medium conversations (20-30 msgs): ~6,500 tokens total
|
||||
- Long conversations (50+ msgs): ~8,000-10,000 tokens total
|
||||
|
||||
### Step 4: Quality Checks
|
||||
|
||||
**Test Understanding of Obsidian Context**:
|
||||
1. Ask: "Create a note in 00_Inbox with today's date"
|
||||
2. Ask: "Add a wiki-link to another note"
|
||||
3. Verify Claudian still understands Obsidian concepts
|
||||
|
||||
**Expected**: Should still understand:
|
||||
- Markdown formatting
|
||||
- Wiki-links [[note]]
|
||||
- Vault structure
|
||||
- Relative paths
|
||||
|
||||
**Test Tool Usage**:
|
||||
1. Ask: "Find all markdown files with the word 'TODO'"
|
||||
2. Ask: "Read the first result"
|
||||
3. Ask: "Update it to remove the TODO"
|
||||
|
||||
**Expected**: Should correctly use Read, Grep, Edit tools
|
||||
|
||||
### Step 5: Edge Cases
|
||||
|
||||
**Test 1: Long Conversation with Session Break**
|
||||
1. Open a conversation with 30+ messages
|
||||
2. Send a message that requires context from early messages
|
||||
3. Observe if Claudian maintains enough context
|
||||
|
||||
**Expected**: May not remember details from messages 16-29 (that were windowed out), but should handle gracefully with truncation notice
|
||||
|
||||
**Test 2: Current Note Context**
|
||||
1. Open a note in Obsidian
|
||||
2. Open Claudian sidebar
|
||||
3. Send a message referencing "this note"
|
||||
|
||||
**Expected**: Should still understand current note context
|
||||
|
||||
---
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### ✅ Must Pass
|
||||
- [ ] Plugin loads without errors
|
||||
- [ ] Can start new conversations
|
||||
- [ ] Can send/receive messages
|
||||
- [ ] File operations work (Read, Write, Edit)
|
||||
- [ ] Tool calls execute correctly
|
||||
- [ ] Existing conversations load properly
|
||||
- [ ] Token usage is reduced (check console)
|
||||
|
||||
### ✅ Should Pass
|
||||
- [ ] Response quality remains high
|
||||
- [ ] Understands Obsidian concepts
|
||||
- [ ] Relative paths work correctly
|
||||
- [ ] No functionality lost
|
||||
|
||||
### ⚠️ Acceptable Trade-offs
|
||||
- [ ] May forget context from messages 16+ back (windowed out)
|
||||
- [ ] Less verbose explanations
|
||||
- [ ] Slightly less hand-holding in responses
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Issue: Plugin Won't Load
|
||||
|
||||
**Symptoms**: Error on enable, plugin stays disabled
|
||||
|
||||
**Fix**:
|
||||
```bash
|
||||
# Restore backup
|
||||
cd /path/to/vault
|
||||
cp .obsidian/plugins/claudian/main.js.backup .obsidian/plugins/claudian/main.js
|
||||
```
|
||||
Then reload Obsidian
|
||||
|
||||
### Issue: Errors in Console
|
||||
|
||||
**Symptoms**: JavaScript errors in console after sending message
|
||||
|
||||
**What to do**:
|
||||
1. Copy the full error message
|
||||
2. Check which function is failing
|
||||
3. Restore backup if critical
|
||||
|
||||
### Issue: Poor Response Quality
|
||||
|
||||
**Symptoms**: Claudian doesn't understand Obsidian concepts, paths are wrong
|
||||
|
||||
**Possible causes**:
|
||||
- System prompt too compressed
|
||||
- Missing essential instructions
|
||||
|
||||
**Fix**: Can restore specific sections (e.g., uncomment image instructions if needed)
|
||||
|
||||
### Issue: Still Using Too Many Tokens
|
||||
|
||||
**Symptoms**: Token usage not significantly reduced
|
||||
|
||||
**Check**:
|
||||
1. Is session resumption working? (Should use persistent sessions normally)
|
||||
2. Are you testing with session breaks? (History windowing only applies when session breaks)
|
||||
3. Check if custom instructions in settings add lots of tokens
|
||||
|
||||
---
|
||||
|
||||
## Rollback Procedure
|
||||
|
||||
If anything breaks:
|
||||
|
||||
1. **Full Rollback**:
|
||||
```bash
|
||||
cp .obsidian/plugins/claudian/main.js.backup .obsidian/plugins/claudian/main.js
|
||||
```
|
||||
|
||||
2. **Reload Plugin**:
|
||||
- Settings → Community Plugins
|
||||
- Disable Claudian
|
||||
- Enable Claudian
|
||||
|
||||
3. **Verify**: Test that original version works
|
||||
|
||||
---
|
||||
|
||||
## Measuring Token Reduction
|
||||
|
||||
### Before Optimization (Typical Values)
|
||||
|
||||
**System Prompt**: ~3,200-6,500 tokens
|
||||
**History (30 msg conversation with session break)**: ~15,000-18,000 tokens
|
||||
**Total**: ~18,000-24,000 tokens per request
|
||||
|
||||
### After Optimization (Expected Values)
|
||||
|
||||
**System Prompt**: ~1,600-2,000 tokens
|
||||
**History (30 msg conversation with session break)**: ~6,000-8,000 tokens
|
||||
**Total**: ~7,600-10,000 tokens per request
|
||||
|
||||
**Overall Reduction**: ~60-70% for medium/long conversations
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 Preview (Future Enhancements)
|
||||
|
||||
If Phase 1 is successful, Phase 2 will add:
|
||||
|
||||
1. **User Settings**:
|
||||
- Configurable history window size (15-30 messages)
|
||||
- Tool result max length setting
|
||||
- Toggle image/editor instructions
|
||||
|
||||
2. **Smart Message Selection**:
|
||||
- Preserve messages with tool calls
|
||||
- Preserve longer/important messages
|
||||
- Dynamic window sizing
|
||||
|
||||
3. **Token Warnings**:
|
||||
- Visual warning at 50% context usage
|
||||
- Auto-suggest starting new conversation at 80%
|
||||
|
||||
4. **Token Usage UI**:
|
||||
- Show breakdown: System | History | Current
|
||||
- Display in conversation header
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- All changes are backwards compatible
|
||||
- JSONL conversation files unchanged
|
||||
- Session management logic unchanged
|
||||
- Can selectively restore sections if needed
|
||||
- Backup file preserved at: `.obsidian/plugins/claudian/main.js.backup`
|
||||
|
||||
---
|
||||
|
||||
## Testing Checklist
|
||||
|
||||
Print this section and check off as you test:
|
||||
|
||||
```
|
||||
Basic Tests:
|
||||
[ ] Plugin loads without errors
|
||||
[ ] New conversation works
|
||||
[ ] Can read files
|
||||
[ ] Can write files
|
||||
[ ] Existing conversation loads
|
||||
[ ] Token usage reduced (check console)
|
||||
|
||||
Quality Tests:
|
||||
[ ] Understands Markdown
|
||||
[ ] Understands Wiki-links
|
||||
[ ] Uses relative paths correctly
|
||||
[ ] Tool calls work
|
||||
[ ] Response quality good
|
||||
|
||||
Edge Cases:
|
||||
[ ] Long conversation (30+ msgs)
|
||||
[ ] Session break handling
|
||||
[ ] Current note context
|
||||
[ ] File operations in subfolders
|
||||
|
||||
If all checked: ✅ Phase 1 Complete!
|
||||
If issues found: Document below and consider rollback/adjustments
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Feedback Section
|
||||
|
||||
**Date Tested**: _____________
|
||||
|
||||
**Token Reduction Observed**: _______% (compare console before/after)
|
||||
|
||||
**Issues Found**:
|
||||
-
|
||||
-
|
||||
-
|
||||
|
||||
**Quality Assessment**:
|
||||
- Response coherence: ___/10
|
||||
- Obsidian understanding: ___/10
|
||||
- Tool usage: ___/10
|
||||
- Overall satisfaction: ___/10
|
||||
|
||||
**Recommendation**:
|
||||
- [ ] Keep Phase 1 changes, proceed to Phase 2
|
||||
- [ ] Keep changes, adjust window size to: ___
|
||||
- [ ] Restore specific section: ____________
|
||||
- [ ] Full rollback needed
|
||||
Reference in New Issue
Block a user