Skip to content

Rewrite API version update guide as tested, validated Claude skill#3433

Open
kdaviduik wants to merge 4 commits intomainfrom
2026-01-update
Open

Rewrite API version update guide as tested, validated Claude skill#3433
kdaviduik wants to merge 4 commits intomainfrom
2026-01-update

Conversation

@kdaviduik
Copy link
Copy Markdown
Contributor

@kdaviduik kdaviduik commented Feb 3, 2026

WHY are these changes introduced?

The original .claude/commands/apis-version-update.md (1618 lines) had two categories of problems:

Structural issues (from previous session):

  • Build steps duplicated 13+ times throughout
  • No anti-hallucination guardrails — Claude was adding analysis and interpretation to issue content
  • Complex issue templates that weren't being followed

Untested API patterns (discovered this session):

  • HEREDOC syntax (cat <<'EOF') is blocked in the Claude Code sandbox — issue creation would silently fail
  • Missing Status field — the "Online Store Developer Platforms" project doesn't auto-set Status; it defaults to "Triage", not "Todo (prioritized)"
  • <PARENT_NUM> literal placeholders in Step 8e GraphQL queries — these were passed literally, not as shell variables, causing sub-issue linking to fail

WHAT is this pull request doing?

Replaces the 1618-line command with a ~900-line skill, validated via live test against real GitHub issues (#1084, #1085, #1086 in Shopify/developer-tools-team):

Aspect Before After
Location .claude/commands/apis-version-update.md .claude/skills/apis-version-update/SKILL.md
Size 1618 lines ~900 lines
Issue body creation HEREDOC (broken in sandbox) Write tool + --body-file
Status field Not set Explicitly set to "Todo (prioritized)"
Sub-issue GraphQL Literal <PARENT_NUM> placeholder Correct '""' expansion
Verification None Checkpoint 3 verifies all 4 criteria end-to-end
Success criteria Implicit Explicit checklist in Quick Reference

All 9 success criteria were confirmed passing via live API test before updating the skill.

HOW to test your changes?

  1. Invoke the skill via /apis-version-update
  2. Verify the sandbox constraint note appears prominently at the top
  3. Confirm Step 7a includes both the "Project" = "Hydrogen" and "Status" = "Todo (prioritized)" mutations
  4. Confirm Checkpoint 3 verification script checks sub-issues, Hydrogen field, Status field, and parent body

Checklist

  • I've read the Contributing Guidelines
  • I've considered possible cross-platform impacts (Mac, Linux, Windows)
  • I've added a changeset if this PR contains user-facing or noteworthy changes
  • I've added tests to cover my changes
  • I've added or updated the documentation

@shopify
Copy link
Copy Markdown
Contributor

shopify Bot commented Feb 3, 2026

Oxygen deployed a preview of your 2026-01-update branch. Details:

Storefront Status Preview link Deployment details Last update (UTC)
Skeleton (skeleton.hydrogen.shop) ✅ Successful (Logs) Preview deployment Inspect deployment March 6, 2026 4:21 AM

Learn more about Hydrogen's GitHub integration.

Replace 1618-line command with 304-line skill (81% reduction).

The old guide had issues with LLM hallucinations (suggesting fixes,
analyzing errors), duplicate sections (build steps appeared 13+ times),
and overly complex templates. The new skill:

- Adds explicit anti-hallucination directive at the top
- Consolidates build steps to appear exactly once
- Uses minimal child issue template to prevent AI interpretation
- Clarifies "8 Tracking Phases" vs "9 Implementation Steps"
- Adds handoff note for phases 3-8 requiring manual execution
- Strengthens checkpoints: "report EXACT error... Do NOT diagnose"
@kdaviduik kdaviduik changed the title Streamline API version update guide into skill Improve SF API/CA API AI-assisted update command Feb 5, 2026
Confirmed all GitHub API calls work via live test (issues #1084, #1085, #1086 in Shopify/developer-tools-team).

Changes:
- Replace all HEREDOC patterns with Write tool + --body-file (HEREDOC blocked in sandbox)
- Add Status field mutation alongside Project field in all three code paths (Step 7a, Step 8d, setup_phase_child_issue function)
- Add Status verification to all three code paths and to Checkpoint 3
- Document 'child' label pre-exists (no creation needed)
- Add Success Criteria Checklist section
- Add new project constants: Status field ID (PVTSSF_lADNH5XOABDyGM4AnCva) and Todo-prioritized option ID (f75ad846)
- Add Lesson 6: HEREDOC blocked in sandbox
- Add Lesson 7: GraphQL variable interpolation with '"ENV_VAR"' pattern
- Fix literal <PARENT_NUM> placeholders in Step 8e GraphQL queries (bug: they weren't expanding)
- Save PARENT_NUM to /tmp/claude/parent_num.txt for cross-step recovery
@kdaviduik kdaviduik changed the title Improve SF API/CA API AI-assisted update command Rewrite API version update guide as tested, validated Claude skill Mar 6, 2026
@kdaviduik kdaviduik marked this pull request as ready for review March 6, 2026 03:37
@kdaviduik kdaviduik requested a review from a team as a code owner March 6, 2026 03:37
4. **Manual testing** - Test changes in a real Hydrogen project
5. **Release versions** - Publish packages to npm
6. **Add post in docs/changelog.json** - Enable `h2 upgrade` command
7. **Update Shopify dev API reference docs** - Sync external documentation
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note: theoretically the dev docs update step should be automated, but I think this skill is more effective if it creates a comprehensive list of all the things that must happen, to ensure nothing slips through the cracks

@binks-code-reviewer
Copy link
Copy Markdown

⚠️ Findings outside the diff

These findings are in files not modified by this PR and cannot be posted as inline comments.


/.claude/skills/apis-version-update/SKILL.md:201Verification queries likely read the wrong project item (false positives/negatives)

In Step 7a, verification reads --jq '.data.repository.issue.projectItems.nodes[0].fieldValueByName.name', which assumes nodes[0] is the item for project #4613. That is not guaranteed—issues can be in multiple projects and GraphQL ordering isn’t stable. Earlier code correctly selects the item id for project 4613 (nodes[] | select(.project.number == 4613) | .id), but verification doesn’t apply the same selection, so it can report success when project 4613 is wrong or failure when project 4613 is correct.

Impact: Reliability hazard for the “validated skill” claim; the skill may exit 1 incorrectly or pass incorrectly, leaving issues in the wrong project/status.

@binks-code-reviewer
Copy link
Copy Markdown

binks-code-reviewer Bot commented Mar 6, 2026

🤖 Code Review · #projects-dev-ai for questions
React with 👍/👎 or reply — all feedback helps improve the agent.

Complete - No issues

📋 History

✅ No issues → ✅ No issues → ✅ No issues

…ueries

All 8 verification queries used nodes[0] to read field values, assuming the first project item belongs to project #4613. This assumption is incorrect — an issue can belong to multiple projects and GraphQL ordering is not stable.

Fix: Add project { number } to the nodes fragment in all verification queries, then filter using nodes[] | select(.project.number == 4613) before reading .fieldValueByName.name. This mirrors the correct pattern already used in the item-ID lookup queries.
@binks-code-reviewer
Copy link
Copy Markdown

⚠️ Findings outside the diff

These findings are in files not modified by this PR and cannot be posted as inline comments.


/.claude/skills/apis-version-update/SKILL.md:162gh issue create output parsing is brittle; child linking can fail

The skill assumes gh issue create returns a URL that can be reliably parsed with grep -oE '[0-9]+$' to obtain the issue number. In practice, gh issue create output varies by gh version/config and may include additional text/newlines. If the output isn’t a bare URL ending with the number, PARENT_NUM / ISSUE_NUM becomes empty or incorrect, cascading into GraphQL query failures, empty project item lookups, and sub-issue linking failures or incorrect linking.

Evidence:

PARENT_ISSUE_URL=$(gh issue create ... --body-file /tmp/claude/parent-body-initial.md)
PARENT_NUM=$(echo "$PARENT_ISSUE_URL" | grep -oE '[0-9]+$')

/.claude/skills/apis-version-update/SKILL.md:274gh issue create output parsing is brittle; child linking can fail

The skill assumes gh issue create returns a URL that can be reliably parsed with grep -oE '[0-9]+$' to obtain the issue number. In practice, gh issue create output varies by gh version/config and may include additional text/newlines. If the output isn’t a bare URL ending with the number, PARENT_NUM / ISSUE_NUM becomes empty or incorrect, cascading into GraphQL query failures, empty project item lookups, and sub-issue linking failures or incorrect linking.


/.claude/skills/apis-version-update/SKILL.md:208Missing guard for empty PARENT_ITEM_ID before mutations

In Step 7a, PARENT_ITEM_ID is computed but never validated as non-empty before being used in GraphQL mutations. If the project item isn’t available yet (race) or the filter doesn’t match, PARENT_ITEM_ID becomes empty and subsequent mutations fail or behave unpredictably without surfacing the root cause early.

Evidence:

PARENT_ITEM_ID=$(gh api graphql ... --jq '... | .id')
# later used as itemId: "$PARENT_ITEM_ID"

…parse

Three brittle silent-failure paths fixed:

1. PARENT_NUM: guard after grep-oE parse of gh issue create output

2. ISSUE_NUM: guard in Step 8c and all 6 phase child blocks (replace_all)

3. PARENT_ITEM_ID: guard in Step 7a before GraphQL mutations

Without these guards, an unexpected gh output format or a race on project item creation propagates an empty variable silently through downstream GraphQL mutations, jq filters, and sub-issue linking — producing misleading errors or silent incorrect behavior.
Copy link
Copy Markdown
Contributor

@fredericoo fredericoo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this PR still valid? if so, here are some comments

there are some merge conflicts because we already moved it all to skills


```bash
ISSUE_URL=$(gh issue create --repo Shopify/developer-tools-team \
--title "Release <VERSION_CALVER> versions" \
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

non-blocking: <VERSION_CALVER> isn't defined anywhere in the skill - every other reference uses <VERSION> (e.g., 2026-01). If CalVer is intentionally different (e.g., 2026.1.0), let's define it in Step 1 alongside <VERSION>. Otherwise, should this just be <VERSION>?

Then:

```bash
git add -A
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

non-blocking: git add -A stages everything including any temp files, .env files, or IDE state that might be in the working directory. For a skill that an agent executes semi-autonomously, let's use explicit paths instead:

Suggested change
git add -A
git add packages/ templates/ .changeset/

grep -o 'shopify.dev/changelog' /tmp/claude/api_changes.json | head -1 && echo "✓ URLs transformed" || echo "✗ URL transformation failed"
```

### 8c: For Each Changelog Entry
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's no 8b!!!

grep "SF_API_VERSION" packages/hydrogen-react/codegen.ts

# Create feature branch
git checkout -b <VERSION>-sfapi-caapi-update
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: let's include origin/main as the base branch to avoid picking up unrelated local changes (happened to me):

Suggested change
git checkout -b <VERSION>-sfapi-caapi-update
git checkout -b <VERSION>-sfapi-caapi-update origin/main

# Add parent issue to project
gh project item-add 4613 --owner Shopify --url "$PARENT_ISSUE_URL"
sleep 2

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: was the sleep 2 determined empirically during the live test? Lesson 4 documents it as part of the required sequence. For a quarterly process this is pragmatic - just checking if there's a known failure mode when GitHub's project API is slower than usual.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants