Skill: ivangdavila/organize (version 1.0.0)

--- name: Organize description: Proactively organize while working. Learn user's structure preferences, think ahead for scale, optimize for future access. --- ## Core Principle Organization isn't a separate task—it happens while you work. Every file created, every folder touched is an opportunity to improve structure. Think ahead: how will this scale? How will it be accessed later? Organize for the future, not just today. Check `principles.md` for organization fundamentals. Check `patterns.md` for learned preferences (update as you learn). --- ## Proactive Triggers Organize when you notice: | Trigger | Action | |---------|--------| | Creating new file | Propose location based on patterns.md | | Multiple related files | Suggest grouping structure | | Naming something | Apply naming conventions from patterns.md | | Searching takes effort | Propose reorganization | | Pattern emerging | Document in patterns.md, confirm with user | --- ## The Organization Loop ``` 1. OBSERVE — Notice structure while working 2. PROPOSE — Suggest improvement before acting 3. CONFIRM — Get explicit OK (until pattern confirmed) 4. APPLY — Organize, document what you did 5. LEARN — Record preference in patterns.md ``` **Never reorganize without asking.** Until a pattern is confirmed, always propose first. --- ## Scale Thinking Before placing anything, ask: - **10x test:** If this grows 10x, does the structure hold? - **Access pattern:** How will this be found later? By whom? - **Related items:** What will live near this? Group accordingly. - **Lifecycle:** Will this be archived? Deleted? Versioned? --- ## Proposal Format ``` 📁 Organization suggestion I'm about to [create/move/rename] [item]. Current: [where it would go by default] Proposed: [where it should go based on patterns] Reasoning: [why this structure scales better] OK to organize this way? (Say "always for X" to skip future asks) ``` --- ## Learning Preferences Track confirmations: | Pattern | Status | |---------|--------| | Seen once | Note, still ask | | Confirmed 2x | Tentative, still ask | | "Always do this" | Auto-apply, stop asking | | "Never do this" | Avoid, record in patterns.md | --- ## Reorganization Proposals When existing structure needs improvement: ``` 📁 Reorganization proposal Problem: [what's inefficient now] Impact: [how it affects access/scale] Proposed change: - [specific moves/renames] Effort: [minimal/moderate/significant] Risk: [what could break] Should I proceed? ``` --- ## Anti-Patterns | Don't | Do instead | |-------|------------| | Reorganize silently | Always propose first | | Organize in bulk later | Organize while working | | Structure for today only | Think 10x ahead | | Assume preferences | Confirm, then record | | Same structure for everything | Adapt to content type |

path: patterns.md
content: # Learned Patterns

Update this file as you learn user's organization preferences.

---

## Naming Conventions
<!-- Confirmed naming patterns -->

### Files
<!-- e.g., kebab-case: confirmed [user said "always"] -->

### Folders
<!-- e.g., lowercase with underscores: tentative [2 confirmations] -->

### Projects
<!-- e.g., prefix with client name: confirmed -->

---

## Folder Structures
<!-- Learned hierarchy preferences by context -->

### Code Projects
<!-- e.g., src/components/feature pattern: confirmed -->

### Documents
<!-- e.g., by-project not by-type: confirmed -->

### Media
<!-- e.g., YYYY/MM subfolders: tentative -->

---

## Grouping Preferences
<!-- How user prefers things grouped -->

### Primary grouping
<!-- e.g., by project > by type: confirmed -->

### Archive behavior
<!-- e.g., move to _archive with date prefix: confirmed -->

---

## Auto-Apply (No Ask Needed)
<!-- Patterns confirmed with "always do this" -->

---

## Never Do
<!-- Patterns explicitly rejected -->

---

## Context-Specific
<!-- Different rules for different contexts -->

### Work vs Personal
<!-- -->

### Shared vs Private
<!-- -->

---

## Observations
<!-- Patterns noticed but not yet confirmed -->
<!-- Format: [date] [observation] [status] -->

---

## Reorganization History
<!-- Major reorganizations done, for reference -->
<!-- Format: [date] [what changed] [outcome] -->

---

*Empty sections = still learning. Propose, confirm, record. Build the user's organization DNA.*


path: principles.md
content: # Organization Principles

Fundamentals that apply across all organization decisions.

## Naming

### Consistency Over Cleverness
- Same type of thing → same naming pattern
- Predictable > memorable
- If someone can guess the name, it's good

### Common Patterns
| Type | Pattern | Example |
|------|---------|---------|
| Dates | YYYY-MM-DD prefix | 2024-01-15-meeting-notes.md |
| Versions | vX.Y.Z suffix | design-v1.2.0.fig |
| Status | prefix | draft-, final-, archived- |
| Type | suffix | -spec, -test, -config |

### Avoid
- Spaces (use hyphens or underscores)
- Special characters
- Ambiguous abbreviations
- Numbers without context (v1 vs version-1-initial)

## Hierarchy

### Depth vs Breadth
- Max 3-4 levels deep (deeper = harder to navigate)
- 5-15 items per folder (fewer = overstructured, more = cluttered)
- If navigating feels like work, restructure

### Grouping Principles
| Group by | When |
|----------|------|
| Project | Work spans multiple types |
| Type | Same processing for all items |
| Date | Temporal access pattern |
| Status | Workflow-based access |
| Owner | Multi-person collaboration |

### Escape Hatches
- `_archive/` for old but kept items
- `_temp/` or `_scratch/` for work in progress
- `_reference/` for external/imported items

## Access Optimization

### Frequency-Based Placement
- Daily access → top level or pinned
- Weekly access → one level deep
- Monthly access → can be deeper
- Rarely accessed → archive

### Search vs Navigate
- Will they search by name? → naming matters most
- Will they browse? → hierarchy matters most
- Both? → optimize for most common pattern

## Scale Patterns

### Signs Structure Won't Scale
- Folder has 50+ items
- Deeply nested (5+ levels)
- Inconsistent naming within same level
- "Misc" or "Other" folders growing

### Future-Proofing
- Leave room for growth (don't over-partition early)
- Use patterns that extend naturally
- Document your structure decisions


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)