Spec Extract Skill (Vue 3 + TypeScript)

How to run

• Open the feature's primary Vue SFC in the editor (the "current file"), e.g. Counter.vue.
• Run /spec-extract.

Inputs (what to read)

You MUST base the spec on the code you can see/read. Use a feature-scoped approach:

1. Read the currently focused Vue SFC (the entry component). Determine it from the most recent ide_opened_file tag in the conversation context. If no such tag is present, ask the user to provide the file path before proceeding.
2. Identify and read the primary composable/store used by that component.
3. Identify and read any direct helper modules used for domain logic by the component/composable.
4. Optionally read the API client functions called by the composable/store (only if referenced).

Scoping rules

• Prioritize files in the same folder as the current component, then nearby feature folders.
• Do NOT attempt to summarize the whole repo.
• If key referenced code is missing/unavailable, record it under Open Questions / Missing Context.

Output location

Write a single markdown file named <ComponentName>.spec.md (e.g. LscLazy.spec.md) in the same folder as the currently focused Vue SFC. Derive the component name from the SFC filename (strip the .vue extension).

GOAL

Produce a feature spec that can be used as a test oracle and to generate unit/component/E2E tests.

Invariants are the primary deliverable. A spec with 5 precise invariants and 3 operations is more valuable than a complete but shallow spec. Prioritize depth of invariant discovery over breadth of section coverage.

OUTPUT FORMAT

Create <ComponentName>.spec.md with this exact structure:

<Feature Name> Spec

Purpose

1–3 sentences of user-visible behavior.

Scope

• In scope
• Out of scope

State Model

List state variables grouped by source. For each, include: name, type, and default/initial value only.

• Inputs (props, route params): propName: Type = default
• UI state (component refs/reactive): varName: Type = default
• Domain state (composable/store): varName: Type = default
• External dependencies (API, storage, time): varName: Type = default

Invariants (Always True)

This is the most important section. Write as:

• INV-1 (<ShortName>): <precise predicate>

Rules:

• Only include invariants strongly supported by the code.
• If uncertain, write as Candidate INV and explain why it's uncertain.
• Prefer precise boolean predicates (e.g. items.length > 0, a ∩ b = ∅).
• Include UI-scoped predicates here too (e.g. saveButton.disabled ↔ !isValid). Do not create a separate UI Rules section.

Where to look for invariants (in priority order):

1. Initialization functions — any function that normalizes, seeds, or derives initial state. Guards inside it reveal what the code treats as always-true (e.g. a filter on valid IDs implies a membership invariant).
2. Cross-collection constraints — when items are split across multiple collections, look for partition properties: disjointness (a ∩ b = ∅), completeness (a ∪ b = allItems), or mutual exclusion.
3. Cardinality guards — > 0 checks, .length validations, clamping logic. Each is a candidate invariant on a count or size.
4. Computed properties with boolean output — computed(() => x && y) used as a guard elsewhere implies x && y must hold for the feature to function correctly.
5. Repeated if (...) return guards — the same condition checked at the top of multiple operations is almost always an invariant the code is trying to enforce.

Operations (Events/Actions)

For every operation that changes state or causes side effects:

OP-<n> <operationName>

• requires (preconditions):
• ensures (postconditions): use x' notation for post-state (e.g., value' = value + 1)
• failure behavior:

Include operations triggered by user events (click/submit), lifecycle hooks (mounted), watchers/effects, and API calls.

Open Questions / Ambiguities

List behaviors not uniquely determined by code. For each:

• give 2–3 plausible options
• state what the code currently implies (if anything)
• note any missing context (imports/types/utilities not read)

STRICT RULES

• Do not invent product intent.
• Prefer "the code implies X" rather than "it should do X".
• If you cannot prove something from the provided code, label it Candidate or put it in Open Questions.
• Use consistent IDs (INV-, OP-).
• Output <ComponentName>.spec.md only (no extra commentary).