@slamb2k/mad-skills 2.0.24 → 2.0.26

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "mad-skills",
   "description": "AI-assisted planning, development and governance tools",
-  "version": "2.0.24",
+  "version": "2.0.26",
   "author": {
     "name": "slamb2k",
     "url": "https://github.com/slamb2k"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@slamb2k/mad-skills",
-  "version": "2.0.24",
+  "version": "2.0.26",
   "description": "Claude Code skills collection — full lifecycle development tools",
   "type": "module",
   "repository": {

package/skills/build/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: build
 description: Context-isolated feature development pipeline. Takes a detailed design/plan as argument and executes the full feature-dev lifecycle (explore, question, architect, implement, review, ship) inside subagents so the primary conversation stays compact. Use when you have a well-defined plan and want autonomous execution with minimal context window consumption.
-argument-hint: <detailed design/plan to implement> [--skip-questions] [--skip-review] [--no-ship] [--parallel-impl]
-allowed-tools: Bash, Read, Write, Edit, Glob, Grep, Agent, AskUserQuestion
+argument-hint: <plan text or spec file path> [--skip-questions] [--skip-review] [--no-ship] [--parallel-impl]
+allowed-tools: Bash, Read, Write, Edit, Glob, Grep, Agent, AskUserQuestion, TaskCreate, TaskUpdate, TaskGet, TaskList
 ---
 
 # Build - Context-Isolated Feature Development
@@ -103,16 +103,14 @@ For each row, in order:
 
 1. Capture **PLAN** (the user's argument) and **FLAGS**
 2. **Load project context** — invoke `/prime` to load domain-specific context
-   (CLAUDE.md, goals, specs, memory). If /prime is unavailable, fall back to
-   manually scanning CLAUDE.md and goals/ directory.
+   (CLAUDE.md, specs, memory). If /prime is unavailable, fall back to
+   manually scanning CLAUDE.md and specs/ directory.
 3. Detect project type using `references/project-detection.md` to populate
    **PROJECT_CONFIG** (language, test_runner, test_setup)
-3. Check for outstanding questions from previous work:
+3. Check for outstanding items from previous work:
+   - Query persistent tasks via `TaskList` for incomplete items
    - Search CLAUDE.md for a "Known Issues" or "Open Questions" section
-   - Search `goals/` for files containing "open_question" or "unresolved"
-   - Search memory (if available) for recent items of type "task" or
-     "open_question" that are unresolved
-   - Check for `DEBRIEF_ITEMS` in any recent build logs
+   - Search memory (if available) for recent unresolved items
 4. If outstanding items found, present via AskUserQuestion:
    ```
    "Found {count} outstanding items from previous work:"
@@ -125,7 +123,23 @@ For each row, in order:
      Items marked "incorporate" get appended to the PLAN as additional
      requirements for Stage 1 to explore.
    - **"No, proceed with the build"** → continue normally
-5. Create a task list tracking all stages
+---
+
+## Plan Resolution
+
+Before Stage 1, resolve the PLAN argument into content:
+
+1. **File detection** — If the argument contains `/` or ends with
+   `.md`, `.yaml`, `.json`, or `.txt`, treat it as a file path:
+   - Try reading the path as-is
+   - If not found, try `specs/{arg}`
+   - If found, use file content as PLAN
+   - If not found at any location, treat the original argument as free-form text
+2. **Free-form text** — If not a file path (or file not found), use the argument
+   verbatim as PLAN
+3. **Display** — In the Input box, show the resolved source:
+   - File: `Plan: {file path} ({line count} lines)`
+   - Text: `Plan: inline ({word count} words)`
 
 ---
 
@@ -303,8 +317,9 @@ Invoke the `/ship` skill:
    Options:
    - **"Fix now"** → create a task list of resolution activities for
      each item; present for user confirmation, then work through them
-   - **"Create tasks for future sessions"** → create persistent tasks via
-     `TaskCreate` for each item, or append to CLAUDE.md as Known Issues
+   - **"Create tasks for future sessions"** → use `TaskCreate` for each
+     item as a persistent task, with category as prefix and suggested
+     action as description
    - **"Note and continue"** → acknowledge items without formal tracking;
      log to memory (if exists) or as source file comments. No further action.
    - **"Let me choose per item"** → present each individually with full
@@ -337,7 +352,7 @@ Invoke the `/ship` skill:
 │     Findings addressed: {count fixed} / {count found}
 │
 │  📊 Debrief: {count resolved} / {count surfaced}
-│     {list of created goals/tasks}
+│     {list of created tasks}
 │
 │  🔗 Links
 │     PR:  {pr_url}

package/skills/build/references/stage-prompts.md

@@ -385,9 +385,10 @@ Options:
      for user confirmation, then work through them.
 
 - "Create tasks for future sessions"
-  → For each item, create a persistent task via TaskCreate with the
-     suggested_action as the task description, or append to CLAUDE.md
-     as a "Known Issues" section. Group by category, not one per item.
+  → For each item, use TaskCreate to create a persistent task with:
+     title: "[{category}] {summary}"
+     description: "{description}\n\nEvidence: {evidence}\nSuggested action: {suggested_action}"
+     Format: one task per item for granular tracking.
 
 - "Note and continue"
   → Acknowledge items without formal tracking. Log to memory (if memory
@@ -398,8 +399,9 @@ Options:
   → Present each item individually via AskUserQuestion. Show the full
      `description`, `evidence`, and `impact` fields so the user has
      enough context to decide. Options per item:
-     "Fix now" / "Add to goals" / "Explain more" / "Note and continue"
+     "Fix now" / "Create task" / "Explain more" / "Note and continue"
      - "Fix now": launch a general-purpose subagent to resolve
+     - "Create task": use TaskCreate to persist for future sessions
      - "Explain more": read the relevant source files/reports cited in
        `evidence`, summarise the context, then re-present the same item
        with the expanded explanation

package/skills/build/tests/evals.json

@@ -17,6 +17,14 @@
       { "type": "semantic", "value": "Describes a multi-stage development lifecycle that includes exploration, architecture design, implementation, code review, and shipping, with stages running in isolated subagents" }
     ]
   },
+  {
+    "name": "file-path-detection",
+    "prompt": "Build specs/user-auth.md",
+    "assertions": [
+      { "type": "contains", "value": "██" },
+      { "type": "semantic", "value": "Detects that the argument is a file path (contains / or ends with .md) and attempts to read it as a spec file rather than treating it as literal plan text. Shows the resolved file path in the Input display." }
+    ]
+  },
   {
     "name": "flag-handling",
     "prompt": "Build --skip-questions --no-ship: Refactor the auth module to use middleware pattern",

package/skills/manifest.json

@@ -1,5 +1,5 @@
 {
-  "generated": "2026-03-11T04:28:37.105Z",
+  "generated": "2026-03-12T03:25:58.495Z",
   "count": 10,
   "skills": [
     {
@@ -16,7 +16,7 @@
       "name": "build",
       "directory": "build",
       "description": "Context-isolated feature development pipeline. Takes a detailed design/plan as argument and executes the full feature-dev lifecycle (explore, question, architect, implement, review, ship) inside subagents so the primary conversation stays compact. Use when you have a well-defined plan and want autonomous execution with minimal context window consumption.",
-      "lines": 363,
+      "lines": 378,
       "hasScripts": false,
       "hasReferences": true,
       "hasAssets": false,
@@ -55,7 +55,7 @@
     {
       "name": "prime",
       "directory": "prime",
-      "description": "\"Load project context before implementing features or making architectural decisions. Invoke proactively at the start of significant work on any project. Scans CLAUDE.md, README, goals/, specs/, docs/, and source structure to build a context summary. Supports optional domain hints to focus on specific areas of the codebase. Use when you need project conventions, architecture understanding, or domain context before coding.\"",
+      "description": "\"Load project context before implementing features or making architectural decisions. Invoke proactively at the start of significant work on any project. Scans CLAUDE.md, README, specs/, docs/, and source structure to build a context summary. Supports optional domain hints to focus on specific areas of the codebase. Use when you need project conventions, architecture understanding, or domain context before coding.\"",
       "lines": 148,
       "hasScripts": false,
       "hasReferences": true,
@@ -76,7 +76,7 @@
       "name": "ship",
       "directory": "ship",
       "description": "\"Ship changes through the full PR lifecycle. Use after completing feature work to commit, push, create PR, wait for checks, and merge. Handles the entire workflow: syncs with main, creates feature branch if needed, groups commits logically with semantic messages, creates detailed PR, monitors CI, fixes issues, squash merges, and cleans up. Invoke when work is ready to ship.\"",
-      "lines": 262,
+      "lines": 356,
       "hasScripts": false,
       "hasReferences": true,
       "hasAssets": false,
@@ -85,8 +85,8 @@
     {
       "name": "speccy",
       "directory": "speccy",
-      "description": "Deep-dive interview skill for creating comprehensive specifications. Reviews existing code and docs, then interviews the user through multiple rounds of targeted questions covering technical implementation, UI/UX, concerns, and tradeoffs. Produces a structured spec via create-specification. Use when starting a new feature, system, or major change that needs a spec.",
-      "lines": 232,
+      "description": "Deep-dive interview skill for creating comprehensive specifications. Reviews existing code and docs, then interviews the user through multiple rounds of targeted questions covering technical implementation, UI/UX, concerns, and tradeoffs. Produces a structured spec in specs/. Use when starting a new feature, system, or major change that needs a spec.",
+      "lines": 241,
       "hasScripts": false,
       "hasReferences": true,
       "hasAssets": false,

package/skills/prime/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: prime
-description: "Load project context before implementing features or making architectural decisions. Invoke proactively at the start of significant work on any project. Scans CLAUDE.md, README, goals/, specs/, docs/, and source structure to build a context summary. Supports optional domain hints to focus on specific areas of the codebase. Use when you need project conventions, architecture understanding, or domain context before coding."
+description: "Load project context before implementing features or making architectural decisions. Invoke proactively at the start of significant work on any project. Scans CLAUDE.md, README, specs/, docs/, and source structure to build a context summary. Supports optional domain hints to focus on specific areas of the codebase. Use when you need project conventions, architecture understanding, or domain context before coding."
 argument-hint: "[domain hints: comma-separated directory or topic names to focus on]"
 allowed-tools: Read, Glob, Grep, LS, Agent
 ---
@@ -66,7 +66,7 @@ subagent — the primary thread only sees a structured PRIME_REPORT.
 
 Extract domain hints from the request (comma-separated). These are directory
 names or topic keywords to focus the context scan on. If no domain specified,
-load core context only (CLAUDE.md, README, goals/, specs/).
+load core context only (CLAUDE.md, README, specs/).
 
 ## Step 2: Load Context via Subagent
 
@@ -92,7 +92,7 @@ Limit PRIME_REPORT to 30 lines maximum.
 
 1. CLAUDE.md — Project conventions, architecture, instructions
 2. README.md — Project overview, setup, usage
-3. goals/ or specs/ — Project goals, specs, roadmap (scan directory if present)
+3. specs/ — Project specifications and roadmap (scan directory if present)
 4. docs/ — Documentation directory (scan if present)
 
 If a file is missing, record as NOT FOUND and continue.

package/skills/ship/SKILL.md

@@ -72,51 +72,140 @@ Parse optional flags from the request:
 
 ---
 
+## Platform Detection
+
+Detect the hosting platform **before** pre-flight so dependency checks are
+platform-specific:
+
+```bash
+REMOTE_URL=$(git remote get-url origin 2>/dev/null)
+if echo "$REMOTE_URL" | grep -qiE 'dev\.azure\.com|visualstudio\.com'; then
+  PLATFORM="azdo"
+elif echo "$REMOTE_URL" | grep -qi 'github\.com'; then
+  PLATFORM="github"
+else
+  PLATFORM="github"   # default fallback
+fi
+```
+
+Pass `{PLATFORM}` into all stage prompts. Each stage uses the appropriate
+CLI tool: `gh` for GitHub, `az repos`/`az pipelines` for Azure DevOps.
+
+---
+
 ## Pre-flight
 
-Before starting, check all dependencies in this table:
+Before starting, check all dependencies in this table. The table contains
+**all** dependencies — some are platform-conditional (see notes after table).
 
 | Dependency | Type | Check | Required | Resolution | Detail |
 |-----------|------|-------|----------|------------|--------|
 | git | cli | `git --version` | yes | stop | Install from https://git-scm.com |
 | gh | cli | `gh --version` | yes | url | https://cli.github.com |
-| ship-analyzer | agent | `~/.claude/agents/ship-analyzer.md` | no | fallback | Uses general-purpose agent |
-
-For each row, in order:
-1. Run the Check command (for cli/npm) or test file existence (for agent/skill)
-2. If found: continue silently
-3. If missing: apply Resolution strategy
+| az devops | cli | `az devops -h 2>/dev/null` | no | fallback | Falls back to REST API with PAT; see AzDO tooling below |
+| ship-analyzer | agent | `~/.claude/agents/ship-analyzer.md` or `~/.claude/plugins/marketplaces/slamb2k/agents/ship-analyzer.md` | no | fallback | Uses general-purpose agent |
+
+**Platform-conditional rules:**
+- **`gh`**: Only required when `PLATFORM == github`. Skip for AzDO repos.
+- **`az devops`**: Only checked when `PLATFORM == azdo`. Skip for GitHub repos.
+
+For each applicable row, in order:
+1. Skip rows that don't apply to the detected `{PLATFORM}`
+2. Run the Check command (for cli/npm) or test file existence (for agent/skill)
+3. If found: continue silently
+4. If missing: apply Resolution strategy
    - **stop**: notify user with Detail, halt execution
    - **url**: notify user with Detail (install link), halt execution
    - **install**: notify user, run the command in Detail, continue if successful
    - **ask**: notify user, offer to run command in Detail, continue either way (or halt if required)
    - **fallback**: notify user with Detail, continue with degraded behavior
-4. After all checks: summarize what's available and what's degraded
+5. After all checks: summarize what's available and what's degraded
 
-Read `default_branch` and `remote` from Stage 1's SYNC_REPORT. These are
-substituted into all stage prompts as `{REMOTE}` and `{DEFAULT_BRANCH}`.
-
-### Platform Detection
+### AzDO Tooling Detection
 
-After sync, detect the hosting platform from the remote URL:
+When `PLATFORM == azdo`, determine which tooling is available. Set `AZDO_MODE`
+for use in all subsequent stages:
 
 ```bash
-REMOTE_URL=$(git remote get-url {REMOTE} 2>/dev/null)
-if echo "$REMOTE_URL" | grep -qiE 'dev\.azure\.com|visualstudio\.com'; then
-  PLATFORM="azdo"
-elif echo "$REMOTE_URL" | grep -qi 'github\.com'; then
-  PLATFORM="github"
+if az devops -h &>/dev/null; then
+  AZDO_MODE="cli"
 else
-  PLATFORM="github"   # default fallback
+  AZDO_MODE="rest"
 fi
 ```
 
-Pass `{PLATFORM}` into all stage prompts. Each stage uses the appropriate
-CLI tool: `gh` for GitHub, `az repos`/`az pipelines` for Azure DevOps.
+- **`cli`**: Use `az repos` / `az pipelines` commands (preferred)
+- **`rest`**: Use Azure DevOps REST API via `curl`. Requires a PAT (personal
+  access token) in `AZURE_DEVOPS_EXT_PAT` or `AZDO_PAT` env var. If no PAT
+  is found, prompt the user to either install the CLI or set the env var.
+
+Report in pre-flight:
+- ✅ `az devops cli` — version found
+- ⚠️ `az devops cli` — not found → using REST API fallback
+- ❌ `az devops cli` — not found, no PAT configured → halt with setup instructions
+
+### AzDO Configuration Validation
+
+When `PLATFORM == azdo`, extract organization and project from the remote URL
+and validate they are usable. These values are needed by every `az repos` /
+`az pipelines` command and every REST API call.
+
+```bash
+# Extract org and project from remote URL patterns:
+#   https://dev.azure.com/{ORG}/{PROJECT}/_git/{REPO}
+#   https://{ORG}@dev.azure.com/{ORG}/{PROJECT}/_git/{REPO}
+#   {ORG}@vs-ssh.visualstudio.com:v3/{ORG}/{PROJECT}/{REPO}
+
+REMOTE_URL=$(git remote get-url origin 2>/dev/null)
+
+if echo "$REMOTE_URL" | grep -q 'dev\.azure\.com'; then
+  # HTTPS format: https://dev.azure.com/{ORG}/{PROJECT}/_git/{REPO}
+  # Also handles: https://{ORG}@dev.azure.com/{ORG}/{PROJECT}/_git/{REPO}
+  AZDO_ORG=$(echo "$REMOTE_URL" | sed -n 's|.*dev\.azure\.com/\([^/]*\)/.*|\1|p')
+  AZDO_PROJECT=$(echo "$REMOTE_URL" | sed -n 's|.*dev\.azure\.com/[^/]*/\([^/]*\)/.*|\1|p')
+  AZDO_ORG_URL="https://dev.azure.com/$AZDO_ORG"
+elif echo "$REMOTE_URL" | grep -q 'vs-ssh\.visualstudio\.com'; then
+  # SSH format: {ORG}@vs-ssh.visualstudio.com:v3/{ORG}/{PROJECT}/{REPO}
+  AZDO_ORG=$(echo "$REMOTE_URL" | sed -n 's|.*vs-ssh\.visualstudio\.com:v3/\([^/]*\)/.*|\1|p')
+  AZDO_PROJECT=$(echo "$REMOTE_URL" | sed -n 's|.*vs-ssh\.visualstudio\.com:v3/[^/]*/\([^/]*\)/.*|\1|p')
+  AZDO_ORG_URL="https://dev.azure.com/$AZDO_ORG"
+elif echo "$REMOTE_URL" | grep -q 'visualstudio\.com'; then
+  # Legacy HTTPS format: https://{ORG}.visualstudio.com/{PROJECT}/_git/{REPO}
+  AZDO_ORG=$(echo "$REMOTE_URL" | sed -n 's|.*//\([^.]*\)\.visualstudio\.com.*|\1|p')
+  AZDO_PROJECT=$(echo "$REMOTE_URL" | sed -n 's|.*/\([^/]*\)/_git/.*|\1|p')
+  AZDO_ORG_URL="https://dev.azure.com/$AZDO_ORG"
+fi
 
-> **Azure DevOps prerequisite:** The `az devops` extension must be installed
-> and configured (`az devops configure --defaults organization=... project=...`).
-> If `az repos` commands fail, report the setup requirement to the user.
+if [ -z "$AZDO_ORG" ] || [ -z "$AZDO_PROJECT" ]; then
+  echo "❌ Could not extract organization/project from remote URL"
+  echo "   Remote: $REMOTE_URL"
+  echo ""
+  echo "Ensure the remote URL follows one of these formats:"
+  echo "  https://dev.azure.com/{ORG}/{PROJECT}/_git/{REPO}"
+  echo "  https://{ORG}.visualstudio.com/{PROJECT}/_git/{REPO}"
+  echo "  {ORG}@vs-ssh.visualstudio.com:v3/{ORG}/{PROJECT}/{REPO}"
+  # HALT — cannot proceed without org/project context
+fi
+```
+
+When `AZDO_MODE == cli`, also configure the defaults so commands work correctly:
+```bash
+az devops configure --defaults organization="$AZDO_ORG_URL" project="$AZDO_PROJECT"
+```
+
+When `AZDO_MODE == rest`, store these for API calls:
+- Base URL: `$AZDO_ORG_URL/$AZDO_PROJECT/_apis`
+- Auth header: `Authorization: Basic $(echo -n ":$PAT" | base64)`
+
+Report in pre-flight:
+- ✅ `azdo context` — org: `{AZDO_ORG}`, project: `{AZDO_PROJECT}`
+- ❌ `azdo context` — could not parse from remote URL → halt with instructions
+
+Pass `{AZDO_MODE}`, `{AZDO_ORG}`, `{AZDO_PROJECT}`, `{AZDO_ORG_URL}` into
+all stage prompts alongside `{PLATFORM}`.
+
+Read `default_branch` and `remote` from Stage 1's SYNC_REPORT. These are
+substituted into all stage prompts as `{REMOTE}` and `{DEFAULT_BRANCH}`.
 
 ---
 
@@ -155,14 +244,16 @@ Task(
 > **Fallback:** If `ship-analyzer` is not available, use `subagent_type: "general-purpose"`.
 
 Substitute `{USER_INTENT}`, `{FILES_TO_INCLUDE}`, `{FILES_TO_EXCLUDE}`,
-`{REMOTE}`, `{DEFAULT_BRANCH}`, `{PLATFORM}` into the prompt.
+`{REMOTE}`, `{DEFAULT_BRANCH}`, `{PLATFORM}`, `{AZDO_MODE}`, `{AZDO_ORG}`,
+`{AZDO_PROJECT}`, `{AZDO_ORG_URL}`, `{PAT}` into the prompt.
 
 Parse SHIP_REPORT. Abort if failed.
 
 **Rollback:** If push succeeds but PR creation fails, report the error and
 suggest the manual PR creation command. Do NOT revert the push.
 - GitHub: `gh pr create --head {branch}`
-- Azure DevOps: `az repos pr create --source-branch {branch} --target-branch {DEFAULT_BRANCH}`
+- Azure DevOps (cli): `az repos pr create --source-branch {branch} --target-branch {DEFAULT_BRANCH} --org {AZDO_ORG_URL} --project {AZDO_PROJECT}`
+- Azure DevOps (rest): Create PR via `{AZDO_ORG_URL}/{AZDO_PROJECT}/_apis/git/repositories/{repo}/pullrequests?api-version=7.0`
 
 **If `--pr-only` flag: Stop here and report PR URL to user.**
 
@@ -182,7 +273,8 @@ Task(
 )
 ```
 
-Substitute `{PR_NUMBER}` into the prompt.
+Substitute `{PR_NUMBER}`, `{BRANCH}`, `{PLATFORM}`, `{AZDO_MODE}`,
+`{AZDO_ORG}`, `{AZDO_ORG_URL}`, `{AZDO_PROJECT}`, `{PAT}` into the prompt.
 
 While CI runs in the background, briefly inform the user:
 ```
@@ -205,7 +297,8 @@ Task(
 )
 ```
 
-Substitute `{PR_NUMBER}`, `{BRANCH}`, `{FAILING_CHECKS}` into the prompt.
+Substitute `{PR_NUMBER}`, `{BRANCH}`, `{FAILING_CHECKS}`, `{PLATFORM}`,
+`{AZDO_MODE}`, `{AZDO_ORG}`, `{AZDO_ORG_URL}`, `{AZDO_PROJECT}`, `{PAT}` into the prompt.
 
 If fixed, return to Stage 3 (run CI watch again).
 If unable to fix after 2 attempts, report to user and stop.
@@ -225,7 +318,8 @@ Task(
 )
 ```
 
-Substitute `{PR_NUMBER}`, `{REMOTE}`, `{DEFAULT_BRANCH}`, merge/branch flags.
+Substitute `{PR_NUMBER}`, `{REMOTE}`, `{DEFAULT_BRANCH}`, `{PLATFORM}`,
+`{AZDO_MODE}`, `{AZDO_ORG_URL}`, `{AZDO_PROJECT}`, `{PAT}`, merge/branch flags.
 
 Parse LAND_REPORT.
 

package/skills/ship/references/stage-prompts.md

@@ -4,6 +4,8 @@ Subagent prompts for each ship stage. The orchestrator reads these and
 substitutes template variables before launching each subagent.
 
 `{PLATFORM}` is either `github` or `azdo` (detected from remote URL).
+`{AZDO_MODE}` is `cli` or `rest` (only relevant when PLATFORM == azdo).
+`{AZDO_ORG}`, `{AZDO_PROJECT}`, `{AZDO_ORG_URL}` provide AzDO context.
 
 ---
 
@@ -69,7 +71,7 @@ FILES TO EXCLUDE: {FILES_TO_EXCLUDE}
      EOF
      )"
 
-   **If PLATFORM == azdo:**
+   **If PLATFORM == azdo AND AZDO_MODE == cli:**
      az repos pr create \
        --title "<type>: <concise title>" \
        --description "$(cat <<'EOF'
@@ -85,20 +87,38 @@ FILES TO EXCLUDE: {FILES_TO_EXCLUDE}
      )" \
        --source-branch "$BRANCH" \
        --target-branch "{DEFAULT_BRANCH}" \
+       --org "{AZDO_ORG_URL}" --project "{AZDO_PROJECT}" \
        --output json
 
+   **If PLATFORM == azdo AND AZDO_MODE == rest:**
+     REPO_NAME=$(basename -s .git "$(git remote get-url origin)")
+     AUTH="Authorization: Basic $(echo -n ":{PAT}" | base64)"
+     PR_JSON=$(curl -s -X POST \
+       -H "$AUTH" \
+       -H "Content-Type: application/json" \
+       "{AZDO_ORG_URL}/{AZDO_PROJECT}/_apis/git/repositories/$REPO_NAME/pullrequests?api-version=7.0" \
+       -d "{\"sourceRefName\": \"refs/heads/$BRANCH\", \"targetRefName\": \"refs/heads/{DEFAULT_BRANCH}\", \"title\": \"<type>: <concise title>\", \"description\": \"## Summary\\n<1-3 sentences>\\n\\n## Changes\\n<bullets>\\n\\n## Testing\\n- [ ] <steps>\"}")
+
 6. **Gather info**
 
    **If PLATFORM == github:**
      PR_URL=$(gh pr view --json url -q .url)
      PR_NUMBER=$(gh pr view --json number -q .number)
 
-   **If PLATFORM == azdo:**
+   **If PLATFORM == azdo AND AZDO_MODE == cli:**
      # If az repos pr create returned JSON, parse it directly:
      PR_NUMBER=$(echo "$PR_JSON" | jq -r '.pullRequestId')
      # Otherwise list to find it:
-     PR_NUMBER=$(az repos pr list --source-branch "$BRANCH" --status active --query '[0].pullRequestId' -o tsv)
-     PR_URL=$(az repos pr show --id $PR_NUMBER --query 'repository.webUrl' -o tsv)/pullrequest/$PR_NUMBER
+     PR_NUMBER=$(az repos pr list --source-branch "$BRANCH" --status active \
+       --org "{AZDO_ORG_URL}" --project "{AZDO_PROJECT}" \
+       --query '[0].pullRequestId' -o tsv)
+     PR_URL="{AZDO_ORG_URL}/{AZDO_PROJECT}/_git/$(basename -s .git "$(git remote get-url origin)")/pullrequest/$PR_NUMBER"
+
+   **If PLATFORM == azdo AND AZDO_MODE == rest:**
+     # Parse from the create response JSON:
+     PR_NUMBER=$(echo "$PR_JSON" | jq -r '.pullRequestId')
+     REPO_NAME=$(basename -s .git "$(git remote get-url origin)")
+     PR_URL="{AZDO_ORG_URL}/{AZDO_PROJECT}/_git/$REPO_NAME/pullrequest/$PR_NUMBER"
 
    COMMITS=$(git log {REMOTE}/{DEFAULT_BRANCH}..HEAD --oneline)
    DIFF_STAT=$(git diff {REMOTE}/{DEFAULT_BRANCH} --shortstat)
@@ -145,14 +165,16 @@ BRANCH: {BRANCH}
 2. **Report final status**
    gh pr checks {PR_NUMBER}
 
-**If PLATFORM == azdo:**
+**If PLATFORM == azdo AND AZDO_MODE == cli:**
 
 1. **Wait for CI to start** (pipelines may take time to trigger after PR creation)
    Poll until at least one run appears (max 2 minutes, check every 15s):
    ```
    RUNS_FOUND=false
    for i in $(seq 1 8); do
-     RUN_COUNT=$(az pipelines runs list --branch "$BRANCH" --top 5 --query "length(@)" -o tsv 2>/dev/null)
+     RUN_COUNT=$(az pipelines runs list --branch "$BRANCH" --top 5 \
+       --org "{AZDO_ORG_URL}" --project "{AZDO_PROJECT}" \
+       --query "length(@)" -o tsv 2>/dev/null)
      if [ -n "$RUN_COUNT" ] && [ "$RUN_COUNT" != "0" ]; then
        RUNS_FOUND=true
        break
@@ -162,27 +184,101 @@ BRANCH: {BRANCH}
    ```
    If no runs appear after 2 minutes, also check PR policy evaluations:
    ```
-   az repos pr policy list --id {PR_NUMBER} --query "[].{name:configuration.type.displayName, status:status}" -o table
+   az repos pr policy list --id {PR_NUMBER} \
+     --org "{AZDO_ORG_URL}" --project "{AZDO_PROJECT}" \
+     --query "[].{name:configuration.type.displayName, status:status}" -o table
    ```
    If no policies exist either, report `no_checks`.
 
-2. **Wait for runs to complete** (max 30 minutes, check every 30s)
+2. **Wait for runs to complete — with fail-fast** (max 30 minutes, check every 30s)
    ```
    for i in $(seq 1 60); do
-     IN_PROGRESS=$(az pipelines runs list --branch "$BRANCH" --top 5 --query "[?status=='inProgress'] | length(@)" -o tsv)
+     # Check for failures FIRST — stop immediately if any run has failed
+     FAILED=$(az pipelines runs list --branch "$BRANCH" --top 5 \
+       --org "{AZDO_ORG_URL}" --project "{AZDO_PROJECT}" \
+       --query "[?result=='failed'] | length(@)" -o tsv 2>/dev/null)
+     if [ -n "$FAILED" ] && [ "$FAILED" != "0" ]; then
+       echo "CI failure detected — stopping wait"
+       break
+     fi
+
+     # Then check if anything is still running
+     IN_PROGRESS=$(az pipelines runs list --branch "$BRANCH" --top 5 \
+       --org "{AZDO_ORG_URL}" --project "{AZDO_PROJECT}" \
+       --query "[?status=='inProgress'] | length(@)" -o tsv 2>/dev/null)
      if [ "$IN_PROGRESS" = "0" ] || [ -z "$IN_PROGRESS" ]; then break; fi
      sleep 30
    done
    ```
 
-3. **Report final status**
-   Check both pipeline runs and PR policy evaluations:
+3. **Determine final status**
+   Query both pipeline runs and PR policy evaluations:
+   ```
+   az pipelines runs list --branch "$BRANCH" --top 5 \
+     --org "{AZDO_ORG_URL}" --project "{AZDO_PROJECT}" \
+     --query "[].{name:definition.name, status:status, result:result}" -o table
+   az repos pr policy list --id {PR_NUMBER} \
+     --org "{AZDO_ORG_URL}" --project "{AZDO_PROJECT}" \
+     --query "[].{name:configuration.type.displayName, status:status}" -o table
+   ```
+
+   **Map results to CHECKS_REPORT status:**
+   - Any pipeline with `result == "failed"` → `some_failed`
+   - Any policy with `status == "rejected"` → `some_failed`
+   - All pipelines `result == "succeeded"` AND no rejected policies → `all_passed`
+   - Pipelines still `inProgress` after timeout → `pending`
+   - No pipelines and no policies found → `no_checks`
+
+   **IMPORTANT:** Do NOT report `all_passed` if any run has `result == "failed"`.
+   Do NOT continue waiting once a failure is detected — report `some_failed`
+   immediately with the failing check names.
+
+**If PLATFORM == azdo AND AZDO_MODE == rest:**
+
+1. **Wait for CI to start** (max 2 minutes, check every 15s)
+   ```
+   REPO_NAME=$(basename -s .git "$(git remote get-url origin)")
+   AUTH="Authorization: Basic $(echo -n ":{PAT}" | base64)"
+   BUILDS_URL="{AZDO_ORG_URL}/{AZDO_PROJECT}/_apis/build/builds?branchName=refs/heads/$BRANCH&\$top=5&api-version=7.0"
+
+   RUNS_FOUND=false
+   for i in $(seq 1 8); do
+     RUN_COUNT=$(curl -s -H "$AUTH" "$BUILDS_URL" | jq '.value | length')
+     if [ -n "$RUN_COUNT" ] && [ "$RUN_COUNT" != "0" ]; then
+       RUNS_FOUND=true
+       break
+     fi
+     sleep 15
+   done
+   ```
+   If no runs appear, check PR policy evaluations via REST:
+   ```
+   EVALS=$(curl -s -H "$AUTH" \
+     "{AZDO_ORG_URL}/{AZDO_PROJECT}/_apis/policy/evaluations?artifactId=vstfs:///CodeReview/CodeReviewId/{AZDO_PROJECT}/{PR_NUMBER}&api-version=7.0")
+   EVAL_COUNT=$(echo "$EVALS" | jq '.value | length')
+   ```
+   If no evaluations exist either, report `no_checks`.
+
+2. **Wait for runs to complete — with fail-fast** (max 30 minutes, check every 30s)
    ```
-   az pipelines runs list --branch "$BRANCH" --top 5 --query "[].{name:definition.name, status:status, result:result}" -o table
-   az repos pr policy list --id {PR_NUMBER} --query "[].{name:configuration.type.displayName, status:status}" -o table
+   for i in $(seq 1 60); do
+     BUILDS_JSON=$(curl -s -H "$AUTH" "$BUILDS_URL")
+
+     # Check for failures FIRST
+     FAILED=$(echo "$BUILDS_JSON" | jq '[.value[] | select(.result=="failed")] | length')
+     if [ "$FAILED" != "0" ]; then
+       echo "CI failure detected — stopping wait"
+       break
+     fi
+
+     # Check if anything still running
+     IN_PROGRESS=$(echo "$BUILDS_JSON" | jq '[.value[] | select(.status=="inProgress")] | length')
+     if [ "$IN_PROGRESS" = "0" ]; then break; fi
+     sleep 30
+   done
    ```
-   A policy status of `approved` or `queued` with no `rejected` means passed.
-   A pipeline result of `succeeded` means passed; `failed` means failed.
+
+3. **Determine final status** — same mapping rules as CLI mode above.
 
 ## Output Format
 
@@ -216,14 +312,29 @@ FAILING CHECKS: {FAILING_CHECKS}
      gh run list --branch {BRANCH} --status failure --json databaseId --jq '.[0].databaseId'
      gh run view <run-id> --log-failed
 
-   **If PLATFORM == azdo:**
-     RUN_ID=$(az pipelines runs list --branch {BRANCH} --top 1 --query "[?result=='failed'].id | [0]" -o tsv)
-     az pipelines runs show --id $RUN_ID --output json
+   **If PLATFORM == azdo AND AZDO_MODE == cli:**
+     RUN_ID=$(az pipelines runs list --branch {BRANCH} --top 1 \
+       --org "{AZDO_ORG_URL}" --project "{AZDO_PROJECT}" \
+       --query "[?result=='failed'].id | [0]" -o tsv)
+     az pipelines runs show --id $RUN_ID \
+       --org "{AZDO_ORG_URL}" --project "{AZDO_PROJECT}" --output json
      # Get timeline for detailed step failures:
      az devops invoke --area build --resource timeline \
-       --route-parameters project=$(az devops configure -l --query '[?name==`project`].value' -o tsv) buildId=$RUN_ID \
+       --route-parameters project="{AZDO_PROJECT}" buildId=$RUN_ID \
+       --org "{AZDO_ORG_URL}" \
        --api-version 7.0 --query "records[?result=='failed'].{name:name, log:log.url}" -o table
 
+   **If PLATFORM == azdo AND AZDO_MODE == rest:**
+     AUTH="Authorization: Basic $(echo -n ":{PAT}" | base64)"
+     # Get failed build ID
+     RUN_ID=$(curl -s -H "$AUTH" \
+       "{AZDO_ORG_URL}/{AZDO_PROJECT}/_apis/build/builds?branchName=refs/heads/{BRANCH}&resultFilter=failed&\$top=1&api-version=7.0" \
+       | jq -r '.value[0].id')
+     # Get timeline for step-level failures
+     curl -s -H "$AUTH" \
+       "{AZDO_ORG_URL}/{AZDO_PROJECT}/_apis/build/builds/$RUN_ID/timeline?api-version=7.0" \
+       | jq '.records[] | select(.result=="failed") | {name, log: .log.url}'
+
 2. **Analyze and fix**
    Read the relevant source files, understand the failures, fix the code.
 
@@ -267,33 +378,80 @@ BRANCH_FLAGS: {--delete-branch (default) | omit if --keep-branch}
    **If PLATFORM == github:**
      gh pr merge {PR_NUMBER} {MERGE_FLAGS} {BRANCH_FLAGS}
 
-   **If PLATFORM == azdo:**
+   **If PLATFORM == azdo AND AZDO_MODE == cli:**
      # 1. Verify all policies pass before attempting merge
-     REJECTED=$(az repos pr policy list --id {PR_NUMBER} --query "[?status=='rejected'] | length(@)" -o tsv 2>/dev/null)
+     REJECTED=$(az repos pr policy list --id {PR_NUMBER} \
+       --org "{AZDO_ORG_URL}" --project "{AZDO_PROJECT}" \
+       --query "[?status=='rejected'] | length(@)" -o tsv 2>/dev/null)
      if [ -n "$REJECTED" ] && [ "$REJECTED" != "0" ]; then
        echo "ERROR: $REJECTED PR policies are rejected — cannot merge"
-       az repos pr policy list --id {PR_NUMBER} --query "[?status=='rejected'].{name:configuration.type.displayName, status:status}" -o table
-       # Report failure
+       az repos pr policy list --id {PR_NUMBER} \
+         --org "{AZDO_ORG_URL}" --project "{AZDO_PROJECT}" \
+         --query "[?status=='rejected'].{name:configuration.type.displayName, status:status}" -o table
        exit 1
      fi
 
-     # 2. Complete the PR with merge strategy
-     MERGE_STRATEGY="squash"   # default; use "noFastForward" if --no-squash
-     DELETE_BRANCH="true"      # default; use "false" if --keep-branch
+     # 2. Resolve merge strategy from flags
+     if echo "{MERGE_FLAGS}" | grep -q "\-\-merge"; then
+       SQUASH_FLAG="false"
+     else
+       SQUASH_FLAG="true"
+     fi
+     if echo "{BRANCH_FLAGS}" | grep -q "\-\-keep-branch"; then
+       DELETE_FLAG="false"
+     else
+       DELETE_FLAG="true"
+     fi
 
+     # 3. Complete the PR
      az repos pr update --id {PR_NUMBER} --status completed \
-       --squash $( [ "$MERGE_STRATEGY" = "squash" ] && echo "true" || echo "false" ) \
-       --delete-source-branch $DELETE_BRANCH
+       --org "{AZDO_ORG_URL}" --project "{AZDO_PROJECT}" \
+       --squash "$SQUASH_FLAG" \
+       --delete-source-branch "$DELETE_FLAG"
+     MERGE_RC=$?
 
-     # 3. If merge fails (e.g. policies still evaluating), wait and retry once
-     if [ $? -ne 0 ]; then
+     # 4. If merge fails (e.g. policies still evaluating), wait and retry once
+     if [ $MERGE_RC -ne 0 ]; then
        echo "Merge failed, waiting 30s for policies to finalize..."
        sleep 30
        az repos pr update --id {PR_NUMBER} --status completed \
-         --squash $( [ "$MERGE_STRATEGY" = "squash" ] && echo "true" || echo "false" ) \
-         --delete-source-branch $DELETE_BRANCH
+         --org "{AZDO_ORG_URL}" --project "{AZDO_PROJECT}" \
+         --squash "$SQUASH_FLAG" \
+         --delete-source-branch "$DELETE_FLAG"
      fi
 
+   **If PLATFORM == azdo AND AZDO_MODE == rest:**
+     AUTH="Authorization: Basic $(echo -n ":{PAT}" | base64)"
+     REPO_NAME=$(basename -s .git "$(git remote get-url origin)")
+     PR_API="{AZDO_ORG_URL}/{AZDO_PROJECT}/_apis/git/repositories/$REPO_NAME/pullrequests/{PR_NUMBER}"
+
+     # 1. Check for rejected policy evaluations
+     EVALS=$(curl -s -H "$AUTH" \
+       "{AZDO_ORG_URL}/{AZDO_PROJECT}/_apis/policy/evaluations?artifactId=vstfs:///CodeReview/CodeReviewId/{AZDO_PROJECT}/{PR_NUMBER}&api-version=7.0")
+     REJECTED=$(echo "$EVALS" | jq '[.value[] | select(.status=="rejected")] | length')
+     if [ "$REJECTED" != "0" ]; then
+       echo "ERROR: PR has rejected policy evaluations — cannot merge"
+       echo "$EVALS" | jq '.value[] | select(.status=="rejected") | {name: .configuration.type.displayName, status}'
+       exit 1
+     fi
+
+     # 2. Resolve merge strategy from flags
+     if echo "{MERGE_FLAGS}" | grep -q "\-\-merge"; then
+       MERGE_STRATEGY="noFastForward"
+     else
+       MERGE_STRATEGY="squash"
+     fi
+     if echo "{BRANCH_FLAGS}" | grep -q "\-\-keep-branch"; then
+       DELETE_BRANCH="false"
+     else
+       DELETE_BRANCH="true"
+     fi
+
+     # 3. Complete the PR
+     curl -s -X PATCH -H "$AUTH" -H "Content-Type: application/json" \
+       "$PR_API?api-version=7.0" \
+       -d "{\"status\": \"completed\", \"completionOptions\": {\"mergeStrategy\": \"$MERGE_STRATEGY\", \"deleteSourceBranch\": $DELETE_BRANCH}}"
+
 2. **Sync local repository**
    Invoke `/sync` to checkout {DEFAULT_BRANCH}, pull latest changes, restore
    any stashed work, and clean up merged branches. This replaces manual git

package/skills/speccy/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: speccy
-description: Deep-dive interview skill for creating comprehensive specifications. Reviews existing code and docs, then interviews the user through multiple rounds of targeted questions covering technical implementation, UI/UX, concerns, and tradeoffs. Produces a structured spec via create-specification. Use when starting a new feature, system, or major change that needs a spec.
+description: Deep-dive interview skill for creating comprehensive specifications. Reviews existing code and docs, then interviews the user through multiple rounds of targeted questions covering technical implementation, UI/UX, concerns, and tradeoffs. Produces a structured spec in specs/. Use when starting a new feature, system, or major change that needs a spec.
 argument-hint: Goal, feature, or high-level description to specify
-allowed-tools: Bash, Read, Write, Edit, Glob, Grep, Agent, AskUserQuestion
+allowed-tools: Bash, Read, Write, Edit, Glob, Grep, Agent, AskUserQuestion, Skill
 ---
 
 # Speccy - Interview-Driven Specification Builder
@@ -60,10 +60,11 @@ Status icons: ✅ done · ❌ failed · ⚠️ degraded · ⏳ working · ⏭️
 ---
 
 Interview the user through multiple rounds of targeted questions to build
-a comprehensive specification. Then hand off to the `create-specification`
-skill to produce the final structured spec document.
+a comprehensive specification, then write it directly using the spec template
+in `references/spec-template.md`.
 
 Interview prompts and question guidelines: `references/interview-guide.md`
+Spec template and writing guidelines: `references/spec-template.md`
 
 ## Pre-flight
 
@@ -71,15 +72,12 @@ Before starting, check all dependencies in this table:
 
 | Dependency | Type | Check | Required | Resolution | Detail |
 |-----------|------|-------|----------|------------|--------|
-| create-specification | skill | `~/.claude/skills/create-specification/SKILL.md` or `~/.agents/skills/create-specification/SKILL.md` | yes | ask | This skill is needed to format the final spec. Install with: `npx skills add slamb2k/mad-skills --skill create-specification` |
 | prime | skill | `~/.claude/skills/prime/SKILL.md` or `~/.claude/plugins/marketplaces/slamb2k/skills/prime/SKILL.md` | no | fallback | Context loading; falls back to manual project scan |
 
 For each row, in order:
 1. Test file existence (check both paths for symlinked skills)
 2. If found: continue silently
 3. If missing: apply Resolution strategy
-   - **ask**: Notify user the skill is missing, offer to install it. If they
-     decline, halt execution — the final spec cannot be produced without it.
 4. After all checks: proceed to context gathering
 
 ---
@@ -90,12 +88,12 @@ Before asking any questions, build a thorough understanding of the project:
 
 1. **Capture GOAL** — the user's argument describing what needs to be specified
 2. **Load project context** — invoke `/prime` to load domain-specific context
-   (CLAUDE.md, goals, specs, memory). If /prime is unavailable, fall back to
+   (CLAUDE.md, specs, memory). If /prime is unavailable, fall back to
    the manual scan below.
 3. **Scan the project** (skip items already loaded by /prime):
    - Read `CLAUDE.md` if present (project conventions, structure, domain)
-   - Read spec directory: `specs/` for existing specifications
-   - Scan existing specs and design docs for context
+   - Scan `specs/` directory for existing specifications
+   - Scan existing design docs for context
    - Read relevant source code that relates to the GOAL
    - Check memory for prior decisions or open questions related to the GOAL
 3. **Identify knowledge gaps** — what must you learn from the user to write
@@ -163,19 +161,26 @@ proceeding to spec generation.
 
 Once the interview is complete and decisions are confirmed:
 
-1. **Invoke the `create-specification` skill** using the Skill tool:
+1. **Create `specs/` directory** if it doesn't exist:
    ```
-   Skill(skill: "create-specification")
+   mkdir -p specs
    ```
 
-2. **Provide the full context** to the skill as input:
-   - The original GOAL
-   - All decisions from the interview rounds
-   - Any relevant code/architecture context discovered in Stage 1
-   - The spec purpose should match the GOAL description
+2. **Read the spec template** from `references/spec-template.md`
 
-3. The `create-specification` skill will handle formatting, naming, and
-   saving the spec file according to its own template and conventions.
+3. **Generate the spec** by filling the template with:
+   - The original GOAL as the introduction and purpose
+   - All decisions from the interview rounds, mapped to the appropriate sections
+   - Code/architecture context discovered in Stage 1
+   - Acceptance criteria derived from requirements decisions
+   - Test strategy aligned with the project's existing patterns
+
+4. **Write the spec file** to `specs/{name}.md` where `{name}` is a
+   kebab-case slug derived from the GOAL (e.g., `specs/user-auth.md`,
+   `specs/payment-integration.md`). Use the Write tool directly.
+
+5. The `specs/` directory is the standard location — `/build` and `/prime`
+   both scan it automatically.
 
 ---
 
@@ -201,6 +206,10 @@ After the spec is created, report to the user:
 │  🔗 Links
 │     Spec: {spec file path}
 │
+│  ⚡ Next steps
+│     1. Review the spec: {path}
+│     2. Run `/build {spec path}` to implement (reads the file automatically)
+│
 └─────────────────────────────────────────────────
 ```
 

package/skills/speccy/references/spec-template.md

@@ -0,0 +1,113 @@
+# Specification Template
+
+Use this template when generating the final specification document in Stage 3.
+Fill every section with content from the interview decisions and project context.
+Omit sections that are genuinely not applicable, but err on the side of inclusion.
+
+## Writing Guidelines
+
+- Use precise, explicit, and unambiguous language
+- Clearly distinguish between requirements, constraints, and recommendations
+- Use structured formatting (headings, lists, tables) for easy parsing
+- Avoid idioms, metaphors, or context-dependent references
+- Define all acronyms and domain-specific terms
+- Include examples and edge cases where applicable
+- Ensure the document is self-contained and does not rely on external context
+
+## File Naming
+
+Save to `specs/{slug}.md` where `{slug}` is a kebab-case name derived from
+the GOAL. Examples: `specs/user-auth.md`, `specs/payment-integration.md`.
+
+## Template
+
+```md
+---
+title: [Concise Title Describing the Specification's Focus]
+version: 1.0
+date_created: [YYYY-MM-DD]
+last_updated: [YYYY-MM-DD]
+tags: [e.g., infrastructure, process, design, app, schema, tool, data, architecture]
+---
+
+# Introduction
+
+[A short concise introduction to the specification and the goal it is intended to achieve.]
+
+## 1. Purpose & Scope
+
+[Clear, concise description of the specification's purpose and scope. State the intended audience and any assumptions.]
+
+## 2. Definitions
+
+[List and define all acronyms, abbreviations, and domain-specific terms used in this specification.]
+
+## 3. Requirements, Constraints & Guidelines
+
+[Explicitly list all requirements, constraints, rules, and guidelines. Use bullet points or tables for clarity.]
+
+- **REQ-001**: [Functional requirement]
+- **SEC-001**: [Security requirement]
+- **CON-001**: [Constraint]
+- **GUD-001**: [Guideline]
+- **PAT-001**: [Pattern to follow]
+
+## 4. Interfaces & Data Contracts
+
+[Describe the interfaces, APIs, data contracts, or integration points. Use tables or code blocks for schemas and examples.]
+
+## 5. Acceptance Criteria
+
+[Define clear, testable acceptance criteria for each requirement using Given-When-Then format where appropriate.]
+
+- **AC-001**: Given [context], When [action], Then [expected outcome]
+- **AC-002**: The system shall [specific behavior] when [condition]
+
+## 6. Test Automation Strategy
+
+[Define the testing approach, frameworks, and automation requirements.]
+
+- **Test Levels**: Unit, Integration, End-to-End
+- **Frameworks**: [appropriate for the project's stack]
+- **Test Data Management**: [approach for test data creation and cleanup]
+- **CI/CD Integration**: [automated testing in pipelines]
+- **Coverage Requirements**: [minimum code coverage thresholds]
+- **Performance Testing**: [approach for load and performance testing]
+
+## 7. Rationale & Context
+
+[Explain the reasoning behind the requirements, constraints, and guidelines. Provide context for design decisions.]
+
+## 8. Dependencies & External Integrations
+
+[Define external systems, services, and architectural dependencies. Focus on what is needed rather than how it's implemented.]
+
+### External Systems
+- **EXT-001**: [External system name] - [Purpose and integration type]
+
+### Third-Party Services
+- **SVC-001**: [Service name] - [Required capabilities and SLA requirements]
+
+### Infrastructure Dependencies
+- **INF-001**: [Infrastructure component] - [Requirements and constraints]
+
+### Data Dependencies
+- **DAT-001**: [External data source] - [Format, frequency, and access requirements]
+
+### Technology Platform Dependencies
+- **PLT-001**: [Platform/runtime requirement] - [Version constraints and rationale]
+
+**Note**: Focus on architectural and business dependencies, not specific package implementations.
+
+## 9. Examples & Edge Cases
+
+[Code snippets or data examples demonstrating correct application, including edge cases.]
+
+## 10. Validation Criteria
+
+[List the criteria or tests that must be satisfied for compliance with this specification.]
+
+## 11. Related Specifications / Further Reading
+
+[Links to related specs or relevant external documentation.]
+```