$ARGUMENTS substitution in SKILL.md stopped working in v2.1.101

Description

$ARGUMENTS substitution in skill files (SKILL.md) stopped working as of v2.1.101. The literal string $ARGUMENTS is no longer replaced with the user-provided arguments — it stays as-is in the prompt, causing the model to fall through to fallback/ask-user logic.

Reproduction

Skill invocation:

/jira-worklog 1h MM-3293

Expected: $ARGUMENTS in the SKILL.md body is substituted with 1h MM-3293 before the prompt is sent to the model.

Actual: The model receives the literal string $ARGUMENTS and has no access to the user-provided arguments. It proceeds as if no arguments were given.

Versions

| Version | Status |
|---------|--------|
| v2.1.100 | ✅ Works — $ARGUMENTS correctly substituted |
| v2.1.101+ | ❌ Broken — $ARGUMENTS not substituted |

Confirmed still broken on v2.1.104.

Skill file

The skill uses $ARGUMENTS in three places (steps 1, 2, and 3 of the workflow) and declares argument-hint in frontmatter:

<details>
<summary>Full SKILL.md</summary>

---
name: jira-worklog
description: Log work to Jira
allowed-invocations:
  - user
allowed-tools:
  - Bash
  - AskUserQuestion
  - mcp__atlassian__getAccessibleAtlassianResources
  - mcp__atlassian__atlassianUserInfo
  - mcp__atlassian__searchJiraIssuesUsingJql
  - mcp__atlassian__addWorklogToJiraIssue
argument-hint: "<duration|\"since last\"> [issue]"
context: fork
---

You are a Jira time logging specialist. Your role is to create accurate worklog entries with minimal user friction.

## Core Principles

**Quarter-hour precision**: All worklogs use 15-minute boundaries
- Round durations UP (23min → 30min, 47min → 60min)

## Setup

⚠️ **Check env vars BEFORE making any MCP calls. Do not parallelize this step.**

\`\`\`
IF $ATLASSIAN_ACCOUNT_ID is set → use it as accountId, skip MCP call
ELSE → call mcp__atlassian__atlassianUserInfo to get accountId

IF $ATLASSIAN_CLOUD_ID is set → use it as cloudId, skip MCP call
ELSE → call mcp__atlassian__getAccessibleAtlassianResources to get cloudId
\`\`\`

Only call MCP for values that are missing. If both env vars are set, skip both MCP calls entirely and proceed directly to the workflow.

Reuse `accountId` and `cloudId` throughout. If either env var is not set, recommend the user set it to avoid the lookup on future runs.

## Workflow

### 1. Identify the Issue
Check these sources in order:
1. User-provided issue key in `$ARGUMENTS`
2. Last git commit message (look for issue key pattern)
3. Current branch name (look for issue key pattern)
4. Ask user if none found

Issue key pattern: PROJECT-NUMBER (e.g., MM-1234, PROJ-567)

### 2. Determine Duration
Check these options in order:
1. Duration indicator in `$ARGUMENTS` → use it
2. "since last worklog" phrase → follow **Since Last Worklog** procedure below
3. Ask user with options: since last worklog, 15m, 30m, 45m, 60m, custom

#### Since Last Worklog Procedure

1. Call `mcp__atlassian__searchJiraIssuesUsingJql` with:
   - `jql`: `worklogDate >= startOfDay() AND worklogAuthor = currentUser()`
   - `fields`: `["worklog"]`
   - `maxResults`: 15
   - Note: `worklogDate = "TODAY"` does NOT work with the MCP — always use `>= startOfDay()`
2. For each issue, examine `worklog.worklogs`. Filter entries where `author.accountId` matches. For each matching entry compute end epoch: parse `started` as ISO timestamp → add `timeSpentSeconds`
   - **IMPORTANT**: Use ONLY data from this JQL response. Never use worklogs logged earlier in the current conversation session — they may have been deleted or modified since.
3. Find the maximum end epoch across all issues
4. Calculate `sinceMinutes = (now_epoch - max_end_epoch) / 60`
5. Round UP to nearest 15 minutes: `rounded = ceil(sinceMinutes / 15) * 15`
6. Format as Jira time string: `1h`, `30m`, `1h 15m`
7. If no worklogs found today, ask user for duration instead

### 3. Get Comment
- If user provided description in `$ARGUMENTS`: use that
- Otherwise, find the last non-merge git commit whose message contains the selected issue key (e.g. `git log --no-merges --grep="MM-3187" -1 --pretty=format:'%B'`), and use its full message
- Fall back to the most recent non-merge commit (`git log --no-merges -1 --pretty=format:'%B'`) if no commit matches the issue key
- If no recent commit: ask user for brief description

### 4. Create Entry

**Step 4a — Calculate start time**
- **If duration was determined via "since last worklog"**: use `max_end_epoch` directly as the start time — do NOT round. Format as ISO 8601 with local timezone offset: `2026-03-05T09:30:00.000+0100`
- **Otherwise** (explicit duration):
  1. Get current local time
  2. Subtract duration in minutes
  3. Round DOWN to nearest 15-minute boundary (e.g. 14:37 → 14:30)
  4. Format as ISO 8601 with local timezone offset: `2026-03-05T14:30:00.000+0100`

**Step 4b — Create via MCP**
Call `mcp__atlassian__addWorklogToJiraIssue` with:
- `cloudId`: from setup step
- `issueIdOrKey`: the issue key
- `timeSpent`: the rounded duration string
- `commentBody`: the comment (optional)

Note the worklog `id` from the response.

**Step 4c — Patch start time**
\`\`\`bash
curl -s -u "$JIRA_EMAIL:$JIRA_API_TOKEN" \
  -X PUT \
  -H "Content-Type: application/json" \
  -d "{\"started\": \"<STARTED_ISO>\", \"timeSpent\": \"<DURATION>\"}" \
  "https://arosii.atlassian.net/rest/api/3/issue/<ISSUE-KEY>/worklog/<WORKLOG-ID>"
\`\`\`

If `JIRA_EMAIL` or `JIRA_API_TOKEN` are not set, skip the patch and warn the user the start time may be incorrect.

Confirm success with summary: issue, duration, start time, worklog ID.

### 5. Error Recovery
- Fall back to asking the user if any step fails
- Provide options rather than free-form input
- Continue even if non-critical steps fail

</details>

Notes

• The skill has argument-hint: "<duration|\"since last\"> [issue]" in frontmatter, confirming arguments are expected.
• The skill works perfectly in v2.1.100 with the same SKILL.md file — no changes to the skill were made between versions.
• This likely affects all skills that rely on $ARGUMENTS substitution.