Workflows
Common scenarios and best practices for getting the most out of Tenax.
Starting a New Project
Set up memory and establish initial decisions
- Memory initializes automatically on first use. Check status with
/tenax:status - Discuss architecture with Claude - it will mark decisions in its responses automatically
- Ask Claude to "record this decision" if you want to ensure something specific is captured
- Session ends - knowledge is automatically extracted from Claude's markers
- Next session, use
/tenax:statusto verify decisions were captured
Tip: You can also manually record with /tenax:record decision -t database "Using PostgreSQL"
Resuming Work After Days Away
Quickly restore context from previous sessions
- Start with a quick summary:
/tenax:status - Load recent context:
/tenax:load-sessions --recent 3 - Or load specific sessions if you remember:
/tenax:load-sessions 005,007 - Search for specific topics:
/tenax:search "authentication" - Review pending tasks to see where you left off
Tip: Set autoLoad: "recent-3" in settings to automatically load context at session start.
Before Making Architecture Decisions
Check history to avoid contradicting past choices
- Before proposing changes, search:
/tenax:search "database" -t decision - Review existing decisions and their rationale
- If changing direction, explicitly record the new decision with updated rationale
- Reference the old decision: "Changing from X to Y because circumstances changed"
Tip: With autoCheckBeforeDecisions: true, Claude will automatically search before proposing architecture changes.
Debugging a Problem
Search for similar issues and past solutions
- Search for related issues:
/tenax:search "connection timeout" - Check insights:
/tenax:search "timeout" -t insight - Load sessions where similar work was done
- After solving, ask Claude to record the insight or use
/tenax:record insight "Connection timeouts were caused by..."
Tip: Always record debugging insights. Future you (or teammates) will thank you.
Exporting for Documentation
Share knowledge with your team or backup
- Export to Markdown:
/tenax:export -f markdown -o ./docs - For Obsidian users:
/tenax:export -f obsidian -o ./vault - For backup:
/tenax:backup - Include full sessions if needed:
/tenax:export -s
Export Formats
| Format | Best For |
|---|---|
markdown | README, docs folder, GitHub wiki |
json | Programmatic access, backups |
obsidian | Personal knowledge management |
notion | Team wikis, Notion databases |
Team Collaboration
Share Tenax via version control
- Add
.claude/tenax/index.jsonto version control - Optionally exclude raw sessions: add
.claude/tenax/sessions/to .gitignore - Team members pull the latest index to share decisions and patterns
- Each person's sessions remain local, but extracted knowledge is shared
Recommended .gitignore
# Keep index and config, ignore raw sessions
.claude/tenax/sessions/
.claude/tenax/embeddings.db
Tip: Set sessionIdPadding: 4 for teams to support more concurrent sessions.
Best Practices
- Mark explicitly in early sessions. Establish the habit of using markers for important decisions.
- Search before deciding. Check if a topic has been addressed before proposing changes.
- Record debugging insights. The fix you found today is the insight that saves hours tomorrow.
- Use consistent topic names. "auth" vs "authentication" matters for search.
- Review pending tasks. Check
/tenax:statusto see what's still open. - Export periodically. Keep a backup and share knowledge with your team.