process-tiering skillA
process-tiering is agent-read markdown (skill) from vmobifystudio/app-dev-team: Use when sizing a ticket at planning time, and when calibrating how much review ceremony a diff needs. Maps the studio's existing XS/S/M/L/XL estimate to how much process a ticket carries — a one-line fix should not walk the same PRD-to-impl-spec pipeline as a multi-screen feature. Triggers from sprint-planner (at ticket creation) and code-reviewer (at review time)..
Indexed from public GitHub and served as immutable, content-addressed versions. Install it pinned to an exact SHA-256 with the mdr CLI, and every file is verified against the hash recorded here before it reaches your agent. The deterministic audit below grades the latest version, and the same file always earns the same grade.
What the file says
# Process tiering Mined from studying `rsmdt/the-startup` (tiered Direct/Standard/Factory dispatch) and `olehsvyrydov/AI-development-team` (`change_classes` → `track` mapping) — both scale process weight to task size instead of running the same ceremony on everything. This studio already has the input those systems built new fields for: `cpo`'s backlog already estimates every item **XS/S/M/L/XL** (`agents/cpo.md`), and `board.mjs add --estimate` already carries it onto the ticket. This skill is the mapping from that existing field to how much process the ticket actually needs — no new field, no new ticket state. ## The tiers | Estimate | Track | What changes | |---|---|---| | XS | **floor** | `tech-lead` may write the impl spec as a single paragraph naming the file and the change — no separate architecture note. `code-reviewer` still runs the full review, but §4b's on-device-measurement and round-trip-execution requirement applies **only if** the change touches a value a user supplies, sees, or is told (§4b's own trigger condition, unchanged) — most XS tickets don't. | …
Read the whole file at its exact version.
How to install
mdr add vmobifystudio/app-dev-team/process-tiering@git:20260810.958b327mdr add vmobifystudio/app-dev-team/process-tiering@sha256:57294bb0fa9c4f1dPin to a label to follow the author's releases, or to a sha256 to freeze the exact bytes forever. Either way the resolved hash is written to mdr.lock, and mdr install reproduces it on any machine.
[](https://markdownregistry.com/a/art_i7mu4n3hgf265s6a)
1 badge views in 30 days
Versions
Audit of the latest version
- pass: Frontmatter block present
- pass: Frontmatter declares a name
- pass: Frontmatter declares a description
- pass: Size between 200 bytes and 200 KB (4450 bytes)
- pass: No zero-width or bidi control characters
- pass: No instruction hidden inside an HTML comment
- pass: No link to an exfiltration or paste host
- pass: No credential-shaped string
- pass: No instruction to send local credentials anywhere
- pass: No text hidden with inline styles
- pass: No prompt-injection phrasing
- pass: No curl or wget piped into a shell
- pass: No recursive delete of root, home or parent
- pass: No instruction to read or print local credentials
- pass: No base64 blob over 200 characters
- pass: No link to a raw IP address
- pass: No script tag
Source
vmobifystudio/app-dev-team · 4 stars · license MIT · pushed 2026-09-19 · branch main
API
GET https://markdownregistry.com/api/v1/artifacts/art_i7mu4n3hgf265s6a GET https://markdownregistry.com/api/v1/resolve?ref=vmobifystudio/app-dev-team/process-tiering GET https://markdownregistry.com/api/v1/blob/57294bb0fa9c4f1d086adcf190d8baa40fccf2d4b73ef6e80f6b46756f59b246
Your agent does the legwork. You hear about the deals worth your word. Hand yours the standing instructions at modelranch.com and it joins the network that reads files like this one.