@ngockhoale/ukit 1.6.8 → 2.0.1

package/templates/.claude/skills/docs-manager/conventions-and-examples.md

@@ -0,0 +1,221 @@
+# Docs Manager — Code Conventions and Worked Examples
+
+## Documentation Structure
+
+Full `docs/` folder layout this skill expects:
+
+```
+docs/
+├── README.md                    # 🎯 BẮT ĐẦU TẠI ĐÂY - Navigation hub
+├── project.md                   # 📋 Project overview
+├── memory.md                    # 🧠 Decisions & context log
+│
+├── architecture/                # 🏗️ System design
+│   ├── overview.md             # Architecture tổng quan
+│   ├── tech-stack.md           # Technologies sử dụng
+│   ├── data-model.md           # Database schema
+│   ├── api-design.md           # API specifications
+│   └── deployment.md           # Infrastructure
+│
+├── agents/                      # 🤖 Multi-agent coordination
+│   ├── agent-roles.md          # Vai trò từng agent
+│   ├── orchestration.md        # Flow điều phối
+│   ├── prompts/                # System prompts
+│   │   ├── architect.md
+│   │   ├── coder.md
+│   │   ├── debugger.md
+│   │   └── orchestrator.md
+│   └── handoff-rules.md        # Quy tắc chuyển giao
+│
+├── standards/                   # 📏 Coding standards
+│   ├── coding-conventions.md   # Code style
+│   ├── commit-conventions.md   # Git conventions
+│   ├── file-structure.md       # File organization
+│   ├── error-handling.md       # Error handling
+│   └── security.md             # Security rules
+│
+├── workflows/                   # 🔄 Development processes
+│   ├── development.md          # Feature development flow
+│   ├── debugging.md            # Debug process
+│   ├── testing.md              # Testing strategy
+│   ├── deployment.md           # Deployment process
+│   └── code-review.md          # Review checklist
+│
+├── context/                     # 📚 Business context
+│   ├── business-rules.md       # Business logic
+│   ├── constraints.md          # Technical constraints
+│   ├── dependencies.md         # External dependencies
+│   └── known-issues.md         # Known issues & workarounds
+│
+├── guides/                      # 📖 How-to guides
+│   ├── onboarding.md           # AI onboarding
+│   ├── quick-start.md          # Quick setup
+│   ├── troubleshooting.md      # Common problems
+│   └── faq.md                  # FAQs
+│
+└── models/                      # 🧠 AI model configs
+    ├── model-configs.md        # Model configurations
+    ├── model-selection.md      # When to use which model
+    ├── token-optimization.md   # Token optimization
+    └── fallback-strategy.md    # Fallback handling
+```
+
+## Agent Coordination
+
+### Agent Roles (From docs/agents/agent-roles.md)
+
+**Architect Agent**
+
+- Design system architecture
+- Make technical decisions
+- Review architectural changes
+
+**Coder Agent**
+
+- Implement features
+- Write tests
+- Follow coding standards
+
+**Debugger Agent**
+
+- Analyze bugs
+- Find root causes
+- Verify fixes
+
+**Orchestrator Agent**
+
+- Break down tasks
+- Coordinate agents
+- Track progress
+
+### Handoff Rules
+
+**Khi nào handoff?**
+
+- Architect → Coder: Sau khi design xong
+- Coder → Debugger: Khi gặp bug
+- Debugger → Architect: Bug do design issue
+- Any → Orchestrator: Task phức tạp cần break down
+
+**Trước khi handoff:**
+
+1. Update `docs/memory.md` với context
+2. Summarize work done
+3. List blockers/questions
+4. Point to relevant docs
+
+## Code Conventions (From docs/standards/coding-conventions.md)
+
+### Database Rules
+
+```javascript
+// ✅ ĐÚNG: UUID primary keys
+id: {
+  type: DataTypes.UUID,
+  defaultValue: DataTypes.UUIDV4,
+  primaryKey: true
+}
+
+// ❌ SAI: Auto-increment
+id: {
+  type: DataTypes.INTEGER,
+  autoIncrement: true,
+  primaryKey: true
+}
+
+// ✅ ĐÚNG: No foreign key constraints
+user_id: {
+  type: DataTypes.UUID,
+  allowNull: false
+}
+
+// ❌ SAI: With FK constraint
+user_id: {
+  type: DataTypes.UUID,
+  references: { model: 'users', key: 'id' }
+}
+```
+
+### Oracle Schema Prefix
+
+```sql
+-- ✅ ĐÚNG: With schema prefix
+SELECT * FROM APPS.MTL_SYSTEM_ITEMS_B
+
+-- ❌ SAI: Without prefix
+SELECT * FROM MTL_SYSTEM_ITEMS_B
+```
+
+### Naming Conventions
+
+```javascript
+// Variables & Functions: camelCase
+const userName = "LeNK";
+function getUserData() {}
+
+// Classes: PascalCase
+class UserService {}
+
+// Constants: UPPER_SNAKE_CASE
+const API_BASE_URL = "https://api.example.com";
+
+// Files: kebab-case
+user - service.js;
+
+// DB tables/columns: snake_case
+(users, user_profiles, created_at);
+```
+
+## Examples
+
+### Example 1: Starting New Feature
+
+```bash
+# User request: "Add user authentication"
+
+# Step 1: Load context
+cat docs/README.md
+cat docs/project.md
+cat docs/memory.md
+
+# Step 2: Check if similar feature exists
+grep -r "authentication" docs/memory.md
+cat docs/context/known-issues.md
+
+# Step 3: Load relevant docs
+cat docs/architecture/overview.md
+cat docs/architecture/data-model.md
+cat docs/standards/coding-conventions.md
+cat docs/standards/security.md
+
+# Step 4: Check workflows
+cat docs/workflows/development.md
+
+# Step 5: Start development following conventions
+
+# Step 6: Document decision
+echo "## [2025-01-24] - User Authentication
+**Context**: Need secure user auth
+**Decision**: Using bcrypt + JWT
+**Impact**: New users table, auth middleware
+**Next**: Implement signup/login endpoints" >> docs/memory.md
+```
+
+### Example 2: Debugging Issue
+
+```bash
+# User: "PostgreSQL auto-increment not working"
+
+# Step 1: Check known issues
+cat docs/context/known-issues.md
+
+# Step 2: Check conventions
+cat docs/standards/coding-conventions.md
+# → Found: We use UUID, not auto-increment!
+
+# Step 3: Check memory for similar cases
+grep -r "auto-increment\|UUID" docs/memory.md
+
+# Step 4: Provide solution based on conventions
+# Step 5: Update docs if needed
+```

package/templates/.claude/skills/docx/SKILL.md

@@ -78,17 +78,7 @@ This workflow allows you to plan comprehensive tracked changes using markdown be
 
 **Batching Strategy**: Group related changes into batches of 3-10 changes. This makes debugging manageable while maintaining efficiency. Test each batch before moving to the next.
 
-**Principle: Minimal, Precise Edits**
-When implementing tracked changes, only mark text that actually changes. Repeating unchanged text makes edits harder to review and appears unprofessional. Break replacements into: [unchanged text] + [deletion] + [insertion] + [unchanged text]. Preserve the original run's RSID for unchanged text by extracting the `<w:r>` element from the original and reusing it.
-
-Example - Changing "30 days" to "60 days" in a sentence:
-```python
-# BAD - Replaces entire sentence
-'<w:del><w:r><w:delText>The term is 30 days.</w:delText></w:r></w:del><w:ins><w:r><w:t>The term is 60 days.</w:t></w:r></w:ins>'
-
-# GOOD - Only marks what changed, preserves original <w:r> for unchanged text
-'<w:r w:rsidR="00AB12CD"><w:t>The term is </w:t></w:r><w:del><w:r><w:delText>30</w:delText></w:r></w:del><w:ins><w:r><w:t>60</w:t></w:r></w:ins><w:r w:rsidR="00AB12CD"><w:t> days.</w:t></w:r>'
-```
+**Principle: Minimal, Precise Edits** — only mark text that actually changes, preserving the original run's RSID for unchanged text. Full explanation and a before/after example: [`redlining-reference.md`](redlining-reference.md).
 
 ### Tracked changes workflow
 
@@ -97,35 +87,14 @@ Example - Changing "30 days" to "60 days" in a sentence:
    pandoc --track-changes=all path-to-file.docx -o current.md
    ```
 
-2. **Identify and group changes**: Review the document and identify ALL changes needed, organizing them into logical batches:
-
-   **Location methods** (for finding changes in XML):
-   - Section/heading numbers (e.g., "Section 3.2", "Article IV")
-   - Paragraph identifiers if numbered
-   - Grep patterns with unique surrounding text
-   - Document structure (e.g., "first paragraph", "signature block")
-   - **DO NOT use markdown line numbers** - they don't map to XML structure
-
-   **Batch organization** (group 3-10 related changes per batch):
-   - By section: "Batch 1: Section 2 amendments", "Batch 2: Section 5 updates"
-   - By type: "Batch 1: Date corrections", "Batch 2: Party name changes"
-   - By complexity: Start with simple text replacements, then tackle complex structural changes
-   - Sequential: "Batch 1: Pages 1-3", "Batch 2: Pages 4-6"
+2. **Identify and group changes**: Review the document and identify ALL changes needed, organizing them into logical batches of 3-10. Location methods and batch-organization strategies: [`redlining-reference.md`](redlining-reference.md). **DO NOT use markdown line numbers** - they don't map to XML structure.
 
 3. **Read documentation and unpack**:
    - **MANDATORY - READ ENTIRE FILE**: Read [`ooxml.md`](ooxml.md) (~600 lines) completely from start to finish. **NEVER set any range limits when reading this file.** Pay special attention to the "Document Library" and "Tracked Change Patterns" sections.
    - **Unpack the document**: `python ooxml/scripts/unpack.py <file.docx> <dir>`
    - **Note the suggested RSID**: The unpack script will suggest an RSID to use for your tracked changes. Copy this RSID for use in step 4b.
 
-4. **Implement changes in batches**: Group changes logically (by section, by type, or by proximity) and implement them together in a single script. This approach:
-   - Makes debugging easier (smaller batch = easier to isolate errors)
-   - Allows incremental progress
-   - Maintains efficiency (batch size of 3-10 changes works well)
-
-   **Suggested batch groupings:**
-   - By document section (e.g., "Section 3 changes", "Definitions", "Termination clause")
-   - By change type (e.g., "Date changes", "Party name updates", "Legal term replacements")
-   - By proximity (e.g., "Changes on pages 1-3", "Changes in first half of document")
+4. **Implement changes in batches**: Group changes logically (by section, by type, or by proximity) and implement them together in a single script — smaller batches make debugging easier and allow incremental progress.
 
    For each batch of related changes:
 

package/templates/.claude/skills/docx/redlining-reference.md

@@ -0,0 +1,34 @@
+# DOCX Redlining — Batching Detail and Example
+
+Supporting detail for the "Redlining workflow for document review" steps in `SKILL.md`.
+
+## Principle: Minimal, Precise Edits
+
+When implementing tracked changes, only mark text that actually changes. Repeating unchanged text makes edits harder to review and appears unprofessional. Break replacements into: [unchanged text] + [deletion] + [insertion] + [unchanged text]. Preserve the original run's RSID for unchanged text by extracting the `<w:r>` element from the original and reusing it.
+
+Example - Changing "30 days" to "60 days" in a sentence:
+```python
+# BAD - Replaces entire sentence
+'<w:del><w:r><w:delText>The term is 30 days.</w:delText></w:r></w:del><w:ins><w:r><w:t>The term is 60 days.</w:t></w:r></w:ins>'
+
+# GOOD - Only marks what changed, preserves original <w:r> for unchanged text
+'<w:r w:rsidR="00AB12CD"><w:t>The term is </w:t></w:r><w:del><w:r><w:delText>30</w:delText></w:r></w:del><w:ins><w:r><w:t>60</w:t></w:r></w:ins><w:r w:rsidR="00AB12CD"><w:t> days.</w:t></w:r>'
+```
+
+## Locating changes in XML (Step 2)
+
+- Section/heading numbers (e.g., "Section 3.2", "Article IV")
+- Paragraph identifiers if numbered
+- Grep patterns with unique surrounding text
+- Document structure (e.g., "first paragraph", "signature block")
+- **DO NOT use markdown line numbers** - they don't map to XML structure
+
+## Batch organization (Steps 2 and 4)
+
+Group 3-10 related changes per batch:
+- By section: "Batch 1: Section 2 amendments", "Batch 2: Section 5 updates"
+- By type: "Batch 1: Date corrections", "Batch 2: Party name changes"
+- By complexity: Start with simple text replacements, then tackle complex structural changes
+- Sequential: "Batch 1: Pages 1-3", "Batch 2: Pages 4-6"
+
+Batching this way makes debugging easier (smaller batch = easier to isolate errors) and allows incremental progress.

package/templates/.claude/skills/duraone/SKILL.md

@@ -133,13 +133,12 @@ Xem chi tiết trong `references/workflow.md`.
 ## Quick Rules (Không Được Vi Phạm)
 
 1. **Vue dùng Options API** — KHÔNG dùng `<script setup>` hay Composition API
-2. **ID field luôn prefix `id_`** — `id_agreement`, không phải `agreement_id`
-3. **Boolean field luôn prefix** — `can_edit`, `is_locked`, không phải `editable`, `locked`
-4. **Datetime LUÔN dùng `dayjs()`** — KHÔNG dùng `new Date()`, `Date.now()`, `.getFullYear()`, v.v.
+2. **ID/Boolean field prefix** — xem bảng "Quy Tắc Đặt Tên" ở trên (`id_`, `can_`/`is_`/`has_`/`show_`)
+3. **Datetime LUÔN dùng `dayjs()`** — KHÔNG dùng `new Date()`, `Date.now()`, `.getFullYear()`, v.v.
    - `dayjs().year()` thay `new Date().getFullYear()`
    - `dayjs().startOf("month").format("YYYY-MM-DD")` thay chuỗi string thủ công
    - Mọi biến date trong `data()` phải khởi tạo bằng dayjs
-5. **CẤM TUYỆT ĐỐI GỌI API RAW — KHÔNG fetch(), KHÔNG axios.get/post/put/delete():**
+4. **CẤM TUYỆT ĐỐI GỌI API RAW — KHÔNG fetch(), KHÔNG axios.get/post/put/delete():**
    - MỌI luồng giao tiếp với server BẮT BUỘC phải dùng các hàm định nghĩa sẵn từ `composables/useRequest.js`.
    - **Nếu phát hiện code sinh ra chứa `fetch(...)`, `axios(...)`, `axios.get(...)`, `axios.post(...)` → LÀM LẠI NGAY LẬP TỨC.**
    - Ba hàm hợp lệ DUY NHẤT:
@@ -147,18 +146,15 @@ Xem chi tiết trong `references/workflow.md`.
      - `requestForm(url, formData)` — Dành riêng cho upload file (multipart/form-data)
      - `request_origin(url, data)` — Gọi custom endpoint (không qua generic `/api/select`)
    - KHÔNG CÓ NGOẠI LỆ. Kể cả khi "chỉ test nhanh", "chỉ gọi 1 lần", hay "endpoint bên ngoài" — vẫn phải dùng 3 hàm trên.
-6. **Schema luôn dùng `get_schema()`** — không hardcode `qas` hay `prd`
-7. **Không dùng Vuex/Pinia** — dùng `state.js` reactive trực tiếp
-8. **Error handling**: trả về `[]` hoặc `{}` — không throw exception lên UI
-9. **SQL views luôn có `COALESCE`** cho numeric fields để tránh null
-10. **Dropdown data format**: `{ value: ..., label: ... }` — không đổi key khác
-11. **workingObj pattern** cho form data — một object chứa toàn bộ form fields
-    - Tên biến BẮT BUỘC là `workingObj` — **CẤM dùng từ "form" trong tên biến** (SAI: `formData`, `userForm`, `isFormValid`. ĐÚNG: `workingObj`, `isValid`)
-    - Thuộc tính bên trong **giữ nguyên snake_case** mapping 1:1 với DB columns (SAI: `workingObj.idUser`. ĐÚNG: `workingObj.id_user`)
-12. **Primary Key luôn là UUID varchar** — dùng uuid_in(overlay(...)) pattern, KHÔNG dùng SERIAL/INT
-13. **Foreign key cũng là varchar** — tham chiếu đến UUID của table khác
-14. **workingObj.id mới = `''`** — KHÔNG dùng `= 0`. UUID là varchar, empty string = record mới chưa có id
-15. **Dùng `check_is_null_or_blank(val)`** để check null/blank/array rỗng/object rỗng — hàm này xử lý mọi loại dữ liệu
+5. **Schema luôn dùng `get_schema()`** — không hardcode `qas` hay `prd`
+6. **Error handling**: trả về `[]` hoặc `{}` — không throw exception lên UI
+7. **SQL views luôn có `COALESCE`** cho numeric fields để tránh null
+8. **Dropdown data format**: `{ value: ..., label: ... }` — không đổi key khác
+9. **workingObj pattern** — xem mục "Quy Tắc workingObj & Cấm Từ 'form'" ở trên
+10. **Primary Key luôn là UUID varchar** — dùng uuid_in(overlay(...)) pattern, KHÔNG dùng SERIAL/INT
+11. **Foreign key cũng là varchar** — tham chiếu đến UUID của table khác
+12. **workingObj.id mới = `''`** — KHÔNG dùng `= 0`. UUID là varchar, empty string = record mới chưa có id
+13. **Dùng `check_is_null_or_blank(val)`** để check null/blank/array rỗng/object rỗng — hàm này xử lý mọi loại dữ liệu
 
 ---
 

package/templates/.claude/skills/executing-plans/SKILL.md

@@ -15,11 +15,23 @@ Load plan, review critically, execute tasks in batches, report for review betwee
 
 ## The Process
 
-### Step 1: Load and Review Plan
+### Step 1: Preflight, then Load and Review Plan
 1. Read plan file
-2. Review critically - identify any questions or concerns about the plan
-3. If concerns: Raise them with your human partner before starting
-4. If no concerns: Create TodoWrite and proceed
+2. Run the preflight checklist — each ✓ needs a real check, not an assumption:
+
+```
+Plan received
+✓ dependencies available   - referenced files/packages/tests exist
+✓ instructions executable  - each step is a concrete action, not a question
+✓ verification possible    - each step's check actually runs
+✓ no contradictory steps   - no step conflicts with an earlier one
+✓ no missing prerequisite  - nothing earlier is silently assumed done
+✓ environment compatible   - required tools/versions installed
+READY TO EXECUTE
+```
+
+3. If any ✓ fails: Raise it with your human partner before starting
+4. If READY TO EXECUTE: Create TodoWrite and proceed
 
 ### Step 2: Execute Batch
 **Default: First 3 tasks**
@@ -49,28 +61,28 @@ After all tasks complete and verified:
 - **REQUIRED SUB-SKILL:** Use superpowers:finishing-a-development-branch
 - Follow that skill to verify tests, present options, execute choice
 
-## When to Stop and Ask for Help
+## Blocker Classifier
 
-**STOP executing immediately when:**
-- Hit a blocker mid-batch (missing dependency, test fails, instruction unclear)
-- Plan has critical gaps preventing starting
-- You don't understand an instruction
-- Verification fails repeatedly
+**Classify every mid-batch blocker before reacting:**
 
-**Ask for clarification rather than guessing.**
-
-## When to Revisit Earlier Steps
+```
+BLOCKER TYPE
+🟡 Recoverable        → retry/fallback, note it, continue
+🟠 Planning defect     → return to Step 1 (Preflight), do not guess a fix
+🔵 Missing information → ask the human partner, do not proceed on assumption
+🔴 Hard stop           → execution unsafe/impossible, stop immediately, explain why
+```
 
-**Return to Review (Step 1) when:**
-- Partner updates the plan based on your feedback
-- Fundamental approach needs rethinking
+- Missing dependency → 🟠 · Test fails once → 🟡, repeatedly → 🔴
+- Instruction unclear → 🔵 · Critical gap blocks starting → 🔴
+- Partner revises the plan, or approach needs rethinking → return to Preflight
 
-**Don't force through blockers** - stop and ask.
+**Ask for clarification rather than guessing.**
 
 ## Remember
-- Review plan critically first
+- Preflight before executing
 - Follow plan steps exactly
 - Don't skip verifications
 - Reference skills when plan says to
 - Between batches: just report and wait
-- Stop when blocked, don't guess
+- Classify blockers before reacting, don't guess

package/templates/.claude/skills/file-organizer/SKILL.md

@@ -259,175 +259,7 @@ When a user requests file organization help:
    Want to organize another folder?
    ```
 
-## Examples
+## Examples and Reference
 
-### Example 1: Organizing Downloads (From Justin Dielmann)
-
-**User**: "My Downloads folder is a mess with 500+ files. Help me organize it."
-
-**Process**:
-1. Analyzes Downloads folder
-2. Finds patterns: work docs, personal photos, installers, random PDFs
-3. Proposes structure:
-   - Downloads/
-     - Work/
-     - Personal/
-     - Installers/ (DMG, PKG files)
-     - Archive/
-     - ToSort/ (things needing decisions)
-4. Asks for confirmation
-5. Moves files intelligently based on content and names
-6. Results: 500 files → 5 organized folders
-
-### Example 2: Finding and Removing Duplicates
-
-**User**: "Find duplicate files in my Documents and help me decide which to keep."
-
-**Output**:
-```markdown
-# Found 23 Sets of Duplicates (156 MB total)
-
-## Duplicate Set 1: "proposal.pdf"
-- `/Documents/proposal.pdf` (2.3 MB, modified: 2024-03-15)
-- `/Documents/old/proposal.pdf` (2.3 MB, modified: 2024-03-15)
-- `/Desktop/proposal.pdf` (2.3 MB, modified: 2024-03-10)
-
-**Recommendation**: Keep `/Documents/proposal.pdf` (most recent in correct location)
-Delete the other 2 copies?
-
-[Continue for all duplicates...]
-```
-
-### Example 3: Restructuring Projects Folder
-
-**User**: "Review my ~/Projects directory and suggest improvements."
-
-**Output**:
-```markdown
-# Analysis of ~/Projects
-
-## Current Structure Issues
-- Mix of active and archived projects (3+ years old)
-- No consistent naming convention
-- Some projects at root, others in random subfolders
-- Duplicate folders (project-name, project-name-old, project-name-v2)
-
-## Proposed Structure
-
-```
-Projects/
-├── Active/
-│   ├── client-work/
-│   ├── side-projects/
-│   └── learning/
-├── Archive/
-│   ├── 2022/
-│   ├── 2023/
-│   └── 2024/
-└── Templates/
-```
-
-## Specific Changes
-1. Move 12 projects not touched since 2022 → Archive/
-2. Consolidate 4 duplicate project folders
-3. Rename projects to consistent format: "client-name-project-name"
-4. Create Archive for old work
-
-Want me to implement this?
-```
-
-### Example 4: Organizing Photos by Date
-
-**User**: "Organize my photo folders by year and month."
-
-**Output**: Creates structure like:
-```
-Photos/
-├── 2023/
-│   ├── 01-January/
-│   ├── 02-February/
-│   └── ...
-├── 2024/
-│   ├── 01-January/
-│   └── ...
-└── Unsorted/
-```
-
-Then moves photos based on EXIF data or file modification dates.
-
-## Common Organization Tasks
-
-### Downloads Cleanup
-```
-Organize my Downloads folder - move documents to Documents, 
-images to Pictures, keep installers separate, and archive files 
-older than 3 months.
-```
-
-### Project Organization
-```
-Review my Projects folder structure and help me separate active 
-projects from old ones I should archive.
-```
-
-### Duplicate Removal
-```
-Find all duplicate files in my Documents folder and help me 
-decide which ones to keep.
-```
-
-### Desktop Cleanup
-```
-My Desktop is covered in files. Help me organize everything into 
-my Documents folder properly.
-```
-
-### Photo Organization
-```
-Organize all photos in this folder by date (year/month) based 
-on when they were taken.
-```
-
-### Work/Personal Separation
-```
-Help me separate my work files from personal files across my 
-Documents folder.
-```
-
-## Pro Tips
-
-1. **Start Small**: Begin with one messy folder (like Downloads) to build trust
-2. **Regular Maintenance**: Run weekly cleanup on Downloads
-3. **Consistent Naming**: Use "YYYY-MM-DD - Description" format for important files
-4. **Archive Aggressively**: Move old projects to Archive instead of deleting
-5. **Keep Active Separate**: Maintain clear boundaries between active and archived work
-6. **Trust the Process**: Let Claude handle the cognitive load of where things go
-
-## Best Practices
-
-### Folder Naming
-- Use clear, descriptive names
-- Avoid spaces (use hyphens or underscores)
-- Be specific: "client-proposals" not "docs"
-- Use prefixes for ordering: "01-current", "02-archive"
-
-### File Naming
-- Include dates: "2024-10-17-meeting-notes.md"
-- Be descriptive: "q3-financial-report.xlsx"
-- Avoid version numbers in names (use version control instead)
-- Remove download artifacts: "document-final-v2 (1).pdf" → "document.pdf"
-
-### When to Archive
-- Projects not touched in 6+ months
-- Completed work that might be referenced later
-- Old versions after migration to new systems
-- Files you're hesitant to delete (archive first)
-
-## Related Use Cases
-
-- Setting up organization for a new computer
-- Preparing files for backup/archiving
-- Cleaning up before storage cleanup
-- Organizing shared team folders
-- Structuring new project directories
+Four worked examples (Downloads cleanup, duplicate detection output, project-folder restructuring, photo organization by date), common request phrasings, pro tips, and folder/file naming best practices are in [`examples-and-practices.md`](examples-and-practices.md).