obsidian-dev-skills 1.0.0

package/obsidian-ops/references/release-readiness.md

@@ -0,0 +1,210 @@
+<!--
+Source: Based on Obsidian Developer Policies, Theme Guidelines, and official release checklist
+Last synced: See sync-status.json for authoritative sync dates
+Update frequency: Check Obsidian Developer Policies and Theme Guidelines for updates
+-->
+
+# Release Readiness Checklist
+
+This document provides a comprehensive checklist to verify your theme is ready for release to the Obsidian community. Use this when preparing a release or when asked "is my theme ready for release?"
+
+**For AI Agents**: When a user asks about release readiness, run through this checklist systematically. Perform automated checks where possible, and ask the user interactively for items that require their input.
+
+## Quick Reference
+
+- **Developer Policies**: [Developer Policies](https://docs.obsidian.md/Developer+policies)
+- **Theme Guidelines**: [Theme Guidelines](https://docs.obsidian.md/Themes/Releasing/Theme+guidelines)
+- **Release Process**: See [versioning-releases.md](versioning-releases.md)
+
+## Automated Checks (AI Can Verify)
+
+These checks can be performed automatically by reading files and scanning code:
+
+### File Requirements
+
+- [ ] **`theme.css`** exists in project root (or compiled from SCSS/Sass)
+  - For themes with build tools: Check that `theme.css` is generated correctly
+  - For simple themes: Check that `theme.css` exists and is valid CSS
+- [ ] **`manifest.json`** exists in project root with valid JSON structure
+- [ ] **`LICENSE`** file exists in project root
+- [ ] **`README.md`** exists in project root
+
+### Manifest Validation
+
+- [ ] **Required fields present**: `name`, `version`, `minAppVersion`, `description`, `author`
+- [ ] **`name` format**: Should match the theme's display name
+- [ ] **`version` format**: Semantic Versioning (x.y.z, e.g., `"1.0.0"`)
+- [ ] **`minAppVersion`**: Set appropriately for CSS features used
+- [ ] **Optional fields** (if applicable): `authorUrl`, `fundingUrl`
+- [ ] **JSON syntax**: Valid JSON (proper quotes, commas, brackets)
+
+### Version Consistency
+
+- [ ] **GitHub release tag**: Matches `manifest.json` version exactly (no "v" prefix)
+  - If checking before release: Verify version format is ready
+  - If checking after release: Verify tag matches manifest version
+
+### CSS Quality Checks
+
+- [ ] **Valid CSS syntax**: No syntax errors in `theme.css`
+- [ ] **No tracking or analytics**: No external tracking scripts, analytics, or telemetry in CSS
+- [ ] **No remote resources**: No `@import` statements loading external stylesheets (unless explicitly disclosed)
+- [ ] **Browser compatibility**: CSS features used are compatible with Obsidian's browser targets (Chrome and iOS Safari)
+- [ ] **No obfuscated code**: CSS is readable and not minified/obfuscated (unless using build tools that minify for production)
+
+### README.md Content
+
+- [ ] **File exists**: `README.md` present in root
+- [ ] **Describes purpose**: Clear description of what the theme does and its design philosophy
+- [ ] **Usage instructions**: How to install and use the theme
+- [ ] **Screenshots**: Visual examples of the theme (recommended)
+- [ ] **Attribution**: If using third-party code or design elements, proper attribution included
+
+### LICENSE File
+
+- [ ] **File exists**: `LICENSE` file present in root
+- [ ] **License specified**: Clear license type (MIT, GPL, etc.)
+- [ ] **Third-party compliance**: If using code or design elements from other themes, verify license compatibility and attribution
+
+## Interactive Checks (AI Asks User)
+
+These checks require user input or confirmation:
+
+### Platform Testing
+
+- [ ] **Windows**: Theme tested and working on Windows
+- [ ] **macOS**: Theme tested and working on macOS
+- [ ] **Linux**: Theme tested and working on Linux
+- [ ] **Android**: Theme tested and working on Android (if applicable)
+- [ ] **iOS**: Theme tested and working on iOS (if applicable)
+
+**Note**: If user doesn't have access to all platforms, they should test on available platforms and note limitations.
+
+### Theme-Specific Testing
+
+- [ ] **Dark mode**: Theme includes dark mode styles and they work correctly
+- [ ] **Light mode**: Theme includes light mode styles and they work correctly (or theme is dark-only and this is documented)
+- [ ] **Mode switching**: Theme correctly switches between dark and light modes
+- [ ] **All Obsidian views**: Theme tested in:
+  - [ ] Editor (Live Preview, Source Mode, Reading Mode)
+  - [ ] File explorer
+  - [ ] Settings pages
+  - [ ] Command palette
+  - [ ] Graph view
+  - [ ] Canvas view (if applicable)
+  - [ ] Other views used by the theme
+
+### GitHub Release
+
+- [ ] **Release created**: GitHub release exists for the version
+- [ ] **Required files attached**: `theme.css` and `manifest.json` attached as **individual binary assets** (not just in source.zip)
+- [ ] **Release name matches version**: Release name/tag exactly matches `manifest.json` version (no "v" prefix)
+
+### Community Theme Registration
+
+- [ ] **`manifest.json` name matches `community-css-themes.json`**: The `name` in your `manifest.json` matches the `name` in the `community-css-themes.json` file (for themes already in the community catalog)
+
+### Documentation Quality
+
+- [ ] **README.md describes purpose**: Clear explanation of what the theme does and its design philosophy
+- [ ] **README.md provides usage instructions**: Step-by-step guide on how to install and use the theme
+- [ ] **Screenshots included**: Visual examples showing the theme in use (highly recommended)
+
+### Developer Policies Adherence
+
+- [ ] **Read Developer Policies**: User confirms they have read [Developer Policies](https://docs.obsidian.md/Developer+policies)
+- [ ] **No prohibited features**:
+  - [ ] No tracking or analytics
+  - [ ] No remote code execution
+  - [ ] No self-updating mechanisms
+- [ ] **Mandatory disclosures** (if applicable):
+  - [ ] Remote resources: Disclosed in README if using `@import` for external stylesheets
+  - [ ] Network usage: Disclosed in README and settings (if any)
+- [ ] **Licensing**: LICENSE file present and compliant with any third-party code/licenses
+
+### Theme Guidelines Adherence
+
+- [ ] **Read Theme Guidelines**: User confirms they have read [Theme Guidelines](https://docs.obsidian.md/Themes/Releasing/Theme+guidelines)
+- [ ] **CSS organization**: CSS is well-organized (logical structure, comments where helpful)
+- [ ] **Browser compatibility**: CSS features are compatible with Obsidian's browser targets
+- [ ] **Performance**: Theme doesn't cause significant performance issues
+- [ ] **Accessibility**: Theme maintains reasonable contrast ratios and readability
+
+### Third-Party Code
+
+- [ ] **License compliance**: All third-party code/licenses are compatible with your theme's license
+- [ ] **Attribution**: Proper attribution given in README.md for any code or design elements from other themes/projects
+- [ ] **License compatibility**: Your theme's license is compatible with any third-party code used
+
+## Developer Policies Summary
+
+For reference, key points from [Developer Policies](https://docs.obsidian.md/Developer+policies):
+
+### Prohibited
+
+- **Tracking or analytics**: No tracking scripts, analytics, or telemetry
+- **Remote code execution**: No fetching and executing remote scripts
+- **Self-updating**: No automatic code updates outside normal releases
+
+### Mandatory Disclosures
+
+If your theme requires any of the following, you **must** disclose it clearly:
+- Remote resources (external stylesheets via `@import`)
+- Network usage (if any)
+
+### Licensing
+
+- Include a LICENSE file
+- Respect licenses of any third-party code or design elements used
+- Provide proper attribution for third-party code or design elements
+
+## Theme Guidelines Summary
+
+For reference, key points from [Theme Guidelines](https://docs.obsidian.md/Themes/Releasing/Theme+guidelines):
+
+- **CSS organization**: Organize CSS into logical sections
+- **Browser compatibility**: Ensure CSS features work in Obsidian's browser targets (Chrome and iOS Safari)
+- **Performance**: Avoid CSS that causes performance issues
+- **Testing**: Test on all applicable platforms and in all Obsidian views
+- **Documentation**: Include clear README with screenshots
+
+## AI Agent Workflow
+
+When user asks "is my theme ready for release?" or similar:
+
+1. **Run automated checks**:
+   - Check file existence (`theme.css`, `manifest.json`, `LICENSE`, `README.md`)
+   - Validate `manifest.json` structure and required fields
+   - Check version format and consistency
+   - Scan CSS for prohibited patterns (tracking, remote imports, etc.)
+   - Verify README.md has basic content
+
+2. **Present interactive checklist**:
+   - Ask about platform testing (Windows, macOS, Linux, Android, iOS)
+   - Ask about theme-specific testing (dark/light mode, all Obsidian views)
+   - Ask about GitHub release status and file attachments
+   - Ask about community-css-themes.json name matching (if applicable)
+   - Ask about README.md quality (purpose, usage instructions, screenshots)
+   - Ask about Developer Policies adherence
+   - Ask about Theme Guidelines adherence
+   - Ask about third-party code license compliance and attribution
+
+3. **Report results**:
+   - Show pass/fail/warning status for each item
+   - Provide actionable guidance for any failures
+   - Summarize overall readiness status
+
+4. **Provide next steps**:
+   - If ready: Guide user through release process (see [versioning-releases.md](versioning-releases.md))
+   - If not ready: List specific items to address before release
+
+## Related Documentation
+
+- [versioning-releases.md](versioning-releases.md) - Release process and versioning
+- [security-privacy.md](security-privacy.md) - Security and privacy guidelines
+- [manifest.md](manifest.md) - Manifest requirements and validation
+- [testing.md](testing.md) - Testing procedures and platform testing
+- [ux-copy.md](ux-copy.md) - UI text conventions (for theme names and descriptions)
+- [build-workflow.md](build-workflow.md) - Build commands (if using build tools)
+- [performance.md](performance.md) - Performance optimization best practices
+

package/obsidian-ops/references/security-privacy.md

@@ -0,0 +1,61 @@
+<!--
+Source: Based on Obsidian Developer Policies and Guidelines
+Last synced: See sync-status.json for authoritative sync dates
+Update frequency: Check Obsidian Developer Policies for updates
+-->
+
+# Security, privacy, and compliance
+
+Follow Obsidian's **Developer Policies** (https://docs.obsidian.md/Developer+policies) and **Theme Guidelines** (https://docs.obsidian.md/Themes/Releasing/Theme+guidelines). See [release-readiness.md](release-readiness.md) for a comprehensive release checklist.
+
+## Developer Policies Requirements
+
+### Prohibited Practices
+
+- **Code obfuscation**: CSS must be readable and not minified/obfuscated
+- **Dynamic ads**: No dynamic advertising
+- **Client-side telemetry**: No hidden telemetry. If you collect optional analytics, require explicit opt-in and document clearly in `README.md`
+- **Self-updating mechanisms**: No automatic code updates outside of normal releases. Never execute remote code, fetch and eval scripts, or auto-update code
+
+### Mandatory Disclosures
+
+If your theme requires any of the following, you **must** disclose it clearly in `README.md`:
+
+- **Payments or subscriptions**: Clearly state if the theme requires payment
+- **User accounts**: Disclose if user accounts are required
+- **Network usage**: Disclose any API calls, external services, or network requests
+- **Files outside vault**: Disclose if the theme accesses files outside the Obsidian vault (rare for themes, but applicable if using any external resources)
+
+### Privacy and Security
+
+- Default to local/offline operation. Only make network requests when essential to the feature.
+- Minimize scope: read/write only what's necessary inside the vault. Do not access files outside the vault.
+- Clearly disclose any external services used, data sent, and risks.
+- Respect user privacy. Do not collect vault contents, filenames, or personal information unless absolutely necessary and explicitly consented.
+- Avoid deceptive patterns, ads, or spammy notifications.
+
+### Licensing
+
+- Include a LICENSE file in your project root
+- Respect licenses of any third-party code used
+- Provide proper attribution for third-party code in `README.md`
+- Ensure license compatibility between your theme's license and any third-party code licenses
+
+## Theme Guidelines
+
+- **CSS organization**: Organize CSS/SCSS into logical files/folders
+- **CSS variables**: Use consistent naming conventions for CSS variables
+- **Security**: Themes are CSS-only and have minimal security surface area
+
+## Implementation
+
+Themes are CSS-only and have minimal security surface area, but still follow privacy guidelines for any optional features.
+
+## Related Documentation
+
+- [release-readiness.md](release-readiness.md) - Comprehensive release checklist including policy adherence
+- [manifest.md](manifest.md) - Manifest requirements (includes security-related fields)
+- [Developer Policies](https://docs.obsidian.md/Developer+policies) - Official Obsidian Developer Policies
+- [Theme Guidelines](https://docs.obsidian.md/Themes/Releasing/Theme+guidelines) - Official Theme Guidelines
+
+

package/obsidian-ops/references/summarize-commands.md

@@ -0,0 +1,153 @@
+<!--
+Source: Project-specific workflow
+Last synced: See sync-status.json for authoritative sync dates
+Update frequency: Update as workflow evolves
+-->
+
+# Summarize Commands
+
+When the user requests "Summarize" or "Summarize for release", use these workflows to generate commit messages or release notes.
+
+## "Summarize" Command
+
+**Purpose**: Generate a succinct git commit message based on all changed files.
+
+**Workflow**:
+
+1. **Get all changed files**:
+   ```bash
+   git status
+   git diff --cached  # For staged changes
+   git diff           # For unstaged changes
+   ```
+
+2. **Read and analyze all changed files**:
+   - Look at the actual file contents, not just the chat history
+   - Understand what changed across all files
+   - Get the overall picture of the changes
+
+3. **Generate commit message** in this format:
+   ```
+   [Summary of changes]
+   - [more detailed item 1]
+   - [more detailed item 2]
+   - [more detailed item 3]
+   ```
+
+4. **Present as a code block** so the user can easily copy it:
+   ````
+   ```
+   [Summary of changes]
+   - [more detailed item 1]
+   - [more detailed item 2]
+   ```
+   ````
+
+**Important**:
+- Look at actual file changes, not just chat context
+- Be succinct but descriptive
+- Focus on what changed, not how it was changed
+- Use present tense (e.g., "Add feature" not "Added feature")
+- Group related changes together
+
+**Example**:
+```
+Reorganize agent instructions into structured directory
+- Split AGENTS.md into topic-based files in .agents/
+- Add build workflow documentation
+- Update ref-instructions with symlink strategy
+- Add summarize command workflows
+```
+
+## "Summarize for Release" Command
+
+**Purpose**: Generate markdown-formatted release notes for a GitHub release.
+
+**Workflow**:
+
+1. **Check the version**:
+   ```bash
+   # Check manifest.json for version
+   # Or check package.json
+   # Or ask the user if version is unclear
+   ```
+
+2. **Get all changes since last release**:
+   ```bash
+   git log --oneline  # See recent commits
+   git diff <last-release-tag>..HEAD  # See all changes
+   ```
+
+3. **Read and analyze all changed files**:
+   - Look at actual file contents and changes
+   - Understand the full scope of changes
+   - Categorize changes by type (Features, Fixes, Improvements, etc.)
+
+4. **Generate release notes** in markdown format:
+   ```markdown
+   ### Features
+   - [Feature description 1]
+   - [Feature description 2]
+
+   ### Fixes
+   - [Fix description 1]
+   - [Fix description 2]
+
+   ### Improvements
+   - [Improvement description 1]
+   ```
+
+5. **Present as a code block** with the version clearly indicated:
+   ````
+   ```markdown
+   ## Version X.Y.Z
+
+   ### Features
+   - [Feature description 1]
+   - [Feature description 2]
+
+   ### Fixes
+   - [Fix description 1]
+
+   ### Improvements
+   - [Improvement description 1]
+   ```
+   ````
+
+**Important**:
+- Start with `###` headings (third-level markdown)
+- Use bullet points under each heading
+- Be succinct and punchy
+- Focus on user-facing changes
+- Group logically (Features, Fixes, Breaking Changes, Improvements, etc.)
+- Include version number at the top
+- Look at actual changes, not just chat history
+
+**Example**:
+```markdown
+## Version 1.2.0
+
+### Features
+- Add structured .agents directory for better organization
+- Implement symlink strategy for reference repositories
+- Add build workflow automation
+
+### Improvements
+- Reorganize documentation into topic-based files
+- Update ref-instructions with Windows symlink guide
+- Add summarize command workflows
+
+### Fixes
+- Fix build command execution order
+- Update documentation paths
+```
+
+## Tips for Better Summaries
+
+- **Read the files**: Don't rely solely on chat history - actually read the changed files
+- **Understand context**: Look at related files to understand the full picture
+- **Be specific**: "Add build workflow" is better than "Update docs"
+- **Group logically**: Related changes should be grouped together
+- **User perspective**: Focus on what users/developers will notice
+- **Version awareness**: For releases, always check and include the version number
+