agentleFS
Sign inStart free
rlajousrlajous/claude-code-commands/skills/status/SKILL.md

status

Skill30 starsChanged 3 months agoMITView on GitHub

Show where you are in the git-workflow pipeline (branch, ticket, commits, PR, release, QA) and what the recommended next step is. Use when the user asks "where am I", "what's the status", "what's next", "status of this branch/PR/release", or wants a quick summary of the current workflow state.

177 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use off, list and 9 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • StakeholderSenseiSkill

    off

    Disable polygraph for this repo (user-only escape hatch; all hooks no-op)

    Also in 4 projects that use this

  • SuShuhengSkill

    list

    Use when checking obshare-cli upload history, finding document tokens, or reviewing previous upload URLs and permission snapshots.

    Also in 8 projects that use this

  • kennethleungtySkill

    pause

    Pause — stop the music (alias for /stop)

    Also in 6 projects that use this

  • codebycoreySkill

    new

    Start a new change with a proposal. Use when starting a feature, creating a proposal, or beginning planned work.

    Also in 7 projects that use this

  • michaelenglandSkill

    import

    This skill should be used when the user wants to import an existing .pptx file into deckwright, bring in a PowerPoint that was created outside this tool, reverse-engineer a presentation for editing, or invoke /deckwright:import. Converts a .pptx into a PptxGenJS generation script so it can be edited and regenerated through the deckwright pipeline.

    Also in 5 projects that use this

  • genomewalkerSkill

    resume

    Resume a thread by loading its ~800-token context capsule

    Also in 15 projects that use this

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 1 is distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 146 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read the durable workflow context if present:

    line 20
  2. Very specific:

    If a canonical file is absent, read its matching legacy .claude/ fallback as defined in the compatibility reference.

    line 25
  3. Very specific:

    If gh is available and authenticated, also gather (skip gracefully on failure):

    line 35
  4. Very specific:

    If --html was passed, resolve {SKILL_DIR} to the absolute, physical directory containing this loaded SKILL.md, then generate a …

    line 83

“Common” is measured: kept by at least 6 in 10 of the 146 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Cross-runtime: follow runtime compatibility for invocation, delegation, configuration precedence, state paths, and permissions.

You are reporting the current position in the git-workflow pipeline and the recommended next step. This is read-only — never modify Git state, never create branches/commits/PRs. Follow each step in order.

Step 1: Parse Arguments

  • --html → also generate a self-contained HTML status report (see Step 6).

Step 2: Load Context

Read the durable workflow context if present:

  • .git-workflow/pr-context.json — ticket id/title, branch, type, timestamps written by /start, /tdd, /commit.
  • .git-workflow/config.yaml — workflow.developmentBranch/productionBranch, issue tracker.

If a canonical file is absent, read its matching legacy .claude/ fallback as defined in the compatibility reference. If neither form exists, fall back to live Git/GitHub state only.

Step 3: Gather Live State (read-only)

git rev-parse --abbrev-ref HEAD                 # current branch
git status --porcelain                          # uncommitted changes?
git log --oneline origin/{devBranch}..HEAD      # commits ahead of the dev branch

If gh is available and authenticated, also gather (skip gracefully on failure):

gh pr view --json number,title,state,reviewDecision,statusCheckRollup,url   # PR for current branch, if any
gh release list --limit 1                                                     # latest release

Step 4: Determine Pipeline Position

Infer which stage the work is in, in this order:

SignalStage
On dev/prod branch, clean treeIdle — no active feature
Feature branch, no commits aheadStarted — branch created, nothing committed
Feature branch, uncommitted changesIn progress — changes not yet committed
Commits ahead, no PRCommitted — ready to open a PR
PR open, checks pending/failingIn review (CI/{state})
PR open, CHANGES_REQUESTEDIn review — changes requested
PR open, APPROVEDApproved — ready to merge
On a release/* branchReleasing

Step 5: Print the Status Report

Output a compact, scannable summary and an explicit next step:

Workflow status
  Branch:   fix/proj-123-login-timeout  (3 commits ahead of staging)
  Ticket:   PROJ-123 — Fix login timeout
  Changes:  clean working tree
  PR:       #42 (OPEN, CI passing, review required) — https://github.com/...
  Stage:    In review

  Next: wait for review, or run /review 42 to self-review before requesting.

Map the stage to the recommended next command:

  • Idle → /start to begin a feature.
  • Started / In progress → make changes, then /commit.
  • Committed → /finish to open a PR.
  • In review → /review <pr> to self-review; address feedback.
  • Approved → merge, then /release when ready.
  • Releasing → after merge, /release-notes then /sync.

Step 6: HTML Report (only with --html)

If --html was passed, resolve {SKILL_DIR} to the absolute, physical directory containing this loaded SKILL.md, then generate a self-contained HTML status page with its bundled helper:

mkdir -p .git-workflow
node "{SKILL_DIR}/scripts/status-report.mjs" > .git-workflow/status.html

The script gathers the same git/gh state as JSON and injects it into the skill-local assets/status-template.html. If the loaded skill path is unavailable, use PLUGIN_ROOT, then CLAUDE_PLUGIN_ROOT, only to locate skills/status/SKILL.md; verify the helper exists and never fall back to /scripts. Tell the user the file path (.git-workflow/status.html) and that it is a single self-contained file they can open in a browser. If Node is unavailable, skip the HTML and print the text report only.

Error Handling

ScenarioAction
Not a git repositoryReport that and stop
gh unavailable / not authenticatedSkip PR/release sections, note it, show git-only status
No .pr-context.jsonUse live Git state; note context is not being tracked
Node unavailable (with --html)Print the text report, skip HTML generation

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free