G Identity

---
name: g-identity
description: Synthesise the project's operational identity from accumulated history — recurring risks, architectural personality, delivery cadence, characteristic strengths and friction points. Output is a narrative summary written to g-docs/identity.md plus a printed snapshot. Read-only.
context: [institutional, architectural, sprint]
---

**Announce:** "Using g-identity to synthesise the project's operational personality from accumulated history."

You are running a long-horizon synthesis: read everything the project has accumulated about itself and produce a coherent description of *who this project is, operationally*. Not metrics in a table — a narrative the developer can show to a new collaborator and have them understand the texture of the work.

## Step 1 — Gather every signal source

Read in parallel:

- All files in `g-docs/retros/` — every retro the project has produced
- All files in `g-docs/forecasts/` — premortems and their Outcome rows
- All files in `g-docs/telemetry/` — historical telemetry snapshots
- All files in `g-docs/blast-radius/` if present — recurring blast-radius targets surface hot zones
- `g-docs/decisions/` if present — ADRs reveal the project's stated values
- `CHANGELOG.md` — what the project chose to ship and when
- `git log --oneline -200` — delivery cadence proxy
- `g-docs/ROADMAP.md` — what's done vs. what remains, version history
- `g-docs/project_brief.md` if present — original goals and constraints

If the corpus is thin (zero retros AND zero forecasts AND fewer than 50 commits), stop:
```
✗ Corpus too thin to synthesise identity. Identity emerges from accumulated retros, forecasts, and history — run /g-retro at milestone close and /g-forecast at plan time to build the corpus.
```

## Step 2 — Categorise signals

Group everything by theme. Suggested buckets:

- **Recurring risks** — failure modes that appear in ≥2 retros' "Avoid / do differently" or ≥2 forecast Outcome `yes` rows
- **Reinforced strengths** — patterns appearing in ≥2 retros' "Worked well"
- **Architectural choices** — explicit decisions in ADRs and consistent patterns in the codebase
- **Velocity texture** — commit cadence, gaps, sprints (read git log timestamps)
- **Hot zones** — files appearing in ≥3 blast-radius reports or with consistently high volatility
- **Friction points** — areas where retros repeatedly flag pain (e.g. same tool, same review type, same kind of bug)

Apply the same `None recorded.` sentinel filter as `/g-patterns` and `/g-forecast` — empty signals are not data.

## Step 3 — Synthesise the narrative

Write 5 short sections, each 2–4 sentences. The voice is observational, not prescriptive — describe what *is*, not what *should be*.

1. **What this project is** — the goal in one sentence, plus the operational shape (single-developer plugin, multi-stack web app, etc.). Source: project_brief, ROADMAP.
2. **How it ships** — delivery cadence in qualitative terms: "ships in concentrated bursts every few weeks" or "steady drumbeat of small commits" or "long gaps punctuated by milestone closes". Source: git log timestamps + CHANGELOG.
3. **What it does well** — reinforced strengths. Cite 1–2 source retros by filename.
4. **Where it struggles** — recurring risks and friction points. Cite 2–3 sources. Do not prescribe fixes; just name the pattern.
5. **What it's becoming** — architectural direction from ADRs, CHANGELOG trajectory, and roadmap. One paragraph.

## Step 4 — Persist identity snapshot

Write to `g-docs/identity.md` (overwrite if exists). Schema:

````markdown
# Project identity — [YYYY-MM-DD]

> Generated by /g-identity from N retros · M forecasts · K telemetry snapshots · L commits

## What this project is

[2–4 sentences]

## How it ships

[2–4 sentences with delivery-cadence observations]

## What it does well

[2–4 sentences. Sources: <retro filenames>]

## Where it struggles

[2–4 sentences. Sources: <retro filenames>]

## What it's becoming

[1 paragraph on architectural direction]

## Sources

- Retros read: [N]
- Forecasts read: [M]
- Telemetry snapshots: [K]
- Commits sampled: [L]
- ADRs: [count]
````

## Step 5 — Print the snapshot

Print the same content verbatim to the chat so the developer can review it without opening the file. End with:
```
Written: g-docs/identity.md
```

## Rules

- Read-only on every source. Never modify retros, forecasts, telemetry, ADRs, ROADMAP, or git state.
- Narrative voice — not metric tables. The Snapshot file produced by `/g-telemetry` already covers the quantitative view; `g-identity` is the qualitative complement.
- Always cite source retro filenames in "What it does well" and "Where it struggles" — traceability matters and developers must be able to verify the synthesis.
- Never predict, recommend, or prescribe. This skill describes the project; it does not tell it what to do. Recommendations are the role of `/g-patterns` and `/g-forecast`.
- Overwrite `g-docs/identity.md` on each run — there is no version history kept inside the file. The git history of `g-docs/identity.md` itself is the version record.
- On a thin corpus, refuse — never fabricate a personality from a small sample. The threshold check in Step 1 is strict.