القائمة
Whacking diffs and PRs into sanity
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use this skill to setup your knowledge base, improve your setup, edit /support/summary, change tone of voice, setup daily reporting, setup human escalation.
Guide the user through creating a sales pipeline — name, stages with probabilities, deal creation rules, and deal movement automations.
Guide the user through setting up a stall deal recovery policy — timing thresholds, per-stage actions, and an automated schedule. Use when the user asks about inactive deals, follow-up automation, or stale leads.
Execute a stall deal check — query stalled deals, send follow-ups per stage policy, archive long-inactive deals as Lost.
Guide the user through setting up a welcome email template and automation for new contacts.
Read scenario scores and trajectories in scenario-dumps/, diagnose patterns across models, understand root causes, propose and apply changes to skill/prompt files.
| name | pr-police |
| description | Whacking diffs and PRs into sanity |
| allowed-tools | Read, Grep, Glob, Bash(git diff*), Bash(gh pr view*), Bash(gh pr diff*), Bash(gh api *) |
Review git diff (unstaged) and git diff --cached (staged) for the current changes.
Read flexus-client-kit/AGENTS.md to understand the project values.
For each changed file, read enough surrounding context to understand what the change does.
Sweeping problems under the rug is bad. Some examples: result.data?.field, x || "", if (result.something_useful) { use it }.
Catching exceptions is bad, especially Exception/BaseException, instead investigate what the calling code would do with the exception, in all likelihood it already does the right thing. Catching a specific error might be a good idea, such as SlackApiError. If it's hard to predict what the exception will be, then write log, crash. Crash is easy to fix later.
Writing isinstance(x, type1) is bad. Decide what type the data should be and stick with it. Make sure the code crashes if the type is wrong. Crash is easy to fix later.
Names must indicate purpose, intent, joke, be unique/searchable, and not already exist in hundreds of places. Avoid: event, data, handler.
Local variables should be one letter like i or x to indicate short life. Flexus uses prefixes for field names (should be fgroup_name not name).
It's more of an issue for Flexus backend than in an individual bot that is not imported in other places, but still keep an eye for bad naming,
especially in integrations.
Instead write comments about: tricks, hacks, ugliness, places for future improvement (should start with XXX), facts hard to grasp just by looking at code, reasons for a piece of code to exist.
Don't pass ugly code without a comment why it exists.
Code should cover the spec of a bot (typically located in BOT_SPEC.md), in a simple straightforward way, not reinvent 100 other things.
Writing a ton of code is easy, value of a marginal line of code is negative. Not just text is bad for clogging context, any logical gates are bad, making it harder to understand what the code actually does.
Generally simplicity and deleting code is good. Complexity and adding code is bad.
Oh yes, it's easy to write a ton of prompts and instructions as well. Value of additional instructions is negative. Shorter prompts work better. What is the justification for adding new instructions, does it actually build a consistent case for the model to follow?
Are the new instructions more atomized, cheating particular use cases to pass, at the expense of instructions being short and simple?
It might be a next step from the current diff, sure, but prompts need testing. Scenarios are the tool for that, the whole utility of a bot from beginning to end should be demonstrated using a scenario. Accept a PR with changes in instructions if it handles scenario better: responses are better or the same, more models work.
Before a bot becomes public, it goes through a review. The review looks at:
Your role is to flag those things before it gets to review: reject crazy libraries, make sure coroutines are 200% reliable, etc.
Bots allow Microfrontends, html files that show an editor for Policy Documents to work together with the user. Does not mean this particular bot should use it! Use QA or Schemed to avoid large hard-to-debug html blobs. Should be a really good case for Microfrontends, like a map or something.
Stick to 1 or 2 main issues. Write it as a short, opinionated review, a paragraph or less.
When there's no global problems, and only issues with files, then quote what is wrong and point out small problems.
If the diff is clean, say so. Don't invent problems. Be direct — "this is bad because...".
