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
+2346
-1309
File diff suppressed because one or more lines are too long
+127
-97
@@ -1,97 +1,11 @@
|
||||
/* src/styles.scss */
|
||||
.properties-field > .setting-item-info {
|
||||
flex: 0;
|
||||
margin: 0;
|
||||
padding: var(--size-4-1) var(--size-4-2);
|
||||
border: var(--input-border-width) solid var(--background-modifier-border);
|
||||
border-radius: var(--input-radius) 0 0 var(--input-radius);
|
||||
}
|
||||
.properties-field > .setting-item-control > input {
|
||||
width: 100%;
|
||||
border-radius: 0 var(--input-radius) var(--input-radius) 0;
|
||||
}
|
||||
.ac-settings-heading:not(:first-child) {
|
||||
margin-top: var(--size-4-10) !important;
|
||||
}
|
||||
.ac-settings-heading:has(.checkbox-container:not(.is-enabled)) {
|
||||
border-bottom-color: var(--background-modifier-border-hover);
|
||||
}
|
||||
.ac-settings-heading .setting-item-description {
|
||||
margin-inline-end: 20px;
|
||||
}
|
||||
.settings-header-children {
|
||||
transform-origin: top center;
|
||||
transform: scaleY(1);
|
||||
transition: transform 0.2s ease-in-out;
|
||||
}
|
||||
.settings-header-children details {
|
||||
flex-direction: column;
|
||||
align-items: initial;
|
||||
}
|
||||
.ac-settings-heading:has(.checkbox-container:not(.is-enabled)) + .settings-header-children {
|
||||
opacity: 0.5;
|
||||
pointer-events: none;
|
||||
height: 0;
|
||||
transform: scaleY(0);
|
||||
}
|
||||
details.setting-item[open] > summary {
|
||||
margin-bottom: 0.75em;
|
||||
}
|
||||
details.setting-item > *:not(summary) {
|
||||
padding-left: 1em;
|
||||
border-left: 1px solid var(--color-accent);
|
||||
}
|
||||
.kofi-banner {
|
||||
position: relative;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
padding: var(--size-4-3);
|
||||
background-color: var(--background-secondary);
|
||||
border: 1px solid var(--divider-color);
|
||||
border-radius: var(--radius-s);
|
||||
}
|
||||
.kofi-banner h1 {
|
||||
margin: 0;
|
||||
margin-bottom: 10px;
|
||||
font-size: var(--font-ui-large);
|
||||
font-weight: 600;
|
||||
}
|
||||
.kofi-banner .progress-container {
|
||||
display: flex;
|
||||
flex-direction: row;
|
||||
align-items: center;
|
||||
justify-items: center;
|
||||
}
|
||||
.kofi-banner .progress-container progress {
|
||||
background: transparent;
|
||||
}
|
||||
.kofi-banner .progress-container progress::-webkit-progress-bar {
|
||||
background-color: var(--background-modifier-border);
|
||||
border-radius: var(--input-radius);
|
||||
}
|
||||
.kofi-banner .progress-container progress::-webkit-progress-value {
|
||||
background-color: var(--color-accent);
|
||||
border-radius: var(--input-radius);
|
||||
}
|
||||
.kofi-banner .progress-container .hourly-rate {
|
||||
margin-left: 10px;
|
||||
font-weight: 600;
|
||||
}
|
||||
.kofi-banner .ac-kofi-button {
|
||||
align-self: flex-end;
|
||||
width: min-content;
|
||||
height: min-content;
|
||||
line-height: 0;
|
||||
}
|
||||
.kofi-banner .ac-kofi-button img {
|
||||
min-width: 100px;
|
||||
width: 25%;
|
||||
max-width: 200px;
|
||||
}
|
||||
.canvas-wrapper > .document-search-container {
|
||||
transform: translateZ(0);
|
||||
margin: 0;
|
||||
}
|
||||
.document-search-count.is-hidden {
|
||||
display: none;
|
||||
}
|
||||
.canvas-wrapper:not(.mod-readonly) .show-while-readonly {
|
||||
display: none;
|
||||
}
|
||||
@@ -106,7 +20,7 @@ details.setting-item > *:not(summary) {
|
||||
.canvas-node[data-shape=document],
|
||||
.canvas-node[data-shape=predefined-process],
|
||||
.canvas-node[data-shape=diamond] {
|
||||
--border-color: rgb(var(--canvas-color));
|
||||
--border-color: var(--canvas-color);
|
||||
--border-width: 3px;
|
||||
--box-shadow: none;
|
||||
}
|
||||
@@ -129,7 +43,7 @@ details.setting-item > *:not(summary) {
|
||||
.is-themed.canvas-node[data-shape=document],
|
||||
.is-themed.canvas-node[data-shape=predefined-process],
|
||||
.is-themed.canvas-node[data-shape=diamond] {
|
||||
--border-color: rgba(var(--canvas-color), 0.7);
|
||||
--border-color: rgb(from var(--canvas-color) r g b / 0.7);
|
||||
}
|
||||
.reactive-node.is-themed.is-focused,
|
||||
.is-themed.is-focused.canvas-node[data-shape=database],
|
||||
@@ -141,7 +55,7 @@ details.setting-item > *:not(summary) {
|
||||
.is-themed.is-selected.canvas-node[data-shape=document],
|
||||
.is-themed.is-selected.canvas-node[data-shape=predefined-process],
|
||||
.is-themed.is-selected.canvas-node[data-shape=diamond] {
|
||||
--border-color: rgb(var(--canvas-color));
|
||||
--border-color: var(--canvas-color);
|
||||
--box-shadow: var(--shadow-border-themed);
|
||||
}
|
||||
.canvas-node[data-text-align=center] .markdown-preview-view {
|
||||
@@ -210,7 +124,7 @@ details.setting-item > *:not(summary) {
|
||||
transform: skewX(-20deg);
|
||||
backface-visibility: hidden;
|
||||
}
|
||||
.canvas-node[data-shape=parallelogram] .canvas-node-container .canvas-node-content .markdown-embed-content {
|
||||
.canvas-node[data-shape=parallelogram] .canvas-node-container .canvas-node-content > .markdown-embed-content {
|
||||
transform: skewX(20deg);
|
||||
}
|
||||
.canvas-node[data-shape=circle] .canvas-node-container {
|
||||
@@ -293,7 +207,7 @@ details.setting-item > *:not(summary) {
|
||||
.canvas-node[data-shape=database].is-themed:not(:has(.embed-iframe)) .canvas-node-container,
|
||||
.canvas-node[data-shape=database].is-themed:not(:has(.embed-iframe))::after,
|
||||
.canvas-node[data-shape=database].is-themed:not(:has(.embed-iframe))::before {
|
||||
box-shadow: inset 0 0 0 1000px rgba(var(--canvas-color), 0.07) !important;
|
||||
box-shadow: inset 0 0 0 1000px rgb(from var(--canvas-color) r g b/0.07) !important;
|
||||
}
|
||||
.canvas-node[data-shape=database] .canvas-node-content:not(:has(.embed-iframe)) {
|
||||
transform: translateY(20px);
|
||||
@@ -354,14 +268,29 @@ details.setting-item > *:not(summary) {
|
||||
.canvas-edges [data-arrow=diamond-outline] polygon,
|
||||
.canvas-edges [data-arrow=circle-outline] polygon {
|
||||
fill: var(--canvas-background);
|
||||
stroke: rgb(var(--canvas-color));
|
||||
stroke: var(--canvas-color);
|
||||
stroke-width: calc(3px * var(--zoom-multiplier));
|
||||
}
|
||||
.canvas-edges [data-arrow=thin-triangle] polygon {
|
||||
fill: transparent;
|
||||
stroke: rgb(var(--canvas-color));
|
||||
stroke: var(--canvas-color);
|
||||
stroke-width: calc(4px * var(--zoom-multiplier));
|
||||
}
|
||||
.icon-modal-suggestion {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: var(--size-4-4);
|
||||
}
|
||||
.icon-modal-suggestion .icon-modal-suggestion-icon {
|
||||
line-height: 0;
|
||||
}
|
||||
.icon-modal-suggestion .icon-modal-suggestion-id {
|
||||
font-size: var(--font-ui-smaller);
|
||||
color: var(--text-muted);
|
||||
}
|
||||
.ac-pinned-pdf-page-embed {
|
||||
height: 100%;
|
||||
}
|
||||
.canvas.is-exporting {
|
||||
--zoom-multiplier: 1;
|
||||
}
|
||||
@@ -395,6 +324,76 @@ details.setting-item > *:not(summary) {
|
||||
.canvas-wrapper.mod-readonly[data-hide-background-grid-when-in-readonly=true] .canvas-background {
|
||||
visibility: hidden;
|
||||
}
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas {
|
||||
}
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas .el-p > p:has(> span.vertical-space) {
|
||||
margin-top: 0px;
|
||||
}
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas .el-p > p {
|
||||
margin-top: 0px;
|
||||
margin-bottom: 0px;
|
||||
}
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas :is(.el-ul, .el-ol) + .el-p > p:has(> span.vertical-space:first-child) {
|
||||
margin-top: 24px;
|
||||
}
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas ol::before {
|
||||
margin-left: -2px;
|
||||
}
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas ol {
|
||||
margin-top: 0px;
|
||||
margin-bottom: 0px;
|
||||
}
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas ul > li > ol > li {
|
||||
margin-left: 36px;
|
||||
}
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas ul::before {
|
||||
margin-left: -2px;
|
||||
}
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas ul {
|
||||
margin-top: 0px;
|
||||
margin-bottom: 0px;
|
||||
}
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas .el-ul > ul > li {
|
||||
margin-top: 0px;
|
||||
margin-bottom: 0px;
|
||||
}
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas ol > li > ul > li {
|
||||
margin-left: 36px;
|
||||
}
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas ul > li > .list-bullet {
|
||||
margin-top: 2px;
|
||||
}
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas .has-list-bullet .list-bullet::after {
|
||||
margin-left: -4px;
|
||||
margin-top: -3px;
|
||||
}
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas .el-h1 > h1,
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas .el-h2 > h2,
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas .el-h3 > h3,
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas .el-h4 > h4,
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas .el-h5 > h5,
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas .el-h6 > h6 {
|
||||
margin-top: 0px !important;
|
||||
margin-bottom: 0px !important;
|
||||
}
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas .markdown-preview-section > .markdown-preview-pusher + :is(.el-h2) > :is(h2),
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas .markdown-preview-section > .markdown-preview-pusher + :is(.el-h3) > :is(h3) {
|
||||
margin-top: 0px !important;
|
||||
}
|
||||
.canvas-wrapper[data-reading-mode-fix-enabled=true] .canvas .el-table {
|
||||
margin-top: 24px;
|
||||
}
|
||||
.canvas-node-iframe-body[data-reading-mode-fix-enabled=true] {
|
||||
}
|
||||
.canvas-node-iframe-body[data-reading-mode-fix-enabled=true] .markdown-source-view .cm-contentContainer > .cm-content.cm-lineWrapping > .cm-line {
|
||||
margin-right: -2px !important;
|
||||
}
|
||||
.canvas-node-iframe-body[data-reading-mode-fix-enabled=true] .mod-inside-iframe .HyperMD-header {
|
||||
padding-top: 0px !important;
|
||||
}
|
||||
.canvas-node-iframe-body[data-reading-mode-fix-enabled=true] .cm-formatting-list.cm-formatting-list-ul {
|
||||
margin-right: 7px;
|
||||
}
|
||||
.collapse-button {
|
||||
position: absolute;
|
||||
left: 0;
|
||||
@@ -404,7 +403,7 @@ details.setting-item > *:not(summary) {
|
||||
transform: translate(0, -100%) scale(var(--zoom-multiplier));
|
||||
border-radius: var(--radius-s);
|
||||
color: var(--text-muted);
|
||||
background-color: rgba(var(--canvas-color), 0.1);
|
||||
background-color: rgb(from var(--canvas-color) r g b/0.1);
|
||||
font-size: 1.5em;
|
||||
line-height: 1;
|
||||
pointer-events: initial;
|
||||
@@ -506,3 +505,34 @@ details.setting-item > *:not(summary) {
|
||||
.canvas-node-interaction-layer[data-is-from-portal=true] .canvas-node-resizer .canvas-node-connection-point {
|
||||
pointer-events: all;
|
||||
}
|
||||
.ac-card-embed {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
overflow: hidden;
|
||||
background-color: var(--background-primary);
|
||||
border: 1px solid var(--canvas-color);
|
||||
border-radius: var(--radius-m);
|
||||
box-shadow: var(--shadow-stationary);
|
||||
}
|
||||
.ac-card-embed.is-themed {
|
||||
background-color: rgb(from var(--canvas-color) r g b/0.07);
|
||||
border-color: rgb(from var(--canvas-color) r g b/0.7);
|
||||
box-shadow: inset 0 0 0 1px rgb(from var(--canvas-color) r g b/0.7), var(--shadow-stationary);
|
||||
}
|
||||
.ac-card-embed > .markdown-content {
|
||||
position: relative;
|
||||
overflow-y: auto;
|
||||
overflow-wrap: break-word;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
width: 100%;
|
||||
height: 100%;
|
||||
padding: 0 var(--size-4-4);
|
||||
font-size: var(--font-text-size);
|
||||
font-family: var(--font-text);
|
||||
line-height: var(--line-height-normal);
|
||||
color: var(--text-normal);
|
||||
user-select: text;
|
||||
-webkit-user-select: text;
|
||||
scrollbar-gutter: stable;
|
||||
}
|
||||
|
||||
Vendored
+4248
-2782
File diff suppressed because one or more lines are too long
Vendored
+1
-1
File diff suppressed because one or more lines are too long
+9
-9
File diff suppressed because one or more lines are too long
@@ -0,0 +1,19 @@
|
||||
.advanced-uri-data-section {
|
||||
display: flex;
|
||||
width: 100%;
|
||||
flex-direction: column;
|
||||
align-items: stretch;
|
||||
}
|
||||
|
||||
.advanced-uri-data-input {
|
||||
display: block;
|
||||
box-sizing: border-box;
|
||||
width: 100%;
|
||||
max-width: none;
|
||||
margin-bottom: var(--size-4-4);
|
||||
resize: vertical;
|
||||
}
|
||||
|
||||
.modal .advanced-uri-mode-option.setting-item:hover {
|
||||
background: var(--background-modifier-hover);
|
||||
}
|
||||
+14
-9
File diff suppressed because one or more lines are too long
+1
-1
File diff suppressed because one or more lines are too long
+147
-147
File diff suppressed because one or more lines are too long
+29493
-24179
File diff suppressed because one or more lines are too long
@@ -30,6 +30,7 @@ div.obsidian-local-rest-api-content pre {
|
||||
background-color: var(--background-modifier-cover);
|
||||
font-family: monospace;
|
||||
user-select: all;
|
||||
overflow-x: auto;
|
||||
}
|
||||
|
||||
div.obsidian-local-rest-api-content p {
|
||||
@@ -104,6 +105,13 @@ div.obsidian-local-rest-api-content div.certificate-regeneration-recommended {
|
||||
border: 2px solid #ffff00;
|
||||
}
|
||||
|
||||
/* Informational, not a warning: the certificate still works, an update exists. */
|
||||
div.obsidian-local-rest-api-content div.certificate-update-available {
|
||||
padding: 10px 20px;
|
||||
border: 1px solid var(--background-modifier-border);
|
||||
color: var(--text-muted);
|
||||
}
|
||||
|
||||
div.obsidian-local-rest-api-content table.api-urls tr {
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
+86
-78
File diff suppressed because one or more lines are too long
+1
-1
File diff suppressed because one or more lines are too long
Vendored
+61
-61
File diff suppressed because one or more lines are too long
Vendored
+200
-201
File diff suppressed because one or more lines are too long
+1
-1
File diff suppressed because one or more lines are too long
+12
-12
File diff suppressed because one or more lines are too long
@@ -30,6 +30,11 @@ textarea.templater-prompt-input:focus {
|
||||
|
||||
.templater-multisuggester-list {
|
||||
margin: 1.5em 0;
|
||||
|
||||
.templater-multisuggester-list-item {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
}
|
||||
}
|
||||
|
||||
.cm-s-obsidian .templater-command-bg {
|
||||
|
||||
@@ -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,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,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,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