Land

Land irodr changes

Intent and scope

This skill applies only to azu/irodr. An explicit landing request authorizes preparation, commits, topic-branch publication, PR creation, and merging through the workflow below. /land and accepting an offer to run this installed skill are explicit landing requests. Proceed without asking for the same permission again. Installing this skill alone does not authorize execution.

Use the attached Delta worktree, not the user's primary checkout. Land only the requested change; preserve unrelated staged, unstaged, and untracked work. Never publish secrets, disable signing or hooks, force-push, rewrite shared history, bypass protection, or change repository settings to make landing pass. If scope is genuinely ambiguous, ask one focused question before proceeding.

When the user requests landing this skill first and another change afterward, land them as separate PRs in that order. Stage only the skill for the first PR; keep the other changes out of its commits. Carry the remaining work forward without discarding it, and create the second PR from the updated target.

Preflight

1. Read applicable AGENT.md/AGENTS.md, current contribution instructions, templates, and the relevant change. Inspect:

   git --no-optional-locks status --short --branch
   git diff
   git diff --cached
   git remote -v
   git log -8 --oneline

   Identify existing relevant commits as well as uncommitted work. Do not stage all files blindly or replace the user's partial staging. Check for unresolved merge markers and Git operations before starting another operation.

2. Verify the publication remote is GitHub azu/irodr; normally it is origin. Never push to Delta's local backlink. Verify the default branch, currently master, and the intended PR base. If the destination differs from this scope, stop and clarify instead of silently choosing main or another repo. Check gh auth status without displaying credentials and confirm Git push access. Authentication and tools can differ between machines.

3. Inspect destination settings using gh api / gh pr view:

   • Repository identity, default branch, viewer permissions, and whether squash merging is allowed.
   • repos/azu/irodr/branches/master and repos/azu/irodr/rules/branches/master.
   • Applicable branch protection and required checks/reviews when protected.
   • For an existing PR: head SHA, base, draft state, review decision, merge state, and check results.

   During setup, master was unprotected, the applicable-rules endpoint returned no rules, and squash merges were allowed. These are observations, not permanent exemptions. The token could not read the branch-protection administration endpoint: do not interpret a 403 as "no requirements." An explicit unprotected branch response plus successfully retrieved empty applicable rules can establish that no branch rules apply. Otherwise, if requirements cannot be established, stop and explain the missing access. Never use gh pr merge --admin.

4. Follow the contribution policy in README.md ("Contributing"): a feature branch and pull request, rather than a direct target-branch push. Use a fork if upstream topic-branch push permission is unavailable; stop if no authorized publication destination is available. Respect CODE_OF_CONDUCT.md. For a newly discovered nonpublic vulnerability, follow the inherited security policy at https://github.com/azu/.github/blob/master/SECURITY.md before publishing sensitive details.

   No additional CLA, mandatory human-authored submission text, changelog entry, or fixed review count was found during setup. Recheck current policies and templates; enforce any applicable unmet requirements, including their conditions and exceptions. Do not invent requirements or ask again about requirements already satisfied. Describe behavior accurately in affected documentation; do not claim tests that were not run.

Prepare and verify

Use the Node version in .node-version (24.14.1 at setup) and pnpm from package.json#packageManager (10.34.5 at setup). CI reads .node-version through voidzero-dev/setup-vp; local verification does not replace CI. Do not silently use whichever Node happens to be first on PATH.

Let the runtime manager read the project version files rather than overriding the version in each command. For mise, the existing settings.idiomatic_version_file_enable_tools setting should include "node" so it reads .node-version automatically. Verify the active versions:

node --version
pnpm --version

Use the ordinary package commands below when those versions match. If the non-interactive terminal has not activated mise, prefix commands with mise exec -- to use its project-selected versions, without an explicit node@... override. Sources: .node-version and package.json#packageManager; the optional wrapper syntax was checked against mise exec --help. Ask before installing global tooling or changing the user's external configuration.

1. Fetch the verified publication remote. Reuse the relevant topic branch/PR where appropriate; otherwise create a descriptive feature/... branch, including when the work started as uncommitted edits on master. Check the entire base-to-head diff so old or unrelated commits do not slip into the PR. Do not discard existing work or stash it without a clear recovery plan.

2. Install project dependencies when needed:

   pnpm install --frozen-lockfile

   Source: .github/workflows/test.yml installs with vp install --frozen-lockfile (Vite+ runs the pnpm version from package.json#packageManager); package.json#packageManager and pnpm-lock.yaml define the dependency state. --frozen-lockfile prevents incidental lockfile changes. package.json#scripts.prepare runs vp config --no-agent, which installs the Vite+ hook dispatcher for .vite-hooks. Preserve that hook behavior. If the manifest and lockfile are inconsistent, fix only the intended dependency change and rerun verification; do not bypass the failure.

3. For code, dependency, or build/test configuration changes, run:

   pnpm run check
   pnpm test
   pnpm run build
   CI=true pnpm run test:e2e

   Sources: .github/workflows/test.yml runs vp check, vp test and vp build (job "Check, unit test and build") and vp run test:e2e (job "Integration tests"). package.json#scripts.check runs vp check (Oxfmt, Oxlint with type checking); package.json#scripts.test runs the Vitest unit tests once (vp test does not watch); package.json#scripts.test:e2e builds with --mode e2e and runs Playwright against the fake APIs in e2e/fake-api. CI=true makes Playwright start fresh servers. Playwright needs Chromium (pnpm exec playwright install chromium, or set PLAYWRIGHT_CHROMIUM_EXECUTABLE).

   For skill/documentation-only changes, local verification can instead check syntax, links, command references, frontmatter, and the scoped diff. This exception is local only: required remote checks still must pass. Check git diff --check for every change.

   If local verification fails due to an environment issue, use the declared runtime and retry. Report genuine unavailable prerequisites or failed checks; do not label them passed, replace tests with mocks, or weaken the checks.

4. Stage only the intended paths/hunks. Use an English conventional commit subject (feat:, fix:, docs:, chore:, etc.), following existing history. Use a non-interactive commit:

   GIT_EDITOR=true git commit -m "type: concise description"

   Preserve the user's signing configuration (SSH commit signing was enabled at setup). Never use --no-verify to bypass .vite-hooks/pre-commit, which runs vp staged (the staged block in vite.config.ts formats and lints staged files) and vp test. Inspect the resulting commit and any hook changes. Verification must cover the final contents, not the pre-hook or earlier version.