engineering_shopify_expansion_2026 09 26 - manishiitg/agentworks GitHub Wiki

Engineering and Shopify template expansion

Date: 2026-09-26. This is an authoring queue, not a list of installed templates. The library currently has 13 Engineering Crew capabilities when QA (3) and Security (3) are browsed under Engineering's 7 core roles, and 7 Shopify Crews. Browse grouping does not change Crew or Playbook package identities; the library now contains 79 Crew IDs and 64 Playbook packages.

Selection rule

Add a Crew only for a recurring human job with a distinct owner, source access, decision, and first reviewable artifact. If an installed Crew can perform the job with a scoped skill, add a capability pack instead. A new multi-Crew Playbook needs an exact handoff, an owner-reviewed action boundary, real-source setup checks, valid and rejected artifacts, and a manual first case. Package selection never activates a write or schedule.

Engineering: next distinct jobs

Priority Candidate Crew and job First artifact and source proof Boundary and Playbook
1 Customer Defect Investigator. Take one Support-reported product defect from exact case/build to reproducible or explicitly unknown Engineering evidence. Browser Journey QA tests an approved journey; Delivery Coordinator tracks an accepted change. Neither owns the case-to-defect diagnosis. Case and customer scope, affected build/environment, current logs or trace, bounded reproduction, existing issue match, Engineering owner and next evidence. Reject a support severity label as reproduction or an issue title as owner acceptance. Proposed Support Escalation to Verified Fix: accepted Support case → defect finding → owned change/deployment → independent QA retest → unsent Support update. Never mark merged code as deployed or a draft as delivered.
2 Service Reliability & Capacity Analyst. Review a service's SLO, demand, saturation and capacity headroom over comparable windows for an accountable service owner. Incident Investigator handles acute failures; Performance Investigator handles a bounded performance question. Versioned SLI/SLO and service identity, error-budget arithmetic, traffic/capacity sources and coverage, forecast assumptions, owner decision. Insufficient instrumentation returns unknown rather than a safe-to-grow claim. Proposed SLO Risk to Owned Capacity Action: observation → reviewed capacity/change plan → later deployed and measured state. No automatic infrastructure scale or purchasing action.

Capability packs before new identities: dependency upgrades should first extend Engineering Delivery Coordinator with exact package/advisory, compatibility, CI, deployed version and rollback checks. A data-pipeline integrity role should wait for a merchant or SaaS pilot that proves a separate data owner and source-to-destination reconciliation job. GitHub's Dependabot version update guidance illustrates why a proposed update is only an input to release review; Google's SRE operational efficiency guidance motivates service objectives, measurement and capacity work.

Shopify: next distinct merchant jobs

Priority Candidate Crew and job First artifact and source proof Boundary and Playbook
1 Order Risk Review Coordinator. Decide whether one flagged order should be held for merchant review, investigated or safely released to fulfillment. Payment Operations Investigator checks transaction state, not order-risk evidence. Exact store/order and risk-assessment revisions, payment state, fulfillment state, merchant risk policy, owner and next check. A risk score alone is not fraud proof. Proposed Order Risk to Fulfillment Decision with Store Operations Coordinator. No cancellation, capture, hold release or customer message from installing or producing a review. Shopify exposes OrderRiskAssessment.
2 B2B Wholesale Coordinator. Reconcile one company location's approved catalog, price, tax and payment terms before a reviewed quote or order. This differs from consumer catalog cleanup. Exact company/location/contact, catalog and price-list revisions, draft/order ID, payment terms, owner decision and mismatches. Reject a default market price as the customer's negotiated price. Proposed B2B Terms to Reviewed Order with Catalog & Merchandising and Store Operations, reusing an existing Crew when the same owner has access. No quote or order submission without merchant review. Shopify's B2B model joins companies, locations, contacts, catalogs and terms.
3 Promotion & Discount Auditor. Check one promotion's eligibility, stacking, market price and actual checkout result against merchant margin policy. Growth Analyst measures an outcome; Catalog Analyst fixes product facts. Discount/version, market/catalog/price, test cart and checkout observation, margin inputs, dates and owner. Reject a configured discount as proof it applied correctly. Proposed Promotion to Verified Checkout with Shopify Growth Analyst for a later comparable result. Creating or changing a discount is a separate approved action. Shopify documents discount classes and combinations.
4 Subscription Commerce Coordinator, only for merchants actually using a Shopify subscription app. Reconcile contract, billing attempt, generated order and fulfillment or customer exception for one cycle. Exact app-owned contract and cycle, attempt state, order ID, payment/fulfillment records, retry policy and owner. A pending billing attempt is not an order or successful renewal. Proposed Subscription Failure to Reconciled Order with Payment Operations Investigator and Store Operations. No automatic charge retry or contract edit. Shopify's contract and billing-attempt model makes the application owner and idempotency key essential.

Shopify customer-service triage and retention remain shared Customer Support or Marketing/Customer Success capabilities with Shopify-specific source joins, as described in the operator category guide. They should not become duplicate Crew IDs solely to increase the count.

Release order

First verify the Engineering browse grouping and package installation on one Crew and one Playbook. Next author the customer-defect and order-risk routes because their owner and evidence gaps are clearest. Validate B2B, promotions and subscriptions with a merchant before promoting them from candidates. Each new package must pass the Playbook validator, frontend catalog projection and one customer-like manual setup case before it is called operationally ready.

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