# Prime Gnadd > Orient a new chat session with a read-only project snapshot using the bundled gnadd script, git, and gh: project shape, current branch state, whether main is behind or diverged from origin, stashes, recent commits, open issues, open and merged PRs, and active issue context. Fetches latest remote state first. Use when the user asks to inspect project state, orient a session, see what work is open, or decide what to do next. - Skill: `alexhagemeister/prime-gnadd` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add alexhagemeister/prime-gnadd` - Raw SKILL.md: https://api.skillmd.com/api/skills/alexhagemeister/prime-gnadd/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: AlexHagemeister (https://skillmd.com/u/alexhagemeister) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/alexhagemeister/prime-gnadd --- # Prime Orient a new chat session with the project's current state. This is read-only: do not create, edit, stage, commit, stash, or delete files. ## Auto-Invocation Gate If this skill was auto-selected from context rather than explicitly invoked with `/prime-gnadd`, stop before running commands. Briefly explain why a repo snapshot appears useful and ask: "Run `/prime-gnadd` now?" Proceed only after confirmation. ## GNADD Invariants - `prime-gnadd` gives spatial awareness and momentum; it does not load implementation context speculatively. - GitHub is the system of record, so open issues, open PRs, recent merged PRs, branches, and commits are the working state. - Surface local `main` divergence and stashes prominently, but do not fix them here; this skill is read-only. - For broader workflow or file-hygiene guidance, use `help-gnadd`. ## Mechanics Git state classification runs through the bundled script — `gnadd.sh` in this skill's directory (the directory containing this SKILL.md). If the script is missing, stop and tell the user to reinstall the GNADD skills per help-gnadd's Install & Update guidance (`npx skills update -y` in the scope used at install, or `scripts/sync.sh` for local-checkout installs); do not reconstruct its logic from raw git commands. ## Commands Run the state snapshot first: ```bash bash "/gnadd.sh" state ``` It fetches (`git fetch --prune` — updates remote-tracking refs only, touching no working files, so it honors the read-only contract) and reports: current branch, detached HEAD, tree clean/dirty (with each dirty path listed under `dirty_files`), stash count, active issue number, and the main classification (`synced` / `behind` / `diverged`, with the divergent commits listed when dangerous). If the repo has no remote it reports `remote=none` — note that and move on. Then gather orientation context: ```bash tree -a -L 2 -I 'node_modules|__pycache__|.git|dist|build|.next|.venv|coverage|target|vendor|.pytest_cache|*.egg-info' git log --oneline -15 git branch --list ``` If `tree` is not installed, use `find . -maxdepth 2 -type d -not -path './.git*' -not -path './node_modules*'` instead. Then check for the intent document: ```bash test -f VISION.md && sed -n '/^## Core/,/^## /{/^## Core/p;/^## /!p;}' VISION.md | head -40 ``` If `VISION.md` is absent, note nothing (a project without one works as before). If present, read only the Core section shown; do not read the rest of the file unless the user asks. Then check GitHub CLI auth: ```bash gh auth status ``` **If `gh` is unavailable or unauthenticated:** do not abort. Report the local snapshot anyway — it contains the safety-relevant signals (divergence, stashes, dirty tree) — and note that issue/PR context was skipped; suggest `gh auth login`. When auth is confirmed, print the authenticated login (the authorship baseline referenced by Interpretation below — it must be visible output, not a shell variable, since shell state does not persist between commands), then list with authors included: ```bash gh api user --jq .login gh issue list --state open --json number,title,author,labels --jq '.[] | "#\(.number)\t\(.author.login // "ghost")\t\(.title)\t\([.labels[].name] | join(","))"' gh pr list --state open --json number,title,author,isDraft --jq '.[] | "#\(.number)\t\(.author.login // "ghost")\t\(if .isDraft then "draft" else "open" end)\t\(.title)"' gh pr list --state merged --limit 10 --json number,title,author --jq '.[] | "#\(.number)\t\(.author.login // "ghost")\t\(.title)"' bash "/gnadd.sh" phase status ``` If `state` reported an active issue N (`issue=`), also run both (the issue view prints a comment count, never the comments, so the round trail needs its own read): ```bash gh issue view bash "/gnadd.sh" round list ``` ## Interpretation ### Project Shape Use the tree output to identify the top-level layout: where source, config, tests, docs, and scripts appear to live. Keep this shallow. Do not inspect files unless the user asks. ### Vision Only when `VISION.md` exists: report that it is present and summarize its Core section in two or three lines (the experience at the center and the numbered invariants by name). Do not summarize the possibility space or open tensions, and do not restate anything as a task. When it is absent, omit the section entirely. ### Recent Git History Use `git log --oneline -15` to infer the recent trajectory — active areas, development focus, recently completed themes. Avoid over-explaining individual commits. ### Current State From the `state` output, report: - Active branch and whether the working tree is clean. When it is dirty, name the files from the `dirty_files` listing. - Other local branches that may indicate in-progress work. - **`main_state=behind`:** normal and safe — origin has commits local main lacks. Say so plainly: "local `main` is N commits behind origin; it will sync on the next `/start-issue-gnadd`." - **`main_state=diverged` (dangerous):** local `main` holds commits origin lacks (git calls this "ahead"; in GNADD every commit reaches `main` through a PR, so a local-only commit on `main` is divergence, not progress). **Flag it as the first line of the summary**, recommend resolving before any new work, and point at the sanctioned recovery path: `gnadd.sh doctor` diagnoses it and `doctor --rescue-main ` performs the lossless fix, then prints the rescued branch's exits (quickfix, `start --from`, or `drop`). Do not fix it from this skill. - **Stashes:** if `stashes` is nonzero, surface it — invisible saved work, easy to abandon. - **Unpushed checkpoints:** on an issue branch, `upstream=none` or a nonzero `ahead_of_upstream` means commits exist only on this machine. Say so: the round trail on GitHub is behind the branch until the next `round post` or `push`. ### Authorship Compare each listed item's author against the authenticated login printed in the commands step. Items authored by anyone else — including bots and `ghost` (deleted accounts) — are **external submissions**: annotate them inline (`— by @`) wherever they appear in the summary, and if any exist, say so up front in the relevant section ("2 of 5 open issues are external"). When every item is self-authored — the common solo case — add no annotations and no authorship commentary at all; the snapshot stays exactly as uncluttered as before. ### Phase From `phase status`: when a milestone is open, report its title, its description (what the phase is trying to find out and what ends it), and the open and closed issue counts. When it reports `phase=none`, say plainly that no phase is open. If more than one milestone is open, report them all and repeat the script's note: the phase rule wants exactly one. Never open or close a phase from this skill. ### Open Issues Summarize pending work from the issue listing. Group by label when present; keep issue titles and numbers visible. Apply the authorship rule — external issues are input from other people and usually deserve a triage look before new self-directed work. ### Open PRs Surface work in flight. Flag PRs awaiting review — a PR sitting open is either waiting on you to review/merge or waiting on feedback. Apply the authorship rule: an external open PR is someone waiting on the maintainer, and outranks self-authored work in the "what needs attention" ordering. ### Recent Completions Summarize the last ~10 merged PRs. Highlight momentum, not every detail. Apply the authorship rule to reveal whether recent shipping was solo or included external contributions. ### Active Issue Only when on an `issue-/` branch: summarize the issue's problem, desired outcome, and subtasks, then the last round from `round list`: its number, what changed, and its feedback in the user's words as the comment has them. A round's feedback is its own "Round N feedback" comment or the block in round N+1. When the last round has neither, say "no feedback on the record yet", which is not "the user had no opinion"; `start-issue-gnadd` asks. When `rounds=0`, say the branch has no round trail. Do not fetch referenced issues or artifacts automatically. ## Output Format ```markdown ## Project Shape <1-2 sentences about top-level layout> ## Vision ## Current State ## Recent Activity ## Phase ## Open Work ## In Flight ## Recently Shipped ## Active Issue ``` Keep the summary short enough to use as quick working context. ## Closing Guidance Offer a brief next-step nudge only when orientation completed successfully — not when the skill halted mid-run. **Skip** when blockers were surfaced in the summary (diverged `main`, stashes, dirty tree on the wrong branch). Nudge toward resolving those first — for a diverged main, that means `gnadd.sh doctor` — not advancing the happy-path loop. **Infer one primary suggestion** from repo state, plus at least one alternative when ambiguous: 1. Open PR awaiting review → review or merge before starting new work. 2. On `issue-/*` with a dirty tree → `/commit-gnadd` or continue implementation. 3. On `issue-/*`, clean → continue that issue's work. 4. On clean `main` with open issues → `/start-issue-gnadd ` on the most actionable issue. 5. No open issues → `/new-issue-gnadd`. Keep it to a sentence or two with invitational options. Do not restate the full GNADD workflow.