agentleFS
DanWahlinDanWahlin/github-azure-agentic-journeys/.github/skills/journey-test-harness/SKILL.md

journey-test-harness

Skill37 starsChanged 4 months agoMITView on GitHub

Run multiple journeys as a cross-platform test suite. Discover journeys, invoke journey-runner in isolated workspaces, deploy, verify, capture screenshots, clean up only owned Azure resources, and produce a consolidated report. USE FOR: test all journeys, regression test, CI journey validation, nightly journey test, end-to-end journey suite, validate journeys deploy correctly. DO NOT USE FOR: running one journey interactively (use journey-runner), creating journeys (use journey-template), or reviewing content (use content-reviewer).

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 1

    1. microsoft/agentic-journeys★ 5100% same

    Edited · 0

    None found.

    Wrote their own version · 0

    None found.

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository8 other files it gives its agents.

The file

Show its rules and text

We split this skill into the rules it gives an agent

22 rules. About 0 are common, 11 are distinctive, and 11 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 11

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use repository file-search APIs or Node.js fs.readdir() to find journeys/*/README.md.

    line 25
  2. Very specific:

    Use .github/skills/journey-runner/scripts/check-prerequisites.mjs with the union of required tools.

    line 53
  3. Very specific:

    Check Azure CLI and azd authentication separately.

    line 57
  4. Very specific:

    Create directories through Node.js filesystem APIs or the active agent's file tools:

    line 65
  5. Very specific:

    Use path.join() and absolute paths.

    line 75
  6. Distinctive:

    Run serially by default. Parallel runs require:

    line 93
  7. Very specific:

    Never share an azd environment across journeys.

    line 101
  8. Very specific:

    Before removing a run directory, copy these artifacts with Node.js filesystem APIs:

    line 105
  9. Distinctive:

    Use the mapping below:

    line 112
  10. Distinctive:

    Use journey-runner's pinned Playwright Chromium helper.

    line 122
  11. Very specific:

    Never run a pipeline over every row from azd env list.

    line 134
  12. Distinctive:

    No active resource remains with that run's environment tag

    line 139
  13. Distinctive:

    If cleanup is incomplete, preserve the workspace and list exact remaining resource IDs in the consolidated report.

    line 143
  14. Distinctive:

    Delete a per-journey working directory only when all of these are true:

    line 147
  15. Distinctive:

    No unresolved cleanup or debugging artifact depends on the directory.

    line 152
  16. Very specific:

    Use Node.js fs.rm(path, { recursive: true, force: true }) on the exact recorded run directory.

    line 154
  17. Very specific:

    Write test-report.md directly with file tools or Node.js.

    line 158
  18. Distinctive:

    Never install system packages or privileged emulation automatically.

    line 194
  19. Very specific:

    Never delete all azd environments.

    line 195
  20. Distinctive:

    Never broaden cleanup scope after a failed deletion.

    line 196
  21. Distinctive:

    Never expose credentials, cookies, authorization headers, connection strings, or generated secrets.

    line 197
  22. Distinctive:

    Never claim Mac, Windows, iOS, or browser verification that didn't actually run.

    line 198

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Journey Test Harness

Orchestrate journey-runner across the selected journey directories. The harness must work on Windows, Mac, and Linux and must never delete an Azure environment merely because it appears in azd env list.

Inputs

  1. Journeys, default all
  2. Stack, default Node.js/TypeScript for multi-stack journeys
  3. Deploy, default true
  4. Location, default westus
  5. Concurrency, default 1; increase only when quota, local ports, and API limits allow it

Each deployed journey uses cleanup: after-verification unless the user explicitly requests otherwise.

Step 1: Discover Journeys

Use repository file-search APIs or Node.js fs.readdir() to find journeys/*/README.md. Do not use ls | sed, shell globs, or platform-specific path parsing.

For each journey, record:

  • Folder name and absolute source path
  • Journey type
  • PLAN.md presence
  • Required and optional tools from the journey prerequisite section
  • Estimated cost and time
  • Screenshot requirement

Filter only against the discovered folder names. Fail early for an unknown requested journey.

Step 2: Suite Preflight

Load journey-runner and run its cross-platform preflight before creating any workspace or Azure resource.

The union of selected-journey requirements may include:

  • Node.js LTS or later
  • Azure CLI and valid authentication
  • azd 1.28.0 or later with auth.useAzCliAuth=true
  • GitHub Copilot CLI
  • Node.js LTS or later for hooks, tests, and verifiers
  • Azure Functions Core Tools v4, Azurite, and Go-based sqlcmd for SmartTodo
  • The pinned Playwright package and bundled Chromium for web screenshots
  • Xcode 16+ only when SmartTodo iOS execution is requested on Mac

Use .github/skills/journey-runner/scripts/check-prerequisites.mjs with the union of required tools. Missing required tools stop the whole suite before provider registration. Do not install system tools during the suite.

Step 3: Azure Preparation

Check Azure CLI and azd authentication separately. Confirm the intended subscription and location.

Register only providers required by selected journeys. Run provider commands as individual processes with argument arrays, not shell loops. Wait for required registrations before starting the first deployment.

Record the subscription ID and each provider's state in the suite report.

Step 4: Create Suite and Journey Workspaces

Create directories through Node.js filesystem APIs or the active agent's file tools:

<journey-runs-root>/test-suite-<UTC timestamp>/
├── test-report.md
├── screenshots/
└── runs/
    └── <journey>-<UTC timestamp>/

Use path.join() and absolute paths. Don't embed ~/, date, mkdir, or shell-specific separators in executable instructions.

Copy PLAN.md with fs.copyFile() when needed. Generated application code, infrastructure, logs, and secrets stay inside the isolated run directory, never the source repository.

Step 5: Run Each Journey

Invoke journey-runner with:

Journey: <journey-source-path>
Stack: <stack>
Location: <location>
Working directory: <absolute-run-directory>
Cleanup: after-verification

The runner owns per-journey preflight, prompts, local ports, deployment, verification, screenshots, and scoped cleanup.

Run serially by default. Parallel runs require:

  • Distinct local ports
  • Distinct azd environment names
  • Distinct resource groups
  • Sufficient regional quota
  • Independent log and screenshot paths

Never share an azd environment across journeys.

Step 6: Preserve Evidence

Before removing a run directory, copy these artifacts with Node.js filesystem APIs:

  • run-report.md
  • issues.md
  • screenshot-*.png
  • Sanitized deployment and verification logs

Use the mapping below:

JourneyWeb outputScreenshot
GrafanaGRAFANA_URLLogin page
n8nN8N_URLOwner-setup or login page
SupersetSUPERSET_URLAuthenticated welcome page when credentials are available
AIMarketWEB_URLStorefront with all images loaded
SmartTodoNoneNo screenshot on Windows/Linux; simulator screenshot only on a suitable Mac/Xcode host

Use journey-runner's pinned Playwright Chromium helper. Never use a branded Chrome channel.

Step 7: Guaranteed Scoped Cleanup

Cleanup runs in a finally path after each deployment attempt, including build, deployment, verification, or screenshot failures.

For each journey, delete only:

  • Its explicitly recorded azd environment
  • Its explicitly recorded resource groups and managed resource groups
  • Soft-deleted resources whose names were recorded as owned by that run

Never run a pipeline over every row from azd env list. Other environments may belong to unrelated work.

After azd down --force --purge --no-prompt, verify:

  • Recorded resource groups return not found
  • No active resource remains with that run's environment tag
  • Any owned soft-deleted resource selected for purge is absent
  • Unrelated environments and resource groups remain unchanged

If cleanup is incomplete, preserve the workspace and list exact remaining resource IDs in the consolidated report.

Step 8: Workspace Retention

Delete a per-journey working directory only when all of these are true:

  1. Evidence was copied successfully.
  2. Azure cleanup was live-verified.
  3. The user didn't request generated code retention.
  4. No unresolved cleanup or debugging artifact depends on the directory.

Use Node.js fs.rm(path, { recursive: true, force: true }) on the exact recorded run directory. Never construct a deletion path from untrusted output.

Step 9: Consolidated Report

Write test-report.md directly with file tools or Node.js. Don't build Markdown through a large shell one-liner.

Include:

  • UTC start/end and total duration
  • Host OS and architecture
  • Tool versions
  • Subscription and location
  • Selected journeys and stack
  • Build, deployment, verification, screenshot, and cleanup status per journey
  • Preserved artifact paths
  • Exact blockers and remaining resource IDs

Example result table:

JourneyBuildDeployVerifyScreenshotCleanupResult
GrafanaPASSPASSPASSPASSPASSPASS
n8nPASSPASSPASSPASSPASSPASS
SupersetPASSPASSPASSPASSPASSPASS
AIMarketPASSPASSPASSPASSPASSPASS
SmartTodoPASSPASSPASSN/A on Linux/WindowsPASSPASS

A journey can't receive PASS when cleanup was requested but not verified.

Failure Policy

  • Missing prerequisite: stop before Azure work.
  • Build failure: one evidence-based repair, then mark FAIL.
  • Deployment failure: collect diagnostics, then run scoped cleanup.
  • Verification failure: retry only documented transient cases, then mark FAIL.
  • Screenshot failure: preserve logs and continue to cleanup; mark PARTIAL only if all functional checks passed.
  • Cleanup failure: mark FAIL and preserve the run directory.

Safety Rules

  • Never install system packages or privileged emulation automatically.
  • Never delete all azd environments.
  • Never broaden cleanup scope after a failed deletion.
  • Never expose credentials, cookies, authorization headers, connection strings, or generated secrets.
  • Never claim Mac, Windows, iOS, or browser verification that didn't actually run.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.