Per federicobartoli's review on #220: the clean-rollback guarantee depended
on "one commit per task" but said nothing about pre-existing uncommitted
changes, which could get absorbed into per-task commits.
- New step: inspect `git status --porcelain` before autonomous execution;
if there are changes outside the expected planning artifacts (SPEC.md,
docs/SPEC.md, spec/*, tasks/plan.md, tasks/todo.md), stop and ask the user
to commit/stash/confirm.
- Commit a generated tasks/plan.md as a single preparatory commit after
approval so it doesn't bleed into the first task.
- Per task, stage only the files that task touched plus its status update
(no blind `git add -A`).
No new between-task gate, so the single-checkpoint design is preserved.
Mirrored across the Claude and Gemini commands.
Per review feedback on #220:
- Drop the `fast` alias (implied skipping verification); keep `auto`
(canonical) and `all`, and state explicitly that autonomous mode is not
faster per task — it only removes human stepping between tasks.
- Tighten spec detection to a closed set of paths (SPEC.md at root,
docs/SPEC.md, or spec/*.md) instead of "SPEC.md (or equivalent)", so a
stray README can't be treated as a spec.
- Define approval as an unambiguous affirmative; hedged responses are not
approval.
- Add resume contract: re-invoke /build auto to pick up the next task.
- Add a high-risk catch-all: anything you can't undo with `git revert`.
- Add dependency fallback: execute in declared plan order when deps aren't
explicit.
Mirrored across the Claude and Gemini commands.
Adds an autonomous mode to the build command: once a spec exists,
`/build auto` (also `all`/`fast`) generates the plan if missing, takes a
single plan approval, then implements every task in dependency order with
full TDD and a commit per task.
Removes the manual stepping between tasks without removing verification —
each task still earns a passing test and its own commit, so any point is a
clean rollback. Auto-pauses for human input on failures, spec ambiguity,
or high-risk/irreversible tasks (auth, destructive migrations, payments,
deletes, deploys, secrets).
- .claude/commands/build.md: two-mode definition (default vs auto)
- .gemini/commands/build.toml: mirrored for Gemini CLI
- README.md, docs/getting-started.md: document the new mode
Replace relative path source ("./") with the canonical GitHub source
object format ({ "source": "github", "repo": "owner/repo" }).
This resolves schema validation errors seen in Claude CLI v2.1.156+
where the relative path format caused 'Invalid input' errors in
strict marketplace JSON validators.
Also adds:
- $schema reference for editor autocomplete and validation
- top-level description field (was nested under metadata)
- owner URL, homepage, license, and keywords fields
Closes#212
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The hard-coded `"version": "1.0.0"` in .claude-plugin/plugin.json
pins every install at the snapshot taken when that string was first
set. Per the Claude Code marketplace docs:
> Setting `version` pins the plugin. If `plugin.json` declares
> `"version": "1.0.0"`, pushing new commits without changing that
> string does nothing for existing users, because Claude Code sees
> the same version and keeps the cached copy. Bump the field on
> every release, or omit it to use the commit SHA.
> https://code.claude.com/docs/en/plugin-marketplaces#version-resolution-and-release-channels
Two consequences observed in practice:
1. Users who ran `/plugin install agent-skills@addy-agent-skills`
weeks ago do not receive the 37 commits landed on main since
the 0.6.0 release (including the new `doubt-driven-development`
and `interview-me` skills, plus several frontmatter and
cross-reference fixes). `claude plugin update` reports no
change because the cached and remote `version` strings match.
2. The release tags `0.5.0` and `0.6.0` have shipped with no
corresponding bump in `plugin.json`, so the existing release
cadence already does not feed Claude Code's update mechanism.
Dropping the `version` field switches the plugin to commit-SHA
versioning, which the same docs explicitly recommend:
> If you omit `version` and host this marketplace in git, every
> commit automatically counts as a new version. This is the
> simplest setup for internal or actively-developed plugins.
Given the repo's commit cadence (37 commits / ~3 weeks between
0.6.0 and HEAD) and its content profile (mostly markdown SKILL.md
files with low per-commit breakage risk), commit-SHA versioning
fits this project better than manual semver bumps. Git tags and
GitHub Releases remain available as editorial milestones for
changelog and announcements; they just no longer need to drive
the update mechanism.
Closes#145.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
A bare confidence percentage gives no signal about what's blocking clarity.
When confidence is below ~70%, the skill now requires a one-line reason on
the same CONFIDENCE line so the user knows exactly what the interview still
needs to surface.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
GitHub Copilot requires custom agent files to be named *.agent.md.
The previous instructions copied them as *.md, which Copilot silently
ignores, so agents would never be available in Copilot Chat.
Changes:
- Rename all three cp commands to use the .agent.md suffix
- Add mkdir -p .github/agents (was missing, cp would have failed)
- Add a callout block explaining the naming requirement with a link
to the VS Code custom agents docs
- Update section heading from "(agents.md)" to "(*.agent.md)"
Fixes#179
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Disambiguate the using-agent-skills flowchart so interview-me and
idea-refine no longer match the same condition top-to-bottom
("Don't know what you want yet?" vs "Have a rough concept, need
variants?").
- Add "grill me" to interview-me's frontmatter description and the
When to Use trigger list (it was already mentioned in README).
- Reorder sections: Example and Interaction with Other Skills now
precede Common Rationalizations and Red Flags, so the persuasive
example lands before the rationalization table.
Per review by @nucliweb on #164.
idea-refine: rewrite the description to follow the repository's
documented "Use when..." trigger convention (AGENTS.md). The previous
description was 135 characters, redundant, and used the skill name
itself as the only trigger phrase, making it the only skill not aligned
with how the other 21 skills self-describe.
browser-testing-with-devtools: surface the Chrome DevTools MCP
dependency at the top of the description and explicitly note the
requirement, so agents that route by MCP availability can detect it
without parsing the body.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Adds interview-me, a skill that sits upstream of every other
Define-phase skill. Trigger: an underspecified ask, or the user
explicitly invoking the skill ("interview me", "are we sure?",
"stress-test my thinking").
The gap it fills: idea-refine generates variations from a raw idea,
spec-driven-development writes requirements down once you know them,
and doubt-driven-development stress-tests a plan after you've drafted
one. None of those cover the moment before — when the user has said
"build me X" and X is the conventional answer rather than what they
actually want. This skill is the structured interview that surfaces
the gap before any plan, spec, or code exists.
Distinctive mechanics:
- Confidence numbers as forcing function (Step 1 commits to 0-100%)
- Q + GUESS format: every question carries the agent's hypothesis
- One question at a time, never batched
- Checkable stop condition: "Can I predict the user's reaction to the
next three questions I would ask?"
- Six-line restate template ending in explicit yes
- Names the four bad yeses ("whatever you think", "sounds good",
"sure let's go", silence) with specific re-prompts
Registers the skill in:
- CLAUDE.md (Define phase, also adding idea-refine which was missing)
- README.md (skills table, count, project tree)
- skills/using-agent-skills/SKILL.md (flowchart, lifecycle sequence,
quick reference table)
The github source object form `{ "source": "github", "repo": "..." }`
fails to install on Claude Code v2.1.112 with:
fatal: repository 'https://github.com/:addyosmani/agent-skills.git/' not found
The `:owner/:repo` template is not interpolated, producing a malformed
URL. Since the plugin lives in the same repo as the marketplace, switch
to a relative path (`./`) which sidesteps the github source path
entirely and works for all marketplace add transports (github, https,
ssh, local).
CI workflow `.github/workflows/test-plugin-install.yml` already uses
`claude plugin marketplace add ./`, so the change is exercised on every
push.
Resolves README.md conflict by taking main's wording ("entry points.
The pack includes 21 skills total") and Meta section, both landed in
PR #142 while this PR was open. The doubt-driven-development row in
the Build table and the directory tree entry auto-merged cleanly.
Folds in the safety and consistency findings surfaced by running
the skill against itself in two cycles (single-model adversarial
review + cross-model verification via Codex).
Cross-model escalation is now offered in every interactive cycle,
and the CLI invocation path uses a read-only sandbox with prompts
piped through stdin to neutralize shell-escaping and prompt-injection
risks (verified against Codex 0.128.0 and Gemini 0.41.2 locally).
Internal consistency fixes from the adversarial self-review: the
adversarial prompt explicitly overrides persona templates; the
persona roster is referenced rather than duplicated; the Step 2
'Claim' bullet is renamed Assertion to disambiguate from the Step 1
CLAIM block; the manual fallback in Loading Constraints is labeled
as a degraded last-resort path; the forward reference to Step 3 is
anchored; the Verification checklist no longer contains an item not
derivable from the Process; and using-agent-skills's Lifecycle
Sequence now includes the skill at position 7.
Codifies adversarial fresh-context review as an in-flight development
posture, distinct from /review (post-hoc PR-level verdict). Every
non-trivial decision passes through a 5-step cycle (CLAIM → EXTRACT →
DOUBT → RECONCILE → STOP) before standing.
Cross-model escalation is described as a contract, not as hardcoded
CLI invocations — the skill instructs the agent to ask the user which
external tool to use and how, since CLI syntax (Gemini, Codex, etc.)
changes and varies by environment.
Updates README skill listing (count, Build table, project tree),
CLAUDE.md Skills by Phase, and using-agent-skills flowchart + Quick
Reference for discoverability parity with the existing skills.
The Claude Code plugin schema accepts string|array for the `skills`
field; passing a directory path auto-discovers every `<name>/SKILL.md`
beneath it (per https://code.claude.com/docs/en/plugins-reference,
which lists `"./custom/skills/"` as a valid example).
Switching `skills` from a 21-element array to `"./skills"` keeps the
fix for #112 (skills are still explicitly declared, so discovery is
not suppressed) while removing the maintenance burden — adding a new
skill no longer requires also editing this manifest.
`agents` stays as an explicit array because `./agents/` contains
`README.md`, which would be picked up as a malformed agent if the
directory form were used here.
Unify the framing across the verification note, rationalization row,
and red flag entry in both incremental-implementation and
test-driven-development skills. The previous wording mixed "once per
increment" (correct) with "no additional value after success" (only
true if nothing has changed), which an agent could read as "skip
verification entirely after one success."
The unified rule: after a successful run, don't repeat the same
command unless the code has changed since.
Addy Osmani