prof18/feedflow-issue-triage.md Secret

## feedflow-issue-triage.md

      
    Raw
  

              feedflow-issue-triage.md
            
          
    name
    feedflow-issue-triage
  
  
    description
    Triage FeedFlow issue-related Gmail messages into the FeedFlow Obsidian board and notes vault. Use when reviewing FeedFlow emails from Gmail, classifying them as bugs, feature improv, or new features, creating notes in /Users/mg/Workspace/Notes/projects/feed-flow/notes, updating /Users/mg/Workspace/Notes/projects/feed-flow/feed-flow-board.md, and marking processed Gmail messages with the FeedFlow/Triaged label while skipping Renovate, GitHub workflow-status notifications, and other non-issue operational mail.
  
  
FeedFlow Issue Triage

Use This Skill


Access the Gmail mailbox through gws gmail.
Triage FeedFlow-related emails into the FeedFlow Obsidian board.
Create one note per actionable unresolved issue in the FeedFlow notes folder.
Mark processed emails with the Gmail label FeedFlow/Triaged and mark them as read.

Fixed Context


Mailbox used in current setup: mymail@gmail.com
FeedFlow board: /Users/mg/Workspace/Notes/projects/feed-flow/feed-flow-board.md
FeedFlow notes folder: /Users/mg/Workspace/Notes/projects/feed-flow/notes
Primary FeedFlow repo for implementation checks: /Users/mg/Workspace/feedflow/feed-flow
Gmail triage label name: FeedFlow/Triaged
Gmail triage label id: Label_123456
Optional Gmail label present but currently unused for discovery: FeedFlow (Label_123456)

Source Types


Sentry issue alerts from noreply@md.getsentry.com or equivalent Sentry senders.
Forwarded Firebase Crashlytics alerts, typically forwarded by mymail@gmail.com from firebase-noreply@google.com.
Direct user emails sent to mymail@gmail.com.
GitHub notifications for prof18/feed-flow.

Ignore Rules


Skip Renovate PR emails, especially anything from renovate[bot].
Skip GitHub workflow-status notifications and other CI activity mail for prof18/feed-flow.
Examples: Run failed, Run completed, workflow digests, github-actions[bot] PR automation, and localization sync workflow failures.
Skip operational and vendor mail that is not an actionable product issue.
Examples: TelemetryDeck reports, Sentry subprocessor notices, generic newsletters, release marketing.
For ignored messages, do not create a note or board card. Still apply FeedFlow/Triaged and remove UNREAD so they are treated as processed.

Classification


Put crashes, parsing failures, regressions, and broken user flows in bugs.
Put improvements to existing UI, settings, workflow, or behavior in feature improv.
Put net-new capabilities in new features.
Default to bugs when the report describes broken behavior in the current product.

Workflow


List candidate Gmail messages that do not already have FeedFlow/Triaged.
Fetch metadata or full message bodies with gws gmail.
Filter out ignored messages after fetch. Do not rely only on Gmail query syntax for Renovate exclusion.
For ignored messages, stop after labeling them FeedFlow/Triaged and removing UNREAD.
Check for an existing note or board card before creating a new one.


Search by Gmail message id.
Search by Sentry issue id when present.
Search by Firebase issue id when present.
Search by distinctive subject or issue phrasing.
Search the board for an existing card, especially under ## done and ## user requests archive.


If the issue already exists and is still open, do not create a duplicate note or board card. Label the email FeedFlow/Triaged, remove UNREAD, and stop.
Run a local resolved check against the FeedFlow repo before creating a new ticket.


Build a short search query from the report: exception name, failing function, feed/domain, screen name, platform, and 2 to 5 distinctive keywords.
Search the repo with rg for those exact identifiers and phrases.
Search recent git history with git -C /Users/mg/Workspace/feedflow/feed-flow log --oneline --decorate -n 200 --grep "<keyword>" for likely fix commits.
Read /Users/mg/Workspace/feedflow/feed-flow/version.properties to know the current app version when the email includes an older reported app version.
Treat the issue as already resolved only when there is strong evidence, such as a matching done card/note, a clear fix commit in the relevant area, or code that already contains the exact guard/behavior the report says is missing.
If the evidence is weak or ambiguous, continue and create the ticket. Prefer false negatives over incorrectly suppressing a real issue.


If the issue appears already resolved and it is a Sentry alert, mark the Sentry issue as fixed in the next release before finishing triage.


Use the current app version from /Users/mg/Workspace/feedflow/feed-flow/version.properties as the target release version.
Use the Sentry issue URL or issue id from the email/note metadata so the correct issue is updated.
If the current environment does not expose a Sentry write action, leave a breadcrumb in the triage output that the issue should be marked as fixed in the next release manually, then continue with email triage.


If the issue appears already resolved, do not create a new note or board card. Label the email FeedFlow/Triaged, remove UNREAD, and stop.
For Sentry and Firebase crash alerts that are not already resolved, run an actionability check before creating a ticket.


Decide whether the report is a real app bug, data loss risk, repeated user-visible failure, crash loop, sync corruption, broken platform integration, or noisy/incorrect telemetry that should be fixed.
Also decide whether it is benign: already handled by the app, expected external/user/environment failure, canceled operation, unavailable local file/device/network resource, stale one-off state, unsupported user setup, or a single exotic occurrence with no clear product impact.
If the only issue is telemetry classification, say so explicitly. A small logging/noise fix can be worthwhile, but do not treat it like a product bug or create a board card unless the user asks.


If the behavior is benign and the app is already doing the right thing, do not create or keep a note or board card. Label the email FeedFlow/Triaged, remove UNREAD, and stop after reporting the skip reason and any uncertainty, such as missing live Sentry counts.
Choose a concise note title that describes the user-visible problem.
Create a note in the FeedFlow notes folder.
Insert - [ ] [[Note Title]] under the matching section in the FeedFlow board.
Apply the Gmail label FeedFlow/Triaged to the source message and remove the UNREAD label in the same modify call.
Verify the label on a follow-up Gmail read when practical.

Resolved Check Guidance


Start with the notes folder and board before searching code. A matching done card or archived request is the strongest signal that a new ticket would be duplicate churn.
For Sentry and Firebase alerts, search the repo with stable identifiers first: issue id, exception class, top stack frame, feature name, and platform.
For user emails, search by the user-visible symptom, affected screen, sync provider, feed domain, and any quoted error string.
When the email includes an app version, compare it with /Users/mg/Workspace/feedflow/feed-flow/version.properties. An old reported version is supporting context, not proof by itself.
Only skip ticket creation when the resolution signal is concrete enough that you would be comfortable explaining why the report is already covered.
When skipping a new ticket because the issue is already resolved, leave a short breadcrumb in the triage thread summary describing the evidence you found, for example the matching done note title or the fix commit subject.
For Sentry alerts that are already fixed, prefer closing the loop in Sentry immediately by marking the issue as fixed in the next release tied to the current repo version.

Actionability Guidance


For Sentry and Firebase alerts, distinguish real product bugs from handled or expected failures before creating a note or board card.
Actionable examples: unhandled crashes, repeated user-visible breakage, data loss, sync corruption, broken platform integration, missing guard that can be fixed, and noisy telemetry that is frequent enough to hide real issues.
Benign/no-card examples: failures already handled by the UI, user-selected files or devices that disappeared, permission or environment problems outside the app's control, canceled operations, transient network/provider failures, unsupported setups, stale one-off state, and single exotic occurrences with no clear product impact.
If the app behavior is correct but Sentry was notified because of logging severity or exception classification, call it a telemetry classification issue. Do not create a board card unless the user asks or the noise is frequent enough to merit a small cleanup.
If live Sentry context is unavailable, do not pretend to know recurrence. Make the best decision from the email, existing notes, and current code, then state that live counts were not verified.
Even when skipping note/card creation, still process the source email by applying FeedFlow/Triaged and removing UNREAD.

Note Format

Start the note with plain key: value lines, then add readable sections.
Use this structure and fill the fields that exist:
source: gmail
source_type: sentry|user-email|github
sender:
subject:
date:
gmail_message_id:
gmail_thread_id:
sentry_issue_id:
sentry_url:
firebase_issue_id:
firebase_issue_url:
triage_category: bugs|feature improv|new features
reported_platform:
reported_platform_version:
app_version:
sync_account:

## Summary
...

## Email Source
- Sender: ...
- Subject: ...

## Body
...
Remove fields that do not apply instead of leaving them blank.
Body Guidance


Preserve the sender and subject exactly.
Preserve the Sentry issue id exactly when present.
For forwarded Firebase Crashlytics mails, preserve the forwarded Gmail sender and subject, then also capture the original Firebase sender and subject in the body.
Preserve firebase_issue_id and firebase_issue_url when they are clearly extractable from the email or its raw body.
If the forwarded Firebase email does not expose a stable standalone Crashlytics issue id, say that explicitly in the note body instead of inventing one.
Summarize the report so the issue is understandable without reopening Gmail.
Include concrete environment details from the email when present.
Quote short user-reported problem statements when that preserves meaning.

Tooling Guidance


Prefer gws schema when unsure about Gmail command payloads.
If gws gmail fails in sandbox due to keychain or root certificate access, rerun the Gmail command with escalated permissions.
For Firebase/Crashlytics forwards, inspect the raw Gmail message when needed because the plain-text view may hide or wrap the original alert link.
Use Firebase MCP only when it can provide issue-level context for the specific alert; otherwise rely on the forwarded email content and preserve any stable identifiers or URLs the email exposes.
Use rg for repo and notes searches, not slow recursive grep.
Use git log in /Users/mg/Workspace/feedflow/feed-flow when the report looks like it may already have landed as a recent fix.
If Sentry mutation tooling is available in the current environment, use it to mark already-fixed Sentry issues as fixed in the next release. If it is not available, record that follow-up explicitly in the triage output.
Use Obsidian CLI if it is working.
If Obsidian CLI is unavailable or unresponsive, edit the vault files directly.
No results found