Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/marcusgoll/Spec-Flownpx agentmods add skills/marcusgoll/spec-flow/workflow-detectionWrote 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.
[](https://agentmods.dev/skills/marcusgoll/spec-flow/workflow-detection)<a href="https://agentmods.dev/skills/marcusgoll/spec-flow/workflow-detection"><img src="https://agentmods.dev/badge/skills/marcusgoll/spec-flow/workflow-detection.svg" alt="Measured on agentmods" height="20"></a>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.00000 | $0.01820 |
| Opus 5 | $0.00000 | $0.00910 |
| Sonnet 5 | $0.00000 | $0.00364 |
| Haiku 4.5 | $0.00000 | $0.00182 |
Grade A, and why
workflow-detection 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 4d 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.
How it starts
The opening of the file, as written. The whole thing — 237 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Workflow Detection Skill
Provides centralized workflow type detection for all phase and deployment commands.
Purpose
Eliminates 50+ lines of duplicated detection code across 44 commands by providing a single source of truth for workflow type detection.
Quick Reference
# Bash (Linux/Mac/Git Bash)
WORKFLOW_INFO=$(bash .spec-flow/scripts/utils/detect-workflow-paths.sh)
# PowerShell (Windows)
$workflowInfo = pwsh -File .spec-flow/scripts/utils/detect-workflow-paths.ps1
Output Format
Returns JSON with workflow information:
{
"type": "epic",
"base_dir": "epics",
"slug": "001-auth-system",
"branch": "epic/001-auth-system",
"source": "files",
"is_worktree": false
}
Fields
| Field | Values | Description |
|---|---|---|
type |
epic, feature, unknown |
Workflow type |
base_dir |
epics, specs, unknown |
Base directory for artifacts |
slug |
string | Feature/epic identifier (e.g., 001-auth-system) |
branch |
string | Current git branch |
source |
files, branch, state, none |
How type was detected |
is_worktree |
boolean | Whether in a git worktree |
Worktree Fields (when is_worktree: true)
| Field | Description |
|---|---|
worktree_path |
Absolute path to worktree |
worktree_type |
epic, feature, or unknown |
worktree_slug |
Extracted slug from worktree path |
Detection Priority
-
Workspace Files (highest priority)
- Checks for
epics/*/epic-spec.md→ Epic workflow - Checks for
specs/*/spec.md→ Feature workflow
- Checks for
-
Git Branch Pattern
- Branch matches
epic/*→ Epic workflow - Branch matches
feature/*→ Feature workflow
- Branch matches
-
Workflow State
- Reads
workflow_typefromstate.yaml
- Reads
-
User Prompt (detection failed)
- Returns
type: unknownwith exit code 1 - Command should use AskUserQuestion as fallback
- Returns
Usage in Commands
Standard Pattern (Recommended)
# In command's <process> section:
### Step 0: Workflow Type Detection
**Detect workflow type using centralized utility:**
<bash>
# Cross-platform detection
if command -v bash >/dev/null 2>&1; then
WORKFLOW_INFO=$(bash .spec-flow/scripts/utils/detect-workflow-paths.sh 2>/dev/null)
elif command -v pwsh >/dev/null 2>&1; then
WORKFLOW_INFO=$(pwsh -File .spec-flow/scripts/utils/detect-workflow-paths.ps1 2>/dev/null)
fi
if [ -n "$WORKFLOW_INFO" ]; then
WORKFLOW_TYPE=$(echo "$WORKFLOW_INFO" | grep -o '"type":"[^"]*"' | cut -d'"' -f4)
BASE_DIR=$(echo "$WORKFLOW_INFO" | grep -o '"base_dir":"[^"]*"' | cut -d'"' -f4)
SLUG=$(echo "$WORKFLOW_INFO" | grep -o '"slug":"[^"]*"' | cut -d'"' -f4)
fi
</bash>
**If detection fails, prompt user:**
Use AskUserQuestion with options: "Epic workflow", "Feature workflow"
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.
- 4d ago First seen · 237 lines · 0 tokens per session scan A b21b61123274
workflow-detection is a skill published in the GitHub repository marcusgoll/Spec-Flow (92 stars, last pushed 4mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,820 tokens. 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-09-03.
Other skills, from other repositories
create-github-issue
Create GitHub issues using GitHub CLI with support for templates, labels, assignees, milestones, and draft issues. Use when the user asks to create a GitHub issue, file a bug report, submit a feature request, or open an issue in a GitHub repository.
catchup
Summarize and review what changed while you were away. Use after a weekend, vacation, or flight to check missed PRs, git commits, Linear tickets, and meetings — one prioritized brief, not a firehose.
machinist
Use Machinist to create, assign, monitor, and resume software tasks. Use when a coding agent needs to work with Machinist, its GitHub issue workflow, lifecycle labels, direct runs, or managed queue.
team-release
Orchestrate the release team: coordinates release-manager, qa-lead, devops-engineer, and producer to execute a release from candidate to deployment.
linear-cli
Use when the user wants to list, view, start, create, or update Linear issues from the terminal via schpet/linear-cli, including setup, auth, repo config, and safe read/write boundaries.
magpie-setup-override-upstream
Walk an adopter through promoting a local .apache-magpie-overrides/ .md file into a PR against apache/magpie. After the PR merges and the adopter runs /magpie-setup upgrade, the override file is no longer needed and the skill prompts for its removal.