suede-graph-flo-xr
О программе
Этот навык использует подход "Графа мыслей" для оценки конкурирующих планов реализации изменений в многопайловом репозитории, выбирая единственного обоснованного победителя до написания кода. Он автоматически останавливается при обнаружении рисков, конфликтов или исчерпании бюджета и работает только в режиме чтения производственного кода без развертывания. Используйте его, когда требуется контролируемый аналитический выбор между сложными вариантами реализации.
Быстрая установка
Claude Code
Рекомендуетсяnpx skills add JasonColapietro/suede-creator-skills -a claude-code/plugin add https://github.com/JasonColapietro/suede-creator-skillsgit clone https://github.com/JasonColapietro/suede-creator-skills.git ~/.claude/skills/suede-graph-flo-xrСкопируйте и вставьте эту команду в Claude Code для установки этого навыка
Документация
Suede Graph Flo XR
Use the bundled workflows/suede-graph-flo-xr.js workflow to search competing plans for
one multi-file repository change. It makes an evidence-backed selection before
any implementation lane mutates the worktree.
Intake and budget gate
Before launch, require all three inputs:
- Repo — an absolute repository path. Relative paths and
~fail closed. - Scope — the requested multi-file change, including any protected paths or constraints.
- Budget —
light,standard, ordeep.
Also detect and pass optional context when available: deploys (whether the
repo has a deploy surface), liveUrl (the read-only production surface), and
vault (the external decision/handoff context path). Their absence does not
block a non-deploying repository, but do not silently discard known values.
When the user names a model for the workers (workerModel: sonnet, opus,
haiku, or fable), pass it — every worker call then runs on that model while
orchestration stays on the session model. Omitted, workers inherit the session
model silently; if the session sits on an expensive model and the user did not
choose it for workers, say so before launch instead of letting the default
decide. A run can spend up to 200 worker calls, so an unchosen inherited model
is a cost decision nobody made.
If repo or scope is missing, halt. Report the missing input in one line, offer to provide the repo path, describe the desired change, or route a one-file edit to direct implementation, then wait for the user's choice.
State the selected range and projected worst-case calls before launching:
light projects and permits 55, standard projects and permits 110, and
deep projects and permits 200 total agent calls. Do not infer a budget from
scope or silently raise a ceiling. If the user has not chosen one, ask and wait.
Runtime prerequisites
The bundled JavaScript workflow is a Claude Code workflow for macOS. It requires
sandbox-exec and the six registered suede-graph-flo-xr-* agent profiles. Install the
full suede-skills plugin, the suede-agent-workflows plugin, or use this
repository's install.sh, which copies the profiles into ~/.claude/agents.
Claude Workflow exposes no Node process global, so the workflow cannot infer
its package namespace. The calling skill must derive it from how this skill was
invoked and pass it on every launch. When the invoked name carries a plugin
prefix, agentNamespace is that prefix verbatim — suede-skills from the full
plugin, suede-agent-workflows from the focused orchestration plugin. A bare
invoked name with no prefix, installed by install.sh or copied by hand, takes
the empty string. This is runtime context, not a user choice. A missing or
unknown value fails before the first agent call.
The workflow also cannot locate its own bundled helper scripts. Pass helperDir:
the absolute path of the invoked skill's workflows/helpers directory (for this
install, <skill base directory>/workflows/helpers). The clamped Bash commands
run these .cjs helpers — the per-spawn clamp cannot verify a rule that is
multi-line or longer than roughly 400 characters, so inline node -e payloads
are not usable. A missing or whitespace-containing path fails before the first
agent call; a missing helper file surfaces as the Scout setup failure.
Payload-carrying helper invocations are admitted by pinned prefixes (helper
path plus worktree, temp root, or base SHA) rather than exact strings; each
helper validates its remaining argv, and the diff attestations — not the clamp —
remain the check that what was applied matches the selected bundle.
The selected patch reaches the applier as bounded base64 chunks staged into the
run's private temp root, because the clamp verifier cannot parse a command
carrying a multi-kilobyte inline payload. Each append carries its offset and an
FNV-1a checksum, and --apply verifies total length and payload checksum before
decoding, so a mistyped chunk fails fast with a retry instruction instead of
producing a corrupt patch.
A skill-folder-only install, a generic skills-CLI install, and the Codex plugin do
not by themselves register or execute Claude Workflow agent profiles. In those
environments, treat this file as the orchestration contract and route the change
to direct implementation; do not claim the bundled workflow ran. To enable it in
Claude Code after a manual single-skill copy, also copy this repository's
agents/suede-graph-flo-xr-*.md files into ~/.claude/agents and restart Claude Code.
The requested Scout setup command probes /usr/bin/sandbox-exec as its first
subprocess, before fetch or worktree creation. If that command is invoked and
the probe fails, Scout reports failure before its setup mutation. The returned
Scout evidence is still a model attestation, not a host execution receipt. Gate
also holds on any later reported sandbox rejection. Never retry an acceptance
command outside the sandbox to turn that hold into a pass.
Run the graph search
Invoke:
Workflow({
scriptPath: "skills/suede-graph-flo-xr/workflows/suede-graph-flo-xr.js",
args: { repo, scope, agentBudget, agentNamespace, helperDir, workerModel, deploys, liveUrl, vault }
})
The workflow executes these operations in dependency order:
- Generate independent implementation plans from the scout and research evidence.
- Score each plan for coverage, evidence, feasibility, safety, and efficiency.
- KeepBestN deterministically prunes the scored beam.
- Refute attacks the surviving plans with evidence-backed objections.
- Improve repairs plans whose refutations are not fatal.
- Aggregate combines compatible surviving lanes without merging conflicting file ownership.
- Select chooses one deterministic winner.
Only the plan selected by Select may mutate files. Rejected, pruned, and unselected thoughts remain evidence only; never build them speculatively.
Boundaries
The workflow halts before the next agent call or entire mutating batch when its
budget is exhausted; it does not undo mutations that completed earlier. It
halts before any mutation unless an independent read-only verifier confirms a
clean, registered origin/main worktree at one direct ${REPO}.worktrees/ship-*
child with the same Git common directory and non-symlink candidate files whose
realpaths remain inside it. Case-folded or Unicode-normalized path aliases fail
closed before graph search. It also halts for
a tracked secret, a live target worktree, a protected-WIP collision, a duplicate
file owner, an overflowed safety manifest, or no selectable plan. Scout parses
NUL-delimited Git porcelain so both sides of renames remain protected, parses
lsof -Fn CWD fields with path-component boundaries, and never discards fresh
dirty or live claims merely because committed history was cherry-landed. A
selected Build or Fix result that is blocked, missing context, reports concerns,
fails, or reports no changed path also halts before the next verification stage. On a halt, name the
blocker in one line and offer 2–4 applicable
resolutions (for example: narrow scope, exempt protected WIP, resolve the
collision, choose a higher budget, or provide missing context), and wait. Do
not relaunch or mutate while halted.
Reading a search halt
An empty search used to report no safe graph winner however it ended, so an
infrastructure flake and a genuine evidence conflict printed the same line. The
halt now names which happened, and haltDetail carries the counts behind it:
| Reason | What it means |
|---|---|
every candidate lost its score to an agent failure | No thought in the run was ever scored. Infrastructure, not evidence — rerun. |
no candidate reached Select | The search emptied upstream for some other reason; read graph.dropped. |
every finalist lost its score before Select | Finalists existed and were pruned as unscored. |
every finalist was pruned before Select | Finalists were pruned for a non-score reason. |
every finalist carries a degraded or missing score | Finalists reached Select without a valid score. |
every finalist failed deterministic plan eligibility | Real rejection. haltDetail.eligibilityRejections lists every reason. |
no safe graph winner | None of the above fits — read the graph. |
haltDetail.infrastructureDegraded is independent of the reason: both can be
true at once. Read the reason for what stopped Select and that flag for what
degraded the pool feeding it.
Score calls are read-only and idempotent, so a transport-level death is retried:
twice per call, capped run-wide at 5% of the agent ceiling, and refused entirely
once the remaining budget falls to the reserved floor (20% of the ceiling). A
malformed score is never retried — the schema is enforced at the tool layer, so
an invalid score is a judgment to keep, not a connection to redial. Every
attempt and every refused retry lands in graph.scoreRetries, and
scoreReliability rides out in the result on every run, halted or not: a flake
that costs two finalists still degrades a run that goes on to ship.
Claude's registered agent profiles enforce tool separation: local readers have
no shell, write, or web tools; public-web readers have no local-file or shell
tools; patch authors have no mutation tools; and appliers/verifiers have only
Bash plus structured output. Patch authors return unified diffs, one clamped
applier applies them, and a separately budget-reserved clamped verifier compares
the exact path set and diff digest immediately after every Build or Fix Apply,
before any reader or Gate call. Patch validation rejects symlinks, gitlinks,
binary patches, renames, copies, and file-type transitions before Apply. Gate
runs only allowlisted local validation
commands under macOS sandbox-exec, with no network, host reads limited to
runtime/system roots, the worktree, its .git common directory derived again
inside the exact Gate clamp, and the run's private temp root. The model-reported
common directory is never interpolated into sandbox permissions. Writes are limited to known generated artifacts
and that private temp root. The allowlist includes bounded project-local checks
for Node, Python, Go, Rust, Make, Swift Package Manager, Xcode simulator builds
with derived data under the private temp root, and offline Gradle validation.
Nested module build roots are derived only from selected files under that
module's src tree and are rejected if a symlink or realpath can escape the
worktree. A second diff attestation runs after Gate and hashes
the binary Git diff plus every reported file's mode, size, and bytes, including
untracked additions.
A successfully applied blocker patch is not treated as semantically cleared.
The original blocker remains in fixedBlockersPendingVerification. The Gate
attempt records its exact command set and reported output, but it cannot prove
those commands ran because the Workflow API exposes no trusted required-tool
execution receipt. The workflow therefore sets claimedPassed from the agent
report, forces passed:false, sets gateVerified:false, and keeps the verdict
and handoff status at hold. Only a trusted outer runner with immutable
execution receipts can promote that evidence.
These controls have a precise trust boundary. bashCommandClamp constrains a
Bash command when an agent invokes it; Claude Workflow does not provide a
required-tool-call receipt, so a structured verifier response remains a model
attestation rather than cryptographic proof that Bash ran. Likewise,
authority, allowedRepo, allowedFiles, and allowedCommands are audit
metadata, not filesystem permissions. Local reader tools are separated from web
tools but are not path-sandboxed by the Workflow API. Report these facts in any
security-sensitive handoff and do not describe the result as host-certified.
Production inspection is read-only. This skill never deploys, publishes, releases, pushes, merges, changes credentials, deletes or reverts protected work, or claims live verification. It does not choose the user's budget or decide that missing scope can be skipped. Its ship verdict is evidence for the user, not authority to perform an external action.
Handoff and completion
Read the workflow's returned runKey, the validated unique ship-<UUID> leaf
from its isolated worktree. On a completed run, use the returned handoff
markdown. On a post-Scout halt, write a factual halt handoff from the structured
result and graph trace without spending another agent call; include any Build
or Fix lanes that completed before the halt. If Scout returns an invalid path
before runKey validation, report the halt without writing a run-keyed
handoff. Otherwise, save it to
.suede-graph-flo-xr/${runKey}/handoff.md at the target repo root, then verify it exists:
test -f ".suede-graph-flo-xr/${runKey}/handoff.md"
Report that path, the selected plan if any, gate result, changed files, commands run, and explicit caveats. A completed local graph does not prove a deployment.
Third-party license
The operation graph and thought-state model in workflows/suede-graph-flo-xr.js adapt
Graph of Thoughts by ETH Zurich. The complete upstream BSD notice, conditions,
disclaimer, and requested citation travel with this skill at
LICENSE.graph-of-thoughts-BSD.txt. Keep that file with every source or binary
redistribution of the workflow.
Routing
- High-volume, well-specified, independent worker tasks → a separate private worker-fleet pass.
- Findings-only review of an existing diff →
suede-code-review. - CI, required checks, or branch-protection wiring →
suede-ci-gate. - Copy-only search and publication readiness →
suede-ship-copy. - From
suede-code-review,suede-ci-gate, orsuede-ship-copy: route a multi-file implementation-plan search with one selected mutating winner back tosuede-graph-flo-xr.
GitHub репозиторий
Часто задаваемые вопросы
Что такое Skill suede-graph-flo-xr?
suede-graph-flo-xr — это Claude Skill от JasonColapietro. Skills объединяют инструкции и ресурсы, которые Claude загружает по мере необходимости, чтобы выполнять задачи, связанные с suede-graph-flo-xr, без дополнительных запросов.
Как установить suede-graph-flo-xr?
Используйте команды установки на этой странице: добавьте suede-graph-flo-xr в Claude Code как плагин или клонируйте репозиторий в каталог skills, затем перезапустите Claude, чтобы загрузить Skill.
К какой категории относится suede-graph-flo-xr?
suede-graph-flo-xr относится к категории Мета.
Можно ли использовать suede-graph-flo-xr бесплатно?
Да. suede-graph-flo-xr размещён на AIMCP и доступен для бесплатной установки.
Похожие навыки
Этот навык предоставляет проверенную в продакшене настройку для Content Collections — TypeScript-ориентированного инструмента, который преобразует файлы Markdown/MDX в типобезопасные коллекции данных с валидацией Zod. Используйте его при создании блогов, сайтов документации или контентных приложений на Vite + React для обеспечения типобезопасности и автоматической проверки содержимого. Он охватывает всё: от настройки плагина Vite и компиляции MDX до оптимизации развертывания и валидации схем.
Этот навык позволяет разработчикам создавать приложения на платформе прогнозных рынков Polymarket, включая интеграцию с API для торговли и получения рыночных данных. Он также обеспечивает потоковую передачу данных в реальном времени через WebSocket для отслеживания текущих сделок и рыночной активности. Используйте его для реализации торговых стратегий или создания инструментов, обрабатывающих обновления рынка в реальном времени.
Этот навык помогает разработчикам создавать плагины OpenCode, которые подключаются к более чем 25 типам событий, таким как команды, файлы и операции LSP. Он предоставляет структуру плагина, спецификации API событий и шаблоны реализации для модулей на JavaScript/TypeScript. Используйте его, когда вам нужно перехватывать, отслеживать или расширять жизненный цикл ассистента OpenCode AI с помощью пользовательской событийно-ориентированной логики.
SGLang — это высокопроизводительный фреймворк для обслуживания больших языковых моделей (LLM), специализирующийся на быстрой структурированной генерации JSON, regex и рабочих процессов агентов с использованием кэширования префиксов RadixAttention. Он обеспечивает значительно более высокую скорость вывода, особенно для задач с повторяющимися префиксами, что делает его идеальным для сложных структурированных результатов и многократных диалогов. Выбирайте SGLang вместо альтернатив, таких как vLLM, когда вам требуется ограниченное декодирование или вы создаете приложения с интенсивным совместным использованием префиксов.
