本文へ移動
cccskills
無料GitHub で公開

update-stack

Use this whenever a downstream Vue project needs to absorb upstream Devkit Vue changes — triggers on "update stack", "sync with devkit", "merge upstream", "pull stack updates", "resolve stack conflicts". Two-phase: ISO merge (stack modules stay byte-identical to upstream) then project alignment (apply MIGRATIONS.md, diff project modules vs `tasks` reference, /verify). Stack-code failures get an issue on `pierreb-devkit/Vue`.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md8.5 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Update Stack Skill

Two-phase workflow. Phase 1 brings the stack down ISO. Phase 2 aligns the project.

Phase 1 — ISO merge

Goal: stack modules exit this phase identical to upstream. Zero downstream logic in them.

Stack scope = every file under src/modules/, src/lib/, src/config/ that exists in devkit-vue/master. Auto-discovered by the step 3ter gate; do not enumerate by hand.

1. Setup remote + merge

git remote get-url devkit-vue >/dev/null 2>&1 || git remote add devkit-vue https://github.com/pierreb-devkit/Vue.git
git fetch devkit-vue
git merge devkit-vue/master

2. Resolve conflicts

FileRule
src/modules/app/app.router.jsgit checkout --ours src/modules/app/app.router.js then merge stack route changes manually — this file always contains downstream routes
Other stack module files (src/modules/home, auth, users, tasks, core, app, secure)git checkout --theirs <file>
package-lock.jsongit checkout --theirs package-lock.json — regenerate after package.json is resolved
ERRORS.mdMerge stack entries + project entries — never drop lines
MIGRATIONS.md (if present)Read it (needed for Phase 2), then git checkout --theirs MIGRATIONS.md
src/config/defaults/<project>.jsgit checkout --ours src/config/defaults/<project>.js (downstream-only file)
vite.config.jsgit checkout --ours vite.config.js then merge upstream changes manually
package.jsongit checkout --ours package.json then merge upstream version bumps
Downstream-only new files (new modules, helpers, composables, lib additions)Never delete — these do not exist in the stack, git checkout --ours <file> if flagged

After resolving package.json, regenerate the lockfile with a full install (not --package-lock-only):

rm -rf node_modules package-lock.json
npm install
git add package-lock.json

Why full install, not npm install --package-lock-only: --package-lock-only writes the lockfile without actually installing, so platform-specific optional peer deps (e.g. @emnapi/core on darwin) can be omitted from the top-level lockfile tree. The lockfile looks fine locally but npm ci on the linux CI runner fails with Missing: @emnapi/core@X.Y.Z from lock file. A full npm install resolves the cross-platform optional dep tree correctly and validates the install in one go. Do not "optimize" this back to --package-lock-only.

Stage all resolved files and complete the merge:

git add -u
git merge --continue

3. /verify

Failures typically indicate regressions from conflict resolution — fix these before Phase 2. However, if failures originate from stack module code itself (see 3bis), report them upstream.

3bis. Report stack issues

If /verify failures originate from a stack file (any file under src/modules/, src/lib/, or src/config/ present in devkit-vue/master) and not from conflict resolution mistakes, open a GitHub issue on pierreb-devkit/Vue.

How to determine the failure origin:

  • Stack code failure: error occurs in unmodified stack module files (resolved with --theirs)
  • Conflict resolution mistake: error occurs in files you manually merged or in downstream-only modules

Create the issue:

gh issue create \
  --repo pierreb-devkit/Vue \
  --title "fix(scope): <short description>" \
  --body "$(cat <<'BODY'
## Problem
<failing command output>

## Affected file(s)
<list>

## Steps to reproduce
<steps>
BODY
)" \
  --label "Fix"

Proceed to Phase 2 and track the upstream fix separately — do not block downstream alignment on it.

3ter. Block on drift

After /verify passes, run a final diff sweep before starting Phase 2. Any shared non-test stack file that diverges from upstream blocks the flow. No ledger exception (user decision 2026-06-02 — drift must never happen, not be documented).

git fetch devkit-vue master --quiet

drift_found=0
while IFS= read -r f; do
  # Both sides exist + differ → drift
  if git cat-file -e "devkit-vue/master:$f" 2>/dev/null && git cat-file -e "HEAD:$f" 2>/dev/null; then
    echo "BLOCK: drift on shared file: $f"
    echo "  Fix A — revert to upstream: git checkout devkit-vue/master -- $f"
    echo "  Fix B — promote upstream:   open a devkit PR with the change, merge, /update-stack here"
    echo "  Fix C — relocate:           move logic to a downstream-only module or src/config/defaults/<project>.config.js"
    drift_found=1
  # Upstream has it, local doesn't → missing-locally
  elif git cat-file -e "devkit-vue/master:$f" 2>/dev/null; then
    echo "BLOCK: missing locally (was on upstream): $f"
    echo "  Fix — restore: git checkout devkit-vue/master -- $f"
    drift_found=1
  fi
  # Downstream-only file (not in upstream) → skip silently
done < <(git diff --name-only devkit-vue/master HEAD -- src/modules src/lib src/config 2>/dev/null \
  | grep -vE "/(tests|__tests__)/" | grep -vE "\.(test|spec)\.(js|jsx|ts|tsx|vue)$")

[ "$drift_found" -eq 1 ] && exit 1
echo "3ter: no drift — OK"

Rules:

  • Block on ANY shared-file divergence. No "declare and skip" path — the DOWNSTREAM_PATCHES.md ledger model was abandoned 2026-06-02 (memory feedback_no_dev_in_shared_modules).
  • Scan source is git diff --name-only devkit-vue/master HEAD (bidirectional) — catches both files that differ AND files present upstream but missing locally (deleted downstream). The previous git ls-files approach only saw locally-present files.
  • Test files (paths containing /tests/ or /__tests__/, or filenames ending .test.{js,jsx,ts,tsx,vue} / .spec.{js,jsx,ts,tsx,vue}) are excluded — downstream test adaptations are acceptable.
  • E2E helpers under src/lib/helpers/e2e/ ARE scanned — they are stack-managed. Downstream modification triggers BLOCK; use Fix B (promote upstream) if a downstream needs e2e helper changes.
  • src/modules/app/app.router.js historically diverged on every downstream (downstream routes). Under no-ledger this must be refactored: app.router.js does NOT currently expose an extension hook — the refactor needs to add one (e.g. a registerDownstreamRoutes() call sourced from a downstream-only module like src/modules/{project}/{project}.router.js), then keep app.router.js stack-iso. Until that refactor lands, this gate will BLOCK on every Vue downstream /update-stack.
  • This gate runs after /verify (never blocks on transient verify failures) and before Phase 2 (failure is recoverable — no merge commit yet).
  • Ref: the stack/downstream perfect-alignment plan, Tasks E.1 + E.2.

Phase 2 — Project alignment

Goal: project-specific modules work and match stack patterns.

4. Apply MIGRATIONS.md (if present)

Read the last entries — they list breaking changes requiring updates in project modules. Apply each one to non-stack modules.

5. Align project modules

Diff project modules against src/modules/tasks (stack reference). Fix any pattern drift flagged by ERRORS.md.

6. /verify


Red flag: conflicts in src/main.js

src/main.js is stack-managed. If /update-stack reports a conflict here, do NOT keep the downstream side via --ours. Instead:

  1. List the downstream-only lines:

    # Show the actual downstream-only lines that exist locally but not in upstream stack
    git diff devkit-vue/master..HEAD -- src/main.js
    # (alternatively, check the conflict markers left by the merge)
    git log --oneline -- src/main.js | head -10
    
  2. Move each downstream-only side-effect (import './modules/.../foo.css', posthog/sentry init, custom plugin install) into a project-owned entry — typically src/modules/{project}/views/{project}.view.vue (preferred) or a downstream-only module index imported from there.

  3. Take the upstream version of src/main.js (git checkout --theirs src/main.js) once the migrations are committed.

  4. Add a regression note to DOWNSTREAM_PATCHES.md if the migration is non-obvious.

This protects against the silent visual / analytics regressions seen on a downstream project (per-card mesh/grain CSS wiped on stack sync).

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Use this whenever the user asks to "create a module", "scaffold a feature", "add a Vue domain", "new module called X", or starts work on a brand-new vertical (views + components + store + router entry + tests). Duplicates the canonical `src/modules/tasks` template, applies kebab/Pascal/camel/ UPPER renames, and wires config-driven values. Module stays self-contained.

日本語の概要は準備中です。原文の説明を表示しています。

pierreb-devkit/Vue202026年10月9日 更新

feature

無料

Use this whenever the user asks to "implement", "add", "build", "create", or "modify" a feature, page, view, component, or module in this Vue project. Three phases: Phase 0 scope analysis (flows + edge cases + UI needs + plan validation, STOP for user), Phase 1 implementation (layered UI → Store → API, Vue 3 Composition + Vuetify 4, /ui design rules), Phase 2 Definition-of-Done checklist + /verify + /pull-request. Auto-runs /create-module if the target module doesn't exist.

日本語の概要は準備中です。原文の説明を表示しています。

pierreb-devkit/Vue202026年10月9日 更新

naming

無料

Use this whenever a new file/folder is created or renamed in this Vue project, when reviewing a module for consistency, or when the right path for a file is unclear. Also triggers on "what should I name this?", "is this file named correctly?", "audit module naming". Enforces kebab-case folders, dot-prefixed `{module}.{name}.{type}.vue|js` files, multi-entity rules, singular vs plural for views, and the layered structure UI → Store → API.

日本語の概要は準備中です。原文の説明を表示しています。

pierreb-devkit/Vue202026年10月9日 更新

Use this whenever the user asks to "open a PR", "ship this", "create the pull request", "make a PR", or once a Vue feature/fix is verified and ready to push. Full lifecycle: branch → commit (commitizen) → issue → draft PR → CI → ready → autonomous monitor loop (fix comments, resolve threads, iterate until CI green + zero unresolved threads). `--perfect` adds a CodeRabbit convergence loop on top. Never works on `main`/`master`, never uses `--no-verify`.

日本語の概要は準備中です。原文の説明を表示しています。

pierreb-devkit/Vue202026年10月9日 更新

ui

無料

Design system reference for the Devkit Vue stack (Vuetify 4 + custom theme helpers). Use when asked about styling, theming, layout, design system, Vuetify components, visual verification, or UI patterns. Automatically consumed by /feature when the task has a visual component. Can also be invoked directly for design-only tasks (restyle, theme change, layout fix).

日本語の概要は準備中です。原文の説明を表示しています。

pierreb-devkit/Vue202026年10月9日 更新

verify

無料

Run this after every code change in this Vue project, before committing, before opening a PR, or whenever the user says "verify", "check", "lint", "run tests", "build", "audit". Diff audit (router guards, store boundaries, UX, /ui consistency, error handling) → lint → tests + coverage gate → build. Coverage drops → add tests, never lower thresholds. Triggers on "is this ready to commit?", "any issues?", "tests passing?".

日本語の概要は準備中です。原文の説明を表示しています。

pierreb-devkit/Vue202026年10月9日 更新

pierreb-devkit のスキルをすべて見る

このスキルの問題を報告する