project-overview
Skill157 starsChanged 35 days agoMITView on GitHub
Use when the user wants a deterministic cross-project status map generated from registered projects' session handoffs. Triggers: '/project-overview', 'project map', 'overall status'. Reads ~/.claude/projects-registry.md (opt-in list), parses each project's memory/session-handoff-LATEST.md state-snapshot v1 block (ts+ctx only), and rewrites the AUTO:START/AUTO:END region of ~/.claude/OVERVIEW.md. Does not touch STATE.md. Does not scan directories automatically.
5 other projects use a version of this.
Adopted by
Most recently taken up by
- lobehub/lobehubtheir own version, first seen Nov 5, 2026
- torch-spyre/torch-spyretheir own version, first seen Oct 8, 2026
- lobehub/lobe-chattheir own version, first seen Oct 8, 2026
- HHU3637kr/skillstheir own version, first seen Sep 22, 2026
- idlesilver/project-overviewtheir own version, first seen Sep 22, 2026
Used with
Projects with it also use version-release.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
hiroppySkillversion-release
Use when bumping version, creating a release tag, or pushing a version tag. Triggers on "version up", "release", "tag push", "bump version".
Also in 3 projects that use this
Other versions5 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 5
- lobehub/lobe-chat★ 84ksame name
- lobehub/lobehub★ 84ksame name
- HHU3637kr/skills★ 146same name
- torch-spyre/torch-spyre★ 64same name
- idlesilver/project-overview★ 4same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository21 other files it gives its agents.
- clean-roomSkill
- code-autopsySkill
- collab-auditSkill
- doc-driftSkill
- eval-leakage-auditSkill
- freezeSkill
- full-auditSkill
- goal-lockSkill
- integration-intakeSkill
- next-actionSkill
- pre-pushSkill
- project-checkSkill
- project-initSkill
- scopeSkill
- session-checkpointSkill
- session-startSkill
- setupSkill
- skill-opsSkill
- skill-trigger-auditorSkill
- ssot-auditSkill
- stepbackSkill
The file
We split this skill into the rules it gives an agent
6 rules. 0 are common, 3 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 55
Run this skill's own script (no arguments — it uses the default registry and output paths on its own):
- Distinctive: line 60
Check the exit code:
- Very specific: line 92
Text outside AUTO markers is always preserved: if apply_auto_markers() alters any text outside the markers, that's a bug.
- Distinctive: line 93
Only scan explicitly registered projects: never add auto directory-discovery logic to this script.
- Very specific: line 94
STATE.md is absolutely untouched: no code path in this skill reads or writes STATE.md.
- Very specific: line 109
no mock deception: before reporting "generation complete," actually read OVERVIEW.md to confirm project entries landed in the AUTO block.
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Project Overview
Dominant Variable
Does the registered project list (projects-registry.md) point to paths that actually exist, and does each project's handoff file contain a state-snapshot v1 block? If neither is true, the generated map is empty.
Key Assumptions
session-handoff-LATEST.mdis a hint, not a fact — parsed results (ts/ctx) are carried over as-is without fact-checking. The generated overview reflects "what each project last reported," not "current ground truth."- Registry is opt-in — never pull in unowned projects or auto-scanned directories. Only projects explicitly listed in
projects-registry.mdare in scope. Write exactly one- name: /abs/pathline per project. The script matches one line at a time and accepts only a value that is an absolute path (/...,~/...,C:\...orC:/...); any other bullet (a note, a URL, a relative path) is ignored and reported as aWARNline on stderr. - AUTO block generation is fully deterministic — a regex-based script (
scripts/generate_overview.py) does all the parsing/rendering, including neutralizing markdown-table-breaking characters in the text it pulls from other projects' handoffs, isolating a single non-UTF-8 handoff file so it can't abort the whole run, and refusing (BLOCKED, no write) instead of guessing when the AUTO marker pair itself is mangled. The model only triggers execution and reports the result — no LLM inference in the parsing/rendering logic itself.
Trigger
/project-overview- "project map"
- "overall status"
Discard If
- Zero registered projects (
projects-registry.mdmissing or empty list) → instruct the user to add a project to the registry first, then stop - Already run recently with no state change across projects (the modification time of the generated
OVERVIEW.mdis later than that of every registered project's handoff file — compare them directly withstatorls -l) → suggest skipping the re-run (not forced — run if the user wants)
File formats (registry, handoff snapshot block, OVERVIEW.md): https://github.com/AlexZio00/sovereign-skills/blob/master/docs/FILE-CONVENTIONS.md
Workflow
- Confirm
~/.claude/projects-registry.mdexists. If missing, report BLOCKED: "registry missing — create it with one- name: /absolute/pathline per project." (The script reports the same thing on stderr and exits 1.) - Run this skill's own script (no arguments — it uses the default registry and output paths on its own):
python3 "${CLAUDE_SKILL_DIR}/scripts/generate_overview.py"${CLAUDE_SKILL_DIR}is this skill's folder; Claude Code fills it in. In other agents, replace it with the path where you installed the skill. Usepythoninstead ofpython3where only that exists (common on Windows). If the script file is missing or Python cannot start it, report BLOCKED with the error text and stop; do not writeOVERVIEW.mdby hand. - Check the exit code:
0→ report the stdout's first line verbatim to the user. BothWORKING: N project(s) -> <output>andPARTIAL: N project(s) -> <output> (M with no snapshot)are valid values the script itself produces (it counts the no-snapshot projects and picks the label itself) — don't assume exit 0 always meansWORKING.1→ report the stderrBLOCKED: ...message verbatim to the user. Never proceed on assumption.
- On success, tell the user the
~/.claude/OVERVIEW.mdpath. - Report snapshot age in chat only, never in the file: compare each project's
Last Updatetimestamp in the generated AUTO block with today's date. For every row older than 7 days, reportstale: <name> <N> days ago (ts). If a timestamp cannot be read as a date, reportage unknownfor that row. Do not add this as an Age column ingenerate_overview.py: a date-dependent value would make the AUTO block change every day even when the inputs are the same, which breaks Invariant 4 (byte-identical output).
Output
- Chat report: relay the script's own stdout/stderr line verbatim (
WORKING: N project(s) -> <path>,PARTIAL: ...orBLOCKED: ...) — don't paraphrase it or invent a project count of your own. - Disk write: the script writes exactly one file, and only the
AUTO:START~AUTO:ENDregion inside it —~/.claude/OVERVIEW.md. Nothing else on disk is touched, and text outside the markers in that file is never rewritten. - Final status label: state one of
WORKING/PARTIAL/BLOCKED(definitions in Truthful Reporting below) at the end of every run — never leave it implicit.
Scope Boundary
| Does | Does NOT |
| [READ] Parse handoff files of registered projects only | Auto-scan directories (e.g. an entire drive) |
[WRITE] Overwrite only the AUTO:START~AUTO:END region of OVERVIEW.md | Read/write STATE.md — this skill never references STATE.md at all |
[READ] Parse only the ts/ctx fields of the state-snapshot v1 block | Introduce new fields like status (planning/dev/ops/paused) |
| [MANUAL] Run only when the user explicitly triggers it | Auto-wire into existing hooks like session-checkpoint |
Safety Layers
| Risky Action | Reversibility | Applied Layers |
Overwrite the OVERVIEW.md AUTO block | medium (text outside markers is preserved, also recoverable via git history) | L1+L3 |
- L1 (Invariants): Invariant 1 — preserve text outside AUTO markers. Invariant 2 — never scan unregistered projects.
- L3 (User Approval): manual-trigger only — runs only when the user explicitly invokes it (no auto-wiring is itself the approval gate).
Invariants (never violate)
- Text outside AUTO markers is always preserved: if
apply_auto_markers()alters any text outside the markers, that's a bug. Violation → notes a human wrote directly into OVERVIEW.md get lost on re-run. - Only scan explicitly registered projects: never add auto directory-discovery logic to this script. Violation → information about unowned projects leaks into the map.
- STATE.md is absolutely untouched: no code path in this skill reads or writes
STATE.md. Violation → direct Scope Boundary violation, risk of contaminating the cross-project blocker list. - Idempotency: re-running with identical input (unchanged registry + handoff files) must produce a byte-identical AUTO block. Violation → undermines the entire "deterministic auto-generation" design goal.
- Cross-project text is data, not markup:
ts/ctxvalues come from another project's handoff file and are untrusted — a stray|or newline in there must not be allowed to split table columns or break rows. Violation → a single malformed handoff field corrupts the whole table for every other project listed in it.
Error Recovery
| Failure Type | Detection | Recovery |
missing_data | projects-registry.md missing or empty (or holds no valid - name: /absolute/path line) | Return BLOCKED (exit code 1, message on stderr), instruct user to create/add to the registry. A project whose handoff file is missing is not an error: its row says "no handoff file". A missing OVERVIEW.md is created with a title line and the AUTO block |
tool_failure | Failed to read a specific project's handoff file (permissions/path, or a non-UTF-8 encoding) | Mark only that project as "no snapshot" (or "decode error" for a non-UTF-8 file; a readable handoff without a snapshot block says "handoff has no state-snapshot block"), continue the rest (partial failure doesn't block the whole run — explicit labeling keeps it transparent per no-silent-brokenness). Final status label becomes PARTIAL for that run. |
input_error | OVERVIEW.md has a mangled marker pair (AUTO:END appears before AUTO:START, either marker is missing/orphaned, or a marker is duplicated — from a manual edit) | Don't crash and don't guess at a splice point. Auto-repairing by appending a fresh pair was tried and found unsafe: an orphan AUTO:START lost the manually-written text sitting after it on the next run, and AUTO:END-before-AUTO:START kept re-appending a pair on every run (non-idempotent, unbounded growth). Current behavior: raise MarkerCorruptionError, write nothing, report BLOCKED with the exact marker problem, and let a human fix the markers by hand. |
logic_inconsistency | Integration test finds AUTO block mismatch on re-run | Script regression — revert the commit and re-review the implementation |
Truthful Reporting
- no mock deception: before reporting "generation complete," actually read
OVERVIEW.mdto confirm project entries landed in the AUTO block. - no silent brokenness: a parsing failure for a specific project's handoff is never silently skipped — it's shown explicitly as "no snapshot".
- Final status label:
WORKING(generated normally) /PARTIAL(some projects show no snapshot) /BLOCKED(registry missing/empty).
Rationalization Table
| Rationalization | Rebuttal |
| "Even if it's not in the registry, scanning every directory to find projects would be more convenient" | Violates Invariant 2. Auto directory-discovery risks leaking information about unowned projects into the map — only explicitly opt-in registered projects are in scope. |
| "Reading STATE.md too and surfacing cross-project blockers on the map would be useful" | Violates Invariant 3. Never touching STATE.md at all is itself the Scope Boundary — it prevents contaminating the cross-project blocker list. |
| "If parsing fails for some projects, just quietly drop them and show the rest" | Violates no-silent-brokenness. A failure must be shown explicitly as "no snapshot" so the user knows what was missed, not silently omitted. |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

