@enterpriseai/cli 3.19.0 → 3.19.1

package/resources/gofer/copilot-prompts/0a_problem_validation.prompt.md

@@ -1,429 +0,0 @@
----
-name: 0a_problem_validation
-description: Validate the business problem using 5 Whys root-cause analysis and stakeholder mapping.
-agent: copilot-workspace
-tools:
-  - Read
-  - Grep
-  - Glob
-  - Bash
-  - WebSearch
-argument-hint: feature-name-or-description
-gofer:
-  workflowProfile: standard
-  canonicalSource: .specify/commands/0a_problem_validation.md
-  canonicalChecksum: 2895960ddcbfa562871976c81a13bbc13f50c817648d2d8b4a92d2651b2c2c66
-  metadataSource: scripts/generate-commands.ts
----
-
-## Workspace Preflight
-
-Before doing stage/helper work:
-
-1. Resolve the repository root.
-2. Check the core Gofer sentinels:
-   - `.specify/.gofer-version`
-   - `.specify/commands/0_gofer_start.md`
-   - `.specify/templates/spec-template.md`
-   - `.specify/templates/loop-contract-template.json`
-   - `.specify/templates/working-backwards-prfaq-template.md`
-   - `.specify/templates/business-owner-summary-template.md`
-   - `.specify/templates/cto-architecture-summary-template.md`
-   - `.specify/templates/ciso-security-summary-template.md`
-   - `.specify/templates/stakeholder-review-index-template.md`
-   - `.specify/scripts/bash/create-new-feature.sh`
-   - `.specify/scripts/node/parse-stage-command.mjs`
-   - `.specify/scripts/node/gofer-loop-audit.mjs`
-   - `.specify/scripts/hooks/post-tool-use.mjs`
-   - `.specify/scripts/powershell/install-optional-tools.ps1`
-   - `.specify/templates/gofer-model-policy.yaml`
-   - `.specify/memory/gofer-model-policy.yaml`
-   - `.specify/specs/`
-   - `.specify/memory/`
-3. Check host-specific repo-owned files when relevant:
-   - Claude: `AGENTS.md`, `CLAUDE.md`, `.claude/settings.json`
-   - Codex: `AGENTS.md`
-   - Copilot: `.github/copilot-instructions.md`
-   - VS Code extension mirrors Claude/Copilot/Gemini resources itself and should still keep the core scaffold healthy
-4. If the repo already has the workspace checker script, prefer running:
-   - `node .specify/scripts/node/gofer-workspace-check.mjs --host copilot --json`
-5. If the workspace is missing or stale, ask exactly:
-   - **"This repo is missing or stale for Gofer. Initialize/update it now?"**
-6. If the user says yes, run the Gofer workspace bootstrap helper and then resume this command from the top.
-7. If the user says no, stop and explain that Gofer stage/helper work depends on the repo-owned scaffold.
-
-
-# Gofer Problem Validation
-
-## EAI Platform Session Preflight
-
-Before any Gofer stage/helper command does pipeline work:
-
-1. Treat durable delivery as EAI Platform delivery by default, with Azure second
-   and every other stack only by explicit exception.
-2. Run `eai whoami` and confirm the EAI CLI is installed, the user is logged in,
-   and an active workspace is visible.
-3. If `eai` is missing, `eai whoami` fails, the token is expired, or no active
-   workspace is available, stop and run `/gofer:eai-first-run` or ask the user to
-   approve login/setup before continuing.
-4. For EAI app delivery, do not continue into research, specification, planning,
-   tasks, implementation, or validation until
-   `.specify/specs/{feature}/eai-preflight.md` records login, workspace, template,
-   app-readiness, and next-action evidence.
-5. Do not write tokens, secrets, private workspace IDs, Entra/CIAM authority tenant IDs, or local `.env` values into
-   Gofer artifacts; record only product-safe readiness status and evidence.
-
-## Token And Cost Policy
-<!-- gofer:token-cost-policy:start -->
-
-Before spawning agents, calling tools, or loading large files:
-
-1. Treat `.specify/memory/gofer-model-policy.yaml` as the repo-owned source of truth for simple, medium, hard, and arbiter model routing. If it is missing, run `/gofer:bootstrap-workspace` before continuing.
-2. Use the cheapest capable model first.
-   - Claude: Haiku for scouting/extraction; Sonnet for normal implementation, synthesis, validation, and security; Opus for high-risk arbitration or release-critical failures.
-   - Codex/OpenAI: GPT mini for simple coding; GPT nano only for locate/classify/summarize/mechanical work; GPT-5.3-Codex or flagship GPT for tool-heavy coding, architecture, and release-critical validation.
-   - Gemini: Flash-Lite for cheap large-context scan/summarize; Flash for default research synthesis; Pro for large-context architecture or high-risk arbitration.
-   - Copilot: prefer Auto for simple and default work; ask the user before choosing a paid/high-tier picker model for hard security, architecture, or release gates.
-3. Keep raw tool output out of the main conversation context. Save stable findings to `.specify/specs/{feature}/context-bundle.md`, then work from summaries.
-4. Use provider prompt/context caching only for stable, non-secret prefixes: Gofer scaffold, AGENTS/CLAUDE/Copilot instructions, constitution, repo map, stage contracts, and validation rubric.
-5. Before continuing after large research, planning, implementation, or validation bursts, checkpoint the durable artifacts and compact/clear/resume context when the host supports it.
-6. Escalate model tier only when a cheaper pass is low-confidence, contradictory, security-sensitive, or blocking release quality.
-<!-- gofer:token-cost-policy:end -->
-
-## User Input
-
-```text
-$ARGUMENTS
-```
-
-You **MUST** consider the user input before proceeding (if not empty).
-
-## Outline
-
-This stage sits BEFORE `#1_gofer_research` in the pipeline. Your job is to:
-
-1. Deconstruct the problem statement
-2. Run 5 Whys root cause analysis
-3. Map stakeholder impact
-4. Assess business case (cost of doing nothing vs value of solving)
-5. Check if software is even the right answer
-6. Research the market for existing solutions
-7. Track initial assumptions
-8. Produce a validated Problem Brief
-
-**Output**: `.specify/specs/{feature}/problem-brief.md`,
-`.specify/specs/{feature}/assumptions.md`
-
----
-
-## Step 0: Context Health Check
-
-```bash
-.specify/scripts/bash/check-context-health.sh
-```
-
-- If **< 50%**: Proceed normally
-- If **50-70%**: Be concise with outputs
-- If **> 70%**: Start new session with handoff summary
-
----
-
-## Step 1: Get Problem Statement
-
-If no problem description provided in $ARGUMENTS:
-
-Use the AskUserQuestion tool:
-
-**"What business problem are you trying to solve?"**
-
-| Option | Description                                          |
-| ------ | ---------------------------------------------------- |
-| Custom | Describe the problem in your own words (Recommended) |
-
-Encourage the user to describe the PROBLEM, not the SOLUTION. If they describe a
-solution ("I need a dashboard"), probe deeper: "What problem would the dashboard
-solve?"
-
----
-
-## Step 2: Create Feature Directory
-
-Once you have the problem statement:
-
-1. **Generate a short name** (2-4 words) for the feature
-2. Run `.specify/scripts/bash/create-new-feature.sh --json "$DESCRIPTION"` with
-   `--short-name "your-short-name"` to create the feature directory
-3. Parse JSON output for FEATURE_DIR and BRANCH_NAME
-
----
-
-## Step 3: Problem Deconstruction
-
-Parse the user's problem statement and extract:
-
-- **Stated Problem**: What they said is wrong
-- **Implied Solution**: What they think should be built (if any)
-- **Context Clues**: Industry, scale, urgency
-- **Emotional Signals**: Frustration points, pain intensity
-
-Present back to the user:
-
-**"Let me make sure I understand the problem correctly:"**
-
-| Element          | My Understanding         |
-| ---------------- | ------------------------ |
-| Core Problem     | [extracted]              |
-| Who's Affected   | [extracted]              |
-| Current Impact   | [extracted or "unknown"] |
-| Implied Solution | [extracted or "none"]    |
-
-Use AskUserQuestion: "Is this correct? Would you like to adjust anything?"
-
----
-
-## Step 4: Run 5 Whys Analysis
-
-Spawn the business-problem-validator agent:
-
-```
-Task: subagent_type="business-problem-validator", model="sonnet"
-Prompt: "Validate this business problem using 5 Whys analysis:
-
-Problem: [USER'S PROBLEM STATEMENT]
-Context: [ANY ADDITIONAL CONTEXT]
-
-Perform:
-1. 5 Whys root cause analysis
-2. Stakeholder impact mapping
-3. Business case assessment
-4. Problem-solution fit check
-
-Return structured report (<2000 tokens)."
-```
-
----
-
-## Step 5: Market Landscape Research
-
-Spawn the market scanner agent **in parallel** with the problem validator:
-
-```
-Task: subagent_type="research-market-scanner", model="haiku"
-Prompt: "Research the market landscape for this business problem:
-
-Problem: [USER'S PROBLEM STATEMENT]
-Industry: [EXTRACTED FROM CONTEXT]
-
-Find:
-1. Commercial SaaS solutions that address this
-2. Open-source alternatives
-3. Industry standards or regulations
-4. Build vs Buy analysis
-
-Return structured report (<2000 tokens)."
-```
-
-**Run both agents in parallel.**
-
----
-
-## Step 6: Synthesize Findings
-
-Once both agents complete:
-
-### 6.1 Present Root Cause
-
-Use AskUserQuestion to confirm the root cause:
-
-**"Based on my analysis, the root cause appears to be:"**
-
-| Element        | Finding                                     |
-| -------------- | ------------------------------------------- |
-| Stated Problem | [What user said]                            |
-| Root Cause     | [From 5 Whys]                               |
-| Gap            | [How far stated problem is from root cause] |
-
-| Option                                   | Description                  |
-| ---------------------------------------- | ---------------------------- |
-| A. Root cause is correct                 | Proceed with this root cause |
-| B. Root cause needs adjustment           | Let me clarify further       |
-| C. I want to solve the symptom, not root | Focus on the stated problem  |
-
-### 6.2 Present Market Findings
-
-Use AskUserQuestion to get build/buy decision:
-
-**"I found these existing solutions in the market:"**
-
-| Option           | Description                                              |
-| ---------------- | -------------------------------------------------------- |
-| A. Build custom  | No existing solution fits — we should build from scratch |
-| B. Buy/subscribe | [Solution X] looks like a good fit — investigate further |
-| C. Hybrid        | Use [Solution X] as foundation, customize on top         |
-| D. Not sure      | I need more information to decide                        |
-
-### 6.3 Present Business Case
-
-Display the impact assessment:
-
-```
-╔══════════════════════════════════════════════════════╗
-║  BUSINESS CASE SUMMARY                               ║
-╠══════════════════════════════════════════════════════╣
-║                                                       ║
-║  Problem: [Root cause in plain English]               ║
-║                                                       ║
-║  Cost of Doing Nothing: [$/hours per year]            ║
-║  Estimated Value of Solving: [$/hours per year]       ║
-║  Payback Period: [weeks/months]                       ║
-║                                                       ║
-║  Software Needed? [Yes/No/Partial]                    ║
-║  Recommendation: [PROCEED/INVESTIGATE/RECONSIDER]     ║
-║                                                       ║
-╚══════════════════════════════════════════════════════╝
-```
-
----
-
-## Step 7: Generate Problem Brief
-
-Write to `{FEATURE_DIR}/problem-brief.md` using the template at
-`.specify/templates/problem-brief-template.md`.
-
-Populate with:
-
-- User's confirmed root cause
-- Stakeholder impact from validator agent
-- Business case metrics
-- Market landscape findings
-- Build/buy decision
-- All identified assumptions
-
----
-
-## Step 8: Generate Initial Assumptions Register
-
-Write to `{FEATURE_DIR}/assumptions.md` using the template at
-`.specify/templates/assumptions-template.md`.
-
-Extract assumptions from:
-
-- Problem statement (business assumptions)
-- Market research (competitive assumptions)
-- Root cause analysis (causal assumptions)
-- Stakeholder mapping (user behavior assumptions)
-
-Mark ALL assumptions as `UNVALIDATED` at this stage.
-Populate the **Drift Controls** table with an owner, expiry/revalidation date,
-trigger, and reopen stage for every assumption that could invalidate the plan
-later.
-
----
-
-## Step 8a: Always Emit Market and Business Analysis Artifacts (FR-035)
-
-Regardless of the `competitiveAnalysisEnabled` constitutional setting, this
-stage MUST emit BOTH baseline traceability artifacts so downstream stages and
-audits can find them at deterministic paths:
-
-- `{FEATURE_DIR}/market-analysis.md` — competitive landscape and build-vs-buy
-  reasoning. When `competitiveAnalysisEnabled=false`, this file is still created
-  and contains a clearly worded **disabled-state notice** explaining that
-  competitive analysis was skipped per constitution and that the section is
-  reserved for future enrichment.
-- `{FEATURE_DIR}/business-analysis.md` — business case, ROI sketch,
-  cost-of-doing-nothing summary, and stakeholder impact mapping. Emitted
-  unconditionally; this is the primary record consumed by
-  `#7a_stakeholder_comms` and the validation council.
-
-When `competitiveAnalysisEnabled=false`, the market-analysis.md file includes
-the following stub at the top so consumers can detect the disabled state
-programmatically:
-
-```markdown
-> **Notice:** Competitive analysis is disabled in this project's constitution
-> (`competitiveAnalysisEnabled: false`). This file is emitted as a baseline
-> traceability artifact only and contains no competitor research. Re-enable in
-> `.specify/memory/constitution.md` if you want full market analysis on the next
-> pipeline run.
-```
-
-Both files participate in the same audit trail and are referenced from the
-`7_gofer_save` checkpoint and the `7a_stakeholder_comms` package.
-
----
-
-## Step 9: Report and Continue
-
-After saving artifacts:
-
-```
-════════════════════════════════════════════════════════════════
-  PROBLEM VALIDATED: [Feature Name]
-════════════════════════════════════════════════════════════════
-
-  Root Cause: [One sentence]
-  Business Case: [Cost of doing nothing] vs [Value of solving]
-  Market: [Build/Buy/Hybrid decision]
-  Assumptions: [N] tracked ([N] critical)
-
-  Artifacts:
-  - {FEATURE_DIR}/problem-brief.md
-  - {FEATURE_DIR}/assumptions.md
-  - {FEATURE_DIR}/market-analysis.md
-  - {FEATURE_DIR}/business-analysis.md
-
-  Recommendation: [PROCEED/INVESTIGATE/RECONSIDER]
-
-════════════════════════════════════════════════════════════════
-```
-
-If recommendation is PROCEED or user confirms they want to continue:
-
-
----
-
-## Step 10: Observability Logging
-
-```bash
-.specify/scripts/bash/log-stage.sh 0a_problem_validation --complete --tokens [N] --compactions [N]
-```
-
----
-
-## Important Notes
-
-- **Write for business people** — no technical jargon in outputs
-- **Challenge assumptions** — don't take the problem at face value
-- **Quantify impact** — use numbers, not adjectives
-- **Consider process solutions** — code is expensive, process is cheap
-- **Keep it short** — max 15 minutes of user interaction
-- **Don't propose solutions** — this stage is about the PROBLEM, not the answer
-- **Track everything as assumptions** — they get validated later in the pipeline
-
----
-
-## "Explain Like I'm a Consultant" Mode
-
-All outputs from this stage are written in business language by default. This
-stage sets the tone for the entire pipeline when `audience: business` is set.
-
-Check `.specify/memory/constitution.md` for audience setting. If
-`audience: business` is set, pass this context to all subsequent pipeline stages
-so they include plain-English companion sections in their outputs.
-
----
-
-## Quick Reference: Pipeline Position
-
-```text
-  #0a_problem_validation  ← YOU ARE HERE
-       ↓ AUTO
-  #1_gofer_research
-       ↓ AUTO
-  #2_gofer_specify
-       ↓ AUTO
-  ... (rest of pipeline)
-       ↓ AUTO
-  #7a_stakeholder_comms
-```