g-identity · diff
git:20260519.96d0097 to git:20260628.bdb8cad
9 added, 9 removed. Audit A to A.
---
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 docs/identity.md plus a printed snapshot. Read-only.
+ 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 `docs/retros/` — every retro the project has produced
- - All files in `docs/forecasts/` — premortems and their Outcome rows
- - All files in `docs/telemetry/` — historical telemetry snapshots
- - All files in `docs/blast-radius/` if present — recurring blast-radius targets surface hot zones
- - `docs/decisions/` if present — ADRs reveal the project's stated values
+ - 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
- `ROADMAP.md` — what's done vs. what remains, version history
- `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 `docs/identity.md` (overwrite if exists). Schema:
+ 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: docs/identity.md
+ 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 `docs/identity.md` on each run — there is no version history kept inside the file. The git history of `docs/identity.md` itself is the version record.
+ - 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.