Workflow Spec & Design Doc Builder

Converting raw, unstructured input (meeting notes, bullet points, rough descriptions) into clean, actionable workflow specifications that are ready for implementation, while ensuring all referenced data fields and objects actually exist in Salesforce and Snowflake before documentation is finalized

Two-phase process: Phase 0 runs live queries against Salesforce and Snowflake to verify that every object, field, and record set mentioned in the input actually exists and returns expected data (marking findings as ✅ verified, ⚠️ flagged, or ❌ missing). Phase 1 writes the structured workflow spec using verified data only, formatted as markdown ready to paste into Google Docs. Spec includes: Objective, Workflow at a Glance table, Process Steps (with System, Reads, Produces, Query, Guards/notes for each), Data Connections, Output, Readiness Assessment, Open Questions, Error Handling, and Feedback Loops. Target output is 3–5 pages with scannable sections and real record counts, not generic language.

Eliminates guesswork from workflow documentation by enforcing data verification before spec writing; ensures specs are built on confirmed field names, actual record counts, and validated data shapes rather than inference, reducing downstream implementation errors and rework

Verification uses SOQL and SQL queries (SELECT ... LIMIT 5 or SELECT COUNT(*)) against Salesforce (including FieldDefinition and EntityDefinition for field lookups) and Snowflake. Mark results ✅ if field exists with expected values, ⚠️ if present but flagged (sparsely populated, unexpected values), ❌ if not found or 0 rows. Never write unverified field names into spec; use [UNVERIFIED: field_name] placeholder and list in Open Questions. Include actual executable SOQL/SQL queries in Process Steps using verified field names only. Record counts populate Scale and Guards/notes fields (e.g. '9 active BDRs × ~210 accounts each', 'unpopulated on ~30% of accounts'). SF writeback always marked ⚠️ pending Dinakar validation.

Cannot proceed with spec writing if Phase 0 verification returns ❌ (field not found, 0-row queries, ambiguous filters) — must ask blocking questions before continuing. Cannot infer field names, object names, or record values; these must be confirmed via live query. Sections like ROI narrative, governance architecture, agent building blocks, safeguard layers, autonomy dial, and board language must be omitted from specs unless input explicitly requires them — these belong in strategy docs, not workflow specs. Process Steps must be scannable in under 30 seconds; long sections should be cut rather than compressed. Specs are decision-making tools, not design documents — every section must be as short as it can be while remaining actionable. Cannot mark Human-in-the-loop as ✅ if customer-facing output is present without a review step.