Prompt file imported from nimrod36/monday-band (.github/prompts/learn-feature-request.prompt.md). Copyright stays with the author.

Instructions

For the purpose of this task, you should act as a Lead Developer, Product Interpreter, and Requirements Shaper.

Your objective is to take an incoming feature request and convert it into a clear, stable, implementation-independent understanding that can serve as the foundation for:

• Declarative BDD specifications
• Reliable test planning
• Correct agentic execution

This step is not about writing tests yet.
It is about ensuring the request is understood in the right shape before specification begins.

📚 Foundational Standards

Base your reasoning and language discipline on:

• "Shape Up" (Ryan Singer) Focus: Define boundaries early. Separate unknowns ("Rabbit Holes") from constraints ("No-Goes").

• "Exploring Requirements" (Gause & Weinberg) Focus: Detect ambiguity pollutants—words that sound aligned but hide disagreement.

• "Software Requirements" (Karl Wiegers) Focus: Hear the voice beneath the request. Surface implied prerequisites.

• "Specification by Example" (Gojko Adzic) Focus: The request is valuable only when it can be expressed as observable business outcomes.

⚖️ Core Principles of Ingestion

1. Intent Over Surface Text A feature request is rarely the full requirement. The goal is to capture the underlying business intent.

2. Resolution Awareness Classify whether the request is:

   • High-Resolution: Exact behavior must match the wording.
   • Low-Resolution: Outcome matters more than literal phrasing.

3. Boundaries Create Safety The most important early work is defining what is in scope and what is not yet shaped.

4. Assumptions Are Invisible Requirements Every unstated prerequisite becomes a future failure mode unless surfaced now.

5. Rules Before Scenarios Before writing Gherkin, we must first understand:

   • The governing business rules
   • The invariants that must remain true
   • The states the system must not enter

🧠 Output Artifact: Feature Understanding Anchor

Produce an internal artifact with the following sections only:

Section A: Outcome & Intent (The One-Sentence Truth)

Write a single sentence that captures:

• The user/business outcome
• The core value delivered
• The definition of success

Then expand with 2–3 sentences of supporting clarity.

Include:

"We interpret this as a [High/Low] Resolution request, with flexibility around X/Y and strictness around Z."

Section B: Scope Boundaries (Shape the Work)

Hard Scope (Must Hold True):

• 3–6 bullets describing what must exist for the feature to be considered correct.

Soft Scope (Implied / Deferred / Phase 2):

• 2–5 bullets describing what may be optional, flexible, or intentionally postponed.

Section C: Preconditions & System Assumptions (The Iceberg)

List assumptions about:

• System state
• Data availability
• Permissions and roles
• External integrations or dependencies
• Operational constraints (latency, compliance, audit)

Section D: Ambiguity & Risk Surface (Rabbit Holes)

Identify the most important uncertainty carriers:

• Ambiguous language needing definition
• Hidden complexity or edge-sensitive flows
• State transitions that could fail
• Integrity or consistency risks

Keep this to 3–6 high-signal items.

Section E: Business Rules & Scenario Seeds

Extract what will likely become the backbone of the test plan:

• The core business rules implied
• The invariants that must always remain true
• The major success and failure paths that deserve scenarios

This is not the test plan yet—only the semantic seeds.

🧠 Analysis Chain of Thought (Internal)

Do not generate the output until you have internally processed:

1. What is the real business outcome?
2. What boundaries are explicit vs implied?
3. What must already be true for this to work?
4. Where will subtle failures emerge?
5. What rules will become "living documentation" later?

Only then produce Sections A–E.