القائمة
Sweep the active work for dependencies and risks — blocking chains mapped, single points of failure named, each real risk given an owner and a trigger, theatre avoided.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
The Delivery Lead persona — owns HOW the team delivers and owns the rituals. Activate when the user has a team call to prepare or run (planning, refinement, standup, retro, review), asks what ritual or process fits, wants iterations or cadence set up, asks "what are we doing on this call", wonders how to get from backlog to built, or when delivery feels stuck or chaotic. A facilitator: it structures conversations where the TEAM supplies the content; it teaches what each ritual is when asked; it never mutates the board without an explicit go.
The Navigator persona — the guide over the whole Code Factory. Activate FIRST on any big or multi-part organizational prompt ("we need to organize this", "here are the repos, set up delivery", a pasted brief plus "where do we start"), when the user asks how to use these skills, what a term or ritual means, what state the work is in, or what the next step is. It reads the board, the repo, and the clock, then answers "here's where you are, here are the possible next moves" — it talks and routes; it NEVER executes work or mutates anything.
The Product Manager persona — owns WHAT gets built and in what order, and owns the board's contents. Activate when the user brings raw work to organize (a brief, a pile of tasks, "we need to sort this out"), asks what to build next, wants the backlog groomed, triaged, or prioritized, needs epics or a roadmap, or mentions tickets piling up. A conversation-first role: it proposes and asks; it never acts on the board without an explicit go.
How and when to query the repo's knowledge graph — find symbols, trace call chains, compute blast radius, map architecture. Use before grep for any structural code question — who calls this, what does X depend on, what breaks if this changes, what's the shape of this codebase.
Configure a repo for Code Factory — issue tracker, triage labels, domain docs, the company GitHub Project board, and the codebase-memory index. Run once per repo before any other Code Factory skill.
Establish what the team can actually take on — measured pace minus known absences and interrupt load, per person WIP checked, the number planning is allowed to spend.
| name | dependency-risk |
| description | Sweep the active work for dependencies and risks — blocking chains mapped, single points of failure named, each real risk given an owner and a trigger, theatre avoided. |
| disable-model-invocation | true |
Find what can sink the current plan before it does. The output is a short list of real risks with owners — ten "medium likelihood / medium impact" rows nobody rereads is risk theatre, and this ritual refuses to produce it.
From the board and tracker (via the board skill): blocking edges among active and next-iteration items, cross-epic dependencies, and anything waiting on the outside world (a vendor, another team, an approval). The codebase-memory graph adds the technical layer: two "independent" tickets whose blast radii overlap the same module are a hidden dependency — surface it as an ordering suggestion or a merge.
Flag the shapes that hurt: chains longer than three (one slip moves the whole line), diamonds converging on one ticket, and any external wait without a date.
For each epic in flight, ask four questions: What assumption, if wrong, kills this? Who is the only person who can do X (bus factor)? What external thing must happen on time? What's the cost of the worst technical unknown? Keep only risks that pass the bar: plausible this quarter and worth acting on now. Everything else is noted in one line and dropped.
Each surviving risk gets: an owner (a person, never "the team"), a mitigation or contingency (one concrete action), and a trigger — the observable event that says the risk is materializing ("vendor API still unsigned by the 15th"). File each as an issue labelled risk; blocking-chain fixes become reordered edges on the board.
Done when: every active epic was swept, every filed risk has owner + action + trigger, and the closing summary fits in five lines — chains flagged, risks filed, risks dropped.
