Nested local path imports in remote workflows should resolve

[strawgate]

When a workflow is added via gh aw add owner/repo/path/to/workflow.md, the top-level remote import resolves correctly. However, if the imported file itself has relative imports (e.g., shared/tools.md), those are resolved against the local .github/workflows/ directory instead of the remote repo they came from.

Repro:

mkdir test && cd test && git init && mkdir -p .github/workflows
gh aw add elastic/ai-github-actions/gh-agent-workflows/mention-in-pr.md
gh aw compile

Error:

import file not found

Debug output (DEBUG=parser:remote_fetch):

Resolving include path: file_path=elastic/ai-github-actions/.../rwxp.md@..., base_dir=.../.github/workflows
Detected workflowspec format: ...
Using cached import: ... (SHA: ...)           ← top-level remote import succeeds
Resolving include path: file_path=shared/elastic-tools.md, base_dir=.../.github/workflows
Using local file resolution for: shared/elastic-tools.md
Local file not found: .../.github/workflows/shared/elastic-tools.md   ← nested import fails

Expected: Nested relative imports from a remote file should resolve relative to the remote repo (e.g., shared/elastic-tools.md inside elastic/ai-github-actions/.../rwxp.md should resolve to elastic/ai-github-actions/gh-agent-workflows/shared/elastic-tools.md@same-ref).

[strawgate]

When resolving locally, the imports appear to be relative to the importing workflow. When resolving remotely they are relative to .github/workflows and so to dogfood your own shared workflows in a repository a symlink allows you to achieve both behaviors at the same time.

[strawgate]

You can kind of see what im going for in this repo: https://github.com/elastic/ai-github-actions

I want a central repository where I can define workflows as a Shim/Trigger Workflow (defines engine + triggers) + Reusable Workflow (holds the prompt + toolsets + etc). The user calls gh aw path/to/shim to install/update the shim workflow with the majority of the interesting stuff being imported from the workflow.

This works -- the shim/trigger workflows can be at the root of the repo (which gives you a nice command for adding them) but the reusable workflows that hold the meat need to be under .github/workflows.

I also want to use these workflows in my central repository to dogfood them.

[pelikhan]

Very nice. Would be great to document this as a way to develop workflows AND share at the same time.