@runcofactor/cli 0.46.0 → 0.47.0

package/dist/{skill-G2654GLA.js → skill-A4MN7UIT.js}

@@ -1,7 +1,7 @@
 import { createRequire as __cr } from "module"; import { fileURLToPath as __fup } from "url"; import { dirname as __dn } from "path"; const require = __cr(import.meta.url); const __filename = __fup(import.meta.url); const __dirname = __dn(__filename);
 import {
   WORKFLOW_GUIDE_CONCEPT_SECTIONS
-} from "./chunk-IJTIWAY6.js";
+} from "./chunk-BYKQ5N5L.js";
 import {
   brandSkillContentFor,
   command
@@ -1469,18 +1469,18 @@ canary upgrade           # Upgrade to latest version
 // src/skill-templates/test-cases-current.ts
 var testCasesRenderCurrent = () => `---
 name: test-cases
-version: 2.5.0
-description: Author high-quality test cases as \`.cofactor.md\` specs that compile straight into Cofactor workflows. Invoke when the user asks to write test cases, draft a test plan, plan QA scenarios, decide what to test, or convert a PRD/ticket/design into tests.
+version: 2.6.0
+description: Plan high-quality test journeys and assertions, then create or update Cofactor workflows through the CLI using the caller\u2019s requested output.
 allowed-tools: Read, Grep, Glob, Bash, Write
 ---
 
 # Test Case Authoring (Cofactor)
 
-Use this skill when the user asks for test cases, a test plan, QA scenarios, "what should we test for X", or wants to turn a PRD / ticket / design into tests. The output is one or more **\`.cofactor.md\` spec files** \u2014 each file is one workflow, one journey, one test case. \`cofactor spec compile <file>\` turns them into runnable Cofactor workflows; \`cofactor spec validate <file>\` enforces the structural rules below. (Legacy \`.canary.md\` files still validate and compile; new specs default to \`.cofactor.md\`.)
+Use this skill to plan high-quality test journeys and assertions. By default, create or update the flow directly through \`cofactor workflow create\`, \`cofactor workflow patch\`, and workflow node commands. Follow the caller\u2019s requested output. Write \`.cofactor.md\` files only when explicitly requested; the file-format sections below apply only to that mode.
 
 The skill has three layers:
 1. **Industry rubric** \u2014 what makes a test case good (ISTQB-aligned).
-2. **Spec mapping** \u2014 how each rubric piece becomes a section of \`.cofactor.md\`.
+2. **Authoring guidance** \u2014 direct CLI flows by default; file-format mapping when requested.
 3. **Domain Context** \u2014 customer-specific sources of truth, filled in once.
 
 Read the Domain Context block at the bottom **first**. If it is unfilled, follow the discovery instructions there before authoring any cases.
@@ -1496,12 +1496,12 @@ A case covers a single coherent journey \u2014 one user objective, possibly with
 
 - Good (coherent journey, multiple checks): "Onboard an org: create org \u2192 invite a user \u2192 claim invite \u2192 land on dashboard." Each step verifies its own outcome inline.
 - Good (single short journey): "Submit a ticket and confirm it appears in the queue."
-- Bad (unrelated jobs): "Submit a ticket, edit a user, generate a report." \u2014 three journeys, three separate \`.cofactor.md\` files.
+- Bad (unrelated jobs): "Submit a ticket, edit a user, generate a report." \u2014 three journeys, three separate workflows.
 
 **Rule of thumb:** if isolating a check (e.g. "tagging works") would force you to duplicate most of another case's setup, fold it in as an inline assertion on the larger journey instead. Splitting only pays off when the setup is genuinely different or the failure modes are independent.
 
 ### 2. Specific, observable expected results
-Every assertion must be something a stranger could verify without judgement.
+Every assertion must be something a stranger could verify without judgement. Expected results come from codified requirements or confirmed user intent, not incidental DOM details discovered in exploration. Keep conditions about user-visible behavior; do not invent ARIA/SVG checks, arbitrary pixel thresholds, or signed-in-user checks when identity is only setup. Chosen scroll distances are action inputs; live measurements and tolerances belong in verification code.
 - Good: "URL ends with \`/dashboard\`." / "A row with name \`X\` appears in the table."
 - Bad: "The page looks correct." / "It works."
 
@@ -1556,6 +1556,8 @@ Aim for the smallest set that proves the feature works. Five sharp cases beat tw
 
 ## 3. Authoring \`.cofactor.md\`
 
+Sections 3\u20135 apply only when the caller explicitly requests file-based specs. For direct CLI authoring, use \`cofactor workflow --help\` and \`cofactor workflow guide\` for supported inputs, and return the workflow URL printed by the CLI.
+
 \`.cofactor.md\` is one workflow per file. Frontmatter sets identity; H2 sections carry prose and structured config; \`## Journey\` is the linear test itself. The compiler validates structure; lint enforces the rubric semantics above.
 
 Run these for the definitive grammar \u2014 do **not** restate them here:
@@ -1615,7 +1617,9 @@ When you need a value (workflow-level \`## Inputs\` or step-level \`- field\`),
 
 ## 4. Output format
 
-For each case, write a \`.cofactor.md\` file alongside a one-row summary line. Default location: \`cofactor/specs/<slug>.cofactor.md\` (confirm with the user if their repo uses a different layout \u2014 check Domain Context below).
+For direct CLI authoring, return the created or updated workflow link and a concise summary of the journey, assertions, data dependencies, and blockers.
+
+The file output below applies only when explicitly requested. For each case, write a \`.cofactor.md\` file alongside a one-row summary line. Default location: \`cofactor/specs/<slug>.cofactor.md\` (confirm with the user if their repo uses a different layout \u2014 check Domain Context below).
 
 ### Summary table
 
@@ -1766,12 +1770,12 @@ After writing, run \`cofactor spec validate cofactor/specs/submit-ticket.cofacto
 - **Default environment**: <unfilled \u2014 \`prod\` | \`staging\` | \`dev\`>
 - **Credentials / role matrix** (\`actor:\` is a persona name by default \u2014 list via \`cofactor persona list --application "<application>"\`. Prefix with \`credential \` to bind a specific raw credential \u2014 list via \`cofactor credential list\`. Use the persona form unless the case genuinely needs a fixed named account.): <unfilled \u2014 list the persona names available on the default application, with a one-line note on which to use when. Common shape: \`actor: Admin\` (standard user), \`actor: Superadmin\` (full access).>
 - **Tagging conventions**: <unfilled \u2014 e.g. \`smoke\`, \`regression\`, plus the priority tags \`p0\` / \`p1\` / \`p2\`>
-- **Spec directory**: <unfilled \u2014 where \`.cofactor.md\` files live in this repo, e.g. \`cofactor/specs/\`>
+- **Spec directory (file mode only)**: <unfilled \u2014 where \`.cofactor.md\` files live in this repo, e.g. \`cofactor/specs/\`>
 - **Existing workflows to extend or avoid duplicating**: <unfilled \u2014 search via \`cofactor workflow list --search <term>\`>
 - **Glossary / domain terms**: <unfilled \u2014 terms that show up in tickets and should appear verbatim in spec names>
 - **Other sources of truth**: <unfilled \u2014 runbooks, support tickets, analytics dashboards>
 
-When this block is fully populated, every case you author should reference at least the **Requirements**, **Default property**, **Spec directory**, and **Credentials** entries.
+When this block is fully populated, every case you author should reference at least the **Requirements**, **Default property**, and **Credentials** entries. Consult **Spec directory** only for explicitly requested file output; do not ask for it when authoring through the CLI.
 `;
 
 // src/skill-templates/test-cases-v2-3-0.ts
@@ -2065,6 +2069,314 @@ After writing, run \`cofactor spec validate cofactor/specs/submit-ticket.cofacto
 When this block is fully populated, every case you author should reference at least the **Requirements**, **Default property**, **Spec directory**, and **Credentials** entries.
 `;
 
+// src/skill-templates/test-cases-v2-5-0.ts
+var testCasesRenderV2_5_0 = () => `---
+name: test-cases
+version: 2.5.0
+description: Author high-quality test cases as \`.cofactor.md\` specs that compile straight into Cofactor workflows. Invoke when the user asks to write test cases, draft a test plan, plan QA scenarios, decide what to test, or convert a PRD/ticket/design into tests.
+allowed-tools: Read, Grep, Glob, Bash, Write
+---
+
+# Test Case Authoring (Cofactor)
+
+Use this skill when the user asks for test cases, a test plan, QA scenarios, "what should we test for X", or wants to turn a PRD / ticket / design into tests. The output is one or more **\`.cofactor.md\` spec files** \u2014 each file is one workflow, one journey, one test case. \`cofactor spec compile <file>\` turns them into runnable Cofactor workflows; \`cofactor spec validate <file>\` enforces the structural rules below. (Legacy \`.canary.md\` files still validate and compile; new specs default to \`.cofactor.md\`.)
+
+The skill has three layers:
+1. **Industry rubric** \u2014 what makes a test case good (ISTQB-aligned).
+2. **Spec mapping** \u2014 how each rubric piece becomes a section of \`.cofactor.md\`.
+3. **Domain Context** \u2014 customer-specific sources of truth, filled in once.
+
+Read the Domain Context block at the bottom **first**. If it is unfilled, follow the discovery instructions there before authoring any cases.
+
+---
+
+## 1. The 7-rule rubric
+
+Each case must satisfy all seven. If a rule cannot be satisfied, say so explicitly and explain why \u2014 don't silently skip.
+
+### 1. One coherent journey per case (atomic, but not micro)
+A case covers a single coherent journey \u2014 one user objective, possibly with several verifications along the way. "Atomic" means *coherent*, not *minimal*: if multiple checks share the same setup and naturally flow from one another, they belong in the same case.
+
+- Good (coherent journey, multiple checks): "Onboard an org: create org \u2192 invite a user \u2192 claim invite \u2192 land on dashboard." Each step verifies its own outcome inline.
+- Good (single short journey): "Submit a ticket and confirm it appears in the queue."
+- Bad (unrelated jobs): "Submit a ticket, edit a user, generate a report." \u2014 three journeys, three separate \`.cofactor.md\` files.
+
+**Rule of thumb:** if isolating a check (e.g. "tagging works") would force you to duplicate most of another case's setup, fold it in as an inline assertion on the larger journey instead. Splitting only pays off when the setup is genuinely different or the failure modes are independent.
+
+### 2. Specific, observable expected results
+Every assertion must be something a stranger could verify without judgement.
+- Good: "URL ends with \`/dashboard\`." / "A row with name \`X\` appears in the table."
+- Bad: "The page looks correct." / "It works."
+
+Lint enforces this as **R1**: a spec with zero run-failing (\`fail\`/\`fatal\`) assertions warns.
+
+### 3. Idempotent, self-owned, isolated \u2014 by default
+These are strong defaults, not absolutes: a case defaults to the rule, uses the named workaround when the app makes the rule impossible, and says so in \`## Preflight\` / \`## Cleanup\` so the deviation is visible, never silent.
+- **Idempotent** \u2014 rerunning the case, including after a failed run, passes without a manual reset. Canonical macros (\\$EMAIL(), \\$UUID(), \`QA Test \u2014 \\$RANDOM_STRING(6)\`) make this true even when cleanup never ran. Workaround: if the app forbids duplicates (a singleton setting), revert in \`## Cleanup\` and say so.
+- **Controls its own data** \u2014 create the records the case operates on **inline** (\`## Inputs\` + \`## Scenarios\`, an action node that creates them). A \`**Seed**\` node is for data that several specs share; a seed with one consumer is overhead. Workaround: pre-existing environment data the case only *reads* is fine \u2014 declare it in \`## Preflight\` and never mutate it.
+- **Isolated** \u2014 works only on data it created; never modifies shared resources (billing, integrations, API keys, org config) as a side effect. Cases that genuinely depend on one another are ordered as **suite layers** (\`cofactor test-suite \u2026 --layer\`), never by implicit ordering.
+- **Cleanup survives failure** \u2014 a \`fatal\` assertion halts the run before trailing cleanup nodes execute; seed-paired teardowns run on pass and fail. Inline cleanup is best-effort and pairs with unique naming; a record that must be gone even after a failure is provisioned by a seed with a teardown.
+- **External dependencies are declared or captured** \u2014 email delivery via a seed credential output with an email inbox; payments, third-party APIs, and feature flags declared in \`## Preflight\`.
+
+### 4. Traceable
+Every case carries \`requirementRef:\` in frontmatter pointing at the ticket / PRD / design. If you can't find one, flag the gap to the user \u2014 untraceable specs rot. Lint **R2** warns when missing.
+
+### 5. Risk-prioritized
+Tag each case with a priority via the \`tags:\` array. Use one of: \`p0\`, \`p1\`, \`p2\`.
+- **p0** \u2014 happy path of the core promise; if this breaks, the feature is broken.
+- **p1** \u2014 primary edge cases, validation, role variants, common error states.
+- **p2** \u2014 rare conditions, visual/agentic checks, low-frequency edges.
+
+### 6. Includes preconditions, data, and cleanup
+- **Auth/role preconditions** \u2192 \`actor:\` in frontmatter.
+- **Other preconditions** (feature flags, seeded data, sister flows, pre-existing data the case reads but doesn't own, external systems) \u2192 bulleted prose in \`## Preflight\`.
+- **Test data** \u2192 \`## Inputs\` (with macros) and per-variant \`## Scenarios\`.
+- **Teardown** \u2192 bulleted prose in \`## Cleanup\`.
+
+### 7. Written as human intent, not UI mechanics
+Action titles describe *what the user is trying to do*; the optional \`> blockquote\` underneath gives just enough context for the recorder/agent. Don't write click-by-click sequences.
+- Good: \`**Action \u2014 Assign the ticket to Support**\`
+- Bad: \`**Action \u2014 Click 'Assign' dropdown, scroll, click 'Support', click Save**\`
+
+Lint **R9** warns when an action reads as click-by-click.
+
+---
+
+## 2. Coverage checklist
+
+Before handing back a set of specs, sanity-check coverage. For each, either include a case or note why it doesn't apply:
+- Happy path (p0)
+- Primary edges / boundary inputs
+- Negative paths / validation errors
+- Permissions and role variants (admin / member / unauthenticated)
+- Empty, loading, and error states
+- Cross-entity side effects (does this change something visible elsewhere?)
+- Cleanup / undo where applicable
+
+Aim for the smallest set that proves the feature works. Five sharp cases beat twenty fuzzy ones.
+
+---
+
+## 3. Authoring \`.cofactor.md\`
+
+\`.cofactor.md\` is one workflow per file. Frontmatter sets identity; H2 sections carry prose and structured config; \`## Journey\` is the linear test itself. The compiler validates structure; lint enforces the rubric semantics above.
+
+Run these for the definitive grammar \u2014 do **not** restate them here:
+
+\`\`\`bash
+cofactor spec --help               # validate / compile / diff commands
+cofactor spec validate <file>      # parse + lint offline; enforce the rules in \xA71
+cofactor spec compile <file>       # create or update the workflow (prints the live URL)
+cofactor workflow guide            # node-shape and macro reference
+\`\`\`
+
+After \`cofactor spec compile\`, echo the printed \`URL:\` line back to the user verbatim \u2014 it points at the workflow you just created (\`https://app.runcofactor.com/flows/<id>\` for prod, \`https://app.dev.runcofactor.com/flows/<id>\` for dev). Don't construct it yourself.
+
+Mapping at a glance:
+
+| Rubric piece                            | Where it lives in \`.cofactor.md\`                                          |
+|-----------------------------------------|---------------------------------------------------------------------------|
+| Case title                              | \`frontmatter.name\`                                                       |
+| Requirement / ticket ref                | \`frontmatter.requirementRef\`                                             |
+| Priority (rule 5)                       | \`tags: [p0]\` (or p1/p2) in frontmatter                                   |
+| Auth role precondition                  | \`actor: <X>\` + \`authenticated: true\` in frontmatter. \`<X>\` is a **persona** name by default (e.g. \`actor: Admin\` or the explicit \`actor: persona Admin\`), or a specific raw credential via \`actor: credential <name>\` when the case genuinely needs one named account. Personas resolve at run/suite level; raw credentials bind a single fixed account. Legacy \`actor: template Admin\` remains accepted. List personas with \`cofactor persona list --application "<application>"\`; list credentials with \`cofactor credential list\`. |
+| Feature flag / seeded data / read-only pre-existing data preconditions | Bulleted prose in \`## Preflight\` ("Feature flag X enabled.", "Seed workflow Y published.", "Property 'Acme Demo' exists with \u22651 issue \u2014 read only.") |
+| One-paragraph user-visible promise      | \`## Spirit\` (blockquote)                                                 |
+| Workflow-level declared inputs          | \`## Inputs\` (e.g. \`- foo: \\$EMAIL()\`) \u2014 parses to \`workflows.inputs_json\`, surfaces in Workflow Settings \u2192 Inputs. Later values may compose earlier value inputs with \`\\$var.<name>\`; self/forward/unknown references are invalid. |
+| Per-step bound values                   | \`- field X: Y\` under an Action \u2014 populates *that* step's Inputs panel with \`Y\` as the default (compiler mirrors fields \u2192 \`dataRequirements\` + \`inputValues\` on the node). Prefer \`## Inputs\` for values shared across actions. |
+| Variants (free / enterprise, etc.)      | \`## Scenarios\` with per-scenario \`values:\` / \`credentials:\` overrides  |
+| Steps (human intent)                    | \`## Journey\` \u2014 \`**Navigate to** \u2026\`, \`**Action \u2014 \u2026**\`, \`**Seed** \u2026\`     |
+| Inline expected results                 | \`- assert (fatal \\| fail \\| warn): <condition>\` under the action that produced it. \`fatal\` ends the test now (gating preconditions), \`fail\` marks the run failed but keeps going (feature claims), \`warn\` records without failing (cosmetics) |
+| Standalone assertion                    | \`**Assert** <condition>\` node (prefer inline when possible)              |
+| Role change mid-journey                 | \`**Switch role to** <X>\` \u2014 mirrors \`actor:\`. \`<X>\` is a persona name by default (\`**Switch role to** Admin\`), \`persona <name>\` is the explicit persona form (\`**Switch role to** persona Admin\`), \`credential <name>\` binds a specific raw credential (\`**Switch role to** credential admin-bob\`). Legacy \`template <name>\` remains accepted. Compiles to a login node with \`performLogin: true\`. Repeat as many times as needed in one journey. |
+| Cross-action data flow                  | \`- capture: <name>\` on the upstream action, \`\\$var.<name>\` downstream  |
+| Cleanup                                 | Bulleted prose in \`## Cleanup\`                                           |
+
+When a journey shares setup and naturally flows end-to-end, emit **one** \`.cofactor.md\` with multiple action nodes and inline assertions. When journeys are unrelated, emit **one file per journey**; if one journey depends on data created by another, link them with \`**Seed** <spec-name>\` at the top of the dependent file (setup nodes are deprecated). If the journeys must *run* in order rather than share data, order them as suite layers.
+
+### Action altitude \u2014 what each \`**Action \u2014**\` step should cover
+
+Each \`**Action \u2014**\` is one coherent, intent-level step. The same altitude the Flow Designer and recorder use applies here (see \`cofactor workflow guide action-nodes\`):
+
+- **One coherent step, usually broader than a single click** \u2014 "Submit the ticket", "Fill out the subscription form". A lone action that stands on its own ("Click Start to open the config modal") is fine; a purely mechanical title ("Click the button") or a stuffed multi-outcome step is not. When the recorder compiles your step it should land around 3\u20138 playbook actions \u2014 if one \`**Action \u2014**\` implies ~20 clicks across several screens, it's two actions.
+- **End each step at an assertable boundary** (modal gone, URL changed, row appeared) and assert it inline. Relative or temporal checks must reference an upstream \`- capture:\` \u2014 \`assert (fail): current count = \\$var.start_count - 2\`, never "the count dropped by 2" (a cache-replayed action's assertion can be judged with no memory of the "before" state).
+- **No conditionals inside a step** \u2014 "if patient X isn't there, create X" usually means the data wasn't seeded; stage it in \`## Preflight\` / a \`**Seed**\` instead. If the same steps reach the goal from any starting state (idempotent), just write them unconditionally.
+
+### Inputs defaults \u2014 the decision rule
+
+When you need a value (workflow-level \`## Inputs\` or step-level \`- field\`), pick where it comes from in this order:
+
+1. **Names existing data in the target environment** \u2014 a property name, a credential, a seeded record, an existing org/user/team. **Stop and ask the user for the value before writing the spec.** Don't hand-pick. The right sources of truth:
+   - \`cofactor property list\` \u2014 properties (target apps)
+   - \`cofactor persona list --application "<application>"\` \u2014 personas (these are what \`actor:\` and \`- credential \u2026\` reference)
+   - \`cofactor workflow list --search <term>\` \u2014 existing workflows to seed/link to
+   - \`cofactor feature-flag list --env <env>\` \u2014 flag names for Preflight prose
+2. **Synthesizable** \u2014 a new email, a UUID, a throwaway string, an ISO date. Pick a macro (\`\\$EMAIL()\`, \`\\$UUID()\`, \`\\$TODAY()\`) and move on without asking. Parentheses are mandatory, including for zero-argument macros. These render as pills in the Inputs panel and resolve at run time.
+3. **Prefer personas** for any auth/role-scoped input. \`actor: Admin\` (frontmatter) and \`- credential admin: Admin\` (inputs) are cleaner than passing \`username:\` + \`password:\` and work across environments. Reach for the raw-credential form (\`actor: credential <name>\`, \`**Switch role to** credential <name>\`, \`- credential admin: <name>\`) only when the case genuinely requires a specific fixed account.
+
+---
+
+## 4. Output format
+
+For each case, write a \`.cofactor.md\` file alongside a one-row summary line. Default location: \`cofactor/specs/<slug>.cofactor.md\` (confirm with the user if their repo uses a different layout \u2014 check Domain Context below).
+
+### Summary table
+
+| file                              | name                                       | priority | requirementRef   |
+|-----------------------------------|--------------------------------------------|----------|------------------|
+| cofactor/specs/submit-ticket.cofactor.md | Submit a ticket and confirm it appears in the queue | p0       | <ticket/PRD ref> |
+
+### Per-case file
+
+\`\`\`markdown
+---
+name: <one user goal, action-oriented>
+actor: <persona name from Domain Context \u2014 verbatim, e.g. "Admin"; or \`credential <name>\` for a specific raw credential>
+authenticated: true
+tags: [p0]            # or p1 / p2; add other tags from Domain Context's tagging conventions
+requirementRef: <ticket id, PRD path, design link>
+---
+
+# <same as name>
+
+## Spirit
+> <one short paragraph: the user-visible promise this case proves>
+
+## Preflight
+- <feature flag / seed / sister flow / role precondition, one per bullet>
+
+## Cleanup
+- <records to delete, flags to reset>
+
+## Inputs
+- <name>: <value or macro>
+
+## Journey
+
+**Navigate to** \\\`/some/path\\\`.
+
+**Action \u2014 <human intent>**
+> <one-sentence context for the recorder/agent>
+- field <name> [(type)]: <value or \\$input>
+- capture: <name>        # optional, only if a later step needs it via \\$var.<name>
+- assert (fatal): <gating precondition \u2014 test must stop if wrong>
+- assert (fail): <observable condition \u2014 feature is broken if wrong>
+- assert (warn): <softer signal \u2014 cosmetic, run still passes>
+
+**End**.
+\`\`\`
+
+A case is one coherent journey \u2014 long or short, with no target node count. If a case grows very long, ask whether it's really several independent journeys: splitting them into separate \`.cofactor.md\` files lets them run in parallel and fail independently. Keep a single coherent journey together \u2014 don't split mid-flow.
+
+---
+
+## 5. Worked example (generic)
+
+Request: "Test the support ticket flow."
+
+| file                                      | name                                                | priority | requirementRef |
+|-------------------------------------------|-----------------------------------------------------|----------|----------------|
+| cofactor/specs/submit-ticket.cofactor.md       | Submit a ticket and confirm it appears in the queue | p0       | <fill in>      |
+| cofactor/specs/ticket-required-fields.cofactor.md | Required-field validation blocks submit          | p1       | <fill in>      |
+| cofactor/specs/ticket-non-admin-reassign.cofactor.md | Non-admin cannot reassign a ticket            | p1       | <fill in>      |
+
+\`cofactor/specs/submit-ticket.cofactor.md\`:
+
+\`\`\`markdown
+---
+name: Submit a ticket and confirm it appears in the queue
+actor: Admin
+authenticated: true
+tags: [p0, smoke, support]
+requirementRef: <fill in>
+---
+
+# Submit a ticket and confirm it appears in the queue
+
+## Spirit
+> A member can file a support ticket from the in-app form and immediately
+> see it land in their team's queue without a refresh.
+
+## Preflight
+- At least one Support team exists in the test org (seed workflow \\\`support-team-seed\\\`).
+- Feature flag \\\`support_inbox_v3\\\` is enabled.
+
+## Cleanup
+- Delete the created ticket.
+
+## Inputs
+- subject: "QA \\$UUID()"
+- priority: high
+
+## Journey
+
+**Navigate to** \\\`/support/new\\\`.
+
+**Action \u2014 Submit the ticket**
+> Fill subject and priority, then submit.
+- field subject: \\$subject
+- field priority (select): \\$priority
+- assert (warn): Toast contains "Ticket created"
+- assert (fail): URL ends with \\\`/support\\\`
+
+**Navigate to** \\\`/support/queue\\\`.
+
+**Action \u2014 Confirm it appears in the queue**
+> Locate the new ticket in the team queue.
+- assert (fail): A row matching \\\`\\$subject\\\` is visible
+
+**End**.
+\`\`\`
+
+After writing, run \`cofactor spec validate cofactor/specs/submit-ticket.cofactor.md\` and resolve any errors / warnings before handing back.
+
+---
+
+## 6. Anti-patterns
+
+- Mega-files that try to cover five unrelated journeys.
+- The opposite: splitting one coherent journey into N tiny files that each re-create the same setup. Bundle them into one \`## Journey\` instead.
+- Click-by-click action titles ("Click X, scroll, click Y").
+- Conditional steps ("if X isn't set, set it"; "if patient X is missing, create X") \u2014 seed the precondition or write idempotent steps instead.
+- Relative or temporal assertions ("the count dropped by 2") with no upstream \`- capture:\` to anchor the baseline.
+- "Looks correct" / "everything works" assertions.
+- Hardcoded emails, IDs, or names that collide on rerun. Use macros (\\$EMAIL(), \\$UUID()).
+- Specs that depend on another spec having run first without an explicit \`**Seed**\` node or a suite layer. Setup nodes are deprecated \u2014 don't emit them.
+- A \`**Seed**\` for data only this spec uses \u2014 create it inline instead.
+- Mutating data the spec didn't create, or relying on pre-existing data without declaring it in \`## Preflight\`.
+- Skipping \`requirementRef\` because "it's obvious".
+- Asserting state via toasts only \u2014 confirm the underlying record changed.
+- Dropping the priority tag \u2014 risk-rank every case (\`p0\` / \`p1\` / \`p2\`).
+
+---
+
+## 7. Domain Context
+
+<!-- AGENT/CUSTOMER: fill in this block on first use of the skill, then commit it. -->
+<!-- If any field below is "<unfilled>", do a discovery pass before authoring cases: -->
+<!--   - Read README.md, CLAUDE.md, AGENTS.md, docs/, specs/ for requirement and design pointers. -->
+<!--   - Scan recent git log for ticket-tracker references (JIRA-123, LIN-456, #issue). -->
+<!--   - Run \`cofactor property list\` and \`cofactor persona list --application "<application>"\` to learn applications + the personas that map to \`actor:\` values. -->
+<!--   - (\`cofactor credential list\` shows live credentials \u2014 useful, but the \`actor:\` field references personas, not credentials.) -->
+<!--   - Run \`cofactor workflow list --search <feature>\` to avoid duplicating existing workflows. -->
+<!--   - Run \`cofactor feature-flag list\` to confirm flag names referenced in Preflight prose. -->
+<!--   - Propose values to the user, get confirmation, then edit this block in place. -->
+
+- **Requirements / PRDs**: <unfilled \u2014 paths or URLs, e.g. \`docs/specs/\`, Notion space, Linear project>
+- **Designs**: <unfilled \u2014 Figma links, design system doc>
+- **Ticket tracker**: <unfilled \u2014 Jira/Linear project key + how to format \`requirementRef\` (e.g. \`PROJ-123\` or a URL)>
+- **Default property**: <unfilled \u2014 the property name to target; find via \`cofactor property list\`>
+- **Default environment**: <unfilled \u2014 \`prod\` | \`staging\` | \`dev\`>
+- **Credentials / role matrix** (\`actor:\` is a persona name by default \u2014 list via \`cofactor persona list --application "<application>"\`. Prefix with \`credential \` to bind a specific raw credential \u2014 list via \`cofactor credential list\`. Use the persona form unless the case genuinely needs a fixed named account.): <unfilled \u2014 list the persona names available on the default application, with a one-line note on which to use when. Common shape: \`actor: Admin\` (standard user), \`actor: Superadmin\` (full access).>
+- **Tagging conventions**: <unfilled \u2014 e.g. \`smoke\`, \`regression\`, plus the priority tags \`p0\` / \`p1\` / \`p2\`>
+- **Spec directory**: <unfilled \u2014 where \`.cofactor.md\` files live in this repo, e.g. \`cofactor/specs/\`>
+- **Existing workflows to extend or avoid duplicating**: <unfilled \u2014 search via \`cofactor workflow list --search <term>\`>
+- **Glossary / domain terms**: <unfilled \u2014 terms that show up in tickets and should appear verbatim in spec names>
+- **Other sources of truth**: <unfilled \u2014 runbooks, support tickets, analytics dashboards>
+
+When this block is fully populated, every case you author should reference at least the **Requirements**, **Default property**, **Spec directory**, and **Credentials** entries.
+`;
+
 // src/skill-templates/test-cases-v2-4-0.ts
 var testCasesRenderV2_4_0 = () => `---
 name: test-cases
@@ -2369,12 +2681,13 @@ When this block is fully populated, every case you author should reference at le
 // src/skill-templates/test-cases.ts
 var testCasesTemplate = {
   name: "test-cases",
-  description: "Author high-quality test cases as `.cofactor.md` specs that compile straight into Cofactor workflows. Invoke when the user asks to write test cases, draft a test plan, plan QA scenarios, decide what to test, or convert a PRD/ticket/design into tests.",
-  version: "2.5.0",
+  description: "Plan high-quality test journeys and assertions, then create or update Cofactor workflows through the CLI using the caller\u2019s requested output.",
+  version: "2.6.0",
   render: testCasesRenderCurrent,
   previousVersions: {
     "2.3.0": testCasesRenderV2_3_0,
-    "2.4.0": testCasesRenderV2_4_0
+    "2.4.0": testCasesRenderV2_4_0,
+    "2.5.0": testCasesRenderV2_5_0
   }
 };
 
@@ -3049,4 +3362,4 @@ export {
   resolveInstallDir,
   runSkill
 };
-//# sourceMappingURL=skill-G2654GLA.js.map
+//# sourceMappingURL=skill-A4MN7UIT.js.map