Translate Customer Needs into Engineering Requirements

{"category":"operations","description":"Use when an FDE or solution consultant owns the conversion of observed customer needs into a clear, testable engineering specification for product or implementation teams. The output is an implementation-ready problem and requirement definition, not a commitment that engineering has accepted a roadmap date. Do not use when the request is only a bug reproduction or an already-approved change ticket.","inputSchema":{"additionalProperties":false,"properties":{"customer":{"description":"Customer or engagement identifier.","minLength":1,"type":"string"},"knownConstraints":{"description":"Platform, integration, security, contractual and delivery constraints.","items":{"type":"string"},"type":"array"},"requestOrProblem":{"description":"User request, observed pain, or desired workflow.","minLength":1,"type":"string"},"sourceMaterial":{"description":"Customer interviews, recordings, support cases, examples, and relevant specs.","items":{"type":"string"},"type":"array"}},"required":["customer","requestOrProblem"],"type":"object"},"schemaVersion":1,"steps":[{"expectedOutputs":[{"description":"Problem statement, affected users, evidence, impact and unknowns.","kind":"validated-problem"}],"id":"93TF","instructions":"Reconstruct the triggering workflow, actors, frequency, current alternative, breakdowns and measurable consequences from customer evidence. Distinguish directly observed user need from a proposed feature solution. Capture examples, counterexamples, stakeholder disagreements and the number of distinct customers affected when visible. Validate where the request fits the intended product or deployment strategy. Gate: the team can articulate the user problem and business reason independently of any proposed implementation.","resourceHints":[],"title":"Find the underlying job and verify demand"},{"expectedOutputs":[{"description":"Scope and non-goals, alternatives, constraints and decisions.","kind":"scope-options"}],"id":"R0HW","instructions":"Draft functional outcomes, in-scope workflows, non-goals, quality attributes, integration boundaries, data constraints, exceptions, and dependencies. Explore at least one simpler workaround and one full solution; note trade-offs and reusable versus customer-specific work. Seek engineering/product input on critical feasibility or architecture claims rather than assuming them. Distinguish contractual commitments from wishes. Gate: solution direction can be chosen with risk and scope clearly visible.","resourceHints":[],"title":"Bound scope and compare solution directions"},{"expectedOutputs":[{"description":"Structured PRD with prioritized requirements, non-goals and acceptance criteria.","kind":"requirements-spec"}],"id":"0VDA","instructions":"Use write-spec if accessible for structure and acceptance-criteria discipline; otherwise create a self-contained PRD. Include problem, users/personas, goals, scope/non-goals, user journeys, requirements prioritized by criticality, exception cases, permission/security behavior, integrations, measurable success metrics and explicit assumptions. Each requirement must be independently testable; avoid vague words such as fast, easy or secure without acceptance criteria. Gate: an engineer and QA reviewer can infer the required behavior without reverse-engineering a sales conversation.","resourceHints":[{"kind":"skill","ref":"github:anthropics/knowledge-work-plugins","selector":"product-management/skills/write-spec"}],"title":"Write a testable PRD or technical specification"},{"expectedOutputs":[{"description":"Reviewed specification, edge-case checklist, and decision/open-question register.","kind":"reviewed-spec"}],"id":"08WP","instructions":"Review the draft with engineering, product, security/data owner and customer-facing owner where relevant. Challenge missing edge cases, error and recovery behavior, scale assumptions, integration ownership, dependencies and build-versus-buy. Record conflicts, decisions and open issues in the document without silently choosing for the team. Define what customer acceptance can observe versus what only engineering tests can validate. Gate: material ambiguities are resolved or labeled as blockers before implementation is promised.","resourceHints":[],"title":"Review feasibility, edge cases and acceptance"},{"expectedOutputs":[{"description":"Estimation-ready PRD with acceptance tests, constraints and explicit approval status.","kind":"engineering-ready-prd"}],"id":"XIR0","instructions":"Present a concise change summary, recommended scope, remaining assumptions, test cases, priorities, dependencies and measurable acceptance. Separate a ready-to-estimate specification from an approved development commitment. Obtain acknowledgement of feasibility or identify exact missing decisions; do not imply sprint, budget or delivery-date approval. The final result is the quality of the spec itself, without adding an unrelated generic handoff ceremony. Gate: the receiving team can estimate and plan from the artifact and knows which issues remain unresolved.","resourceHints":[],"title":"Make the specification ready for engineering commitment"}],"title":"Translate Customer Needs into Engineering Requirements"}