39 lines
2.0 KiB
Markdown
39 lines
2.0 KiB
Markdown
|
# Repository Guidelines
|
||
|
|
|
||
|
|
## Project Structure & Module Organization
|
||
|
|
This repository is an Obsidian vault organized with the PARA method:
|
||
|
|
- `000-inbox/`: unprocessed notes and clippings
|
||
|
|
- `100-project/`: active projects (personal and work)
|
||
|
|
- `200-area/`: ongoing areas of responsibility
|
||
|
|
- `300-resources/`: reference material by topic
|
||
|
|
- `400-archive/`: completed/inactive items
|
||
|
|
- `Clippings/` and `ReadItLater Inbox/`: saved articles
|
||
|
|
|
||
|
|
Top-level date notes (for example `2025-12-29.md`) live at the root. Treat the vault as content, not an app project.
|
||
|
|
|
||
|
|
## Build, Test, and Development Commands
|
||
|
|
There is no build or test system. Use standard shell tools to inspect and edit Markdown files.
|
||
|
|
- Example: `rg "keyword" 200-area/` for fast search
|
||
|
|
|
||
|
|
## Writing Style & Naming Conventions
|
||
|
|
- Use Markdown for all notes. Keep headings short and sentence-case.
|
||
|
|
- Prefer ASCII characters unless the note already uses non-ASCII.
|
||
|
|
- Frontmatter keys should be consistent: `title`, `aliases`, `tags`, `created`, `updated`, `source`.
|
||
|
|
- Do not modify `.obsidian/` or `.smart-env/` unless explicitly requested.
|
||
|
|
|
||
|
|
## Content Safety & Refactor Rules
|
||
|
|
- Never delete information. If merging or replacing notes, move originals to `400-archive/` and leave a short stub linking to the new note.
|
||
|
|
- Keep changes incremental: one clear objective per batch.
|
||
|
|
- When moving/renaming, update affected wikilinks `[[...]]` across the vault.
|
||
|
|
|
||
|
|
## Testing Guidelines
|
||
|
|
No automated tests are configured. If you make large changes, run a link check if you have one locally, or do a targeted `rg` search to spot broken wikilinks.
|
||
|
|
|
||
|
|
## Commit & Pull Request Guidelines
|
||
|
|
Recent commits use short, descriptive summaries (for example: “Refactor Personal folder structure for improved organization”). If you add backup commits, follow the existing pattern `vault backup: YYYY-MM-DD HH:MM:SS`.
|
||
|
|
|
||
|
|
PRs should include:
|
||
|
|
- A brief description of what moved/changed and why
|
||
|
|
- A list of affected directories (for example `100-project/Personal/`)
|
||
|
|
- Any manual checks performed (link search, spot review)
|