- Transform tufte-press from reference guide to conversation-aware generator - Add JSON generation from conversation context following strict schema - Create build automation scripts with Nix environment handling - Integrate CUPS printing with duplex support - Add comprehensive workflow documentation Scripts added: - skills/tufte-press/scripts/generate-and-build.sh (242 lines) - skills/tufte-press/scripts/build-card.sh (23 lines) Documentation: - Updated SKILL.md with complete workflow instructions (370 lines) - Updated README.md with usage examples (340 lines) - Created SKILL-DEVELOPMENT-STRATEGY-tufte-press.md (450 lines) - Added worklog: 2025-11-10-tufte-press-skill-evolution.org Features: - Agent generates valid JSON from conversation - Schema validation before build (catches errors early) - Automatic Nix shell entry for dependencies - PDF build via tufte-press toolchain - Optional print with duplex support - Self-contained margin notes enforced - Complete end-to-end testing Workflow: Conversation → JSON → Validate → Build → Print Related: niri-window-capture, screenshot-latest, worklog skills
8.2 KiB
Feature 001: Screenshot Analysis - Resolution
Status: ✅ IMPLEMENTED (Minimal Viable Version)
Location: skills/screenshot-latest/
Implementation Date: 2025-11-08
What We Built
A minimal skill that finds the most recent screenshot automatically so users don't have to type paths.
Files created:
skills/screenshot-latest/SKILL.md- Agent instructions (83 lines)skills/screenshot-latest/scripts/find-latest.sh- Bash script (22 lines)skills/screenshot-latest/README.md- User documentationskills/screenshot-latest/examples/example-output.txt- Example output
Total implementation: 185 lines (including documentation)
Usage
User: "Look at my last screenshot"
AI: → <finds /home/user/Pictures/Screenshots/Screenshot-2025-11-08-14-06-33.png> →
What We Learned
The Over-Engineering Journey
- Initial spec: 635 lines of planning for 22 lines of code
- Task breakdown: 82 tasks to implement 1 bash script
- Reality check:
ls -t ~/Pictures/Screenshots/*.png | head -1already works - Reset: Built minimal version in 22 minutes instead of implementing 82 tasks
Key insight: Specification time (115 min) vs Implementation time (22 min) = 5.2x waste
Root Causes
- Template-driven development: Filled in specification template without questioning scope
- Solution-first thinking: Designed before coding
- Over-engineering bias: Added features user didn't request
- Lost sight of value: Built framework instead of solving problem
What We Should Have Done
# Step 1: Test if problem is real (5 seconds)
ls -t ~/Pictures/Screenshots/*.png | head -1
# Step 2: It works? Ship it with docs (22 minutes)
echo "#!/bin/bash" > find-latest.sh
echo "ls -t ~/Pictures/Screenshots/*.{png,jpg,jpeg} | head -1" >> find-latest.sh
# Step 3: Done
Scope Decisions
What We Implemented (P1)
- ✅ Find latest screenshot by modification time
- ✅ Clear error messages (directory missing, no files)
- ✅ Support PNG, JPG, JPEG formats
- ✅ Fast execution (<1 second)
- ✅ Natural language triggers ("look at my screenshot")
What We Deferred (P2-P3)
- ⏸️ Custom directories (YAGNI - default works for 95% of users)
- ⏸️ Nth screenshot lookup (YAGNI - not requested)
- ⏸️ Time-based filtering (YAGNI - not requested)
- ⏸️ Configuration files (YAGNI - hardcoded path is fine)
- ⏸️ Symlink handling (YAGNI - not mentioned in original request)
Future Enhancements (If Requested)
File-based improvements:
- Support custom screenshot directories
- Find "second-to-last" or Nth screenshot
- Time-based filtering ("screenshot from 5 minutes ago")
Direct capture approach (more interesting):
- Bypass files entirely with
grim - | <inject to AI> - Clipboard-based workflow (
grim - | wl-copy) - Region capture with niri window geometry
- Real-time screen analysis
See FUTURE-ENHANCEMENT.md for details on direct capture.
Deliverables
Specification Documents (635 lines - ARCHIVED)
- ❌
specs/001-screenshot-analysis/spec.md- Over-specified - ❌
specs/001-screenshot-analysis/plan.md- Premature planning - ❌
specs/001-screenshot-analysis/tasks.md- 82 unnecessary tasks
Implementation (185 lines - SHIPPED)
- ✅
skills/screenshot-latest/SKILL.md- Agent instructions - ✅
skills/screenshot-latest/scripts/find-latest.sh- Working script - ✅
skills/screenshot-latest/README.md- User docs - ✅
skills/screenshot-latest/examples/example-output.txt- Example
Analysis Documents (VALUABLE)
- ✅
specs/001-screenshot-analysis/RESET.md- Problem analysis - ✅
specs/001-screenshot-analysis/COMPARISON.md- Spec vs reality - ✅
specs/001-screenshot-analysis/FUTURE-ENHANCEMENT.md- Direct capture research - ✅
specs/001-screenshot-analysis/RESOLUTION.md- This document
Testing
Manual test:
./skills/screenshot-latest/scripts/find-latest.sh
# Expected: /home/dan/Pictures/Screenshots/Screenshot from 2025-11-08 14-06-33.png
# Actual: /home/dan/Pictures/Screenshots/Screenshot from 2025-11-08 14-06-33.png
✓ PASS
Integration test: Deploy to ~/.claude/skills/ and ask "look at my screenshot"
- Status: NOT YET TESTED (requires deployment)
- Next step: Deploy and validate with actual AI usage
Deployment
Not Yet Deployed
The skill needs to be deployed to:
~/.claude/skills/screenshot-latest(for Claude Code), OR~/.config/opencode/skills/screenshot-latest(for OpenCode)
Deployment command:
# Claude Code
ln -s $(pwd)/skills/screenshot-latest ~/.claude/skills/screenshot-latest
# OpenCode
ln -s $(pwd)/skills/screenshot-latest ~/.config/opencode/skills/screenshot-latest
Deployment blocked by: Need to test in actual AI environment first
Success Criteria
Original (overcomplicated):
- SC-001: Work in 100% of cases (unmeasurable)
- SC-002: Complete in <1 second for 1000 files (premature optimization)
- SC-003: Succeed in 95% of requests (can't measure without data)
- SC-004: Clear error messages ✓ (kept this)
- SC-005: Save 40+ keystrokes ✓ (accurate)
Actual (pragmatic):
- User says: "look at my screenshot"
- AI responds with analysis of correct file
- User says: "thanks" (not "that's the wrong file")
That's the only metric that matters.
Lessons for Future Features
Specification Process
Use comprehensive specs when:
- Multiple developers need coordination
- Complex domain requiring analysis
- High risk of rework
- Unclear requirements needing clarification
- Enterprise/compliance requirements
DON'T use comprehensive specs when:
- Solution is obvious (1-liner test confirms)
- Single developer working alone
- Simple domain (file operations)
- Low risk of rework (<50 lines of code)
- Requirements are crystal clear
Development Process
For small features:
- Test one-liner solution (5 seconds)
- If it works → Write script + docs (20 minutes)
- Ship it
- Iterate on feedback
For large features:
- Write specification
- Break down tasks
- Implement incrementally
- Test thoroughly
- Ship after validation
This feature was small. We should have skipped steps 1-2.
Related Work
Research discoveries:
grim -can output PNG to stdout (verified)niri msgprovides window geometry (verified)- Direct capture approach is feasible (untested with AI)
- Clipboard injection is possible (untested with AI)
Follow-up questions:
- Can OpenCode/Claude Code read from clipboard?
- Can OpenCode/Claude Code accept base64 image data?
- What's the actual latency in real usage?
Recommendations
For This Feature
- ✅ Ship current file-based implementation
- ⏸️ Deploy to
~/.claude/skills/or~/.config/opencode/skills/ - ⏸️ Test with actual AI usage
- ⏸️ Gather user feedback
- ⏸️ Consider direct capture IF users request it
For Future Features
- Test before you specify
- Build before you plan (for simple problems)
- Question every requirement
- Ship minimal version first
- Enhance based on actual usage
For Spec-Kit Tool
Consider adding a "complexity gate":
Before running /speckit.specify:
- Can you solve this with a one-liner?
- YES → Just write the code
- NO → Continue with specification
This would have saved 93 minutes on this feature.
Status Summary
| Aspect | Status |
|---|---|
| Problem Understanding | ✅ Clear |
| Solution Validation | ✅ Tested (one-liner works) |
| Implementation | ✅ Complete (minimal version) |
| Documentation | ✅ Complete (SKILL.md + README) |
| Testing | ⚠️ Manual test passed, integration test pending |
| Deployment | ⏸️ Not yet deployed |
| User Validation | ⏸️ Awaiting real usage |
Closure
Original request: "Make it so I don't have to type '~/Pictures/Screenshots' every time"
Solution delivered: 22-line bash script that finds latest screenshot automatically
Time to implement: 22 minutes
Time to specify: 115 minutes (wasted)
Time to analyze: 60 minutes (valuable - generated learning)
Next action: Deploy and test with actual AI usage
Feature status: ✅ RESOLVED (minimal viable implementation shipped)
Sometimes the best specification is shipping working code.