/sdlc:info

Report which copy of the sdlc plugin this session loaded and what state it's
in, so the user can self-verify after a /reload-plugins or an install change.

Usage:

• /sdlc:info — print a human-readable report of the loaded plugin's state.
• /sdlc:info --json — same data as a JSON object (for piping / scripting).

The authoritative signal is CLAUDE_PLUGIN_ROOT, which Claude Code sets to
the on-disk root of the running plugin component. The op resolves it through
symlinks, reads the manifest version, inspects git state of the resolved
tree, and cross-references the ~/.claude/plugins/ registration records.

Steps

1. Run the info op from anywhere (it does not depend on the project
   working directory):

   ${CLAUDE_PLUGIN_ROOT}/cli/sdlc plugin info

   Append --json if the user invoked the skill with --json.

2. Read the op output and present it to the user, leading with the
   answers that matter for self-verification:

   • Loaded from — the resolved on-disk root. If it came from
     CLAUDE_PLUGIN_ROOT (the normal case) it's authoritative; if the op
     printed the ⚠ fallback warning (env var unset), say so and treat the
     path as "the source tree this file lives in," not a confirmed answer.
   • Version and Liveness — manifest version, and whether it's a
     directory (live working tree) (edits show up after /reload-plugins)
     or a snapshot (no git working tree) (a pinned cache copy).
   • Git — branch, short SHA, and -dirty flag of the resolved tree, plus
     git describe when a tag is reachable.
   • Tag check — whether the manifest version is actually backed by a git
     tag (v<version> or bare <version>) and, if so, how far HEAD has
     drifted from that tag's commit: exact, N ahead, N behind, or
     diverged. For a live directory source this is the real answer to "is
     this the 0.1.1 release, or 0.1.1 plus unreleased commits?" If the
     version is untagged (or the repo has no tags), say so plainly — the
     version label can't be verified against a commit.

3. If the report lists more than one registration (e.g. both a user
   scope and a project scope, or two marketplaces), surface that explicitly:
   note which scopes/marketplaces are configured and which version each
   resolves to, so a divergence (user-level on one version, project-level on
   another) is obvious. Each registration also reports how far the commit
   recorded at install time has drifted from the live HEAD, so a stale install
   record is visible. The final INFO-OK … marker line summarizes the
   loaded root, version, source kind, git state, and the tag verdict (tag=)
   in one line for quick copy/paste.

Notes

• Read-only. Reports state. Changing what's installed is /plugin's job.
• directory sources are unversioned — they always load the current
  on-disk tree, so the manifest version there is metadata; the git
  branch/SHA is the real "what state" signal. Pinned versions come from
  github/git marketplace sources, which the report shows as snapshot.
• The version label is verified against a git tag. The report looks up the
  matching git tag and quantifies HEAD's drift from it. The tag= field in the
  INFO-OK marker carries the machine-readable verdict: vX@sha=HEAD (at the
  release), vX@sha+N (N unreleased commits past it), vX@sha+N-M (diverged),
  or none (untagged / unverifiable).
• Fallback caveat. Run outside a plugin context (e.g. …/cli/sdlc plugin info by
  hand with no env), CLAUDE_PLUGIN_ROOT is unset and the op derives the root from its own file
  location — that reports the source tree it lives in, not the plugin the session loaded. Invoke via
  /sdlc:info for the authoritative answer.
• Registration cross-reference reads ~/.claude/plugins/installed_plugins.json
  and known_marketplaces.json (honouring CLAUDE_HOME), the same records
  sdlc plugin resolve resolves against.