-
-
Notifications
You must be signed in to change notification settings - Fork 146
Description
Summary
TELOS is described as a "framework" but currently functions more as a markdown template with analysis prompts. I think TELOS could benefit from atomic prompt patterns for maintaining TELOS files - making the framework pseudo-deterministic, structured, and suitable for version control.
The Opportunity
1. TELOS as the Future of Daily Journaling
I can see TELOS becoming the next step in how daily journaling is done. Imagine: you have a conversation with your digital assistant, and they handle the rest - merging insights into your TELOS, pushing reflections, and logging daily updates with Git version tracking.
This could extend further:
- Scraping photos and videos taken during the day to accompany journal entries
- Pulling in completed tasks from your to-do list tool
- Integrating calendar events and work accomplished
- Unifying all of this into a single, version-controlled life document
A t_daily_review pattern could facilitate this - a conversational daily check-in that the AI merges into your TELOS structure.
2. Analysis Patterns Exist, But Maintenance Patterns Don't
The t_* patterns (t_check_metrics, t_find_neglected_goals, etc.) are excellent for analyzing an existing TELOS. However, there are no patterns for:
- Adding a daily journal entry from a conversation
- Creating a new Goal linked to a Mission
- Marking a Project as complete
- Guided review of core pillars (Problems/Missions)
Analysis alongside maintenance tooling could make TELOS more complete.
3. Git-Native Version Tracking
The current ## LOG (Journal) section with dated entries duplicates what Git already does well:
## LOG (Journal)
- 2025-12-12: Created TELOS file...
- 2025-12-13: Updated goals...If TELOS were version-controlled by design, Git history becomes the changelog. The LOG section could instead capture meaningful reflections rather than mechanical change tracking.
4. Gap Between TELOS (File) and Daemon (API)
Daemon uses bracket syntax [TELOS] for API exposure, but there's no bridge to sync the rich personal_telos.md with the summarized daemon.md. Users manually keep these in sync.
Possible Solution: Atomic Prompt Patterns
Following Fabric's pattern approach, maintenance patterns could complement the existing analysis patterns:
| Current (Analysis) | Possible (Maintenance) |
|---|---|
t_check_metrics |
t_add_goal |
t_find_neglected_goals |
t_daily_review |
t_visualize_mission_goals_projects |
t_complete_project |
t_analyze_challenge_handling |
t_review_problems |
Each maintenance pattern could:
- Take structured input (goal text, mission reference, conversation transcript, etc.)
- Output valid TELOS markdown that preserves structure
- Maintain cross-reference integrity
Why This Could Matter
- Conversational journaling - Talk to your AI, let it update your TELOS
- Git-native workflow - TELOS as a tracked file, not a changelog-in-markdown
- Lower friction - Atomic operations vs. manual full-file editing
- Future integrations - Photos, tasks, calendar events unified into TELOS
Precedent
vjspal/telos built markdown→JSON conversion and CI/CD automation - the only fork of 137 with actual tooling. This suggests some community interest in programmatic TELOS access.
Example Implementation
Atomic patterns following Fabric conventions:
t_daily_review - Conversational daily check-in, merges into TELOS
t_add_goal - Add goal with mission linkage
t_add_reflection - Add dated reflection to journal section
t_complete_project - Mark project complete, update status
t_sync_daemon - Generate daemon.md [TELOS] section from full TELOS
TL;DR: I think TELOS could benefit from atomic maintenance patterns (not just analysis), Git-native version tracking, and patterns that enable conversational daily journaling - talk to your AI, let it handle the rest.