just-vibe 0.7.0

package/plugins/just-vibe/skills/setup/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: setup
+description: "Install, diagnose, update, or remove just-vibe through native host plugin management. Use for an intentional installation, update or removal; doctor inspects without changes."
+---
+
+# setup
+
+Install, diagnose, update, or remove just-vibe through native host plugin management.
+
+## Choose this workflow
+
+Use for an intentional installation, update or removal; doctor inspects without changes.
+
+Read [shared execution](../../references/execution.md) for context/mode/authority handling and [Installation methods](../../references/packs/installation.md) for tool selection and operational details. Resolve these paths from this skill file; all runtime assets ship inside the plugin.
+
+## Input and mode
+
+Use the complete request appended to this invocation, preserving all constraints and references. Default mode: **apply**. Apply for an installation request; target host, bundled source, --github or --local checkout, and Claude scope. A preview request uses the existing `--dry-run` behavior.
+
+Node.js 22+ and the selected host CLI with native plugin support. Git is required only for --github. Use the bundled installer; preserve marketplace and scope checks.
+
+Resolve any task-specific tools, target identity and evidence before dependent actions. No external connection is assumed.
+
+## Scope
+
+Install/enable just-vibe through the selected host's plugin manager; no unrelated plugin, permission, hook, or integration changes.
+
+Selected host plugin registration and its managed just-vibe payload directory only.
+
+## Execute
+
+1. Resolve scripts/installer.mjs relative to this installed plugin. Choose doctor for a status question, setup for an install request, update for a refresh request, and uninstall only for an explicit removal request.
+2. Honor the host, bundled default / --github / --local source and Claude --scope user|project|local; project/local operations use the requested project directory. Never place tokens in commands or files.
+3. For a requested preview append --dry-run and report conditional steps without claiming installed state was inspected. Preserve all native source/scope/inventory conflict checks.
+4. After success, report actual native state and explain that changed skills load in a fresh conversation. Uninstall retains marketplace registration and persistent data. Do not bypass errors with global edits or cache deletion.
+
+Task-specific method: Resolve host/scope, check prerequisites and marketplace identity, run the bundled installer, preserve conflict checks, verify result, and explain fresh-session loading requirements. Resolve host, scope and source before mutation; inspect the proposed native operations and preserve unrelated marketplace entries and user configuration.
+
+## Decision branches
+
+- **When an existing managed source conflicts with the selected channel:** Report the conflicting identity and supported switch procedure instead of overwriting arbitrary directories.
+
+## Deliver and verify
+
+- Installation outcome or precise blocker with host/source/scope and actual verification.
+- Installation source/version, native host state and executable validation or precise failure.
+
+Verify these observable conditions when applicable to the actual task; do not claim they were exercised from merely reading this file:
+
+- Repeated setup does not create duplicate registrations; an existing marketplace with another source stops without replacement.
+
+## Stop and recover
+
+- Dry run does not inspect host state and must not imply it did. No manual global-config edits or credentials embedded in commands.
+
+## Example requests
+
+- **Normal (inspect):** Check my just-vibe installation without changing it.
+- **edge (apply):** Update a bundled installation after its original package cache was removed.
+- **blocked (inspect):** Inspect installation prerequisites on a machine without a supported host executable.

package/plugins/just-vibe/skills/skill/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: skill
+description: "Create or improve a workflow skill Use to author or revise a reusable workflow; ordinary one-off work should not create a new skill."
+---
+
+# skill
+
+Create or improve a workflow skill
+
+## Choose this workflow
+
+Use to author or revise a reusable workflow; ordinary one-off work should not create a new skill.
+
+Read [shared execution](../../references/execution.md) for context/mode/authority handling and [General methods](../../references/packs/general.md) for tool selection and operational details. Resolve these paths from this skill file; all runtime assets ship inside the plugin.
+
+## Input and mode
+
+Use the complete request appended to this invocation, preserving all constraints and references. Default mode: **apply**. Apply; workflow purpose, activation conditions, target host, and examples.
+
+Resolve the user brief and inspect the relevant project or supplied evidence. External capabilities are optional unless the selected action actually needs them.
+
+Declared evidence requirements: `project.read`. Use actual host discovery or adequate supplied artifacts; unavailable evidence remains blocked/unknown.
+
+## Scope
+
+Create/update a skill and necessary supporting utilities; installation/publication is separate unless requested.
+
+Only the requested local changes; external actions require their exact action and target in session authorization.
+
+## Execute
+
+- Inspect existing skills, define boundaries and inputs, write actionable instructions, separate repeatable execution into utilities, and validate triggering plus behavior fixtures.
+- Define a matching and a near-miss request, reuse established packaging conventions, and move conditional detail into references only when needed.
+
+## Decision branches
+
+- **When guidance merely repeats generic model capabilities:** Remove it and retain decisions, invariants and examples that change behavior.
+
+## Deliver and verify
+
+- Skill files, capability requirements, usage examples, and validation evidence.
+- Skill entry point, supporting assets, matching boundaries and independent fixture evidence.
+
+Verify these observable conditions when applicable to the actual task; do not claim they were exercised from merely reading this file:
+
+- A matching request triggers the intended behavior; a nearby out-of-scope request does not acquire unrelated instructions.
+
+## Stop and recover
+
+- Do not create universal catch-all skills, silently enable hooks, or claim executable guarantees from prose alone.
+
+## Example requests
+
+- **Normal (apply):** Create a focused workflow for reviewing database migrations in this project.
+- **edge (apply):** Create a skill whose name overlaps an existing deployment workflow.
+- **blocked (inspect):** Review a proposed skill without host installation access or claiming it is enabled.

package/plugins/just-vibe/skills/spec/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: spec
+description: "Produce requirements, acceptance criteria, and edge cases Use to define observable product behavior before implementation; plan maps an accepted specification onto code."
+---
+
+# spec
+
+Produce requirements, acceptance criteria, and edge cases
+
+## Choose this workflow
+
+Use to define observable product behavior before implementation; plan maps an accepted specification onto code.
+
+Read [shared execution](../../references/execution.md) for context/mode/authority handling and [General methods](../../references/packs/general.md) for tool selection and operational details. Resolve these paths from this skill file; all runtime assets ship inside the plugin.
+
+## Input and mode
+
+Use the complete request appended to this invocation, preserving all constraints and references. Default mode: **plan**. Plan; feature brief, users, constraints, and relevant existing contracts.
+
+Resolve the user brief and inspect the relevant project or supplied evidence. External capabilities are optional unless the selected action actually needs them.
+
+Resolve any task-specific tools, target identity and evidence before dependent actions. No external connection is assumed.
+
+## Scope
+
+Requirements and observable behavior; no code changes or invented business policy.
+
+None by default. Plan artifacts may be saved when requested.
+
+## Execute
+
+- Inspect current behavior, identify actors and states, define normal/error paths, record exclusions, and turn ambiguity into explicit assumptions or decisions.
+- Write actors, preconditions, state transitions and observable acceptance examples; separate business decisions from implementation preferences.
+
+## Decision branches
+
+- **When two requirements conflict on the same transition:** Surface the concrete conflicting example and resolve that decision before specifying dependent behavior.
+
+## Deliver and verify
+
+- Requirements, acceptance criteria, edge cases, compatibility needs, and unresolved questions; save only when requested.
+- Requirement IDs, acceptance examples, exclusions and unresolved decision owners.
+
+Verify these observable conditions when applicable to the actual task; do not claim they were exercised from merely reading this file:
+
+- Each requirement has an observable completion condition; conflicting requirements are flagged before downstream implementation.
+
+## Stop and recover
+
+- Do not silently choose billing, privacy, or access policy that needs the user's decision. Continue specifying independent behavior.
+
+## Example requests
+
+- **Normal (plan):** Specify organization invitations, including expiry and already-registered users.
+- **edge (plan):** Specify account deletion with a pending subscription and recoverable failure.
+- **blocked (inspect):** Draft a specification with unknown retention policy; leave that decision explicit.

package/plugins/just-vibe/skills/tasks/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: tasks
+description: "Convert a brief or plan into ordered, verifiable tasks Use to turn an accepted plan into independently verifiable work; plan resolves architecture and sequencing first."
+---
+
+# tasks
+
+Convert a brief or plan into ordered, verifiable tasks
+
+## Choose this workflow
+
+Use to turn an accepted plan into independently verifiable work; plan resolves architecture and sequencing first.
+
+Read [shared execution](../../references/execution.md) for context/mode/authority handling and [General methods](../../references/packs/general.md) for tool selection and operational details. Resolve these paths from this skill file; all runtime assets ship inside the plugin.
+
+## Input and mode
+
+Use the complete request appended to this invocation, preserving all constraints and references. Default mode: **plan**. Plan; accepted brief/spec/plan and optional tracking format.
+
+Resolve the user brief and inspect the relevant project or supplied evidence. External capabilities are optional unless the selected action actually needs them.
+
+Resolve any task-specific tools, target identity and evidence before dependent actions. No external connection is assumed.
+
+## Scope
+
+Break work into implementable units; external issue creation is separate and requires a request to submit.
+
+None by default. Plan artifacts may be saved when requested.
+
+## Execute
+
+- Preserve requirements, map dependencies, define bounded outputs and checks, order the critical path, and flag tasks needing a decision.
+- Assign each task one observable output and dependency edge; keep inseparable schema/client changes together or state their compatibility bridge.
+
+## Decision branches
+
+- **When tasks overlap the same shared interface:** Define an integration order and owner boundary before parallel work is proposed.
+
+## Deliver and verify
+
+- Ordered tasks with scope, dependencies, acceptance criteria, and traceability to the brief.
+- Task IDs, requirements covered, prerequisites, deliverables and acceptance checks.
+
+Verify these observable conditions when applicable to the actual task; do not claim they were exercised from merely reading this file:
+
+- Every required outcome maps to a task; tasks do not duplicate ownership of the same inseparable change.
+
+## Stop and recover
+
+- Do not create estimates, owners, or external tickets as established facts when none were supplied.
+
+## Example requests
+
+- **Normal (plan):** Break the accepted invitation spec into ordered tasks with acceptance checks.
+- **edge (plan):** Split a migration plan into tasks that leave every intermediate release usable.
+- **blocked (inspect):** Break down known work while keeping an unresolved provider choice as a dependency.

package/plugins/just-vibe/skills/teach/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: teach
+description: "Teach a programming topic or the concepts needed to understand and implement a just-vibe workflow. Use for conceptual instruction or prerequisites; use explain for an existing implementation and teach-test for assessment."
+---
+
+# teach
+
+Teach a programming topic or the concepts needed to understand and implement a just-vibe workflow.
+
+## Choose this workflow
+
+Use for conceptual instruction or prerequisites; use explain for an existing implementation and teach-test for assessment.
+
+Read [shared execution](../../references/execution.md) for context/mode/authority handling and [General methods](../../references/packs/general.md) for tool selection and operational details. Resolve these paths from this skill file; all runtime assets ship inside the plugin.
+
+## Input and mode
+
+Use the complete request appended to this invocation, preserving all constraints and references. Default mode: **inspect**. Inspect; a topic, command name, implementation question, or current project context, plus optional experience level, language, depth and time available. Teaching never executes the target workflow.
+
+Resolve the user brief and inspect the relevant project or supplied evidence. External capabilities are optional unless the selected action actually needs them.
+
+Resolve any task-specific tools, target identity and evidence before dependent actions. No external connection is assumed.
+
+## Scope
+
+Explain the requested topic or implementation prerequisites using relevant catalog/source evidence. Do not implement the target command, alter files, install packages, or enroll the user in an unsolicited course.
+
+None by default. Save lesson notes or example files only when explicitly requested.
+
+## Execute
+
+1. Interpret the complete brief first. Explicit requests such as "teach linked lists" are topic lessons. A known workflow ID such as ml-split or git-bisect selects implementation teaching when the user asks how that tool works or how to implement it. If both interpretations fit, state the useful interpretation and cover their connection.
+2. For a workflow lesson use toolkit show with the exact ID and read the referenced implementation files. The catalog supplies purpose and boundaries; the current source supplies actual mechanisms. Never call the workflow itself to obtain a lesson.
+3. Read the teaching guide at ../../references/teaching.md. Choose the minimum prerequisites, adapt to the requested depth/language, explain in readable connected prose, and use a concrete example before broad abstractions.
+4. For a topic lesson, provide the explanation directly. For an implementation lesson, map each prerequisite to the relevant algorithm, data shape, invariant, tool boundary, verification case or source module.
+5. Check the lesson for factual accuracy and hidden assumptions. End with optional practice, not a mandatory quiz. Stop at the requested learning scope; do not turn a lesson into an implementation or service action.
+
+Task-specific method: Resolve whether the user wants a topic lesson or an implementation-focused lesson. Infer experience from context; otherwise start with approachable fundamentals and offer depth without blocking on a questionnaire. For a named just-vibe workflow, read its catalog record, skill and relevant utility source, distinguish implemented behavior from design requirements, and identify the concepts necessary to build it. For a standalone topic, define a concrete learning outcome and choose a useful worked example. Order prerequisites from the minimum foundation to the requested implementation. Explain the purpose, core model, and terminology in connected plain-language prose before introducing complexity. Use an annotated example and trace its state step by step. Relate each concept to a concrete design or implementation decision. Explain alternatives, tradeoffs, failure modes and common misconceptions. Use a small diagram or table only when it clarifies the lesson, and short code examples in the requested language when helpful. End with a concise understanding check or optional exercise and a recommended next step. Keep the explanation useful without requiring the user to answer a quiz; offer hints or an answer when requested. Choose one running example and state its assumptions before deriving the mechanism; distinguish conceptual pseudocode from runnable, version-specific code.
+
+## Decision branches
+
+- **When learner asks about a workflow with missing project context:** Teach the concepts using a labeled hypothetical example; do not invent the project's architecture.
+
+## Deliver and verify
+
+- A readable lesson with a clear learning outcome, prerequisite sequence, worked example, relevant tradeoffs and mistakes, and an optional practice/check step. For tool lessons, include a concept-to-implementation map and links to actual source where available.
+- Learning objective, worked example, common misconception, and a concrete next exercise.
+
+Verify these observable conditions when applicable to the actual task; do not claim they were exercised from merely reading this file:
+
+- A linked-list lesson traces nodes/links and operations, distinguishes singly/doubly linked lists, and explains that constant-time insertion requires the position/node to be known; finding it can require linear time.
+- An ml-split implementation lesson explains prediction time, entity dependence, temporal/group separation and leakage checks, ties these to the actual workflow, and never runs training or changes datasets.
+- An unfamiliar topic is not silently interpreted as a command to execute; unknown experience level yields an accessible explanation rather than a mandatory questionnaire.
+
+## Stop and recover
+
+- Ask one focused question if the topic or workflow cannot be identified. Do not invent source behavior, assume required knowledge without explaining it, claim the user mastered the topic, or execute the workflow merely because it was named. Verify version-sensitive claims against relevant primary sources.
+
+## Example requests
+
+- **Normal (inspect):** Teach linked lists from the basics, with a worked insertion example and practical tradeoffs.
+- **edge (inspect):** Teach linked-list deletion when only the head pointer is available.
+- **blocked (inspect):** Teach db-migrate concepts without database access; do not run a migration.

package/plugins/just-vibe/skills/teach-test/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: teach-test
+description: "Quiz the user on a topic or workflow through native multiple-choice question dialogs, with feedback and adaptive practice. Use for interactive assessment after checking native dialog support; teach handles lessons without assessment."
+---
+
+# teach-test
+
+Quiz the user on a topic or workflow through native multiple-choice question dialogs, with feedback and adaptive practice.
+
+## Choose this workflow
+
+Use for interactive assessment after checking native dialog support; teach handles lessons without assessment.
+
+Read [shared execution](../../references/execution.md) for context/mode/authority handling and [General methods](../../references/packs/general.md) for tool selection and operational details. Resolve these paths from this skill file; all runtime assets ship inside the plugin.
+
+## Input and mode
+
+Use the complete request appended to this invocation, preserving all constraints and references. Default mode: **inspect**. Inspect; a topic, workflow, or recent lesson plus optional experience, question count and practice/test preference. Requires an available native question tool permitted for this interaction in the current host mode.
+
+Resolve the user brief and inspect the relevant project or supplied evidence. External capabilities are optional unless the selected action actually needs them.
+
+Declared evidence requirements: `user.questions`. Use actual host discovery or adequate supplied artifacts; unavailable evidence remains blocked/unknown.
+
+## Scope
+
+Assess understanding through one native dialog question at a time. Do not render quiz questions inline, implement the named tool, alter project files, or change host mode/settings automatically.
+
+No project or external-service writes. Keep quiz state in session context; save results only on request.
+
+## Execute
+
+1. Read ../../references/teaching.md and ../../references/teach-test.md. Resolve the topic from the complete brief or immediately preceding lesson; ask for it only if unresolved.
+2. Inspect actual callable tools. Prefer request_user_input_async in a Codex environment that exposes and permits it, otherwise request_user_input only in its supported mode; use AskUserQuestion in Claude when available. Follow the actual host schema and restrictions. If no suitable dialog is available, explain that native interactive testing is unavailable here and stop without inline questions.
+3. Create quiz state with toolkit quiz create. Generate a question grounded in the lesson or target workflow, with exactly three short neutral choices, a correctOptionId, concept, and explanation. Keep this answer material out of the user-facing question.
+4. Call toolkit quiz present to validate and shuffle the choices and produce a presentation payload for the observed dialog. Actually invoke that native host tool with presentation.arguments. Merely printing the payload does not ask the question.
+5. For asynchronous tools, retain the quiz as awaiting-answer and wait for a user response; a returned pending tool call or preselected option is not submission. Do not advance, reveal the answer, or end with an inline replacement question while waiting.
+6. Normalize the actual response into questionId, submitted, selection/freeText, skipped/cancelled and call toolkit quiz answer. For a free-text explanation, use quiz review only after assessing its meaning; preserve the actual response and explain the judgment.
+7. Show returned feedback after answers in practice mode; withhold correctness in test mode until finished. Generate the next question using demonstrated misconceptions and remaining budget, then repeat through the native tool. Use quiz report for the final assessment; report sample limits and optional review topics.
+
+Task-specific method: Resolve the topic or recent lesson, select practice by default or test when requested, and set a bounded question count (default five). Identify the native question tool and verify availability and permitted use before preparing the quiz. Ask one clear question with three plausible short choices using the real native question tool. Include prerequisite understanding, a worked-state prediction and an application or tradeoff question as appropriate; shuffle choices and avoid answer-revealing labels or descriptions. Wait for an actual submitted answer. A default/preselected option, an async call returning, a timeout, skip or cancellation is not a correct or incorrect answer. Keep the same pending question until its response is resolved. In practice mode explain the answer after submission and adapt subsequent difficulty/concept to demonstrated understanding. In test mode defer correctness feedback until completion. Evaluate free-text answers fairly against the actual question rather than guessing a clicked option. Finish at the question limit or user cancellation with a bounded assessment, missed concepts and suggested review. Do not claim mastery from a short quiz or save a permanent learner profile without request. Establish question count and practice versus test mode; test one concept per question and keep the answer key out of the presentation payload.
+
+## Decision branches
+
+- **When question tool is missing or restricted to clarification:** Report that assessment is unavailable in this mode; do not disguise quiz questions as implementation clarifications.
+
+## Deliver and verify
+
+- Native multiple-choice question dialogs, answer-dependent feedback, and a final short assessment with concepts to revisit. Question text stays in the dialog; explanations may appear in normal conversation after answers.
+- Submitted-answer evidence, grading rationale, skips, and a scoped assessment of demonstrated knowledge.
+
+Verify these observable conditions when applicable to the actual task; do not claim they were exercised from merely reading this file:
+
+- The host receives question/options only, with no answer key or explanation in the native payload. A second question cannot be presented before the pending answer is resolved.
+- Empty, absent, default-only and delayed async responses do not advance or grade the quiz. Skips/cancellations do not count as incorrect; stale answers cannot answer a newer question.
+- A linked-list quiz checks traversal, known-node insertion and pointer order. An ml-split quiz checks temporal/entity leakage and never starts training. If native dialogs are unavailable, the workflow reports that limitation and does not substitute inline quiz questions.
+
+## Stop and recover
+
+- Stop on the requested question limit, cancellation, missing native-dialog capability, ambiguous topic, or an unresolved answer. Respect tool-specific host/mode restrictions; do not force Plan mode, grant permissions, or simulate a native dialog by printing JSON or markdown.
+
+## Example requests
+
+- **Normal (inspect):** Quiz me on linked lists using the native question dialog, one question at a time.
+- **edge (inspect):** Test linked-list operations; skip one question and explain only at the end.
+- **blocked (inspect):** Inspect whether this host permits native assessment dialogs; do not print an inline quiz.

package/plugins/just-vibe/skills/test/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: test
+description: "Add meaningful coverage for specified behavior Use to implement behavior checks; coverage identifies gaps and verify runs existing checks."
+---
+
+# test
+
+Add meaningful coverage for specified behavior
+
+## Choose this workflow
+
+Use to implement behavior checks; coverage identifies gaps and verify runs existing checks.
+
+Read [shared execution](../../references/execution.md) for context/mode/authority handling and [General methods](../../references/packs/general.md) for tool selection and operational details. Resolve these paths from this skill file; all runtime assets ship inside the plugin.
+
+## Input and mode
+
+Use the complete request appended to this invocation, preserving all constraints and references. Default mode: **apply**. Apply; behavior to protect, target code, and existing test conventions.
+
+Resolve the user brief and inspect the relevant project or supplied evidence. External capabilities are optional unless the selected action actually needs them.
+
+Declared evidence requirements: `project.read`. Use actual host discovery or adequate supplied artifacts; unavailable evidence remains blocked/unknown.
+
+## Scope
+
+Meaningful behavior coverage at the cheapest reliable layer; no arbitrary coverage quota or whole-suite rewrite.
+
+Only the requested local changes; external actions require their exact action and target in session authorization.
+
+## Execute
+
+- Inspect existing tests, identify important gaps, choose unit/integration/end-to-end scope, add representative cases, and run relevant checks.
+- Choose the lowest layer that can observe the contract; retain an independent expected result and demonstrate that the check detects a plausible regression.
+
+## Decision branches
+
+- **When the proposed assertion mirrors internal implementation:** Replace it with an external invariant or consumer-observable result.
+
+## Deliver and verify
+
+- Tests, fixture changes when necessary, execution results, and covered behavior.
+- Tests and fixtures mapped to requirements, execution results and uncovered boundaries.
+
+Verify these observable conditions when applicable to the actual task; do not claim they were exercised from merely reading this file:
+
+- A realistic behavioral regression fails the new test; harmless internal refactoring does not invalidate assertions.
+
+## Stop and recover
+
+- Report unavailable services/runners. Avoid tests that merely restate implementation or require live paid endpoints without authorization.
+
+## Example requests
+
+- **Normal (apply):** Add meaningful coverage for expired invitations and repeated acceptance.
+- **edge (apply):** Add tests for duplicate submissions and a legitimate repeated purchase.
+- **blocked (inspect):** Assess test design without the integration environment; do not mark mocks as live coverage.

package/plugins/just-vibe/skills/test-e2e/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: test-e2e
+description: "Exercise complete user journeys and recovery Use for a critical user journey across the actual interface; test-unit is preferable for pure logic branches."
+---
+
+# test-e2e
+
+Exercise complete user journeys and recovery
+
+## Choose this workflow
+
+Use for a critical user journey across the actual interface; test-unit is preferable for pure logic branches.
+
+Read [shared execution](../../references/execution.md) for context/mode/authority handling and [Testing methods](../../references/packs/testing.md) for tool selection and operational details. Resolve these paths from this skill file; all runtime assets ship inside the plugin.
+
+## Input and mode
+
+Use the complete request appended to this invocation, preserving all constraints and references. Default mode: **apply**. Apply; critical journey, environment, test accounts, and external side-effect constraints.
+
+defined behavior, existing test conventions/runners, isolated fixtures, and relevant dependencies. Execution belongs in apply mode. Never test destructive behavior against production by default; distinguish mocked behavior from real integration evidence.
+
+Declared evidence requirements: `project.read`. Use actual host discovery or adequate supplied artifacts; unavailable evidence remains blocked/unknown.
+
+## Scope
+
+Full user-visible flows including recovery, through real application boundaries available in the test environment.
+
+Only the requested local changes; external actions require their exact action and target in session authorization.
+
+## Execute
+
+- Seed controlled data, use robust user-facing selectors, exercise the journey and failure recovery, assert observable outcomes, and clean up owned data.
+- Define stable setup and cleanup, drive user-visible controls with semantic locators and assert the final meaningful outcome plus a recovery path.
+
+## Decision branches
+
+- **When a third-party payment or email effect is real:** Use an authorized sandbox or controlled boundary; do not send real effects merely to complete a test.
+
+## Deliver and verify
+
+- End-to-end tests, traces on failure, and environment/coverage notes.
+- Journey steps, environment, assertions, artifacts and untested external boundaries.
+
+Verify these observable conditions when applicable to the actual task; do not claim they were exercised from merely reading this file:
+
+- A completed UI action has the intended persisted outcome; failed submission preserves recoverable user state.
+
+## Stop and recover
+
+- Do not send real payments/emails or modify user accounts without explicit scope. Missing integrations are labeled honestly.
+
+## Example requests
+
+- **Normal (apply):** Test checkout error recovery using controlled test accounts and no real charges.
+- **edge (apply):** Test checkout failure and retry without duplicate orders.
+- **blocked (inspect):** Plan browser tests when no browser tool is available; do not claim rendered success.

package/plugins/just-vibe/skills/test-fixtures/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: test-fixtures
+description: "Create representative, maintainable test data Use for controlled test data and factories; data-profile inspects real datasets."
+---
+
+# test-fixtures
+
+Create representative, maintainable test data
+
+## Choose this workflow
+
+Use for controlled test data and factories; data-profile inspects real datasets.
+
+Read [shared execution](../../references/execution.md) for context/mode/authority handling and [Testing methods](../../references/packs/testing.md) for tool selection and operational details. Resolve these paths from this skill file; all runtime assets ship inside the plugin.
+
+## Input and mode
+
+Use the complete request appended to this invocation, preserving all constraints and references. Default mode: **apply**. Apply; behaviors, schema, edge cases, existing factories, and privacy constraints.
+
+defined behavior, existing test conventions/runners, isolated fixtures, and relevant dependencies. Execution belongs in apply mode. Never test destructive behavior against production by default; distinguish mocked behavior from real integration evidence.
+
+Declared evidence requirements: `project.read`. Use actual host discovery or adequate supplied artifacts; unavailable evidence remains blocked/unknown.
+
+## Scope
+
+Representative deterministic test data and lifecycle helpers.
+
+Only the requested local changes; external actions require their exact action and target in session authorization.
+
+## Execute
+
+- Derive minimal realistic entities, encode valid defaults and deliberate invalid cases, isolate identities/timestamps, and verify cleanup and repeatability.
+- Define valid defaults and deliberate invalid variants, isolate identifiers and clocks and make teardown safe after partial setup failure.
+
+## Decision branches
+
+- **When random generation makes failures hard to reproduce:** Use a recorded seed and expose the important boundary explicitly.
+
+## Deliver and verify
+
+- Fixtures/factories with semantics, usage, and consistency checks.
+- Fixture contract, edge variants, cleanup behavior and concurrent-use checks.
+
+Verify these observable conditions when applicable to the actual task; do not claim they were exercised from merely reading this file:
+
+- Two concurrent tests do not collide on shared identifiers; boundary cases remain explicit rather than accidental random data.
+
+## Stop and recover
+
+- Never copy raw production personal data for convenience. Avoid large opaque snapshots that hide which conditions matter.
+
+## Example requests
+
+- **Normal (apply):** Build deterministic organization fixtures safe for concurrent test runs.
+- **edge (apply):** Create fixtures that remain isolated when tests run in parallel.
+- **blocked (inspect):** Design fixtures without copying production personal records.

package/plugins/just-vibe/skills/test-flaky/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: test-flaky
+description: "Repair nondeterminism using repeated evidence Use for nondeterministic failures; debug first identifies the relevant failing test/environment."
+---
+
+# test-flaky
+
+Repair nondeterminism using repeated evidence
+
+## Choose this workflow
+
+Use for nondeterministic failures; debug first identifies the relevant failing test/environment.
+
+Read [shared execution](../../references/execution.md) for context/mode/authority handling and [Testing methods](../../references/packs/testing.md) for tool selection and operational details. Resolve these paths from this skill file; all runtime assets ship inside the plugin.
+
+## Input and mode
+
+Use the complete request appended to this invocation, preserving all constraints and references. Default mode: **apply**. Apply; flaky test, failure history, environment, and repetition budget.
+
+defined behavior, existing test conventions/runners, isolated fixtures, and relevant dependencies. Execution belongs in apply mode. Never test destructive behavior against production by default; distinguish mocked behavior from real integration evidence.
+
+Declared evidence requirements: `project.read`. Use actual host discovery or adequate supplied artifacts; unavailable evidence remains blocked/unknown.
+
+## Scope
+
+Nondeterminism from shared state, order, time, async behavior, randomness, or environment.
+
+Only the requested local changes; external actions require their exact action and target in session authorization.
+
+## Execute
+
+- Reproduce under controlled repeats/order/seeds, inspect first divergent evidence, fix isolation or synchronization, and rerun bounded stress checks.
+- Record order, seed, clock and shared-resource conditions, vary one factor under a repeat cap and replace timing guesses with explicit synchronization.
+
+## Decision branches
+
+- **When no failure occurs during bounded repeats:** Report the sample and uncertainty; do not declare the flake eliminated solely from absence.
+
+## Deliver and verify
+
+- Cause, repair, repeat counts, failure rates, and residual uncertainty.
+- Trigger conditions, isolation/synchronization fix and bounded repeat results.
+
+Verify these observable conditions when applicable to the actual task; do not claim they were exercised from merely reading this file:
+
+- The triggering interleaving/order is exercised; no failures across a stated sample is not described as mathematical proof.
+
+## Stop and recover
+
+- Do not hide failures with retries, sleeps, skipped tests, or inflated timeouts without evidence. Stop at the repeat budget.
+
+## Example requests
+
+- **Normal (apply):** Fix the test that fails only in suite order; cap diagnosis at 30 repeats.
+- **edge (apply):** Repair a test that fails only after another test changes global state.
+- **blocked (inspect):** Inspect flake logs without rerunning expensive suites or adding arbitrary sleeps.