{
  "markdown": "# Workflow Skills\n\nGive your coding agents a repeatable workflow for turning ideas and issues into\ntested, independently reviewed pull requests, with less manual coordination.\n\nThese skills are reusable instructions for Claude Code, Codex, and other agents\nthat support Agent Skills. They teach agents how to clarify a plan, split it into\nscoped tickets, implement the work, and move it through review and merge under\nyour repo's rules.\n\nUse them to:\n\n- Diagnose a failure and verify an authorized narrow fix.\n- Assess architecture or compare module interfaces before choosing a change.\n- Turn a rough idea into an approved spec and dependency-ordered tickets.\n- Hand an agent one issue to implement, test, and open as a pull request.\n- Review a branch or PR in a fresh agent context.\n- Coordinate several agents across a set of issues, track checks and review\n  feedback, and advance work until it is done or blocked on human input.\n\nYou can run one skill for a specific task or use the full delivery workflow.\nEach repo gets a small config at `docs/agents/workflow/config.md` that records\nits issue tracker, verification commands, worker setup, and approval rules.\nConfig holds stable mappings and policies. Project progress, blockers, and\nfollow-up work stay in Linear or the configured tracker; CI and PR status are\nread live rather than copied into config.\nThe skills read it before acting, so you can reuse the workflow across repos\nwithout re-explaining how each project works.\n\n## Install\n\nPrerequisites:\n\n- Node 24 and `pnpm@10.19.0`\n- `gitleaks` for `pnpm security:secrets` and `pnpm ci:check`\n- `gh` for downstream fanout PR creation with `--pr`\n\nInstall into the current project, selecting skills and agents when prompted:\n\n```sh\nnpx skills add zaks-io/skills\n```\n\nThis is the default mode for repos whose remote or cloud workers must get the\nworkflow skills from a fresh clone. Commit the generated project skill\ndirectories and `skills-lock.json` as a mechanical dependency update.\n\nRefresh project-installed skills:\n\n```sh\nnpx skills update -p -y\n```\n\nFrom this source repo, discover downstream consumers before updating them:\n\n```sh\npnpm skills:downstream\n```\n\nOpen mechanical project-skill refresh PRs across downstream repos:\n\n```sh\npnpm skills:downstream:update\n```\n\nThe coordinator reconciles the complete published skill set using the pinned\n`skills@1.7.0` CLI. It installs new skills, refreshes existing skills, and removes\nretired skills from the selected source. Other sources remain unchanged. Agent\ntargets come from tracked project skill paths, not the operator's global installs.\nIt verifies lockfile hashes and installed files against the fetched GitHub source\ncommit before committing or publishing. This requires authenticated `gh` access.\n\n`skills update -p -y` alone refreshes installed skills but does not add newly\npublished skills. Version 1.7.0 also retains retired skills in non-interactive\nmode. Use this coordinator when refreshing the complete workflow skill set.\n\nThe update command creates a temporary `git worktree` for each target, commits\ngenerated changes on a deterministic daily update branch, pushes the branch, and\nopens or reuses the GitHub PR. The PR body includes `@coderabbitai ignore` so\nCodeRabbit does not spend review quota on the mechanical refresh. Git commit and\npush hooks always run; a failed install or requested check blocks publication.\nIncomplete targets make the batch exit nonzero, with all command output retained.\n\nWorktrees branch from a freshly fetched `origin/main` by default, falling back\nto local `main` only when the repo has no remote, so a dirty or stale source\ncheckout does not block the safe worktree flow and is never used as the update\nbase. Changed apply-only worktrees are kept for inspection;\ncommitted, pushed, PR-created, and unchanged worktrees are removed unless\n`--keep-worktree` is passed. Use `--base-ref <ref>` to choose another base and\n`--worktree-root <path>` to choose the scratch location. Use `--in-place` only\nwhen you intentionally want to mutate the target checkout directly.\n\nCreate local update commits after checks:\n\n```sh\nnode scripts/update-downstream-skills.mjs --apply --check --trust-check-commands --commit\n```\n\n`--check` runs the target repo's configured full local gate from\n`docs/agents/workflow/config.md` with shell behavior. Use it only for downstream\nrepos whose workflow config you trust, and pass `--trust-check-commands` to make\nthat explicit.\n\nPush branches and open PRs when you want the full fanout:\n\n```sh\npnpm skills:downstream:update --check --trust-check-commands\n```\n\nInstall globally for one local user:\n\n```sh\nnpx skills add zaks-io/skills -g\n```\n\nList available skills:\n\n```sh\nnpx skills add zaks-io/skills --list\n```\n\nInstall the complete workflow skill set:\n\n```sh\nnpx skills add zaks-io/skills --skill '*'\n```\n\n## Distribution\n\nInstall `ziw-*` skills together. Their sibling references share canonical\nplanning, design, debugging, and complaint guidance; partial installs can leave\nthose links unresolved. The managed downstream updater and Claude plugin ship\nthe complete set. Running one workflow still loads only its relevant instructions.\n\nUse the narrowest distribution mode that still reaches the agents that work the\nrepo:\n\n- Project skills: commit `.agents/skills`, `.claude/skills`, `.codex/skills`, or\n  the target agent's project skill path when repo or cloud workers need the\n  skills from a fresh clone. Treat these as vendored generated dependencies from\n  `zaks-io/skills`; update them through `npx skills update -p -y` and commit the\n  lockfile and generated diff.\n- Plugins or marketplaces: prefer these for clients that support versioned\n  cross-project distribution, especially Claude Code plugin users. This repo\n  already includes `.claude-plugin/plugin.json` for that path.\n- Global/user installs: use for personal local convenience only. They do not\n  configure remote workers or teammates who clone a downstream repo.\n\nDo not hand-edit downstream generated `ziw-*` skill copies. Change the source in\nthis repo, run the configured updater in each target repo, and keep the update PR\nmechanical.\n\n## Claude Code Plugin\n\nThis repo also defines a Claude Code plugin manifest and root subagents:\n\n```text\n.claude-plugin/plugin.json\nagents/*.md\n```\n\nWhen loaded as a Claude Code plugin, the workflow agents are available as\nnamespaced subagents:\n\n```text\nzaks-io-skills:ziw-triager\nzaks-io-skills:ziw-implementer\nzaks-io-skills:ziw-reviewer\n```\n\nClaude Code should keep the orchestrator in the main thread and delegate the\ncontext-heavy pieces to these isolated subagents:\n\n- `ziw-triager`: issue tracker inventory and metadata cleanup.\n- `ziw-implementer`: one issue's implementation, checks, judgment-based author\n  QA, and PR handoff.\n- `ziw-reviewer`: clean-context review of latest committed PRs, branches,\n  ranges, main-drift findings, and orchestrator refactor candidates. An explicit\n  PR `--submit` mode publishes the local verdict and inline findings to GitHub.\n\nSetup, PR creation, and code review details remain workflow skills that these\nsubagents load only when needed.\n\nCodex and other Agent Skills runtimes should use the same orchestration model\nwith native skill names:\n\n```text\n$ziw-orchestrate ZAK-123 ZAK-456\n$ziw-orchestrate project \"Payments\" until clear\n$ziw-orchestrate Linear Backlog until clear\n```\n\n`Linear Backlog until clear` first triages the Linear `Backlog` state. It only\nimplements tickets promoted into the ready queue; uncommitted, parked, or badly\nshaped Linear Backlog tickets stay out of the delivery scope with a clear next\nowner.\n\nWhen the runtime supports subagents, sessions, branches, or worktrees,\nOrchestrator should keep the parent thread small and delegate context-heavy work\nto `$ziw-triage`, `$ziw-implement`,\nand `$ziw-code-review`.\n\nFor local development, validate the plugin shape when Claude Code is available:\n\n```sh\nclaude plugin validate .\n```\n\nFor private cloud environments, grant the agent system access to this repository\nthrough the provider's GitHub integration, or inject a read-only deploy key or\nfine-grained token before running `skills add`.\n\n## Quick Start\n\nSet up a repo once, or rerun setup when you want to confirm the workflow config\nis still current:\n\n```text\n$ziw-setup\n```\n\nThat creates or refreshes:\n\n```text\ndocs/agents/workflow/config.md\n```\n\nOn refresh, setup reads the existing config first, checks what changed in the\nrepo, issue tracker, CI, worker delegation paths, and environment rules, then\npatches stale or missing values.\n\nThen run the normal flow:\n\n```text\n$ziw-grill <idea|plan|spec>\n$ziw-to-issues <spec|prd|epic>\n$ziw-triage\n$ziw-orchestrate\n```\n\nFor focused investigation or design work, use:\n\n```text\n$ziw-debug <symptom|reproducer|issue>\n$ziw-architecture <area|module|design-problem>\n```\n\nDebug respects diagnosis-only or fix scope. Architecture returns proposals;\nselected proposals with unresolved decisions go to Grill. Neither starts\nticket creation or PR shipping merely because it was invoked.\n\nOrchestrate a bounded scope:\n\n```text\n$ziw-orchestrate ZAK-123 ZAK-456\n$ziw-orchestrate label:ready-for-agent one pass\n$ziw-orchestrate project \"Payments\" until clear\n$ziw-orchestrate Linear Backlog until clear\n```\n\nLinear `Backlog` is not the agent work queue. The Linear Backlog form means\n\"triage this parked tracker state, promote only correct ready work, and leave the\nrest with a truthful parked, human, To Issues, duplicate, or out-of-scope\noutcome.\" The set Orchestrator is trying to implement is the delivery scope.\n\nReadiness-label scopes such as `ready-for-agent` and `ready-for-human`\nautomatically exclude the configured `Done` state unless you explicitly ask to\naudit Done cleanup.\n\nGrill resolves material ambiguity in rounds of independent questions and marks the\nauthoritative spec `Ready for slicing` only after explicit user approval. To\nIssues turns that spec, a complete PRD, or an epic ticket into\ndependency-ordered one-PR tickets. Triage gets the current set consistent.\nOrchestrator runs the loop: dispatch, review, integrate, repeat.\n\nUse direct skills when you want one specific action:\n\n```text\n$ziw-implement <issue>\n$ziw-code-review <branch|pr|range>\n$ziw-pr\n```\n\n## The Operating Model\n\nThe issue tracker is the source of truth for issue state. In most repos that is\nLinear. The tracker is dumb storage: it holds status, labels, and relationships\nand verifies nothing. Labels are signals. Status is state. Skills define and\ncheck what \"ready\" means; the tracker just stores the label. When a GitHub PR\nand Linear ticket are linked, assume the integration sync is active: Linear may\nadvance ticket state from PR state. Repo config defines how labels and synced\nstate transitions are treated.\n\nDraft PRs are pre-review. If a PR is ready-for-review, it must be non-draft in\nthe code host. Draft state is not a request for another code review; the\norchestrator should diagnose the draft blocker and unstick the PR when no blocker\nremains.\n\nThe configured review evidence label, such as `code-review-passed`, is not a\nticket state. It means the linked PR's review-relevant diff passed the configured\ncode review gate. Agents resolve it by exact configured slug or ID and remove it when\nthe review-relevant diff changes, blocking findings appear, the linked PR changes, or evidence\nis stale.\n\nThe configured code-host human-merge PR label, such as `needs-human-merge`,\nmeans the PR is ready to merge except for required human merge authority. Agents\napply it only after current clean code review evidence, passing required checks,\na non-draft PR, complete or policy-skipped hosted review, matching issue scope,\nand no unresolved blocking review thread; they clear it when any of those facts\nchanges.\n\nBy default, `ready-for-agent` means the ticket needs no further human refinement\nbefore handoff to an implementation agent. Worker environment labels such as\n`remote-cursor` mean the issue is approved for that configured environment. Those\nlabels are not dependency or scheduling gates. When a ticket moves to `Done`,\nOrchestrator or verified stale-state triage removes `ready-for-agent`.\nReadiness-label queries exclude `Done` by default so stale labels on terminal\ntickets do not keep growing the active queue.\n\nFriction intake is separate from delivery work. Prefer the configured MCP\ncomplaint store, with Exposure Ledger as the setup default when available.\nRecord an event in one store only. Use tracker storage as an explicitly\nconfigured fallback or preserve a legacy tracker-primary config until refreshed.\nReport unavailable storage instead of creating another\nlog. Agent-created friction tickets\nstart outside the work queue, usually in `Inbox` or `Triage`, and a configured\nreview loop such as a daily automation dedupes them, closes noise, and opens PRs\nfor concrete skill or config improvements.\n\nKind is a separate, single-select axis: `kind-spec` and `kind-epic` are\ncontainers that To Issues reads as input and are never dispatched; `kind-slice`\nis a one-PR ticket and the only kind a worker runs. Multi-PR work should stay\nunder a container and be split into separate slices so a first linked PR cannot\nfalsely close the whole scope.\n\nSlices are sized to be worth a PR. Each one costs a worker session, a check\nrun, a review, and a merge, so To Issues cuts the fewest slices that ship\nsafely: a slice is a whole outcome with its code, tests, docs, and migration.\nWork is separated only for a distinct outcome, size, rollout order, risk or\nauthority, or readiness. A layer, a scaffold, a verification step, or the tests\nfor an unmerged sibling's behavior is merged into the slice it serves unless a\nsplit reason keeps it apart, and work the plan does not ask for is never\nticketed.\n\nEvery ready `kind-slice` needs a hard boundary: one primary outcome, concrete\n`in scope`, and concrete `out of scope`. The out-of-scope field should name\nadjacent tickets, optional polish, broad refactors, production actions, and\nfollow-up behavior the worker must not deliver. If that boundary is unclear,\nthe ticket is not ready for agent handoff.\n\nAgent suitability is based on work type and risk, not agent brand. Docs, tests,\nbuild or CI updates, small refactors, scoped bugs, and isolated UI changes are\ngood default agent work. Auth, PII, secrets, payments, production, destructive\ndata, broad refactors, cross-repo changes, unclear domain behavior, and\nperformance work without benchmarks require human planning first.\n\nIssue Triage grooms the configured ready state, usually `Todo`, plus configured\nintake, usually `Triage`, into a clean handoff queue for Orchestrator. The\nsnapshot also includes direct blockers of those tickets so the dependency graph\nstays correct without reading unrelated parked work. It runs the configured\nworkflow scripts, inspects their output, and fixes tickets: labels, kind,\nreadiness, body shape, estimates when configured, dependency relationships,\nstale readiness, and exact next owners. It does not review unrelated Linear\n`Backlog` or Duplicate tickets unless asked. Linear `Backlog` means work you do\nnot want agents working yet: uncommitted ideas, intentionally parked scope, or\ntickets that are not shaped correctly. Dependency blockers should be encoded\nseparately, not used to remove readiness or park ready work in Linear Backlog.\n\nA normal `$ziw-triage` run processes `Triage` without another opt-in phrase:\ncomplete `ready-for-agent` `kind-slice` tickets move to `Todo`, even when blocked\nby another ticket. It reads cited source-of-truth project docs to repair the\nsmallest direct dependency graph. Use `$ziw-triage` or the namespaced\n`ziw-triager` worker for this workflow, not a generic triage skill with a\ndifferent state model.\n\nTriage is not exploration. It should not manually inspect code, GitHub, CI,\ndeploys, logs, alerts, or repo health outside the approved workflow scripts.\nTracker/MCP tools are for specific ticket reads and mutations, not for\nrediscovering queue state. Agent Orchestrator owns active delivery, PR/check\nstate, worker starts, reviews, integration, and completion.\n\nA one-off user request for a single ticket is still orchestration, just scoped to\nthat ticket. The agent should claim, implement, review, integrate when allowed,\nrefresh synced GitHub/Linear state, and mark that ticket complete when the normal\nDone evidence exists. It should not fan out into the broader queue.\n\nReview-created follow-up tickets are current-work intake when config defines a\nreview-debt route. Agent Review files real findings there; Triage normalizes\nthem into `kind-slice` work, To Issues input, or human-decision items; and\nOrchestrator includes concrete ready slices in the normal queue. This keeps code\nreview debt visible without pretending every review finding is immediately\ndispatchable.\n\nAgent Orchestrator does whatever needs to happen to get tickets handled safely.\nIts job is to find where tickets are stuck in the tracker-to-PR-to-merge\npipeline, determine why they are not advancing, and take the next safe action to\nunblock them. It uses model judgment to synthesize tracker state, PR state,\nchecks, review evidence, worker signals, repo config, and risk into the next safe\naction. The named actions are examples, not a complete menu; if a ticket is not\nmoving, Orchestrator should identify and take any safe workflow action needed to\nmove it forward. It can start local subagents in isolated branches or worktrees,\nassign a tracker-exposed coding agent to a ticket, request another code review,\nrerun checks, diagnose draft PRs that have stalled, move unblocked draft PRs to\nready-for-review, apply or remove the configured review evidence label, request\nconfigured hosted bot review such as CodeRabbit or Cursor Bugbot for risky or\ncomplex diffs, reply directly to the original worker, mark tickets for human\nreview or missing information, or stop on a real blocker. The repo config\nrecords supported worker delegation paths such as `local-worktree`,\n`issue-assigned`, or both, plus only the project-specific routing or\ndirect-agent continuation details that are annoying to rediscover. For hosted\nbot review, the repo config records the provider, auto-review state, trigger\npolicy, and exact command policy. CodeRabbit can use root `.coderabbit.yaml` and\n`@coderabbitai ignore`; Cursor Bugbot is an alternative provider and must use\nthe repo-configured trigger or automatic review policy.\n\nWhen you hand Orchestrator a large ticket set that has already been triaged or\nverified as ready to implement, that set is the delivery scope. Routine\nmisunderstandings about when to apply a label, move a status, attach review\nevidence, set repo-route metadata, or mark a PR ready-for-review are\norchestration repairs. It should fix those from tracker, PR, check, and config\nevidence and keep going instead of escalating them.\n\nGrill is the planning front door when intent is fuzzy or contradictory. It\nchecks code and docs before asking, asks one recommended question at a time,\nupdates confirmed current-truth specs, and keeps them `Draft` until you approve\n`Ready for slicing`. It never creates tracker tickets.\n\nTo Issues is the ticketing front door. It turns a ready spec, complete PRD, or\nepic ticket into the fewest dependency-ordered `kind-slice` tickets that ship\nsafely, adopts any tickets you made by hand instead of duplicating them, merges\nfragments into the outcome they belong to, applies the body contract, labels, and\nconfigured estimates, and emits a dependency graph and predicted file\nfootprint. Run it whenever you want the tickets to match the plan; re-running\nconverges. Draft specs return to Grill instead of producing ready slices.\n\nAgent Orchestrator is the work loop. It is self-scheduling: it runs on the\nruntime's own recurring mechanism (a schedule, `/loop`, or wake-up timer in\nClaude Code; Codex automations, either cron automations or heartbeat\nautomations) and never needs a human to re-trigger a pass. Each tick it wakes\nlight, refreshes external state, reconciles its dispatch ledger, advances open\nPRs and previews while immediately filling every safe worker slot up to the\nworker concurrency cap (default 3), calls review and integrate as steps,\nreasons over the available evidence, and logs where it struggled to a friction\nintake sink with compact event entries and run rollups. It can also nudge a worker,\nrepair workflow state, route feedback, mark tickets for human review when the\nnext action genuinely needs human input, or stop on a real blocker. It keeps only\na compact queue, ledger, capacity snapshot, and checkpoint between ticks and\ndelegates heavy reads to isolated workers, so a long-running loop stays as light\nas a first run. Config records supported worker delegation paths such as\n`local-worktree`, `issue-assigned`, or both.\n\nThe capacity snapshot does not trust the ledger alone. It also counts active\ntracker claims in the repo route-label domain and dirty or baseline-unmerged\nlocal worktrees, reconciles squash-merged heads, then deduplicates those signals\nagainst open PRs.\n\nIf every scoped item is blocked and no orchestration action remains, the\norchestrator stops the recurring loop for that scope instead of waking forever.\nThe blocked report names each blocker, next owner, and what would make the scope\nrunnable again.\n\nFor issue-assigned remote workers such as Cursor, the orchestrator delegates by\nsetting the issue's agent delegate, requires the repo-route label (such as\n`<org>/<repo>`) so the agent knows which repo to clone, and continues a session\nby replying into its agent-session thread rather than a top-level comment.\nBefore re-delegating, it checks for duplicate sessions, branches, or PRs tied to\nthe same issue and resolves the duplicate from code-host evidence.\n\nA delegated worker, local or remote Cursor, owns implementation: it writes code,\nruns required checks, decides whether `ziw-code-review` author QA would add\nvalue, and opens its own PR with `ziw-pr`. A changed commit alone does not force\nanother author-QA pass. The worker cannot apply review evidence or declare its\nown work merge-ready. The orchestrator coordinates; it does not write code or\nopen PRs.\n\nAgent Review and integrate are steps the orchestrator calls, not loops. Agent\nReview fetches latest state, runs `ziw-code-review` from clean context against\ncurrent committed code, and returns freshness, refactor candidates, and a\nverdict; integrate is the auto-merge gate that defines green, updates moved\nGitHub PR branches with `gh pr update-branch <pr>`, delegates only merge\nconflicts, merges with the configured method, and runs a post-merge check.\nWorker and PR local gates must match configured CI scopes, thresholds, cache\npolicy, generated-artifact checks, and secret-scan range.\n\nThe research behind this operating model is captured in\n[docs/agent-delivery-research.md](docs/agent-delivery-research.md). The short\nversion: keep one work loop, keep issues focused and verifiable, measure outcomes,\nand add agent or skill complexity only when it improves delivery.\n\n## The Skills\n\nThe public skill surface and trim rationale are tracked in\n[docs/skill-portfolio.md](docs/skill-portfolio.md). Provider-specific workflow\nglue should stay under `.agents/` unless it proves portable.\n\n- `ziw-setup`: create repo workflow config or refresh it against current\n  repo and tracker state.\n- `ziw-debug`: reproduce failures, test hypotheses, and return a supported cause\n  or named evidence gap; verify a narrow fix when authorized.\n- `ziw-architecture`: assess concrete structural friction or design a named\n  module interface, comparing alternatives and migration costs without refactoring.\n- `ziw-grill`: resolve material product, domain, scope, and architecture\n  ambiguity in rounds of independent questions; update authoritative planning artifacts;\n  and require explicit approval before a spec becomes ready for slicing.\n- `ziw-to-issues`: turn a spec, PRD, or epic ticket into the fewest\n  dependency-ordered one-PR `kind-slice` tickets that ship safely, adopt\n  hand-created tickets, merge fragments, apply the body\n  contract with explicit non-goals, labels, and configured estimates, and emit a\n  dependency graph and file footprint.\n- `ziw-triage`: update current tracker labels, kinds, readiness, stale\n  verified states, orphans, body shape, estimates when configured, and\n  dependencies so Todo tickets are clean and agent-ready. It follows the\n  repo-configured label treatment policy, processes configured intake on every\n  normal run, skips Linear Backlog unless asked, and\n  asks or lists exact human next actions when something is unclear.\n- `ziw-orchestrate`: run the script-backed work loop, dispatching startable\n  `kind-slice` tickets and calling review and integrate as steps, without\n  becoming the coder or reviewer.\n- `ziw-implement`: take one startable issue through implementation,\n  checks, review, and PR creation.\n- `ziw-code-review`: shared review gate for branches, PRs, and explicit\n  working trees, plus independent latest-committed PR review, checkpointed\n  main-drift review, review-debt issue filing, and explicit current-head GitHub\n  review submission from clean context.\n- `ziw-pr`: helper shipping gate that checks, reviews, commits,\n  pushes, creates or updates the PR, and hands tracker state to Orchestrator.\n\n## Recommended Flow\n\nReview a PR entirely locally and publish the result as a GitHub review:\n\n```text\n$ziw-code-review https://github.com/owner/repo/pull/123 --submit\n```\n\nWithout `--submit`, PR review remains read-only.\n\n1. Run `ziw-setup` once per repo, and rerun it when the workflow config may\n   be stale.\n2. Run `ziw-grill` when an idea or existing spec has material ambiguity. Stop\n   when the user approves `Ready for slicing`.\n3. Run `ziw-to-issues` on the ready spec, complete PRD, or epic ticket to create the\n   `kind-slice` tickets and dependency graph. Re-run it any time to reconcile the\n   tickets with the plan.\n4. Run `ziw-triage` before the first orchestration run and whenever Todo,\n   Triage, or active tracker state needs repair. Ask explicitly only when you\n   want Linear Backlog review or backfill.\n5. Run `ziw-orchestrate` to run the loop: dispatch, review,\n   integrate, repeat until the delivery scope is delivered or completely\n   blocked. A completely blocked loop stops instead of rescheduling itself.\n6. Use `ziw-pr` directly only when you are already on a branch and\n   want to ship it.\n\nFor the deeper agent contract, state model, handoff shape, and diagrams, see\n[docs/agent-workflow.md](docs/agent-workflow.md).\n\n## Done Means\n\nA repo is ready when:\n\n- `docs/agents/workflow/config.md` exists with the required verified mappings\n- every populated behavior-affecting config value has verified evidence;\n  unresolved setup work is tracked outside config\n- issue tracker state, PR state, checks, previews, and deploy state all have\n  named systems of record\n- issue tracker location has verified IDs or query-safe names, not stale slugs\n- Orchestrator mutation authority is explicit\n- issue-assigned worker environment labels and no-mutation delegation probe\n  policy are explicit\n- local, development, preview, and production rules are explicit\n- verification commands are recorded\n- planning artifact authority, status convention, and documentation checks are\n  recorded\n- kind labels, CI-equivalent local gate policy, merge method, duplicate-dispatch\n  policy, worker concurrency cap, saturation policy, PR closure guard,\n  stuck-worker timeout, required-checks-for-merge, auto-merge risk tiers,\n  friction intake, and delivery metrics are set when running the autonomous loop\n- `ziw-grill`, `ziw-to-issues`, `ziw-orchestrate`, `ziw-implement`,\n  `ziw-code-review`, and `ziw-pr` can run without guessing repo\n  conventions\n\n## Validate This Repo\n\n```sh\npnpm ci:check\n```\n",
  "bytes": 27873,
  "sha": "2c3f3962cdf428905aab006f36aa923986290ac340da79432dc88606add65660",
  "repo_slug": "zaks-io/skills",
  "fonte": "repo",
  "truncated": false,
  "api": "https://api.agentalog.com/api/listings/skl_zaks_io_skills_ziw_implement_24388734/readme"
}