[docs-linker] workshop docs: add gh-aw doc links

workshop/side-quest-11-09-agent-session-phases.md

@@ -21,7 +21,7 @@ After you submit the scenario prompt, the session shows a live activity feed. Th
 | Phase | What you see | What to look for |
 |---|---|---|
 | **Reading** | The agent fetches the `create.md` reference and reads existing files in your repository | Confirm the agent fetched the reference guide and found your repository files |
-| **Planning** | The agent decides what frontmatter keys, permissions, and task brief to use | The planning output should reflect your intended scenario |
+| **Planning** | The agent decides what frontmatter keys, [permissions](https://github.github.com/gh-aw/reference/permissions/), and task brief to use | The planning output should reflect your intended scenario |
 | **Writing** | The agent creates the workflow `.md` file in `.github/workflows/` | The file should contain a [YAML frontmatter](https://github.github.com/gh-aw/reference/frontmatter/) block between `---` fences and a Markdown task brief |
 | **Compiling** | The agent runs `gh aw compile --validate` and fixes any errors it finds | A green success message indicates the `.lock.yml` was generated without errors |
 | **Opening PR** | The agent commits both files and opens a pull request | The pull request should list two changed files: the `.md` source and the `.lock.yml` |

workshop/side-quest-12-01-iterate-agent-output.md

@@ -2,7 +2,7 @@
 <!-- page-adventure: side-quest -->
 # Side Quest: Evaluating and Iterating on Agent Output
 
-> _Optional: use this side quest when you want a repeatable way to judge one workflow run, improve one sentence in the workflow brief, and compare the result — then return to [Refine, Test, and Improve Your Workflow](09-agentic-editing.md)._
+> _Optional: use this side quest when you want a repeatable way to judge one workflow run, improve one sentence in the [workflow brief](https://github.github.com/gh-aw/reference/markdown/), and compare the result — then return to [Refine, Test, and Improve Your Workflow](09-agentic-editing.md)._
 
 ## :dart: What You'll Do
 

workshop/side-quest-13-01-pr-labeler-pattern.md

@@ -15,7 +15,7 @@ Extend your PR reviewer workflow to automatically apply [GitHub labels](https://
 
 Labels help teams filter and prioritise pull requests at a glance. Applying them manually is easy to forget, especially on busy repositories. An agentic labeller reads the list of changed files and applies the right labels before a human reviewer opens the PR.
 
-The [LabelOps pattern](https://github.github.com/gh-aw/patterns/label-ops/) keeps the approach simple: map file path patterns to label names in your workflow brief, then instruct the agent to pick and apply the matching labels.
+The [LabelOps pattern](https://github.github.com/gh-aw/patterns/label-ops/) keeps the approach simple: map file path patterns to label names in your [workflow brief](https://github.github.com/gh-aw/reference/markdown/), then instruct the agent to pick and apply the matching labels.
 
 ## The Labeller Workflow
 

workshop/side-quest-13-01-schedule-expressions.md

@@ -8,11 +8,11 @@
 
 - You have completed [Refine, Test, and Improve Your Workflow](09-agentic-editing.md) or are working through it now.
 - You understand that [GitHub Actions](https://github.github.com/gh-aw/reference/triggers/) schedules use **cron expressions** (e.g., `0 9 * * 1` runs at 09:00 UTC every Monday).
-- You know how to run `gh aw compile` to regenerate a workflow's lock file.
+- You know how to run `gh aw compile` to regenerate a workflow's [lock file](https://github.github.com/gh-aw/reference/workflow-structure/#lock-file-header).
 
 ## :dart: What You'll Do
 
-You'll learn how `gh-aw`'s plain-English schedule syntax maps to GitHub Actions cron schedules. By the end, you'll know which [fuzzy expression](https://github.github.com/gh-aw/reference/schedule-syntax/#fuzzy-schedules) fits your workflow, how to verify the compiled cron value, and how agentic workflows differ from classic Actions YAML when it comes to scheduling.
+You'll learn how `gh-aw`'s plain-English schedule syntax maps to GitHub Actions cron schedules. By the end, you'll know which [fuzzy expression](https://github.github.com/gh-aw/reference/schedule-syntax/#fuzzy-schedules) fits your workflow, how to verify the compiled cron value, and how [agentic workflows](https://github.github.com/gh-aw/introduction/overview/) differ from classic Actions YAML when it comes to scheduling.
 
 ## Cron in one minute
 

workshop/side-quest-13-03-pr-checklist-pattern.md

@@ -86,7 +86,7 @@ Ideas:
 - **Screenshot**: If any UI file changed, a screenshot is linked in the PR description.
 - **Ticket link**: The PR title or description contains a reference to an issue number (`#NNN`).
 
-Update the checklist in the workflow brief, recompile, and open a fresh PR to verify the new criterion appears in the table.
+Update the checklist in the [workflow brief](https://github.github.com/gh-aw/reference/markdown/), recompile, and open a fresh PR to verify the new criterion appears in the table.
 
 ## :white_check_mark: Checkpoint
 

workshop/side-quest-13-04-token-optimization.md

@@ -47,7 +47,7 @@ Use your baseline to decide what to change first:
 
 | If you observe this | Check for this cause | First fix to try |
 |---|---|---|
-| AIC grows after you add more repository data | Too much raw context in the brief | Pre-filter the data in a deterministic step before passing it to the agent |
+| AIC grows after you add more repository data | Too much raw context in the brief | Pre-filter the data in a [deterministic](https://github.github.com/gh-aw/patterns/deterministic-ops/) step before passing it to the agent |
 | One run is much higher than the others | The agent explored too broadly or retried tool calls | Tighten the brief and remove tools the task does not need |
 | Every run costs about the same and feels high | The brief is longer than it needs to be | Shorten instructions, examples, and repeated boilerplate |
 | Costs spike after adding a new schedule | The workflow runs more often than the value it creates | Reduce the schedule frequency or add conditions so no-op runs skip the agent |

workshop/side-quest-15-01-expressions-and-contexts.md

@@ -164,7 +164,7 @@ if: steps.recent.outputs.commit_count != '0' && steps.day.outputs.day != 'Saturd
 ---
 ```
 
-This pattern — deterministic shell step produces a string output, `if:` expression reads that output — applies broadly wherever you need workflow control flow based on data that is not already in a GitHub Actions context object.
+This pattern — [deterministic](https://github.github.com/gh-aw/patterns/deterministic-ops/) shell step produces a string output, `if:` expression reads that output — applies broadly wherever you need workflow control flow based on data that is not already in a GitHub Actions context object.
 
 ## :white_check_mark: Checkpoint
 

workshop/side-quest-15-02-chaining-conditions.md

@@ -2,7 +2,7 @@
 <!-- page-adventure: side-quest -->
 # Side Quest: Chaining Conditions — Run an Agent Only When Security Findings Exist
 
-> _The cheapest agent invocation is the one you skip. Use a deterministic step to decide whether your repository state is worth an agent's attention._
+> _The cheapest agent invocation is the one you skip. Use a [deterministic](https://github.github.com/gh-aw/patterns/deterministic-ops/) step to decide whether your repository state is worth an agent's attention._
 
 ## :dart: What You'll Do
 
@@ -17,7 +17,7 @@ Add a security scanning step to your workflow that counts open Dependabot vulner
 
 ### Understand why this pattern matters
 
-Running an agent every time a schedule fires is expensive, even when there is nothing to report. This side quest solves that by front-loading a fast, [deterministic](https://github.github.com/gh-aw/patterns/deterministic-ops/) check: a shell step calls the GitHub API to count open Dependabot alerts, then the `if:` expression evaluates the count before the agent job starts. If no alerts are open, the job is skipped entirely — zero AI credits spent.
+Running an agent every time a schedule fires is expensive, even when there is nothing to report. This side quest solves that by front-loading a fast, [deterministic](https://github.github.com/gh-aw/patterns/deterministic-ops/) check: a shell step calls the GitHub API to count open Dependabot alerts, then the `if:` expression evaluates the count before the agent job starts. If no alerts are open, the job is skipped entirely — zero [AI credits](https://github.github.com/gh-aw/reference/cost-management/#ai-credits-aic) spent.
 
 The same skeleton applies to any tool that can write a count or boolean to `$GITHUB_OUTPUT`: code scanning alerts, secret scan findings, lint error totals, or failing test counts.