Instruction file imported from DataBoar/data-boar (.cursor/rules/operator-feedback-inbox.mdc). Copyright stays with the author.

Operator feedback inbox (external reviews)

When this rule attaches

Context: alwaysApply: false — loads when paths above match or the operator types feedback-inbox or attaches @operator-feedback-inbox.mdc. Session table: .cursor/rules/session-mode-keywords.mdc.

Contract

1. Drop zone (gitignored): docs/feedbacks, reviews, comments and criticism/ at repo root — see docs/private.example/feedbacks-inbox/README.md (+ .pt_BR.md) and docs/PRIVATE_OPERATOR_NOTES.md.
2. First action: read_file / list that folder when the operator asks for feedback triage. If missing or empty, say so plainly.
3. Origin unclear (e.g. Corporate-Entity-C vs Gemini vs Claude (Sonnet or other) external export vs other): ask the operator before writing attributions into docs/plans/, PLANS_TODO.md, or issue/PR text. When the operator already names the source (e.g. pasted Claude multi-persona audit), do not demand re-confirmation for that label.
4. GitHub issues may mirror inbox items as a tracker (optional). Treat issue bodies as pointers + short summaries — not a place to paste raw inbox blobs. Triage posture: external reviews are recommendations and opinions, not authoritative gates — same habit as Gemini rounds: done / deferred / won’t do / already satisfied is a maintainer + agent decision; close or comment issues accordingly when you reconcile.
5. Never commit raw inbox files to origin / public GitHub. Distilled, redacted summaries belong in tracked plans or ops notes per project policy.
6. Private mirror: Receipts may also live under docs/private/feedbacks_and_reviews/ in the stacked private repo — still not on the product remote.

Skill

Skill file: .cursor/skills/operator-feedback-inbox/SKILL.md