Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/griddynamics/rosetta/coding-flowgit clone --depth 1 https://github.com/griddynamics/rosettaWrote 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/commands/griddynamics/rosetta/coding-flow)<a href="https://agentmods.dev/commands/griddynamics/rosetta/coding-flow"><img src="https://agentmods.dev/badge/commands/griddynamics/rosetta/coding-flow.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 | $0.00024 | $0.02236 |
| Opus 5 | $0.00012 | $0.01118 |
| Sonnet 5 | $0.00005 | $0.00447 |
| Haiku 4.5 | $0.00002 | $0.00224 |
Grade A, and why
coding-flow 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 today.
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 — 144 lines — stays where its author put it; the contents beside it link to each section on GitHub.
<coding_flow>
<description_and_purpose>
Problem: Unstructured coding leads to scope drift, missing validation, autonomous runaway, and misaligned deliverables. Solution: Sequential workflow with reviewer gates, HITL gates, subagent delegation, and skill-driven execution scaled per Request size classification. Validation: Each phase produces verifiable outputs; reviewer catches issues before user; HITL gates prevent autonomous runaway; final validation confirms implementation matches approved intent. Lightweight variant: a single architect pass produces discovery, design, specs, and plan; one reviewer gate and one HITL gate approve all of it before implementation.
</description_and_purpose>
<workflow_phases>
- All Rosetta prep steps MUST be FULLY completed
- MUST USE SKILL
load-project-context(required: all),orchestration(all except trivial),hitl(all, unlessNo HITLorFully Autonomous) - MUST ALWAYS use todo tasks ledger, ASAP. Phases are sequential. Independent tasks can run in parallel.
- No rush, take your time, MUST FOLLOW WORKFLOW ENTIRELY, no skipping, if in doubt - select the safest / longest path, no deviation from the workflow is allowed
- When debugging is needed, INVOKE SUBAGENT
engineerwithdebuggingskill to save LLM context - INVOKE SUBAGENT
executorfor building, running tests, installing packages, and similar mechanical actions. - MUST just-in-time load each phase's skills
- If workflow is for REQUIREMENTS, MUST USE SKILL
requirements-useand LOAD all affected requirements. Use refs to requirements for subagents. - If
/goalis set repeat phases 4-7 postponing final_validation until goal is met. - If migrate/modernize: implementation phase MUST use tiny batches ONLY (1-3 files), never bulk-read (other phases may); specs/plan enforce; FS-copy RECOMMENDED; no behavior change/new code; mirror source; subagents same; REQUIRED TO log started/completed; Use impl subagents like MAP-REDUCE;
- Run architect subagent with required model in the background and consult with it if already supported or prefer advisor if already available
- Coding workflow state MUST be saved to
agents/TEMP/<FEATURE>/coding-flow-state.mdfile. - If context already contains request for TDD => implement properly red and green adjusting this workflow, including by moving execution of phases
testsandreview_teststo be afteruser_review_designand beforeimplementation.
<solution_design phase="1" applies="ALL" subagent="architect" role="Architect producing discovery, design, specs, and plan in one pass" subagent_required_model="GPT-5.6 Sol, Claude Opus 5, Gemini 3.7 Flash">
Execute strongly in the specified order. A step MUST NOT start before the previous step is complete.
- Step 1: Discover project context, affected and related code, dependencies, constraints, and requirements; derive the architecture requirements that address the user request fully. Input: user request +
CONTEXT.md+ARCHITECTURE.md+IMPLEMENTATION.md. Do not stop until 100% clear. - Step 2: Design 3 best architecture solutions on high level with pro/cons analysis.
- Step 3: Define the best solution, but concise, phrase-terse, compressed, etc. Record Steps 1-3 as concise
architecture-notes.mdin FEATURE PLAN folder. - Step 4: Once done, USE SKILL
tech-specs(load JIT) to createplans/<FEATURE>/<FEATURE>-SPECS.md. Specs own WHAT. - Step 5: Once done, USE SKILL
planning(load JIT) to createplans/<FEATURE>/<FEATURE>-PLAN.md. Plan owns HOW. Target: 100% clarity. Cross-reference specs, never duplicate them. - Required skills:
reasoning,tech-specs,planning - Recommended skills:
questioning,codemap(structural project discovery) - If REQUIREMENTS in use:
requirements-useskill is required. Plan/Specs must have pointers to requirements identifiers. - Additionally discover existing libraries, packages, and search web for similar problems/tasks (if this make sense)
- SMALL: output specs and plan as message, no files. MEDIUM: concise. LARGE: full.
- Update
coding-flow-state.md
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.
- today First seen · 144 lines · 24 tokens per session scan A 0854a90cd676
coding-flow is a command published in the GitHub repository griddynamics/rosetta (342 stars, last pushed today), licensed Apache-2.0. It adds 24 tokens to every session and 2,236 once invoked, about $0.0001 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-09-03.
Other commands, from other repositories
OPSX: Apply
Implement tasks from an OpenSpec change (Experimental).
OPSX: Propose
Propose a new change - create it and generate all artifacts in one step.
OPSX: Archive
Archive a completed change in the experimental workflow.
OPSX: Explore
Enter explore mode - think through ideas, investigate problems, clarify requirements.
resolve-conflicts
Resolve merge conflicts on a GitHub PR by merging the base branch into the PR branch in an isolated git worktree, with JSON/markdown-aware conflict resolution.
ship
Commit all changes and push to remote in one operation (combines /commit and /push).