Skip to content
Claresia Docs

For Engineers

You’re an engineer. You live in your IDE, your code-review tool, your terminal, your incident channel, and your LLM. Claresia adds 5 skills that fit into that flow without making you context-switch.

This guide is the first week.

What landed in your LLM

Section titled “What landed in your LLM”

For the standard Software Engineer Cowork:

SkillWhen you’d use it
gatespic.incident-postmortemWithin 24h of any P1/P2 incident
gatespic.change-risk-reviewBefore merging a deploy that touches prod
gatespic.on-call-handoffEnd of every on-call shift
steve.prd-reviewWhen you’re the engineering reviewer on a PRD
steve.acceptance-criteria-genWhen you draft an internal feature spec

If you’re on the Eng Lead Cowork, you also get steve.rice-scoring, gatespic.security-advisory-triage, and boss.team-weekly-digest.

Day 1 — your first incident

Section titled “Day 1 — your first incident”

3 AM, PagerDuty fires: INC-2026-04-1873 — firmware regression in feat/v8-bms.

You diagnose, ship a hotfix, page off. The incident is closed at 5 AM.

That morning at 9, you open your LLM and type:

@claresia.gatespic.incident-postmortem INC-2026-04-1873

Returns within ~3 seconds:

Incident Postmortem — INC-2026-04-1873

Summary

Section titled “Summary”

A firmware regression in branch feat/v8-bms caused 18 minutes of battery-management write failures across the European fleet…

Timeline

Section titled “Timeline”
  • 02:14 — feat/v8-bms deployed to canary (1% of fleet)
  • 02:31 — Telemetry alert: write_failure_rate > 0.5%
  • 02:34 — On-call engaged
  • 02:47 — Rollback triggered
  • 02:53 — Fleet stable; canary held
  • 04:21 — Hotfix feat/v8-bms-hotfix-1 deployed
  • 04:55 — Closed

Root cause

Section titled “Root cause”

The bms_v8.write_cell_state() call had an off-by-one in the cell index calculation when cell_count > 64. The European fleet’s most recent battery design uses 72 cells; previous test fixtures topped at 60.

Impact

Section titled “Impact”
  • 18 min of degraded write availability for ~12K vehicles
  • 4 customer support tickets received
  • No data loss (writes queued + retried)

Remediation

Section titled “Remediation”
  • Hotfix shipped (commit a1b2c3d4)
  • Test fixture extended to 72 cells (PR #4231)
  • Pre-deploy linter added for off-by-one in cell-index helpers (PR #4232)

Lessons learned

Section titled “Lessons learned”
  • The canary cohort caught it (correctly), but the alert threshold could be tighter. Proposed: lower threshold from 0.5% to 0.2% — rollback would have triggered 6 minutes earlier.
  • Test fixtures need to track real fleet hardware variation more aggressively.

Claresia · Incident Postmortem · $0.04 · 2.3s · View record

You review, edit a few sentences, click Capture decision to log your approval as a decision Hub record. The PIR is now in your team’s audit chain

  • available to anyone with access to the Hub.

Day 2 — pre-deploy change review

Section titled “Day 2 — pre-deploy change review”

You’re about to merge a PR that touches production. You type:

@claresia.gatespic.change-risk-review

Parameters:

  • PR URL: https://github.com/dainese/firmware/pull/4232
  • Deploy target: prod-eu

Returns a risk score (low / medium / high) with a reasoning chain:

  • Files touched (✓)
  • Test coverage delta (✓)
  • Recent incidents in this code area (none in 30 days)
  • Deploy time of week (Tuesday afternoon — green)
  • Suggested rollout plan (canary 1% → 10% → 100% over 4 hours)

If “high”, the skill suggests holds + checklists. You can capture your decision (proceed / wait / re-test) as a Hub record.

Day 3 — you’re on call this week

Section titled “Day 3 — you’re on call this week”

End of shift Friday, you type:

@claresia.gatespic.on-call-handoff

Returns a structured handoff to next week’s on-call engineer:

On-Call Handoff — Week of Apr 22 → Marco Mazzolin → Tommaso Masiero

What I shipped

Section titled “What I shipped”
  • Hotfix INC-2026-04-1873 (closed)
  • Tightened canary threshold (PR #4231)

What’s still warm

Section titled “What’s still warm”
  • PR #4225 — pending review from Tommaso
  • Customer ticket #2891 (high-cell-count battery, EICMA prep) — escalated to product team

Risks for next week

Section titled “Risks for next week”
  • EICMA show this weekend → expect spike in EU traffic Sunday → Monday
  • New firmware push planned Wed; defer if Sunday traffic spikes

Runbooks updated

Section titled “Runbooks updated”
  • docs/runbooks/battery-write-failure.md — refreshed with the v8 lesson

You drop this in your team’s #oncall channel. Tommaso has a one-page summary to start his week.

Day 4 — a PRD lands in your queue

Section titled “Day 4 — a PRD lands in your queue”

A new PRD lands in your queue from product. You type:

@claresia.steve.prd-review

Parameters:

  • PRD URL or paste: (paste the PRD)
  • Review depth: engineering (vs executive or design)

Returns a structured PRD review:

  • Engineering feasibility per requirement (✓ / ⚠️ / 🔴)
  • Open questions for the PM
  • Estimated effort by area
  • Risks (technical, dependency, deploy)
  • Acceptance criteria check (vs the company rubric)
  • Suggested follow-up: who else to loop in

You forward to the PM with your endorsement (or pushback). The decision Hub record captures your stance.

Day 5 — drafting your own spec

Section titled “Day 5 — drafting your own spec”

You’re spec’ing a new internal tool. You type:

@claresia.steve.acceptance-criteria-gen

Parameters:

  • Feature description: (1-paragraph from your spec)
  • Personas affected: firmware-engineer, sre
  • Format: gherkin (or bdd, checklist)

Returns 8–12 acceptance criteria in your chosen format. You paste into your spec doc.

Section titled “Hub deep-link footer”

Every response ends with a footer link:

*[View record](https://hub.dainese.claresia.com/records/rec_abc)*

Click to see:

  • The full payload
  • The provenance hash + co-sign verification
  • Linked records (e.g., the original incident, the related PR)
  • Your team’s commentary thread (if anyone added a comment)

Tips from real engineers

Section titled “Tips from real engineers”
  • Run incident-postmortem within 24h. The model has the freshest context (recent commits, recent telemetry). Don’t wait a week.
  • Use change-risk-review for any deploy touching prod, not just “scary” ones. It’s the Marie Kondo of code review — tells you when something is fine.
  • The on-call handoff skill is not a replacement for talking to your successor. It’s the structured doc you give them so the conversation can be 5 min instead of 30.
  • Your IDE-side tools (Cursor, Continue, Copilot Code) are NOT Claresia. Those are great for code generation. Claresia is for the org-memory side: postmortems, PRDs, decisions, runbooks.

Maturity progression

Section titled “Maturity progression”

L0 → L1 in ~4 weeks:

  • 8+ invocations/week, 3+ unique skills, 4 weeks

L1 → L2 in ~14 weeks:

  • 12+ invocations/week, 5+ unique skills
  • Author or maintain at least 2 custom skills for your team
  • Pass the Agent Operator Certification (Forge)

Help

Section titled “Help”
  • @claresia.forge.coaching-session — Socratic walk-through, 3-level hint escalation
  • Your team channel + your CSM
  • This docs site