{"slug":"goga-define-requirements","title":"goga-define-requirements","summary":"Imported from qarium/goga/goga/assets/skills/goga-define-requirements.","platform":"Claude","tags":[],"authorName":"LLM Mart","authorSlug":"llm-mart","score":0,"source":"github","price":null,"verified":false,"createdAt":"2026-08-24T17:38:10.206667Z","repo":{"url":"https://github.com/qarium/goga","stars":32,"forks":0,"license":"BSD-3-Clause","updatedAt":"2026-09-27T19:31:53Z"},"bodyHtml":"<hr>\n<h2>name: goga-define-requirements\ndescription:</h2>\n<h1>goga-define-requirements</h1>\n<h2>Purpose</h2>\n<p>Define the product requirements that describe what the product must do to deliver the established user experience and achieve the agreed product goals.</p>\n<p>Transform the product context and user experience into explicit, observable, and testable product behaviour.</p>\n<p>The result must be detailed enough for engineering to begin technical design without requiring product decisions to be invented.</p>\n<hr>\n<h2>Contract</h2>\n<pre><code>consume:\n  - product\n  - problem\n  - users\n  - goals\n  - user_experience\n\nproduce:\n  - requirements\n</code></pre>\n<hr>\n<h2>Core Principle</h2>\n<p>A requirement describes required product behaviour.</p>\n<p>It answers:</p>\n<blockquote>\n<p>What must the product do?</p>\n</blockquote>\n<p>It must not answer:</p>\n<blockquote>\n<p>How should engineers implement it?</p>\n</blockquote>\n<p>For example:</p>\n<blockquote>\n<p>When the user cancels an eligible order, the product must show that cancellation is in progress.</p>\n</blockquote>\n<p>is a product requirement.</p>\n<p>This is not:</p>\n<blockquote>\n<p>The frontend must call <code>POST /orders/{id}/cancel</code>.</p>\n</blockquote>\n<p>The second describes implementation.</p>\n<hr>\n<h2>Process</h2>\n<h3>1. Derive requirements from the experience</h3>\n<p>Review the complete <code>user_experience</code>.</p>\n<p>Identify every meaningful product behaviour required to make that experience possible.</p>\n<p>Trace:</p>\n<pre><code>Goal\n  ↓\nUser Experience\n  ↓\nRequirement\n</code></pre>\n<p>Every significant requirement should have a clear reason to exist in the user experience.</p>\n<p>Do not create requirements that are not needed by the established product experience.</p>\n<hr>\n<h3>2. Define observable behaviour</h3>\n<p>Requirements should describe behaviour that can be observed from outside the implementation.</p>\n<p>Prefer:</p>\n<blockquote>\n<p>The user can retry the operation after a recoverable failure.</p>\n</blockquote>\n<p>over:</p>\n<blockquote>\n<p>The retry handler must invoke the operation again.</p>\n</blockquote>\n<p>The requirement should remain valid regardless of the implementation approach.</p>\n<hr>\n<h3>3. Cover the primary scenario</h3>\n<p>Define the behaviour required for the main user flow.</p>\n<p>For each meaningful user action, determine what the product must do.</p>\n<p>Consider:</p>\n<ul>\n<li>accepted actions;</li>\n<li>resulting state;</li>\n<li>displayed information;</li>\n<li>available next actions;</li>\n<li>completion behaviour.</li>\n</ul>\n<p>Do not describe trivial UI details unless they materially affect the product behaviour.</p>\n<hr>\n<h3>4. Cover alternative scenarios</h3>\n<p>Translate meaningful alternative user paths into requirements.</p>\n<p>Consider:</p>\n<ul>\n<li>different valid choices;</li>\n<li>different product states;</li>\n<li>optional actions;</li>\n<li>different user roles;</li>\n<li>repeated actions.</li>\n</ul>\n<p>Do not duplicate requirements when the same behaviour applies across multiple scenarios.</p>\n<hr>\n<h3>5. Cover failure scenarios</h3>\n<p>Define product behaviour for relevant failures.</p>\n<p>For each meaningful failure, establish:</p>\n<ul>\n<li>what the product must communicate;</li>\n<li>whether the user can retry;</li>\n<li>whether the previous state is preserved;</li>\n<li>what action is available next;</li>\n<li>whether the failure changes the product state.</li>\n</ul>\n<p>Do not leave important failure behaviour implicit.</p>\n<hr>\n<h3>6. Cover important states</h3>\n<p>Where the user experience defines meaningful states, describe the required product behaviour for those states.</p>\n<p>Examples:</p>\n<pre><code>Initial\nProcessing\nCompleted\nFailed\nUnavailable\nCancelled\nExpired\n</code></pre>\n<p>Only include states that affect observable product behaviour.</p>\n<p>Do not expose internal implementation states as requirements.</p>\n<hr>\n<h3>7. Define business rules</h3>\n<p>Capture rules that determine product behaviour.</p>\n<p>Examples:</p>\n<ul>\n<li>who can perform an action;</li>\n<li>when an action is available;</li>\n<li>when an action becomes unavailable;</li>\n<li>what conditions must be satisfied;</li>\n<li>what happens when conditions conflict;</li>\n<li>what information must be preserved.</li>\n</ul>\n<p>Rules must be expressed as product behaviour or product constraints.</p>\n<p>Do not turn technical validation logic into implementation instructions.</p>\n<hr>\n<h3>8. Define permissions and access behaviour</h3>\n<p>If different users have different capabilities, explicitly define:</p>\n<ul>\n<li>who can perform the action;</li>\n<li>who can view the relevant information;</li>\n<li>what happens when a user is not allowed to perform an action.</li>\n</ul>\n<p>Do not specify how authorization is implemented.</p>\n<hr>\n<h3>9. Define data visible to the user</h3>\n<p>When the user experience depends on information, define what information must be available to the user.</p>\n<p>For example:</p>\n<blockquote>\n<p>The product must show the current status of the order and the time at which it was last updated.</p>\n</blockquote>\n<p>Do not specify:</p>\n<ul>\n<li>database fields;</li>\n<li>schemas;</li>\n<li>storage;</li>\n<li>API payloads.</li>\n</ul>\n<p>Describe only the product-level information required by the user experience.</p>\n<hr>\n<h3>10. Define consistency across scenarios</h3>\n<p>Check whether the same product concept behaves consistently throughout the experience.</p>\n<p>For example, if an order is described as cancelled in one scenario, another relevant scenario must not imply that the same order remains active.</p>\n<p>Identify inconsistent behaviour as a conflict.</p>\n<hr>\n<h2>Requirement Quality</h2>\n<p>Each requirement should be:</p>\n<h3>Observable</h3>\n<p>Its outcome can be understood from product behaviour.</p>\n<h3>Specific</h3>\n<p>It is clear what the product must do.</p>\n<h3>Unambiguous</h3>\n<p>Different engineers should not derive materially different product behaviour from it.</p>\n<h3>Necessary</h3>\n<p>It exists because of a goal, user need, constraint, or user experience.</p>\n<h3>Solution-independent</h3>\n<p>It does not prescribe technical implementation.</p>\n<h3>Testable</h3>\n<p>Its behaviour can be verified after implementation.</p>\n<hr>\n<h2>Avoid Implementation Leakage</h2>\n<p>Do not include:</p>\n<ul>\n<li>programming languages;</li>\n<li>frameworks;</li>\n<li>libraries;</li>\n<li>database schemas;</li>\n<li>classes;</li>\n<li>internal services;</li>\n<li>internal events;</li>\n<li>deployment details;</li>\n<li>API endpoint design;</li>\n<li>implementation algorithms.</li>\n</ul>\n<p>A REST API, CLI application, background job, or other technical interface may still require extensive product requirements.</p>\n<p>Describe those interfaces from the user's perspective.</p>\n<p>For example:</p>\n<blockquote>\n<p>The CLI must clearly indicate whether the requested operation succeeded and provide an actionable error when it cannot be completed.</p>\n</blockquote>\n<p>is a product requirement.</p>\n<p>Do not define the command implementation, internal architecture, or libraries here.</p>\n<hr>\n<h2>Challenge the Requirements</h2>\n<p>Verify the relationship:</p>\n<pre><code>Problem\n  ↓\nGoals\n  ↓\nUser Experience\n  ↓\nRequirements\n</code></pre>\n<p>Challenge the requirement set:</p>\n<ul>\n<li>Does every major goal have supporting requirements?</li>\n<li>Does every major user scenario have defined behaviour?</li>\n<li>Are failure cases covered where they matter?</li>\n<li>Are important product rules explicit?</li>\n<li>Are there contradictory requirements?</li>\n<li>Are there requirements that have no product justification?</li>\n<li>Are requirements accidentally prescribing implementation?</li>\n<li>Can engineering make a technical decision without having to invent product behaviour?</li>\n</ul>\n<p>Do not add technical requirements merely to make implementation easier.</p>\n<hr>\n<h2>Conflict Detection</h2>\n<p>Report a conflict when requirements cannot be made consistent with the established context.</p>\n<p>Examples:</p>\n<pre><code>conflict: |\n  The requirements allow users to cancel an order at any time,\n  while the existing product constraint states that cancellation\n  is unavailable after preparation begins.\n\nreason: |\n  The requirements contradict an established product constraint.\n</code></pre>\n<p>Another example:</p>\n<pre><code>conflict: |\n  The user experience requires the operation to be completed\n  immediately, while the requirements define the operation as\n  asynchronous with no intermediate user-visible state.\n\nreason: |\n  The requirements do not support the established user experience.\n</code></pre>\n<p>The orchestrator will invoke <code>goga-define-resolve</code>.</p>\n<p>Do not resolve cross-context conflicts yourself.</p>\n<hr>\n<h2>Missing Information</h2>\n<p>Ask the user only when a missing product decision prevents a requirement from being defined unambiguously.</p>\n<p>Valid questions may concern:</p>\n<ul>\n<li>user-visible behaviour;</li>\n<li>business rules;</li>\n<li>permissions;</li>\n<li>state transitions;</li>\n<li>error behaviour;</li>\n<li>required information;</li>\n<li>consequences of an action.</li>\n</ul>\n<p>Do not ask about technical implementation.</p>\n<p>Do not ask questions whose answers can reasonably be derived from the existing context.</p>\n<hr>\n<h2>Do Not Define</h2>\n<p>This skill must not define:</p>\n<ul>\n<li>technical architecture;</li>\n<li>API contracts;</li>\n<li>database schemas;</li>\n<li>implementation tasks;</li>\n<li>code structure;</li>\n<li>technology choices;</li>\n<li>deployment;</li>\n<li>ADR decisions.</li>\n</ul>\n<p>Those belong to the engineering design process that follows the PRD.</p>\n<hr>\n<h2>Output</h2>\n<p>Produce a complete set of product requirements.</p>\n<p>Requirements should be organized so that engineering can clearly understand:</p>\n<ul>\n<li>what the product must do;</li>\n<li>under which conditions;</li>\n<li>for which users;</li>\n<li>what happens in important states;</li>\n<li>how relevant failures behave;</li>\n<li>what information must be presented;</li>\n<li>what business rules govern the behaviour.</li>\n</ul>\n<p>The result must be detailed enough to support technical design while remaining independent of implementation.</p>\n","files":[{"path":"SKILL.md","sizeBytes":8701,"isText":true}],"reviewScore":null,"reviewSummary":null,"trust":{"provenance":"trusted-source-unreviewed","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow.","bodySource":null},"bodyLocked":false,"purchaseUrl":null,"sourceUrl":null,"report":{"provenance":"trusted-source-unreviewed","screen":{"ran":true,"outcome":"clean","suspicious":0,"notes":0,"hiddenCharacters":false},"virusScan":{"engine":"clamav","status":"clean","scannedAt":"2026-08-24T17:40:04.372425Z","sha256":"EA4CC1007601CA120ADD522AEC6FF3DAF7426693E377E5B965453566D6C8F30D","sizeBytes":3207},"review":null,"source":{"repositoryUrl":"https://github.com/qarium/goga","path":"goga/assets/skills/goga-define-requirements","license":"BSD-3-Clause","commit":"9fdb39b191bec889e345e42ffa1549d2727ca247","subtreeSha":"CC809B30B549931750B6DEAB8ED55F26F5660EC48067EC495931B9FBEDAB0DEB","lastSyncedAt":"2026-09-27T20:56:56.704728Z"},"reviewedAt":"2026-08-24T17:48:48.725957Z","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow."},"install":[{"target":"skills-cli","command":"npx skills add https://github.com/qarium/goga/tree/1.2.x/goga/assets/skills/goga-define-requirements"},{"target":"claude-code","command":"claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install qarium-goga@llmmart"},{"target":"git","command":"git clone https://github.com/qarium/goga.git"}]}