eq-frontend-workflow

Enforces trunk-based git workflow covering branches, worktrees, commits, PRs, reviews, releases, and rollbacks.

Updated Aug 3, 2026
One-click install
npx skills add https://github.com/everquint/frontend-skills --skill eq-frontend-workflow-everquint
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: eq-frontend-workflow
Source: https://github.com/everquint/frontend-skills/tree/main/skills/engineering/eq-frontend-workflow
Command: npx skills add https://github.com/everquint/frontend-skills --skill eq-frontend-workflow-everquint

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Teams and AI agents working on frontend repos often produce inconsistent branch names, unverifiable PR claims, silent multi-session git collisions, and changelogs that disagree with what actually shipped. This Skill defines one delivery workflow — from branch creation through merge, release, and rollback — so every change follows the same enforceable rules. ## Core Features & Use Cases - Branch and worktree model: Trunk-based branching with a decision table for when to use a git worktree, including the shared-HEAD hazard when two sessions share one checkout. - Commit and PR discipline: Conventional-commit format enforced by commitlint, merge-commit-only history, a four-section PR body template, and a pre-push gate (typecheck, lint, tests, build) that stops at the first failure. - Review, release, and rollback: Two parallel required reviews (conventions and correctness), Changesets-based versioning where the release job owns CHANGELOG.md, and revert commands named before merging. - Use Case: An agent starting a feature creates feat/AB-1420-inline-citations, opens a draft PR after the first commit, runs the gate, gets both reviews, and merges with a changeset — with every step verifiable. ## Quick Start Ask the agent to start a new feature following the frontend workflow, including branch naming, the pre-push gate, and a draft PR with the required body sections.

Frequently Asked Questions about eq-frontend-workflow

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure a frontend git workflow with trunk-based development?

Use one long-lived default branch with short-lived feature branches named <type>/<ticket>-<slug>, merged via PRs with required checks. Never commit directly to the default branch, and delete branches on merge.

When should I use a git worktree instead of a branch?

Use a worktree when two or more agents or sessions work concurrently, for risky disposable spikes, or for hotfixes mid-feature. A shared checkout has a shared HEAD, so one session's checkout can silently retarget another's commit.

Changesets vs semantic-release for versioning — which should I use?

Changesets makes the version bump a human, per-PR, reviewable decision, while semantic-release infers it from commit messages. A mistyped commit type ships a wrong version silently; a missing changeset fails CI visibly.

Why does the changesets release job fail at the commit step?

The action's default commit message 'Version Packages' has no conventional-commit type, so a live commitlint hook rejects it. Set both the commit and title inputs to 'chore: version packages' rather than disabling the hook.

Can I hand-edit CHANGELOG.md between releases?

No. CHANGELOG.md is a build output regenerated by changeset version from the pending changesets. A hand edit makes the file underivable from the changesets and is either overwritten or causes a conflict at the next release.

What checks must pass before merging a frontend pull request?

CI must be green for typecheck, lint, tests, and build; both conventions and correctness reviews must be complete; the branch must be up to date; a changeset is required for user-visible changes; and the PR must be out of draft.