Safina

The Daily Loop

Every working session follows the same four-step loop. Each step has a prerequisite. Skipping steps breaks context — your ticket won’t be linked, your standards won’t be checked, and your PR will go out with unresolved problems.

The flow

flowchart TD
    A["/safina:backlog\nPull tickets · pick focus · set session context"]
    B["Do the work\nWrite code · write unit tests · commit"]
    C["/safina:test\nConformance + correctness · standards · QA readiness"]
    D["Fix Errors"]
    E["/safina:hunt\nSecurity · CVEs · bugs · regressions · flaky tests"]
    F["Remediate"]
    G["/safina:update\nPost commit summary · Slack · QA handoff"]
    H["Merge / PR"]

    A --> B
    B --> C
    C -->|"Errors"| D
    D --> C
    C -->|"Clean"| E
    E -->|"Errors"| F
    F --> E
    E -->|"Clean"| G
    G --> H

Step-by-step

1. /safina:backlog — every session, first

Pull your assigned tickets from Linear (Tier 1) or GitHub issues (Tier 2). Pick what you’re working on today. The ticket ID you confirm here is the context that /safina:update requires.

What it gates: /safina:update will not post an update without a ticket. If you try to run it without knowing your ticket, it stops and sends you back here.

→ /safina:backlog guide

2. Do the work — and write tests

Write code. As you work, write the unit tests that cover what you’re building. This is not optional — /safina:test checks for test coverage before running standards checks, and flags missing tests as a Error.

What it gates: /safina:test scans for test files covering the changed code before doing anything else. No tests → Error → you write tests first.

3. /safina:test — before merging

Reads the diff against Ilmiya’s skills docs and checks:

  • Standards: API design, resource naming, error design, naming conventions, observability
  • Correctness: does the implementation do what it claims?
  • Test coverage: are critical paths covered and are assertions real?
  • Commit convention: do commits follow the Ilmiya format?

Produces a report: Errors (must fix) / Patches (should fix) / Notices (worth knowing).

Fix all Errors before moving forward.

→ /safina:test guide

4. /safina:hunt — before any PR or merge

Goes on the offensive. Hunts for what a developer wouldn’t catch in normal review:

  • Security vulnerabilities (OWASP Top 10, auth bypass, injection, exposed secrets)
  • Dependency CVEs and version mismatches
  • Hidden bugs: null dereferences, unchecked errors, race conditions
  • Regressions in existing behaviour
  • Flaky test patterns
  • Data integrity gaps and multi-tenancy risks

What it gates: /safina:update will not apply a QA-ready or PR-ready flag if hunt hasn’t been run or if Errors remain unresolved.

→ /safina:hunt guide

5. /safina:update — after committing work

Reads your recent git commits, links them to the right ticket, and posts a smart summary comment. Notifies Slack. Optionally flags the ticket as QA-ready and pings Adnan.

Requires:

  1. A ticket in context (from /safina:backlog)
  2. /safina:hunt run and Errors remediated (for QA or PR handoffs)

→ /safina:update guide

The report format

All three analysis commands (test, hunt) use the same three-tier severity:

TierMeaning
ErrorHard standard broken or critical vulnerability — must be fixed
PatchQuality gap or serious bug — should be fixed
NoticeWorth knowing, informational — not blocking

Only Errors block the loop. Patches and Notices are surfaced for awareness but don’t stop you from moving forward.

When to use Claude’s built-in commands

The ilmiya commands manage the backlog and quality loop. Claude’s built-ins complement them for the thinking and creation work in between:

Claude built-inWhen to use it
/planPlanning a new feature or breaking down a ticket
/reviewAd-hoc code review mid-work (less formal than /safina:test)

See Claude’s commands for the full picture.