01Intake
Preserve the raw report.
Sigilix keeps the original customer wording instead of rewriting over it. The vague report stays available as the source signal.
Original title
Reporter note
Customer impact
Triage that starts the repair.
A vague ticket should not become another meeting. Sigilix turns unclear Linear and Jira work into a grounded issue, an owner, and a repair path.
It keeps the human report intact, reads the surrounding code and workflow history, rewrites the issue with evidence, assigns the right person, and can open the PR when the next step is concrete.
Watch it work
A ticket, triaged in real time.
Sigilix takes a vague Linear ticket and returns a grounded issue — priority, owner, evidence, and a repair path — without overwriting the original report.
Sequence
The full pass.
The outcome is not one rewrite. It is a chain of small decisions that turns intake into a PR-ready unit of work.
02Grounding
Read the nearby system.
It pulls the recent pricing PR, checkout callback logs, billing worker code, CI output, and related Linear issues before naming the bug.
PR #1279
checkout callback
billing worker
03Triage
Rewrite the issue into work.
The title, severity, labels, suspected files, repro path, duplicate links, and missing proof are written back into the ticket.
P1
billing regression
retry_state path
04Ownership
Assign with a reason.
The assignee is chosen from ownership, recent edits, and availability. The reason is visible so it can be corrected by the team.
Touched files
recent PR author
on-call context
05Repair
Open the PR.
When the failure path is strong enough, Sigilix creates the branch, opens the PR, links the issue, and carries over the verification checklist.
fix branch
PR body
acceptance checks
06Memory
Keep the lesson bounded.
The confirmed bug shape, false paths, and final fix become memory for the next similar ticket without hiding what was learned.
confirmed cause
discarded theories
merged fix
Pull request
The PR starts with context.
GitHub PR #1284
Fix checkout retry state during plan migrations.
The branch is created from the triaged issue, not from a blank prompt. The PR body carries the suspected failure path, linked Linear ticket, affected files, and verification plan.
Branch: fix/linear-412-billing-retry-state
Linked issue: LIN-412 checkout retry state
Owner: Self-assigned to you with billing-worker ownership attached
Preserve retry_state before subscription_tier migration commits.
Re-run checkout callback when the first billing write fails.
Cover duplicate callback delivery and plan downgrade paths.
Close the Linear ticket only after the retry fixture passes.
Before / after
What changes in the ticket.
Title
Before
Checkout is broken again.
After
P1: Billing webhook drops checkout retry state after plan migration.
Severity
Before
None. The team has to infer urgency from a short customer note.
After
P1, with customer impact and affected checkout path attached.
Owner
Before
Unassigned. Whoever sees it first has to decode it.
After
Self-assigned to you with the ownership reason visible in the issue.
Evidence
Before
No code path, no recent PR link, no logs, no duplicate check.
After
Linked PR, suspected file, callback logs, duplicate issues, and missing checks.
Repair
Before
The ticket still needs someone to start from scratch.
After
Branch and PR opened with reproduction notes and acceptance criteria.
Surfaces
It stays where the work is.
Linear and Jira
Triage updates the issue where the team already tracks work: title, priority, severity, owner, duplicate links, and next action.
GitHub
The PR starts with the issue, suspected code path, reproduction notes, and verification plan already attached.
CLI
Local repair keeps the triage context close to the repository instead of making you restate the failure from scratch.
Learn more->