菜单
Pull the latest agents-core scaffolding from upstream into the current project. Use when the user wants to update their .agents/ directory, AGENTS.md, or other scaffolding files from the shared upstream repository.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/cristoslc/LLM-personal-agent-patterns --skill update-agents-core命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Create, validate, and transition documentation artifacts (Vision, Journey, Epic, Story, Agent Spec, Spike, ADR, Persona, Runbook, Bug, Design) and their supporting docs (architecture overviews, journey maps, competitive analyses) through their lifecycle phases. Use when the user wants to write a spec, plan a feature, create an epic, add a user story, draft an ADR, start a research spike, define a persona, create a user persona, create a runbook, define a validation procedure, file a bug, report a defect, create a design, capture a wireframe, document a UI flow, sketch interaction states, update the architecture overview, document the system architecture, move an artifact to a new phase, seed an implementation plan, implement a spec, fix a bug, work on a story, or validate cross-references between artifacts. When a SPEC, STORY, or BUG comes up for implementation, always chain into the execution-tracking skill to create a tracked plan before any code is written. When execution-tracking is requested on an EPIC,
Cut a release — detect versioning context, generate a changelog from conventional commits, bump versions, and create a git tag. Use when the user says "release", "cut a release", "tag a release", "bump the version", "create a changelog", or any variation of shipping/publishing a version. This skill is intentionally generic and works across any repo — it infers context from git history and project structure rather than assuming a specific setup.
Bootstrap, install, and operate an external task-management CLI as the source of truth for agent execution tracking (instead of built-in todos). Provides the abstraction layer between spec-management intent (implementation plans and tasks) and concrete CLI commands. MUST be invoked when any implementation-tier artifact (SPEC, STORY, BUG) comes up for implementation — create a tracked plan before writing code. Optional but recommended for complex SPIKEs. For coordination-tier artifacts (EPIC, VISION, JOURNEY), spec-management must decompose into implementable children first — this skill tracks the children, not the container. Also use for standalone tasks that require backend portability, persistent progress across agent runtimes, or external supervision. Use this skill whenever the user asks to track tasks, create an implementation plan, check what to work on next, see task status, manage dependencies between work items, or close/abandon tasks — even if they don't mention "execution tracking" explicitly.
基于 SOC 职业分类
正在显示 SKILL.md
| name | update-agents-core |
| description | Pull the latest agents-core scaffolding from upstream into the current project. Use when the user wants to update their .agents/ directory, AGENTS.md, or other scaffolding files from the shared upstream repository. |
| license | UNLICENSED |
| allowed-tools | Bash, Read, Grep, Glob |
| metadata | {"short-description":"Update agents scaffolding from upstream","version":"1.3.0","author":"cristos"} |
Pull the latest agents-core scaffolding from the upstream repository into the current project.
npx is the preferred update path for skills. If unavailable, the skill falls back to pure git.agents-upstream git remote is required for the git fallback path. If it is missing, the skill will prompt the user to add it.If the user just wants to know whether updates are available (without applying them), run steps 1–3c of the workflow below and stop after reporting the diff. Tell the user what changed and how to run the full update when ready.
Confirm the working tree is clean (git status). If there are uncommitted changes, stop and ask the user to commit or stash first — the merge may produce conflicts that are easier to resolve on a clean tree.
Check whether npx is available:
command -v npx >/dev/null 2>&1
If available, run:
npx skills add cristoslc/swain --yes
Track the outcome:
Verify the agents-upstream remote exists:
git remote get-url agents-upstream
If it does not exist, tell the user the remote is missing and show them how to add it:
git remote add agents-upstream https://github.com/cristoslc/swain.git
Then ask them to re-invoke the skill after adding it.
Fetch the upstream branch. A regular fetch (not shallow) is needed so git can compute a proper merge base for incremental merges:
git fetch agents-upstream main
Compare the current HEAD to the fetched upstream. Use a two-dot diff (three-dot is unreliable with unrelated histories).
The diff scope depends on whether npx already updated the skills:
git diff HEAD..agents-upstream/main --stat -- AGENTS.md .agents/README.md .agents/AGENTS-SETUP.md import-agents-standalone.sh
git diff HEAD..agents-upstream/main --stat -- .agents/ AGENTS.md import-agents-standalone.sh
If the diff is empty, tell the user they are already up to date and stop.
git merge agents-upstream/main --allow-unrelated-histories --no-edit
Why --allow-unrelated-histories: The initial import into most projects used --squash, which did not record a merge base. The flag is harmless on subsequent merges where a base already exists — git ignores it when histories are already related.
Why no --squash: A real merge commit records the merge base. This means future updates only diff the delta since the last update — not the entire upstream history. This is what makes subsequent merges fast and keeps conflicts scoped to what actually changed.
Migration note: Projects that previously used the squash-based v1.1 workflow will experience one last full-scope merge on their first v1.2 update (because no merge base exists yet). Every update after that will be incremental.
If the merge goes badly and you want to start over:
git merge --abort
This restores the working tree to the pre-merge state. Safe to run at any point before committing.
After the merge, two categories of files need different treatment:
Skills and scaffolding — remote wins
All files under .agents/ (skills, README, AGENTS-SETUP.md, etc.) and the import-agents-standalone.sh script are upstream-owned. If there are conflicts on any of these files, accept the upstream version unconditionally:
# For each conflicted file under .agents/ or import-agents-standalone.sh:
git checkout --theirs <file>
git add <file>
Local projects should not modify files inside .agents/skills/ directly. Project-specific customizations belong in AGENTS.md or in separate skill directories that upstream does not ship.
AGENTS.md — reconcile
AGENTS.md is the one file that lives at the boundary between upstream scaffolding and local project configuration. Upstream may add new routing rules, artifact types, or structural sections, while the local project may have added its own routing rules, custom artifact types, or project-specific workflow notes.
When AGENTS.md has conflicts:
git diff AGENTS.md or read the file to see conflict markers).git add AGENTS.mdIf there are no conflicts (clean merge), no manual reconciliation is needed.
Show the user what was staged:
git diff --cached --stat
Walk through the changes briefly so the user understands what upstream updated.
If the merge completed without conflicts, git already created the merge commit automatically (via --no-edit). Skip this step.
If there were conflicts that required manual resolution, the merge commit is still pending. After resolving and staging all conflicts, ask the user to confirm, then commit:
git commit -m 'chore: update agents-core scaffolding from upstream'