@codename_inc/spectre 4.0.0 → 5.0.0

package/plugins/spectre-codex/skills/scope/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: "scope"
-description: "👻 | Interactively scope a feature or improvement, generating a complete Scope document that clarifies what's IN and OUT -- primary agent"
+description: "👻 | Interactively scope a feature or improvement, generating a complete Scope document with IN, OUT, and ANTI-SCOPE boundaries -- primary agent"
 user-invocable: true
 ---
 
@@ -12,104 +12,144 @@ Treat the current command arguments as this workflow's input. When invoked from
 
 # scope: Interactive Feature Scoping
 
-Collaborative workflow for structuring unstructured thoughts into clear scope boundaries through contextual brainstorming and targeted clarifications. Focuses on user value and scope boundaries before technical considerations. Output: comprehensive scope document with clear boundaries, user value, and key decisions saved to `{OUT_DIR}/concepts/scope.md`.
+Collaborative workflow for structuring unstructured thoughts into clear scope boundaries through a grounded hypothesis and targeted clarifications. Focuses on user value and scope boundaries before technical considerations. Output: scope document with clear boundaries (IN / OUT / ANTI-SCOPE), user value, load-bearing assumptions, and key decisions saved to `{OUT_DIR}/concepts/scope.md`.
 
 ## ARGUMENTS
 
-<ARGUMENTS> $ARGUMENTS </ARGUMENTS>
+<ARGUMENTS> $ARGUMENTS </ARGUMENTS>
 
-## Step 1: Immediate Reply & Gather Context
+## Step 1: Immediate Reply & Context Pickup
 
 - **Action** — ImmediateReply: Respond before any tools.
-  - **If** `FROM_KICKOFF=true` → acknowledge kickoff context, read `KICKOFF_DOC`, extract (Core Problem, User Value, Decisions Made, Remaining Ambiguities, Key Code Refs), **SKIP to Step 3**
-  - **Else If** ARGUMENTS empty → probe for context enthusiastically
-  - **Else** → proceed to Step 2
-  - **CRITICAL**: No tool calls except reading kickoff doc when FROM_KICKOFF=true
+  - **If** `FROM_KICKOFF=true` → acknowledge kickoff context, read `KICKOFF_DOC`, extract (Core Problem, User Value, Decisions Made, Remaining Ambiguities, Key Code Refs), **SKIP to Step 4**
+  - **Else If** ARGUMENTS empty → probe for context enthusiastically and **WAIT** for user
+  - **Else** → proceed with the steps below
+  - **CRITICAL**: No tool calls in this step except reading the kickoff doc when `FROM_KICKOFF=true`.
 
-## Step 2: Interactive Scope Exploration
+- **Action** — DetectExistingArtifacts: Before proposing a hypothesis, check for prior context that may already answer questions.
+  - `branch_name=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo unknown)`
+  - Look for: `docs/tasks/{branch_name}/concepts/scope.md`, `docs/tasks/{branch_name}/task_context.md`
+  - **If** prior `scope.md` exists → read fully; treat this invocation as a re-scope. Surface what was already settled and ask only about what's new or changed.
+  - **If** captured project knowledge is available (via `apply`-style memory or session logs) → surface decisions/patterns/gotchas relevant to this area before asking the user.
+
+## Step 2: Ground the Hypothesis (Fast)
+
+**SKIP IF FROM_KICKOFF=true** — kickoff already grounded.
+
+- **Action** — FastGround: Run ONE fast lookup to ground the hypothesis in repo reality. Pick the most informative single call:
+  - **`@finder` for one targeted query** — when you need to know what files/components exist for this area
+  - **One `grep` or `glob`** — when you need to verify a specific assumption ("does X already exist?")
+
+  **Constraints**:
+  - **One call only.** This is grounding, not research. Tech research is `plan`'s job.
+  - **Fast.** If the call would take more than a few seconds, skip it and ask the user instead.
+  - If you need more than one signal, that's a sign this should be a `kickoff` rather than a `scope`.
+
+## Step 3: Interactive Scope Exploration
 
 **SKIP IF FROM_KICKOFF=true**
 
-- **Action** — ExploreScope: Collaborative dialogue focused on boundaries and user experience.
+- **Action** — ExploreScope: Collaborative dialogue focused on boundaries, user experience, and anti-scope.
 
-  **CRITICAL**: Focus on WHAT, not HOW. Defer all technical/implementation questions until scope boundaries are finalized. Only ask technical questions if the scope itself is inherently technical (e.g., "migrate database from X to Y").
+  **CRITICAL**: Focus on WHAT, not HOW. Defer all technical/implementation questions to `plan`. Only ask technical questions if the scope itself is inherently technical (e.g., "migrate database from X to Y").
 
-  **PATTERN**: Lead with a rich initial exploration. In your FIRST response, propose concrete hypotheses AND ask 5-8 questions across multiple dimensions. Give the user a full landscape to react to, not a single thread to follow.
+  **PATTERN**: Lead with a grounded hypothesis (informed by Step 2's lookup) AND ask 5–8 questions across multiple dimensions. Mark each question as **(blocking)** or *(optional)* so the user can skim and skip.
 
   **FIRST RESPONSE FORMAT**:
 
-  > Here's my initial read on this, plus questions to help us explore the bounds:
+  > Here's my read on this, grounded in {one-line of what Step 2 surfaced}:
   >
-  > **My hypothesis**: [problem statement, who it affects, proposed IN/OUT]
+  > **Hypothesis**: [problem statement, who it affects, proposed IN / OUT / ANTI-SCOPE]
   >
-  > **Questions to explore**:
-  > 1. [User problem question]
-  > 2. [UX flow question]
-  > 3. [Boundary edge question]
-  > 4. [Alternative approach question]
-  > 5. [Success criteria question]
-  > 6. [Edge case question]
-  > ...
+  > **Questions**:
+  > 1. **(blocking)** [User problem question]
+  > 2. **(blocking)** [Boundary edge question]
+  > 3. **(blocking)** [Anti-scope question]
+  > 4. *(optional)* [UX flow question]
+  > 5. *(optional)* [Alternative approach question]
+  > 6. *(optional)* [Edge case question]
+  > 7. *(optional)* [Success criteria question]
   >
-  > Answer any/all that spark thoughts. Skip what's obvious.
+  > Answer the blocking ones; skip optional if obvious.
 
-  **Question types to include** (aim for 5-8 total, mix from these):
+  **Question types** (mix from these; lean on blocking for boundaries and anti-scope):
 
   - **User & Problem**: Who feels this most? What triggers the need? What's the cost of not solving it?
   - **UX & Feel**: Should this feel fast or thorough? Guided or flexible? What's the ideal flow?
-  - **Boundaries**: What about [adjacent thing]—IN or OUT? If unlimited time, what else? What's essential for v1?
+  - **Boundaries (IN/OUT)**: What about [adjacent thing]—IN or OUT? What's essential for v1?
+  - **Anti-Scope**: What problem are we *intentionally not solving* here? (Different from OUT — anti-scope clarifies the philosophical edge of the feature, not just deferred work.)
   - **Alternatives**: I could see this as [A] or [B]. Which direction?
-  - **Edge cases**: What happens when [unusual situation]? Should we handle [error state]?
-  - **Success**: What makes you say "this shipped well"? What's the one thing we can't get wrong?
+  - **Edge cases**: What happens when [unusual situation]?
+  - **Success**: What makes you say "this shipped well"?
 
-  **DO NOT ask about**: implementation approach, technical trade-offs, architecture, or integration details until boundaries are confirmed.
+  **DO NOT ask about**: implementation approach, technical trade-offs, architecture, or integration details — those belong in `plan`.
 
 - **Action** — IterateBoundaries: After user responds, refine boundaries and ask targeted follow-ups on gaps.
 
-  > **Current Boundaries**: ✅ **IN**: \[list\] ❌ **OUT**: \[list\] ⚠️ **Unsure**: \[edge cases\]
+  > **Current Scope**:
+  > ✅ **IN**: [list]
+  > ❌ **OUT**: [list]
+  > 🚫 **ANTI-SCOPE**: [problems we're intentionally not solving]
+  > ⚠️ **Unsure**: [edge cases]
   >
   > Any items to move? Add exclusions? Clarify edges? Reply 'looks good' to continue.
 
-- **Wait** — User confirms Scope boundaries are accurate
+- **Wait** — User confirms scope boundaries are accurate.
 
-## Step 3: Generate Targeted Clarifications
+## Step 4: Targeted Clarifications
 
 - **Action** — DetermineOutputDir:
-
   - **If** FROM_KICKOFF → use same dir as kickoff doc
   - **Else** → `OUT_DIR = user_specified || docs/tasks/{branch_name}`
-  - `mkdir -p "$OUT_DIR"`
+  - `mkdir -p "$OUT_DIR/concepts" "$OUT_DIR/clarifications"`
 
-- **Action** — GenerateTargetedQuestions: Create 3-6 questions based ONLY on remaining scope ambiguities from Step 2 (or kickoff's "Remaining Ambiguities").
+- **Action** — DetectClarificationMethod: Check if `AskUserQuestion` tool is available.
+  - **If available** → use inline clarification flow (Path A)
+  - **If not available** → use file-based clarification flow (Path B)
 
-  **CRITICAL**: Only ask about unresolved scope ambiguities. Technical questions (architecture, trade-offs, integration) belong in `plan`, not here.
+### Path A: Inline Clarifications (AskUserQuestion available)
 
-- **Action** — SaveClarifications: Create `{OUT_DIR}/clarifications/scope_clarifications_{timestamp}.md`:
+- **Action** — AskInline: Generate 3–6 questions based ONLY on remaining scope ambiguities from Step 3 (or kickoff's "Remaining Ambiguities").
+  - Ask the most critical first (up to 4 at a time, the tool limit).
+  - For trade-off decisions, present options with concise pros/cons.
+  - If more than 4 questions, ask in batches — most important first.
 
+  **CRITICAL**: Only ask about unresolved scope ambiguities. Technical questions belong in `plan`, not here.
+
+### Path B: File-Based Clarifications (no AskUserQuestion)
+
+- **Action** — GenerateTargetedQuestions: Create 3–6 questions in `{OUT_DIR}/clarifications/scope_clarifications_{YYYY-MM-DD_HHMMSS}.md`:
   - Header: concept name, confirmed boundaries so far
-  - Questions: Each focused on a scope edge case with `<response></response>` block
+  - Each question with a `<response></response>` block
 
 - **Action** — PromptUser: "Saved clarifications to `{path}`. Answer in `<response>` blocks. Reply 'Read it' when ready."
 
-- **Wait** — User replies
+- **Wait** — User replies.
 
-- **Action** — ReadClarifications: Read file, use responses (proceed with assumptions if empty)
+- **Action** — ReadClarifications: Read the file; use responses (proceed with intelligent assumptions if blocks are empty).
 
-## Step 4: Create Scope Document
+## Step 5: Create Scope Document
 
-- **Action** — CreateScopeDoc: Generate `{OUT_DIR}/concepts/scope.md` (use scoped filename if exists).
+- **Action** — CreateScopeDoc: Generate `{OUT_DIR}/concepts/scope.md` (use scoped filename if one exists).
 
   **Priority**: User value and boundaries BEFORE technical details.
 
-  **Sections**: The Problem (pain, impact, current state) → Target Users (primary, secondary, needs) → Success Criteria (outcomes, metrics) → User Experience (journeys, principles, trade-offs) → Scope Boundaries (in/out/maybe/future) → Constraints (platform, perf, a11y, scale) → Integration (touches, avoids, dependencies) → Decisions (from clarifications + rationale) → Risks (UX, scope creep, open questions) → Next Steps (`plan` or `create_tasks`, complexity S/M/L)
-
-## Step 5: Light Technical Context (Optional)
+  **Sections**:
 
-**Only if scope identifies specific technical/architecture integration points.**
+  1. **The Problem** — pain, impact, current state
+  2. **Target Users** — primary, secondary, needs
+  3. **Success Criteria** — outcomes; prefer measurable assertions over prose
+  4. **User Experience** — journeys, principles, trade-offs
+  5. **Scope Boundaries** — IN / OUT / ANTI-SCOPE / Maybe / Future
+  6. **Load-Bearing Assumptions** — assumptions that, if wrong, invalidate this scope. Each assumption gets a short *"if this is false, …"* consequence so future-you can recognize when to come back.
+  7. **Constraints** — platform, perf, a11y, scale (user-provided only)
+  8. **Decisions** — from clarifications + rationale
+  9. **Risks** — UX, scope creep, open questions
+  10. **Next Steps** — `plan` or `create_tasks`, complexity S/M/L
 
-- **Action** — IdentifyTouchpoints: Identify desired areas of research, and dispatch parallel @analyst subagents to research each area. Surface-level only (component names, NOT implementation). List features this interacts with, constraints worth documenting, areas to avoid.
-
-- **Action** — UpdateScopeDoc: Add findings to Integration & Constraints sections if relevant.
+  **Note on ANTI-SCOPE vs OUT**:
+  - **OUT** = we're not building it (yet, or for this release).
+  - **ANTI-SCOPE** = we're intentionally not solving this *problem* — it clarifies the philosophical edge of what this feature is for.
 
 ## Step 6: Final Review & Next Steps
 
@@ -117,12 +157,18 @@ Collaborative workflow for structuring unstructured thoughts into clear scope bo
 
   > **Scope Complete**: `{OUT_DIR}/concepts/scope.md`
   >
-  > **Final Boundaries**: ✅ **IN**: \[from doc\] ❌ **OUT**: \[from doc\] ⚠️ **Maybe/Future**: \[from doc\]
+  > **Final Boundaries**:
+  > ✅ **IN**: [from doc]
+  > ❌ **OUT**: [from doc]
+  > 🚫 **ANTI-SCOPE**: [from doc]
+  > ⚠️ **Maybe/Future**: [from doc]
+  >
+  > **Load-Bearing Assumptions** (top 1–3 — if any prove false, return to scope): [from doc]
   >
-  > Docs saved: `{OUT_DIR}/concepts/scope.md`, `{OUT_DIR}/clarifications/scope_clarifications_{timestamp}.md`
+  > Docs saved: `{OUT_DIR}/concepts/scope.md`, clarifications under `{OUT_DIR}/clarifications/`
   >
-  > Reply with any edits, updates, or clarifications — otherwise pick a next step:
+  > Reply with edits — otherwise pick a next step:
 
 - **Action** — RenderFooter: Render Next Steps using `Skill(spectre-guide)` skill.
 
-  > **NOTE**: Do NOT wait for explicit approval. Present next steps immediately inline with the review. User can reply with scope edits OR jump straight into a next step command. If user replies with edits, apply them to the scope doc and re-present.
+  > **NOTE**: Do NOT wait for explicit approval. Present next steps inline with the review. The user can reply with scope edits OR jump straight into a next step command. If they reply with edits, apply them to the scope doc and re-present.

package/plugins/spectre-codex/skills/ux/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: "ux"
+description: "👻 | Define user flows, components, and UX behavior — generates the UX spec for a feature - primary agent"
+user-invocable: true
+---
+
+# ux
+
+## Input Handling
+
+Treat the current command arguments as this workflow's input. When invoked from a slash command, use the forwarded `$ARGUMENTS` value.
+
+# ux: Define Exactly How the Feature Works
+
+Transform product requirements into a definitive behavioral specification. Two stages: align on user flows, then generate detailed spec. Output: `ux.md` ready for implementation.
+
+<ARGUMENTS> $ARGUMENTS </ARGUMENTS>
+
+---
+
+# STAGE 1: Flow Discovery & Alignment
+
+**Goal**: Align on HOW the feature works before specifying details.
+
+## Step 1 — Understand the Feature
+
+1. **Read scope and requirements** in this precedence (read whichever exist FULLY, no offset/limit):
+   - `docs/tasks/{branch}/concepts/scope.md` — the canonical scope doc (preferred)
+   - `docs/tasks/{branch}/specs/prd.md` — if a PRD was generated separately
+   - `docs/tasks/{branch}/task_summary.md` — if present
+   - **If none exist** → ask the user for scope context (or recommend `scope` first) before proceeding.
+2. **Research patterns**: Dispatch `@patterns` to find existing screens/components similar to what we're building. Note conventions, reusable elements, and any design tokens.
+3. **Identify user segments**: List the user segments this feature serves — first-time vs returning, anonymous vs signed-in, free vs paid, role-based variants. UX often diverges across segments and missing this is a common cause of rework.
+4. **Identify journeys**: List user goals, entry points, and completion states.
+
+## Step 2 — Present User Flows
+
+Write each flow as a narrative walkthrough.
+
+**Per flow include**: Goal, Entry point, Journey steps (User sees → User does → System responds), Decision points with branches, Success state, Questions where ambiguity exists.
+
+**Per user segment**: Call out where flows diverge (e.g., "First-time users see X tour; returning users skip directly to Y").
+
+After writing all flows, propose a specific take rather than asking open-ended:
+
+> **User Flows — Proposed**
+>
+> I've mapped {N} flows across {M} user segments: {list with one-line summaries}
+>
+> **Key segmentation calls**: [where flows diverge by user state and why]
+>
+> Push back on anything wrong, missing, or over-/under-segmented. Reply with feedback or **"Flows approved"** to proceed.
+
+**Wait for approval. If feedback → revise and re-present. If approved → Stage 2.**
+
+---
+
+# STAGE 2: Detailed Specification
+
+**Gate**: Only proceed after explicit flow approval.
+
+## Step 3 — Clarify Remaining Details
+
+Review approved flows for gaps: component behaviors, edge cases, state definitions, segment variants.
+
+If significant gaps, ask 3–5 targeted questions (empty states, error handling, loading, limits, segment differences). Save to `clarifications/ux_clarifications_{timestamp}.md`, prompt user to read, incorporate answers.
+
+## Step 4 — Write the Specification
+
+Generate complete spec with these sections:
+
+### Required Sections
+
+1. **Overview** — What this feature is, problem it solves, primary user goal (1 paragraph)
+2. **User Segments** — Each segment served, what's different about their UX (e.g., first-time onboarding, role-based permissions, free vs paid limits, anon vs signed-in)
+3. **Screens** — Every screen: name, purpose (1 line), navigation relationships
+4. **Flows** — Formalized from Stage 1 with alternate paths (validation fail, cancel, network error). Include per-segment branches where they diverge.
+5. **Layouts** — Per screen: header/main/footer structure + responsive behavior (desktop >1024, tablet 768–1024, mobile <768)
+6. **Components** — Each interactive element: purpose, location, applicable states (see State Vocabulary below)
+7. **Interactions** — Table format: Element | Action | Result (exhaustive)
+8. **States** — Table format: State | Trigger | Appearance | Available Actions
+9. **Content** — Exact copy: page titles, buttons, empty states, error messages, confirmation dialogs
+10. **Edge Cases** — Limits/boundaries, null/long data handling, permissions, offline/network failures, segment-specific edge cases
+11. **Accessibility** — Tab order, keyboard actions (Enter/Space/Escape), screen reader announcements, focus management
+
+### State Vocabulary
+
+Use these state categories where applicable. Not every component needs every state — pick what's relevant for the feature.
+
+- **Visual states** (per interactive element): default, hover, focus, active/pressed, disabled
+- **Data states** (per data view): empty, loading, partial-loaded, loaded, error, stale/refreshing
+- **Form states**: pristine, dirty, touched, submitting, submitted-success, submitted-error, validation-error per field
+- **Selection states**: none, single, multi, partial-selection, all-selected
+- **Sync states** (collaborative or async UI): optimistic, pending, conflict, resolved
+- **Network states** (where relevant): online, offline, reconnecting
+
+Save to `docs/tasks/{branch}/ux.md`
+
+Prompt:
+
+> **UX Specification Complete**
+>
+> Written to `{path}`. Please review: Any behaviors wrong or missing? Edge cases not covered? Segment differences captured?
+>
+> **Want a prototype to validate visually before approving?** `prototype` will render this spec (high-fi, no synthesis) and flag assumptions where I had to fill in details — catches issues prose review misses. Reply `prototype` to run it now.
+>
+> Otherwise, reply with feedback, or **"Approved"** to finalize.
+
+**Wait for approval, feedback, or prototype request.** If user replies `prototype`, invoke `prototype` (the post-ux mode auto-detects the complete ux.md). Once prototype completes and any spec updates from filled assumptions are applied, return here for final approval.
+
+## Step 5 — Handoff
+
+Confirm completion with summary: screens specified, segments addressed, flows documented, components with states, edge cases and accessibility covered.
+
+Read `.spectre/next_steps_guide.md` and render Next Steps footer:
+
+```
+Next Steps | Phase: Scope | Status: UX Complete
+Recommendation: {contextual next action — if no prototype was generated, suggest prototype to validate the spec visually before /plan}
+Options: prototype (validate spec visually), create_plan, create_tasks, tdd
+```

package/plugins/spectre/skills/ux_spec/SKILL.md

@@ -1,100 +0,0 @@
----
-name: ux_spec
-description: Define the User Flows and generate a UX Spec - primary agent
-user-invocable: true
----
-
-# ux_spec
-
-## Input Handling
-
-Treat the current command arguments as this workflow's input. When invoked from a slash command, use the forwarded `$ARGUMENTS` value.
-
-# ux_spec: Define Exactly How the Feature Works
-
-Transform product requirements into a definitive behavioral specification. Two stages: align on user flows, then generate detailed spec. Output: `ux.md` ready for implementation.
-
-<ARGUMENTS> $ARGUMENTS </ARGUMENTS>
-
----
-
-# STAGE 1: Flow Discovery & Alignment
-
-**Goal**: Align on HOW the feature works before specifying details.
-
-## Step 1 — Understand the Feature
-
-1. **Read requirements**: `docs/tasks/{branch}/task_summary.md` and `docs/tasks/{branch}/specs/prd.md`
-2. **Research patterns**: Find existing screens/components similar to what we're building, note conventions
-3. **Identify journeys**: List user goals, entry points, and completion states
-
-## Step 2 — Present User Flows
-
-Write each flow as a narrative walkthrough:
-
-**Per flow include**: Goal, Entry point, Journey steps (User sees → User does → System responds), Decision points with branches, Success state, Questions where ambiguity exists
-
-After writing all flows, prompt:
-
-> **User Flows for Review**
->
-> I've mapped {N} flows: {list with one-line summaries}
->
-> Please review: Are these the right flows? Any missing? Do journeys feel right? Answer flagged questions.
->
-> Reply with feedback, or **"Flows approved"** to proceed.
-
-**Wait for approval. If feedback → revise and re-present. If approved → Stage 2.**
-
----
-
-# STAGE 2: Detailed Specification
-
-**Gate**: Only proceed after explicit flow approval.
-
-## Step 3 — Clarify Remaining Details
-
-Review approved flows for gaps: component behaviors, edge cases, state definitions.
-
-If significant gaps, ask 3-5 targeted questions (empty states, error handling, loading, limits). Save to `clarifications/ux_clarifications_{timestamp}.md`, prompt user to read, incorporate answers.
-
-## Step 4 — Write the Specification
-
-Generate complete spec with these sections:
-
-### Required Sections
-
-1. **Overview** — What this feature is, problem it solves, primary user goal (1 paragraph)
-2. **Screens** — Every screen: name, purpose (1 line), navigation relationships
-3. **Flows** — Formalized from Stage 1 with alternate paths (validation fail, cancel, network error)
-4. **Layouts** — Per screen: header/main/footer structure + responsive behavior (desktop >1024, tablet 768-1024, mobile <768)
-5. **Components** — Each interactive element: purpose, location, states (default, hover, active, disabled, loading, error)
-6. **Interactions** — Table format: Element | Action | Result (exhaustive)
-7. **States** — Table format: State | Trigger | Appearance | Available Actions (empty, loading, loaded, error)
-8. **Content** — Exact copy: page titles, buttons, empty states, error messages, confirmation dialogs
-9. **Edge Cases** — Limits/boundaries, null/long data handling, permissions, offline/network failures
-10. **Accessibility** — Tab order, keyboard actions (Enter/Space/Escape), screen reader announcements, focus management
-
-Save to `docs/tasks/{branch}/ux.md`
-
-Prompt:
-
-> **UX Specification Complete**
->
-> Written to `{path}`. Please review: Any behaviors wrong or missing? Edge cases not covered?
->
-> Reply with feedback, or **"Approved"** to finalize.
-
-**Wait for approval.**
-
-## Step 5 — Handoff
-
-Confirm completion with summary: screens specified, flows documented, components with states, edge cases and accessibility covered.
-
-Read `.spectre/next_steps_guide.md` and render Next Steps footer:
-
-```
-Next Steps | Phase: Scope | Status: UX Complete
-Recommendation: {contextual next action}
-Options: /create_plan, /create_tasks, /tdd
-```

package/plugins/spectre-codex/skills/ux_spec/SKILL.md

@@ -1,100 +0,0 @@
----
-name: "ux_spec"
-description: "Define the User Flows and generate a UX Spec - primary agent"
-user-invocable: true
----
-
-# ux_spec
-
-## Input Handling
-
-Treat the current command arguments as this workflow's input. When invoked from a slash command, use the forwarded `$ARGUMENTS` value.
-
-# ux_spec: Define Exactly How the Feature Works
-
-Transform product requirements into a definitive behavioral specification. Two stages: align on user flows, then generate detailed spec. Output: `ux.md` ready for implementation.
-
-<ARGUMENTS> $ARGUMENTS </ARGUMENTS>
-
----
-
-# STAGE 1: Flow Discovery & Alignment
-
-**Goal**: Align on HOW the feature works before specifying details.
-
-## Step 1 — Understand the Feature
-
-1. **Read requirements**: `docs/tasks/{branch}/task_summary.md` and `docs/tasks/{branch}/specs/prd.md`
-2. **Research patterns**: Find existing screens/components similar to what we're building, note conventions
-3. **Identify journeys**: List user goals, entry points, and completion states
-
-## Step 2 — Present User Flows
-
-Write each flow as a narrative walkthrough:
-
-**Per flow include**: Goal, Entry point, Journey steps (User sees → User does → System responds), Decision points with branches, Success state, Questions where ambiguity exists
-
-After writing all flows, prompt:
-
-> **User Flows for Review**
->
-> I've mapped {N} flows: {list with one-line summaries}
->
-> Please review: Are these the right flows? Any missing? Do journeys feel right? Answer flagged questions.
->
-> Reply with feedback, or **"Flows approved"** to proceed.
-
-**Wait for approval. If feedback → revise and re-present. If approved → Stage 2.**
-
----
-
-# STAGE 2: Detailed Specification
-
-**Gate**: Only proceed after explicit flow approval.
-
-## Step 3 — Clarify Remaining Details
-
-Review approved flows for gaps: component behaviors, edge cases, state definitions.
-
-If significant gaps, ask 3-5 targeted questions (empty states, error handling, loading, limits). Save to `clarifications/ux_clarifications_{timestamp}.md`, prompt user to read, incorporate answers.
-
-## Step 4 — Write the Specification
-
-Generate complete spec with these sections:
-
-### Required Sections
-
-1. **Overview** — What this feature is, problem it solves, primary user goal (1 paragraph)
-2. **Screens** — Every screen: name, purpose (1 line), navigation relationships
-3. **Flows** — Formalized from Stage 1 with alternate paths (validation fail, cancel, network error)
-4. **Layouts** — Per screen: header/main/footer structure + responsive behavior (desktop >1024, tablet 768-1024, mobile <768)
-5. **Components** — Each interactive element: purpose, location, states (default, hover, active, disabled, loading, error)
-6. **Interactions** — Table format: Element | Action | Result (exhaustive)
-7. **States** — Table format: State | Trigger | Appearance | Available Actions (empty, loading, loaded, error)
-8. **Content** — Exact copy: page titles, buttons, empty states, error messages, confirmation dialogs
-9. **Edge Cases** — Limits/boundaries, null/long data handling, permissions, offline/network failures
-10. **Accessibility** — Tab order, keyboard actions (Enter/Space/Escape), screen reader announcements, focus management
-
-Save to `docs/tasks/{branch}/ux.md`
-
-Prompt:
-
-> **UX Specification Complete**
->
-> Written to `{path}`. Please review: Any behaviors wrong or missing? Edge cases not covered?
->
-> Reply with feedback, or **"Approved"** to finalize.
-
-**Wait for approval.**
-
-## Step 5 — Handoff
-
-Confirm completion with summary: screens specified, flows documented, components with states, edge cases and accessibility covered.
-
-Read `.spectre/next_steps_guide.md` and render Next Steps footer:
-
-```
-Next Steps | Phase: Scope | Status: UX Complete
-Recommendation: {contextual next action}
-Options: /create_plan, /create_tasks, /tdd
-```