Add YYLO

[InsightFactoryAPP]

Tool

YYLO — command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes.

• Category: orchestrators
• Classification: agent-native
• Pricing: open-source (MIT)
• Website / source: https://github.com/yylo-dev/yylo · npm: @yylo/cli

Inclusion test

1. Classification: agent-native — coding agents are the core actor YYLO coordinates. The README's first line: "YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes."
2. Concrete agent outcome: agents receive typed tasks in dedicated exact-base worktrees, produce receipt-backed commits, and land changes through a fenced merge queue with risk-based review.
3. First-party evidence: the repository README (linked in evidenceSources) documents the agent runs (yy pi, agent aliases), the typed task/merge flow (task start → worktree; merge queue with 0/1/2 sequential reviewers by risk), and the npm distribution.
4. Substantive capability: task lifecycle, validation evidence, merge orchestration, and release-readiness gating are the product itself, not a thin wrapper.
5. Defensible: every claim in the tool file is quotable from the current README.

Changes

• tools/yylo.md — new tool entry (frontmatter + short body with a "So agents can..." section)
• tool-submitters.json — registers yylo

npm test (71/71) and npm run validate:content -- --require-submitters pass locally.

Disclosure

I'm part of the YYLO team; this PR was prepared with an AI coding agent and reviewed by me before submission. YYLO is used daily in our own repositories. Happy to adjust the entry or evidence to fit the editorial policy.

[foo-bender]

Outcome: evidence-requested

Policy assessment

@InsightFactoryAPP YYLO otherwise has a supportable agent-native inclusion case: its documented coding-agent runs, exact-base task worktrees, typed task boundaries, validation receipts, and risk-based merge queue are substantive orchestration capabilities. The Orchestrators category fits, the limitations are appropriately bounded, and no duplicate was found on current main. SEO metadata was not evaluated because one submitted evidence URL could not be inspected.

Evidence checked

• https://github.com/yylo-dev/yylo — validated the CLI orchestration, agent commands, typed task/worktree lifecycle, receipts, merge queue, limitations, and MIT licence.
• https://github.com/yylo-dev/yylo#typed-task-and-merge-flow — validated the exact-base worktree, preflight/finish gates, and risk-sized review flow.
• https://www.npmjs.com/package/@yylo/cli — inaccessible to this review client (HTTP 403 Cloudflare interstitial), so the submitted package-distribution claim could not be substantiated from this URL.

Evidence requiring correction or removal

• https://www.npmjs.com/package/@yylo/cli — the submitted URL returned an HTTP 403/Cloudflare interstitial rather than inspectable package content. Replace it with an accessible first-party HTTPS source that directly supports distribution of the yylo and yy commands, or remove the evidence item and any dependent claim.

• https://www.npmjs.com/package/@yylo/cli — The submitted npm URL returned an HTTP 403 Cloudflare interstitial, so its package-distribution claim could not be substantiated from that URL.

Please correct or remove each evidence item above.

Checks run

• Reviewed the PR body, complete diff, listing, classification, category fit, duplicate search, limitations, pricing/licence claims, and current GitHub check (enrich: success).
• On the exact head merged with current main (af5b0fc05df21cf7cff658bd64be4d01ae2b5648), Node 24.19.0: npm run validate:content passed; npm test passed 84/84.

[InsightFactoryAPP]

Done — the npm evidence URL is now https://registry.npmjs.org/@yylo/cli (registry JSON, no Cloudflare interstitial), which directly shows the published @yylo/cli package with bin commands yylo and yy (plus ypl); the PR body link was updated to match and accessedAt refreshed to 2026-09-25. No claims changed.

[foo-bender]

Outcome: meets-policy

Policy assessment
YYLO passes as agent-native: coding agents are the actors in a substantive task lifecycle that creates exact-base worktrees, records validation receipts, and gates repository changes through a risk-based merge queue. The orchestrators category fits, external agent/provider and release-authority limits are disclosed, and no duplicate listing was found. @bradvin, this is ready for the inclusion decision.

Evidence checked
Validated the first-party repository/README and typed-task section (https://github.com/yylo-dev/yylo and https://github.com/yylo-dev/yylo#typed-task-and-merge-flow), npm registry metadata (https://registry.npmjs.org/@yylo/cli), and MIT license. They support the orchestration, worktree, receipt, merge-review, distribution, and licence claims.

Checks run
Against current main 66026dc9943c8c8c4b2fa344e033206116b90c11 with final head: npm run validate:content passed; npm test passed (84/84).

Reviewer-owned SEO metadata

• agentSummary: written — “YYLO is for developers and project operators who want coding agents to work through explicit repository boundaries. It creates exact-base task worktrees, collects receipt-backed validation evidence, and routes completed changes through a fenced merge queue with review depth based on risk. Agent providers and release or deployment authority remain external.” This adds the supported workflow and limits without replacing the product description.
• seoTitle: written — “YYLO: Typed Task Orchestration for Coding Agents” — names the supported agent-facing use.
• seoDescription: written — “Explore YYLO's CLI workflow for isolated coding-agent worktrees, receipt-backed validation, and risk-based merge review before repository changes land.” — summarizes the validated differentiators.

Reviewer commit: 62044959f6b88150cde1b309e7443550b37e679a — InsightFactoryAPP@6204495. The existing description was preserved byte-for-byte.

[bradvin]

@InsightFactoryAPP I am not convinced this is the right fit for agentfirst.directory
I had a look at your site, and YYLO seems like a CLI + harness to use as a development tool.

I am not sure I want to include any and all agent-related dev tools to this directory.

Convince me.

[InsightFactoryAPP]

Hi @bradvin — thanks for engaging directly; fair challenge, and it's the right bar for this directory. Let me make the case as concretely as I can.

The distinction that matters here is who the actor is. A dev tool has a human actor and treats agents as something to build or manage. YYLO inverts that: coding agents perform the repository work. task start hands an agent a typed task in a dedicated exact-base worktree; the agent edits, tests, and commits there; task finish independently verifies the result; merge land composes and records it. "Process exit is not completion" is a stated invariant — the orchestrator, not the agent's own claim, defines done. Humans hold the authority points (merge, release, production mutation), not the task execution.

Mapped against the Orchestrators inclusion points, all quotable from the README:

• Coordinates multiple agents or runs — typed task records with dependency edges; a controller workspace prepares per-task worktrees; the agent runtimes (yy pi and its aliases) are the configured executors.
• Shared state — the YYLO Ledger Record/task store: task state, wiki, and evidence records held in the repository.
• Observability — validation receipts and run evidence; watch is a read-only observer that can never launch, retry, or complete work.
• Approvals / governance — finish enforces scope, dirty-byte, hydration, ownership, and validation checks before queueing; merge land composes in a private detached candidate under Git expected-old-ref protection; publish requires separate authority.

On "agent-related dev tools" generally: agreed — generic compatibility ("an agent can call it") shouldn't qualify, and I wouldn't ask it to. YYLO's claim is by construction: the workflow only advances through agent-performed, receipt-backed work that a human gates. That's also why the policy review landed on agent-native orchestration rather than a compatibility rationale.

For what it's worth, this PR itself went through that lifecycle — prepared by a coding agent inside a YYLO task worktree and admission-checked before submission, as disclosed in the PR body.

Happy to adjust the entry — sharpen the "So agents can…" framing, or recategorize — if a different framing reads more honestly to you. And if it still doesn't clear the bar, closing with your reasoning is a fair outcome and we'll leave it there.