Pre-flight checks at session start — load context, check prior state, validate env, check for in-flight work from other terminals
Scanned 9/9/2026
Install to Claude Code
npx -y skills add vamseeachanta/workspace-hub --skill session-start-routine --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Session Start Routine?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/vamseeachanta-session-start-routine-workspace-hub)More formats (shields.io, HTML) on the badges page.
---
name: session-start-routine
description: Pre-flight checks at session start — load context, check prior state, validate env, check for in-flight work from other terminals
version: 1.0.0
category: coordination
tags: [session, startup, preflight, governance]
related_skills:
- session-corpus-audit
- comprehensive-learning
---
# Session Start Routine
Pre-flight checklist for every new session. Run these checks before beginning work.
## Checklist
### 1. Load context
- Load memory context files from the repo memory directory
- Check `MEMORY.md` for active project state and recent feedback
### 2. Check prior session state
- Read today's session signals: `.claude/state/session-signals/YYYY-MM-DD.jsonl`
- Look for sessions that ended mid-task (incomplete commits, unreleased `wip:` labels)
- Check `git status` for uncommitted work from prior sessions
### 3. Check for in-flight work
- Scan for wip labels on GitHub issues (gh issue list filtered by wip label)
- Check other terminals: `ps aux | grep claude | grep -v grep`
- Check `/tmp/.claude-wip-*` markers if present
### 4. Validate environment
- Verify tools: `uv --version`, `gh auth status`, `git status`
- Check disk space: `df -h /mnt/local-analysis`
- Verify governance hooks are registered in settings
### 5. Check governance limits
- Review tool-call counter: `.claude/state/session-governor/tool-call-count`
- Confirm counter is below 200 ceiling (or reset if new day)
## When to use
- Start of every interactive session
- After a context reset or conversation compression
- When resuming work after a break
- When the user asks for a terse live "status update" from mobile/Telegram
## Mobile status-update mode
When the user asks only "Status update" (especially from Telegram), produce a compact evidence-backed snapshot rather than a broad narrative.
1. Gather live state before summarizing:
- `git status --short --branch` in the active repo.
- Active/background agent processes or Hermes process-manager state.
- `hermes cron`/cronjob list for active, paused, failed, and next scheduled jobs.
- GitHub counts for `wip`, `status:plan-review`, `status:plan-approved`, and recent closed issues.
- Most recent relevant cron output files when scheduled jobs produced user-facing findings.
2. Separate counts clearly:
- live label counts are not the same as artifact-audited approval readiness;
- closed/recent results are not the same as currently running lanes;
- paused autofeed monitors are not active throughput.
3. For Telegram/mobile delivery:
- avoid pipe tables; use numbered bullets and labeled key/value lines;
- link GitHub issues as `[#{number}](url)`;
- keep to the shortest useful update, with risks and next best action last.
4. Never clean/reset/stage dirty control-plane files during a status-only request; report dirty state and recommend a narrow reconciliation pass if needed.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!