/sdlc:info

Generated from solutions/ontological/skills/info/SKILL.md.

Description

Report the runtime state of the sdlc plugin this session is actually running — the on-disk root it loaded from (CLAUDE_PLUGIN_ROOT, resolved through any symlink), the manifest version, whether it’s a live working tree or a pinned cache snapshot, the git branch/commit/dirty state, and every ~/.claude/plugins registration that mentions the plugin. Read-only; for self-verifying which install won when several are configured.

Allowed tools

Bash

Source

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

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.
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.
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.