What is feature-workflow?

A command for implementing a feature from a written technical specification, or ТЗ, on its feature branch. A feature branch is a separate line of project changes that can later be merged into the main branch.

Use it to locate an unfinished specification under docs and implement it end to end. You can provide a specification slug, branch name, or path, or let the command scan for a suitable one.

It finds unfinished specifications while avoiding general design documents and work whose branches are gone or already merged.

How HelgDemidov/refigure configures Claude Code

Reuse

Borrowing it

Nothing to install: this file belongs to HelgDemidov/refigure. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.

Copy the file

curl -O https://raw.githubusercontent.com/HelgDemidov/refigure/main/.claude/commands/feature-workflow.md

Clone the repo

git clone --depth 1 https://github.com/HelgDemidov/refigure

Made for: Claude Code.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

README.md

[![agentmods](https://agentmods.dev/badge/commands/helgdemidov/refigure/feature-workflow/github.svg)](https://agentmods.dev/commands/helgdemidov/refigure/feature-workflow)

Your own site

<a href="https://agentmods.dev/commands/helgdemidov/refigure/feature-workflow"><img src="https://agentmods.dev/badge/commands/helgdemidov/refigure/feature-workflow/github.svg" alt="Measured on agentmods" height="20"></a>

Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.

Your own site · 80×15

<a href="https://agentmods.dev/commands/helgdemidov/refigure/feature-workflow"><img src="https://agentmods.dev/badge/commands/helgdemidov/refigure/feature-workflow.svg" alt="Reviewed on agentmods" width="80" height="20"></a>

Per session 18 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.

When invoked 1,086 The whole file, excluding the scripts and references it only reads on demand.

Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.

Origin original No closer match found in the catalogue.

Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

Model	Per session	Once invoked
Fable 5.1	$0.00018	$0.01086
Opus 5.5	$0.00007	$0.00434
Sonnet 5.5	$0.00004	$0.00217
Haiku 4.5	$0.00002	$0.00109

Measured 2mo ago against content hash 72a45df38b9b, method: parsed. Prices are Anthropic first-party input rates as of 2026-10-07, from the pricing page.

Security

Grade A, and why

feature-workflow scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2mo ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.claude/commands/feature-workflow.md · 44 lines

How it starts

The opening of the file, as written. The whole thing — 44 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Pick up a spec (ТЗ) drafted by /tech-spec that hasn't been implemented yet, and implement it end-to-end on its feature branch.

Step 1 — Find the target spec

If invoked with an argument (slug, branch name, or path), use that spec directly.

Otherwise scan docs/**/*.md (recursive — specs live under a docs/<category>/<slug>/ subdirectory, not flat, since 2026-08-05) for specs that are BOTH: missing a ## Статус выполнения section, AND whose declared branch (the **Ветка:** line) still exists — local or origin/ — and isn't merged into main. The **Ветка:** line is what distinguishes an actual spec from a general design doc (like docs/project-meta/v1-scope-and-api-design/v1-scope-and-api-design-2026-08-04.md), which has none. This two-signal check avoids false positives on old completed specs whose status section was never backfilled.

This is a plain filesystem scan (unaffected by docs/ being gitignored — untracked files are still on disk), but it only ever finds specs written by /tech-spec in THIS local checkout: since 2026-08-19 the spec file itself is never committed or pushed, so a spec drafted on a different machine, or before a fresh clone, simply isn't there to find.

Zero matches → report nothing pending, stop.
One match → proceed with it.
Multiple matches → ask the user which one (AskUserQuestion) — don't guess.

Step 2 — Enter the branch

git fetch origin, then check out the spec's branch locally. /tech-spec Step 7 creates this branch but deliberately does NOT push it (no commit exists yet to push) — expect a local-only branch here, not an origin/<branch> to track. It gets pushed for the first time as part of Step 4/5 below, once real work lands on it.

Step 3 — Build the task list

Read the spec's "План коммитов/PR" section and turn it into a task list in this conversation, one task per planned commit.

If the spec has no commit breakdown (only a final-PR description), split the work into commits yourself — one coherent, independently buildable unit of change per commit (natural seams: a single module ported, its tests, the public-API wiring, docs).

Read the full file on GitHub · 44 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

2mo ago First seen · 44 lines · 18 tokens per session scan A 72a45df38b9b

Subscribe to this mod's changes

feature-workflow is a command published in the GitHub repository HelgDemidov/refigure (0 stars, last pushed 3d ago), licensed Apache-2.0. It adds 18 tokens to every session and 1,086 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Git and workflow Planning chart-extraction converter document-conversion docx markdown mermaid

feature-workflow next to 6 commands from other repositories
Mod	Type	Stars	Last push	Licence	Scan	Tokens	Works with
feature-workflowHelgDemidov/refigure	Command	0	3d ago	Apache-2.0	A	18	Claude Code
worktree-startopen-agreements/open-agreements	Command	62	8d ago	Apache-2.0	A	0	Claude Code
index-cmdeduardoabreu81/livewiki	Command	1	1mo ago	MIT	A	0	Claude Code
changelogmertjane/awesome-claude-commands	Command	2	8mo ago	MIT	A	32	Claude Code
commit-msgmertjane/awesome-claude-commands	Command	2	8mo ago	MIT	A	28	Claude Code
pr-descmertjane/awesome-claude-commands	Command	2	8mo ago	MIT	A	34	Claude Code
checklistgithub/spec-kit	Command	148k	yesterday	MIT	A	13	Claude Code

refigure: Command for Claude Code