Borrowing it
Nothing to install: this file belongs to devemberx/mcp-server-polarion. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/devemberx/mcp-server-polarion/main/.claude/skills/dev-pipeline/SKILL.mdgit clone --depth 1 https://github.com/devemberx/mcp-server-polarionWrote 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/devemberx/mcp-server-polarion/dev-pipeline)<a href="https://agentmods.dev/skills/devemberx/mcp-server-polarion/dev-pipeline"><img src="https://agentmods.dev/badge/skills/devemberx/mcp-server-polarion/dev-pipeline/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.
<a href="https://agentmods.dev/skills/devemberx/mcp-server-polarion/dev-pipeline"><img src="https://agentmods.dev/badge/skills/devemberx/mcp-server-polarion/dev-pipeline.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00161 | $0.05314 |
| Opus 5 | $0.00081 | $0.02657 |
| Sonnet 5 | $0.00032 | $0.01063 |
| Haiku 4.5 | $0.00016 | $0.00531 |
Grade A, and why
dev-pipeline 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 9d 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 — 346 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Dev Pipeline
Encode the sequence that shipped list_test_records (PR #170): worktree → spec →
plan → TDD implement → gates → simplify → review loop → ship. Main session is the
orchestrator: it sequences stages, holds user approvals, spawns the stage
agents, and merges their reports. Subagents never spawn other subagents
(hard rule here — every paraphrase hop loses information).
0.Worktree → 1.Spec →(approve)→ 2.Plan →(approve)→ 3.Implement(TDD) → 4.Gates ◄─┐
│ │ (re-run)
(5.Simplify, first pass) ▼ │
7.Fix ◄─(findings)─ 6.Review │
│ │(clean) │
└────────────────────┼───────────┘
▼
8.Ship
Data handoff — how stages talk
Subagents share no memory and no conversation history. Three channels only:
-
Prompt in — a subagent sees exactly what you put in its
promptplus its own agent definition. Always pass the handoff-file paths and the task excerpt; never assume it "knows" what was discussed. -
Report out — its final message returns as the tool result. Each agent definition fixes a report format; the report is the interface. Relay what matters to the user — they don't see tool results.
-
Files — the durable channel. This pipeline writes its artifacts to
.pipeline/in the worktree (gitignored, never committed):File Written by Read by .pipeline/spec.mdorchestrator (Stage 1, draft before approval; approved via file link — single copy; approval freezes it) pattern-scout, pipeline-implementer, pipeline-reviewer .pipeline/plan.mdorchestrator (Stage 2, approved via file link — single copy; approval freezes it) pipeline-implementer, pipeline-reviewer .pipeline/review-round-N.mdorchestrator (Stage 6, reviewer report pasted verbatim) pipeline-implementer (Stage 7), user on escalation .pipeline/followups.mdorchestrator (Stage 6, FOLLOW-UPS + unfixed LOW accumulated per round, deduped) orchestrator (Stage 8 issue export)
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 9d ago First seen · 346 lines · 161 tokens per session scan A 4d0c3fef2aee
dev-pipeline is a skill published in the GitHub repository devemberx/mcp-server-polarion (13 stars, last pushed 7d ago), licensed MIT. It adds 161 tokens to every session and 5,314 once invoked, about $0.0008 per session on Opus 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-30.
Other skills, from other repositories
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code.
systematic-debugging
4-phase root cause debugging: understand bugs before fixing.
test-driven-development
TDD: enforce RED-GREEN-REFACTOR, tests before code.
taiyi-dev
A software-development stage that implements planned tasks using test-driven development, or TDD: write a failing test, make it pass, then improve the code. It checks the task plan, dependencies, file boundaries, and required completion evidence.
contract
Outcome-driven Cortex function development — declares a behavioral contract before generation begins, enforces evidence-tiered proof before $ship, and defends against the self-oracle evaluation failure mode.
spec-driven-development
Design and run a Spec-Driven Development (SDD) pipeline for AI software factories — where structured specifications are the input, AI agents generate the code, and quality gates enforce correctness at each phase: SPECIFY → DECOMPOSE → IMPLEMENT → VERIFY → DELIVER. Use when building or refining a spec-driven pipeline…