playbook_library_expansion_2026 09 26 - manishiitg/agentworks GitHub Wiki

Playbook library expansion map

Date: 2026-09-26. This is the next authoring queue for the SaaS launch library. The installable catalog currently contains 40 multi-Crew proposals and 15 focused Workflow guides. The remaining routes below are candidates, not installable Playbooks. Add them only when they provide a different customer job and a verifiable handoff; reuse existing Crew identities and skills first.

Selection rule

A new Playbook needs one concrete customer question, an exact source object, a first useful review result, a real boundary between Crews, and an observable later outcome. A broad category name, another UI tile, or an extra Crew identity is not enough. Each accepted package needs a pending five-to-ten-check setup, one valid and one rejected example, a runnable contract suite, a manual first-run path, and explicit approval and recurrence boundaries. The producer Crew's JSON output must have a structural gate; the route's business validator must block its consumer.

The Trial Account to Reviewed Sales Assist route is now installable as a pending, chat-led proposal with exact-account trial and CRM joins, contact-policy checks and rejected artifacts.

Next cross-team routes

Priority Customer job and why existing routes do not cover it Reuse and handoff Source truth and first useful result Rejected claim / action boundary
2 Support escalation to verified fix. Support case resolution can accept an escalation; incident recovery handles service incidents. A specific customer-reported defect still needs an Engineering owner, deployed fix evidence and a Support-safe update. Escalation Coordinator → Engineering Delivery Coordinator → Support Reply Drafter. Keep the case, affected deployment and proposed message joined. Current case/thread, accepted Engineering issue, code/change/deployment, independent reproduction or QA retest. First result is an owned defect or a sourced “not yet reproducible” blocker. Reject a triage note as Engineering acceptance, merged code as deployed fix, and an unsent update as delivered resolution.
3 Cancellation request to reviewed account and finance closure. Renewal review is pre-decision and refund review covers money movement, but a customer cancellation request needs exact entitlement, policy, final invoice and contact handling. Support Triage Assistant or Customer Health Coordinator → Billing Operations Coordinator → Revenue & Close Analyst, using separate owners only where access requires it. Original request, executed terms, subscription/entitlement state, final invoice/payment and ledger. First result is a policy and timing decision with unknowns exposed. Reject a request as completed cancellation, a CRM stage as provider status, and a projected credit as posted finance treatment.
4 Month-end revenue exception to reviewed close packet. Finance Operations Review exposes an optional close specialist but does not yet validate a source-to-close handoff. Revenue & Close Analyst → Finance Analyst; one Crew may carry both capabilities where owner and approval are shared. Subscription, processor, payout, bank and ledger entries for one entity, currency and close window. First result is a reconciled exception register with an owner decision. Reject unmatched money, mixed periods, missing bank evidence and a proposed journal as posted or approved.
5 Lost-deal signal to positioning decision. Pipeline Health reviews current opportunities and GTM launch covers new offers; neither turns a bounded set of lost reasons into a reviewed offer or message revision. Pipeline Analyst → GTM Strategy Analyst, optionally Competitor Intelligence Analyst when exact sourced claims are needed. Current CRM opportunities, approved loss reasons, segment and period denominator, call or note sources, current offer version. First result is a sourced objection pattern and one pending positioning decision. Reject anecdote as prevalence, competitor hearsay as fact, and a proposed message as launched or causally effective.

Order of work

The new Dispute to Reconciled Outcome route closes a Finance gap using the existing Dispute Review capability. Next, author the Support-to-Engineering route because it connects currently separate categories without duplicating existing Playbooks. Then author cancellation and close after their source and owner boundaries are clear. Run the library validator and frontend catalog projection after each package. Customer-like runs and the final admin-only Dominion deployment remain separate release gates.

⚠️ **GitHub.com Fallback** ⚠️