[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7D2S85VAP9QMASDSTNF5F1B":3,"skill-same:01M7D2S85VAP9QMASDSTNF5F1B":49},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":27,"commitSha":28,"skillDirectory":29,"forksCount":30,"repositoryHtmlUrl":31,"repositoryHomepageUrl":6,"ownerHtmlUrl":32,"ownerBlogUrl":33,"ownerDescription":6,"updatedAt":34,"install":35,"resources":48},"01M7D2S85VAP9QMASDSTNF5F1B","super-bound",null,"Human-started command: it runs only when the human's message begins with `\u002Fsuper-bound`, or under a validated grant, or when a supervisor's bypass grant passes the bundle's `ak-gate.mjs bypass check`, or when the repository or environment opts into the unattended policy and `ak-gate.mjs unattended check` exits 0. On any other request do not load or follow it; tell the human to type that command. Turns an approved direction into a decision-level specification, a reviewed plan and a dependency graph of zero-context implementation tickets with named verification. Use when the direction is agreed and the work needs bounding. Not for deciding what to build, and not for a reviewed ticket that already carries its acceptance criteria.","Pibomeister\u002Fagent-kit","Pibomeister","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F11633791?v=4","01M7D2NBHEKARMHN9MPV2J80XD","Eduardo Picazo","01M7D2NBJ3Z33SGSYCZ0KBD5DE",0,"MIT","https:\u002F\u002Fgithub.com\u002FPibomeister\u002Fagent-kit\u002Fblob\u002Fmain\u002F.cursor\u002Fskills\u002Fsuper-bound\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: super-bound\ndescription: \"Human-started command: it runs only when the human's message begins with `\u002Fsuper-bound`, or under a validated grant, or when a supervisor's bypass grant passes the bundle's `ak-gate.mjs bypass check`, or when the repository or environment opts into the unattended policy and `ak-gate.mjs unattended check` exits 0. On any other request do not load or follow it; tell the human to type that command. Turns an approved direction into a decision-level specification, a reviewed plan and a dependency graph of zero-context implementation tickets with named verification. Use when the direction is agreed and the work needs bounding. Not for deciding what to build, and not for a reviewed ticket that already carries its acceptance criteria.\"\nlicense: MIT\nmetadata:\n  ak_catalog_id: super-bound\n  ak:\n    mode: manual\n---\n\nRequirements and specification, implementation plan, dependency graph, ownership boundaries,\nacceptance criteria and verification commands. A decision ticket is never an implementation ticket.\n\n## When to use\n\n- An approved direction exists and the work needs a specification, a plan and tickets before anyone\n  builds.\n- A specification exists but nobody has settled the slicing, the blocking edges or which ticket owns\n  which file.\n- The approved direction covers several modules and no capability map has been drawn.\n- A delegated controller holds a charter naming the `spec-approval` checkpoint and an approved\n  alignment result binds to the current source revision.\n\n## Not for\n\n- Deciding what to build. An unsettled direction goes back to a human-started alignment run; this\n  skill starts from an approved result and does not reopen it.\n- A reviewed ticket that already carries its acceptance criteria and verification command. That\n  work enters at build, and re-bounding it re-decides what a reviewer already accepted.\n- Charting a multi-session effort into decision tickets and fog. That is `wayfind`.\n- Reviewing the specification for coherence or decision readiness. This skill calls `\u002Fak:doc-review`\n  for that rather than grading its own artifact.\n- A single mechanical rename with one call site and one test.\n\n## Authority\n\nAuthority: `explicit` at the public entrypoint, `delegated-grant` at the phase operation\n`bound.run`. A human starts the public entrypoint by typing `\u002Fsuper-bound`. A request in prose\nis not a start, even when it names this skill or the command. A delegated controller starts\n`bound.run` only under a runner-validated grant covering `spec-approval`, and only with a second\ngrant covering `ticket-approval` when the operation emits implementation tickets\n([`adapters\u002Frunner-contract\u002FCONTRACT.md`](..\u002F..\u002Freferences\u002Fshared\u002Fadapters\u002Frunner-contract\u002FCONTRACT.md)). Where the host cannot validate a grant, the operation\nstops for explicit invocation rather than approving on the controller's word (ruling\n`entrypoint-phase-operation-split`). No skill starts this skill directly; it calls `doc-review`,\nwhich is model-invoked, and that direction is the legal one.\n\nUnder a bypass grant (ADR-0008), a supervisor-held file stands in for the typed command for one\ntask. From the task's worktree, run `node \u003Cthis skill's directory>\u002F..\u002F..\u002Fbin\u002Fak-gate.mjs bypass check --grant \u003Cpath> --task \u003Cid>\n--phase super-bound`: exit 0 is the start, and a refusal is a stop with\n`needs-decision`. The grant starts the phase and nothing else. The specification approval at step 8\nand every ticket approval still come from the supervisor through `needs-decision`; the worker never\napproves its own specification or tickets.\n\nUnder the unattended policy (ADR-0014), `node \u003Cthis skill's directory>\u002F..\u002F..\u002Fbin\u002Fak-gate.mjs unattended\ncheck --phase super-bound` exiting 0 is the start, with no command or grant (an exception to ruling\n`entrypoint-phase-operation-split`). The approved-alignment input, open document-review decisions, the capability-map review, the specification approval and the ticket approvals then\nproceed with your own recommended answers, recorded as unattended advances and never as approvals;\na ticket whose class makes a human the author keeps that class, and a delegation coverage limit (Inputs) never stops this phase. Every implementation ticket, scored or unscored, is still recorded with acceptance criteria and named verification derived from the work source (the issue text or plan); scores and receipts are never invented. Record the `bound` gate as\n[the unattended-lifecycle reference](..\u002F..\u002Freferences\u002Fshared\u002Freferences\u002Funattended-lifecycle\u002FREFERENCE.md) says.\n\n## Inputs\n\n- An approved alignment result that binds to the current source revision. Absent, or bound to a\n  different revision: return `needs-input`. A direction approved against other code is not an\n  approval of this one.\n- Recorded project context, read through the knowledgebase adapter's `readContext`: the `prd` in\n  scope, the settled `adr` pages, and the glossary the vocabulary was agreed in. An empty result is\n  a fact; a configured knowledgebase that cannot be reached returns `failed`. The commands, and\n  what an unconfigured knowledgebase obliges (a coverage limit, never a stop), are in\n  [the knowledgebase-binding reference pack](..\u002F..\u002Freferences\u002Fshared\u002Freferences\u002Fknowledgebase-binding\u002FREFERENCE.md).\n- The project record's configured guidance ([`schemas\u002Fproject.schema.json`](..\u002F..\u002Freferences\u002Fshared\u002Fschemas\u002Fproject.schema.json)) for change size and test\n  shape. Absent: the starting points below are advisory and nothing enforces them.\n- Delegation guidance on that same project record. Outside the unattended policy, missing delegation guidance is `needs-input`. Under the unattended policy, no project record, a valid one without delegation guidance, or a missing `.cursor\u002Fbin\u002Fak delegation` command, is a delegation coverage limit: record it once naming its cause, and give each ticket no `delegation` block and an assumption, resolved `non-goal`, reading `delegation unscored: \u003Ccause> (coverage limit); floor not evaluated; packs: \u003Cids or none>; sensitive actions: \u003Cids or none>`. It never stops this phase, and every required sensitive action still stops. A missing `.cursor\u002Fbin\u002Fak delegation` command is one not on `PATH`, an unknown subcommand or a usage error from an older CLI, as in a sandbox with only `node \u003Cbundle>\u002Fbin\u002Fak-gate.mjs`; with it, a present record's validity is not checked, and the cause reads `missing .cursor\u002Fbin\u002Fak delegation command, project record validity not checked`.\n  A present project record is decided by `.cursor\u002Fbin\u002Fak delegation`, never by hand, whether or not the draft ticket carries a `delegation` block: `ak delegation: project does not match its schema: …` is `needs-input` under every policy, and `ak delegation: project has no guidance.delegation block (weights and cut points)` is the coverage limit. Decide it at step 10. A ticket-side error (`ak delegation: ticket has no delegation block to score`, or `ak delegation: ticket does not match its schema: …`) is about the draft, not the record. Under the limit the persisted unscored ticket carries no `delegation` block, seeded or default, so build has no class to pass. Only an absent project record skips `.cursor\u002Fbin\u002Fak delegation`. A present project record that fails [`schemas\u002Fproject.schema.json`](..\u002F..\u002Freferences\u002Fshared\u002Fschemas\u002Fproject.schema.json) validation is `needs-input` under every policy; with the `.cursor\u002Fbin\u002Fak delegation` command missing, the unattended policy records its validity as not checked, never as valid. Scorer inputs are never invented.\n- The project's verification recipes and surface declarations ([`schemas\u002Fproject.schema.json`](..\u002F..\u002Freferences\u002Fshared\u002Fschemas\u002Fproject.schema.json)).\n  Absent or empty: record the gap; never assume a browser, running service, trace collector or\n  command the project did not declare.\n- At `bound.run` only: a `charter` ([`schemas\u002Fcharter.schema.json`](..\u002F..\u002Freferences\u002Fshared\u002Fschemas\u002Fcharter.schema.json)) listing `spec-approval`, and\n  `ticket-approval` where tickets will be emitted. Absent: `needs-input`.\n\n## Workflow\n\n1. Check how this run was started, before any other step and before any tool call. It is started\n   only when the human's message begins with `\u002Fsuper-bound`, when a controller started the phase\n   operation `bound.run` under a validated grant, when the bypass check in Authority exits 0, or\n   when its unattended check exits 0. A\n   request in prose is not a start, even when it names this skill or the command, or asks for this\n   work without naming either. With neither, stop before reading the repository, checking inputs or\n   answering the task: the only response is to tell the human to type `\u002Fsuper-bound` followed by\n   their request.\n2. Detect before you ask. Read what the repository already states — its dependency manifest, its\n   test runner, its lint configuration, its continuous-integration configuration — report what you\n   found in two lines, and ask only what is left.\n3. When the approved direction spans more than one module, draw the capability map first: a table of\n   stable kebab-case module ids, each with its responsibility and what it depends on. The map is\n   gated like every other step; a human reviews it before any module's specification is written (under the unattended policy that review is an unattended advance, per [the reference](..\u002F..\u002Freferences\u002Fshared\u002Freferences\u002Funattended-lifecycle\u002FREFERENCE.md)).\n4. Write the specification at decision level: problem, solution, non-goals, acceptance criteria,\n   test seams, verification commands, out of scope. No file paths and no code, except a fragment a\n   prototype already settled exactly — a state machine, a reducer, a schema, a type shape. Turn\n   each vague criterion into a frontier question that proposes how the answer would be verified.\n   For each criterion, record its surface and required evidence kinds from the project declaration.\n   Load [verification evidence](..\u002F..\u002Freferences\u002Fshared\u002Freferences\u002Fverification-evidence\u002FREFERENCE.md) for the\n   vocabulary; an undeclared facility becomes a visible gap, never an invented check.\n5. Choose the test seams before the slices. The fewer seams the feature is verified across the\n   better, and the ideal number is one; name the seam you chose and why it is the highest one\n   available. Use the vocabulary the alignment run already established with\n   [the domain-modeling reference pack](..\u002F..\u002Freferences\u002Fshared\u002Freferences\u002Fdomain-modeling\u002FREFERENCE.md) rather than\n   renaming the same things here.\n6. When the caller supplies a draft ticket or scorer input, load the delegation reference and run\n   `.cursor\u002Fbin\u002Fak delegation \u003Cticket> --project \u003Cproject-record>` now. A current agent-kit CLI is a\n   prerequisite: outside the unattended policy a missing command, or a usage error from an older CLI, is reported as\n   `needs-input` naming that prerequisite, not as a scoring failure; under the unattended policy it is a delegation coverage limit (Inputs). Persist the scorer output,\n   readiness and assumptions on the evidence-bearing draft before document review; the draft is not\n   an approved implementation ticket. Under a delegation coverage limit no scorer output is persisted; readiness and assumptions are still persisted.\n7. Run `\u002Fak:doc-review` on the specification and resolve everything it returns before cutting a\n   ticket. A current review receipt bound to this specification with every decision answered\n   satisfies this step; otherwise open decisions return to the human and stop the run.\n   For a single-slice ticket whose every changed path the author claims is text-only, the light\n   route defined in [the delegation reference](..\u002F..\u002Freferences\u002Fshared\u002Freferences\u002Fdelegation\u002FREFERENCE.md) under\n   \"Light route for a text-only single-slice ticket\" governs.\n   While a specification or review decision is open, an evidence-bearing draft, where one exists, is\n   kept and retyped `decision`, and no implementation ticket exists. An open assumption is per\n   slice; that slice becomes a decision ticket at the zero-context gate and unrelated slices\n   proceed.\n8. Take the specification approval. A recorded human approval whose artifact hash equals the\n   current specification hash satisfies this step. Otherwise the plan record takes approval as\n   `specification_approval`, bound to `specification_hash`, so later slicing does not void it.\n   Under a bypass grant, report `needs-decision` naming the specification hash and stop; only the\n   supervisor's answer is the approval.\n9. Load [the delegation reference pack](..\u002F..\u002Freferences\u002Fshared\u002Freferences\u002Fdelegation\u002FREFERENCE.md) and follow its\n   ordered stack, readiness, assumptions, authorship-boundary and advisor procedures for every\n   zero-context slice.\n10. Run `.cursor\u002Fbin\u002Fak delegation \u003Cticket> --project \u003Cproject-record>` after populating its floor, evidenced\n   factors and the `class` seed the reference names; persist its complete JSON with `readiness` and\n   `assumptions` before returning, including on `needs-input`. Never derive the class in this body. Under a delegation coverage limit the ticket carries its unscored assumption in place of the scorer output; readiness and assumptions are still persisted.\n11. Give every ticket its interfaces: what it consumes from earlier tickets with exact signatures,\n    and what it produces that later tickets rely on with exact names, parameters and return types.\n    Write for a skilled developer who knows almost nothing about this toolset or problem domain.\n12. Declare the blocking edges, and then declare what the edges do not cover: exclusive file\n    ownership per ticket, shared generated artifacts, and global migration numbering. Two tickets\n    with no edge between them are still unsafe in parallel when they write the same file.\n13. Read `review.cold_read` from the indexed project record. A missing review object, a missing key,\n    an unknown value, a missing project, or an unindexed project is off. Off keeps the author\n    type-check. An implementer opening the ticket with an empty context window who still cannot do\n    it is not holding an implementation ticket: reshape it, or reclassify it `type: decision` and\n    send it back. Off and shadow keep that action; on uses the independent read. When that read is\n    unavailable, the author check decides. A ticket on the text-only single-slice light route skips\n    the dispatch. In on mode the GS-004g validator still requires `cold_read_ref`, so a light-route\n    implementation ticket cannot be published until GS-004j. Shadow and on dispatch one cold reader\n    per remaining implementation ticket, in parallel, each in its own context. Follow\n    [the delegation reference](..\u002F..\u002Freferences\u002Fshared\u002Freferences\u002Fdelegation\u002FREFERENCE.md) under \"Independent cold\n    read of a ticket\" for the packet, claims, readiness observations, rewrite cap, shadow print,\n    citation, unavailable handling and the green-to-yellow-agent raise.\n14. Self-review the mechanical checks, then publish: every acceptance criterion is covered by a\n    ticket, no ticket carries an unfinished-content marker or a \"same as the earlier ticket\"\n    instruction, and each ticket's produced names and types match the next one's consumed names\n    exactly. Under a bypass grant, report `needs-decision` listing the tickets and their hashes\n    and stop before publishing; only the supervisor's answer approves them.\n\n## Hard gates\n\nGate: a decision ticket is never emitted as executable work. A ticket that fails the zero-context\ncheck is reclassified, never shipped as an implementation ticket because the deadline is close.\nWhen `review.cold_read` is on, that check is the independent cold read, not the author's reread.\nWhen that read is unavailable, the author check decides; cite the read with its reason. When on\nand the read is unavailable, a green class rises to `yellow-agent` by the captain's Q1 decision (GS-004k), unless a live named-human lowering is in force. Only a named human may lower the class, with the reason recorded (ruling `delegation-class-is-authority-not-finding`). Off\nand shadow keep the author type-check as the outcome gate. Off and shadow do not change the class or the scorer inputs.\n\nGate: every ticket carries exact scorer output, all six named `readiness` criteria plus\n`vague_terms`, and `assumptions` items using `text` and `resolved_as`, except an unscored ticket under a delegation coverage limit, which carries every block but `delegation`. Vagueness, an open assumption\nor scorer failure stops it; no total, hand-derived class or request to delegate substitutes (ruling\n`delegation-class-is-authority-not-finding`). No factor or lowering crosses the sensitive floor\n(ruling `sensitive-surface-sets-the-floor`).\n\nGate: each readiness criterion's evidence states what was checked and where. No readiness or stop\nflag is persisted outside the schema: readiness is the six scored criteria with evidence, and the\nstop is stated in the result.\n\nGate: on a ticket whose class makes a human the author, `allowed_changes` remains the full write\nscope for the implementer. Name the agent's permitted file and symbol subset in text, in `goal` or\n`stop_conditions`, alongside non-file assistance such as research; put prohibited agent work in\n`non_goals`. On a decision ticket the boundary lives in `goal` and `non_goals`. Naming a human owner\nalone is not that boundary.\n\nGate: each unresolved vague term becomes a frontier question that proposes the observable, the\nworkload or fixture, the measurement or oracle and the pass condition, as applicable, that would\nverify the answer. Express the pass condition against the value the human supplies, for example\n`p95 of \u003Cobservable> on \u003Cworkload> is at or below the target you name`; never choose a number or\notherwise invent the missing target.\n\nGate: a direction spanning independently deployable stack phases is split in the reference's order,\nwith schema contract separate. Refusal to split emits a decision ticket that itself carries the full\nordered stack as the recommended option, in its `decision` question or its `goal`, with no exception\nalternative; size alone is guidance.\n\nGate: on a supporting host, a ticket whose class requires consultation is not approved until its\n`kb_refs` cites the consultation artifact as the delegation reference defines: a `transcript` or\n`receipt` evidence reference whose one-line `note` names it judgment evidence and says what it was\nused for. A bare path, name or URL is not evidence; an unsupported host cites none (ruling\n`advisor-consultation-follows-class`).\n\nGate: approval binds to the specification's hash, not the whole plan's. A changed specification\ndoes not inherit the old approval; take it again.\n\nGate: while a specification or review decision is open, an evidence-bearing draft, where one exists,\nis kept and retyped `decision`, and no implementation ticket exists. An open assumption is per\nslice; that slice becomes a decision ticket at the zero-context gate and unrelated slices proceed.\n\nGate: no ticket ships with an unfinished-content marker, with \"add appropriate error handling\" or\n\"handle the edge cases\" in place of the specifics, or with a pointer to another ticket in place of\nthe work.\n\nGate: evidence that invalidates a decision settled earlier in this session stops the write. Return a\nblocked-or-replan result naming the settled decision and the new evidence; never resolve it\nsilently.\n\nGate: the consensus plan gate is entered only on genuine architectural disagreement, declared high\nrisk, or a review-driven replan — never automatically on a routine breakdown. It is a protocol this\nskill enters, not a skill it starts:\n[the consensus plan gate protocol](..\u002F..\u002Freferences\u002Fshared\u002Fprotocols\u002Fconsensus-plan-gate\u002FPROTOCOL.md).\n\n| The thought | Why it is wrong | Do this instead |\n|---|---|---|\n| \"The ticket is obvious to me, so it is written clearly enough.\" | The implementer knows almost nothing about this toolset or problem domain. \"Obvious to the author\" names exactly the context the ticket fails to carry. | Write the consumed and produced signatures and the verification command, then run step 13. Off rereads as the author. Shadow and on dispatch a reader who has seen nothing else. |\n| \"This ticket is basically the earlier one — I'll say 'similar to' and save the repetition.\" | A pointer to another ticket is context the implementer's window does not contain. | Repeat the specifics in full in this ticket. |\n| \"I'll put the file paths in the specification so nobody has to guess.\" | A path in the specification settles an implementation decision the specification has not made, and the first refactor makes it wrong while it still reads authoritative. | Keep the specification at decision level; paths belong in the ticket, and only where a prototype settled them. |\n| \"New evidence contradicts what we settled an hour ago — I'll just take the better answer.\" | A decision settled earlier in the session is not the planner's to overturn quietly; the human who settled it is not in the write. | Stop the write and return a blocked-or-replan result naming the settled decision and the evidence against it. |\n| \"Their guidance is about a hundred lines a change, so this has to become three tickets.\" | Change size is a configurable starting point, not a gate, and neither it nor the test split is grounds for a finding on its own (ruling `numeric-heuristics-are-guidance`). | Slice on verifiable behavior. Where the natural slice exceeds the project's own guidance, record the exception in the project record. |\n| \"They insist on one ticket for the whole migration, so I'll keep it together.\" | Refactor, expand, flagged behavior, consumer, backfill and contract are independently deployable delivery boundaries; a request cannot collapse them. | Order the stack with contract separate. On refusal, emit a decision ticket that itself carries the full ordered stack as the recommended option, with no exception alternative. |\n| \"The readiness flag is enough.\" | A flag hides what was checked, and the ticket schema has no field for it. | Persist the six scored criteria with their evidence and state the stop in the result. |\n| \"The owner is human, so authorship is clear.\" | Ownership does not say what agent work is allowed. | Keep `allowed_changes` the implementer's full write scope; name the agent's permitted file and symbol subset and any non-file assistance in `goal` or `stop_conditions`, and prohibited agent work in `non_goals`. |\n\n## Outputs\n\n- `prd` page — the requirements when they are newly stated, published through the knowledgebase\n  adapter's `publishArtifact` under a `kb-document` placement naming kind `prd` and the scope. The\n  knowledgebase resolves the location and this skill supplies no path (ruling\n  `central-kb-owns-project-artifacts`).\n- Plan record, a run artifact with envelope schema `plan-record`\n  ([`schemas\u002Fplan-record.schema.json`](..\u002F..\u002Freferences\u002Fshared\u002Fschemas\u002Fplan-record.schema.json)) — the specification, the seams, the slicing and the dependency\n  graph, published under a `run-artifact` placement and linked from the `prd`.\n- `ticket` ([`schemas\u002Fticket.schema.json`](..\u002F..\u002Freferences\u002Fshared\u002Fschemas\u002Fticket.schema.json)), `type: implementation`, id `bound-\u003Cspec>-\u003Cslice>` — one\n  per slice, with interfaces, ownership, edges, criteria, verification, `readiness`, resolved\n  `assumptions` and the exact ticket-time `delegation` output, or, unscored under a delegation coverage limit, no `delegation` block and the unscored assumption. When `review.cold_read` is on, it\n  cites `cold_read_ref`.\n- `cold-read` ([`schemas\u002Fcold-read.schema.json`](..\u002F..\u002Freferences\u002Fshared\u002Fschemas\u002Fcold-read.schema.json)) — a run artifact per implementation ticket when\n  `review.cold_read` is shadow or on, published under a `run-artifact` placement. Off stores none.\n- `ticket`, `type: decision` — emitted for an open fork, with the three evidence blocks persisted in\n  place of the implementation ticket that could not be written.\n- At `bound.run`: the same artifacts as drafts. That operation drafts to the knowledgebase and does\n  not publish.\n\n## Side effects\n\n`artifact-write`, `scratch-write`, `kb-draft`, `kb-publish`. No `workspace-write`: this skill plans\nthe change and never makes it.\n\n`kb-publish` is a remote side effect. Its idempotency key derives from the run, the operation, the\nknowledgebase record identity and the published artifact's hash; the read-back is the record ref and\nstored hash `publishArtifact` returns, read before the write and confirmed after it\n([`adapters\u002Frunner-contract\u002FCONTRACT.md`](..\u002F..\u002Freferences\u002Fshared\u002Fadapters\u002Frunner-contract\u002FCONTRACT.md), \"Idempotency\"). A publication whose read-back cannot be\nperformed is `failed`, never complete.\n\n## Stop conditions\n\n- `complete` — the specification is approved at its hash, every acceptance criterion is covered by a\n  ticket, every implementation ticket carries the three evidence blocks (an unscored ticket under a delegation coverage limit carries readiness and assumptions, with no `delegation` block), every on-mode\n  implementation ticket cites a finished cold read, or an unavailable read with its reason and, where the ticket is scored and its computed class was green, carries `yellow-agent` or the live named-human lowering that supersedes the raise, and\n  every published artifact's read-back matched what was sent.\n- `needs-input` — a start by none of the typed command, a validated grant, a passing bypass check and the unattended policy's passing `unattended check`, which returns the\n  command to type and nothing else; no approved alignment result, an approval bound to a different\n  revision, missing delegation guidance outside the unattended policy, a project record that fails its schema, a missing grant at `bound.run`, a failed scorer, an unresolved\n  assumption or vague criterion, a document-review decision left open, a settled decision that\n  new evidence invalidated, or an on-mode cold read that still lists an unsettled decision.\n  When assessment ran, the returned draft retains `delegation`, `readiness` and `assumptions`. Under the unattended policy a delegation coverage limit never stops this phase.\n- `cap-reached` — the consensus plan gate reached its round cap, or the runner-supplied ticket\n  budget ran out. Returns the unresolved architectural question or the undecomposed remainder.\n- `cancelled` — the human ended the run before approving the specification.\n- `failed` — a configured knowledgebase is unreachable, or a publication's read-back cannot be\n  performed. A knowledgebase coverage limit — `.cursor\u002Fbin\u002Fak kb check` exit 3 (kb.unbound, kb.unregistered), a publish exit 3 (kb.read-only), kb.in-repo-missing,\n  or a missing or unknown `.cursor\u002Fbin\u002Fak kb` command — never stops this phase under any policy: reads are\n  unavailable, each skipped publish is named in the result as not published, and only exit 1 stops.\n\n## Limits\n\n- Consensus plan-gate rounds: 5 (gate, [`policies\u002Flimits.yaml`](..\u002F..\u002Freferences\u002Fshared\u002Fpolicies\u002Flimits.yaml)).\n- Implementation tickets started per run: the runner-supplied `ticket-budget` (gate when supplied).\n  A cap the runner did not supply is not enforced and not guessed; the run records that it was\n  absent.\n- Test seams a feature is verified across: as few as the feature allows, ideally one (guidance).\n- Change size: roughly one hundred lines where that is natural, and test shape: roughly 80 \u002F 15 \u002F 5\n  across unit, integration and end-to-end tests. Both are configurable starting points carried in\n  the project record, neither is enforced here, and neither is grounds for a finding on its own\n  (ruling `numeric-heuristics-are-guidance`).\n","Requirements and specification, implementation plan, dependency graph, ownership boundaries,\nacceptance criteria and verification commands. A decision ticket is never an implementation ticket.\n\n## When to use\n\n- An approved direction exists and the work needs a specification, a plan and tickets before anyone\n  builds.\n- A specification exists but nobody has settled the slicing, the blocking edges or which ticket owns\n  which file.\n- The approved direction covers several modules and no capability map has been drawn.\n- A delegated controller holds a charter naming the `spec-approval` checkpoint and an approved\n  alignment result binds to the current source revision.\n\n## Not for\n\n- Deciding what to build. An unsettled direction goes back to a human-started alignment run; this\n  skill starts from an approved result and does not reopen it.\n- A reviewed ticket that already carries its acceptance criteria and verification command. That\n  work enters at build, and re-bounding it re-decides what a reviewer already accepted.\n- Charting a multi-session effort into decision tickets and fog. That is `wayfind`.\n- Reviewing the specification for coherence or decision readiness. This skill calls `\u002Fak:doc-review`\n  for that rather than grading its own artifact.\n- A single mechanical rename with one call site and one test.\n\n## Authority\n\nAuthority: `explicit` at the public entrypoint, `delegated-grant` at the phase operation\n`bound.run`. A human starts the public entrypoint by typing `\u002Fsuper-bound`. A request in prose\nis not a start, even when it names this skill or the command. A delegated controller starts\n`bound.run` only under a runner-validated grant covering `spec-approval`, and only with a second\ngrant covering `ticket-approval` when the operation emits implementation tickets\n([`adapters\u002Frunner-contract\u002FCONTRACT.md`](..\u002F..\u002Freferences\u002Fshared\u002Fadapters\u002Frunner-contract\u002FCONTRACT.md)). Where the host cannot validate a grant, the operation\nstops for explicit invocation rather than approving on the controller's word (ruling\n`entrypoint-phase-operation-split`). No skill starts this skill directly; it calls `doc-review`,\nwhich is model-invoked, and that direction is the legal one.\n\nUnder a bypass grant (ADR-0008), a supervisor-held file stands in for the typed command for one\ntask. From the task's worktree, run `node \u003Cthis skill's directory>\u002F..\u002F..\u002Fbin\u002Fak-gate.mjs bypass check --grant \u003Cpath> --task \u003Cid>\n--phase super-bound`: exit 0 is the start, and a refusal is a stop with\n`needs-decision`. The grant starts the phase and nothing else. The specification approval at step 8\nand every ticket approval still come from the supervisor through `needs-decision`; the worker never\napproves its own specification or tickets.\n\nUnder the unattended policy (ADR-0014), `node \u003Cthis skill's directory>\u002F..\u002F..\u002Fbin\u002Fak-gate.mjs unattended\ncheck --phase super-bound` exiting 0 is the start, with no command or grant (an exception to ruling\n`entrypoint-phase-operation-split`). The approved-alignment input, open document-review decisions, the capability-map review, the specification approval and the ticket approvals then\nproceed with your own recommended answers, recorded as unattended advances and never as approvals;\na ticket whose class makes a human the author keeps that class, and a delegation coverage limit (Inputs) never stops this phase. Every implementation ticket, scored or unscored, is still recorded with acceptance criteria and named verification derived from the work source (the issue text or plan); scores and receipts are never invented. Record the `bound` gate as\n[the unattended-lifecycle reference](..\u002F..\u002Freferences\u002Fshared\u002Freferences\u002Funattended-lifecycle\u002FREFERENCE.md) says.\n\n## Inputs\n\n- An approved alignment result that binds to the current source revision. Absent, or bound to a\n  different revision: return `needs-input`. A direction approved against other code is not an\n  approval of this one.\n- Recorded project context, read through the knowledgebase adapter's `readContext`: the `prd` in\n  scope, the settled `adr` pages, and the glossary the vocabulary was agreed in. An empty result is\n  a fact; a configured knowledgebase that cannot be reached returns `failed`. The commands, and\n  what an unconfigured knowledgebase obliges (a coverage limit, never a stop), are in\n  [the knowledgebase-binding reference pack](..\u002F..\u002Freferences\u002Fshared\u002Freferences\u002Fknowledgebase-binding\u002FREFERENCE.md).\n- The project record's configured guidance ([`schemas\u002Fproject.schema.json`](..\u002F..\u002Freferences\u002Fshared\u002Fschemas\u002Fproject.schema.json)) for change size and test\n  shape. Absent: the starting points below are advisory and nothing enforces them.\n- Delegation guidance on that same project record. Outside the unattended policy, missing delegation guidance is `needs-input`. Under the unattended policy, no project record, a valid one without delegation guidance, or a missing `.cursor\u002Fbin\u002Fak delegation` command, is a delegation coverage limit: record it once naming its cause, and give each ticket no `delegation` block and an assumption, resolved `non-goal`, reading `delegation unscored: \u003Ccause> (coverage limit); floor not evaluated; packs: \u003Cids or none>; sensitive actions: \u003Cids or none>`. It never stops this phase, and every required sensitive action still stops. A missing `.cursor\u002Fbin\u002Fak delegation` command is one not on `PATH`, an unknown subcommand or a usage error from an older CLI, as in a sandbox with only `node \u003Cbundle>\u002Fbin\u002Fak-gate.mjs`; with it, a present record's validity is not checked, and the cause reads `missing .cursor\u002Fbin\u002Fak delegation command, project record validity not checked`.\n  A present project record is decided by `.cursor\u002Fbin\u002Fak delegation`, never by hand, whether or not the draft ticket carries a `delegation` block: `ak delegation: project does not match its schema: …` is `needs-input` under every policy, and `ak delegation: project has no guidance.delegation block (weights and cut points)` is the coverage limit. Decide it at step 10. A ticket-side error (`ak delegation: ticket has no delegation block to score`, or `ak delegation: ticket does not match its schema: …`) is about the draft, not the record. Under the limit the persisted unscored ticket carries no `delegation` block, seeded or default, so build has no class to pass. Only an absent project record skips `.cursor\u002Fbin\u002Fak delegation`. A present project record that fails [`schemas\u002Fproject.schema.json`](..\u002F..\u002Freferences\u002Fshared\u002Fschemas\u002Fproject.schema.json) validation is `needs-input` under every policy; with the `.cursor\u002Fbin\u002Fak delegation` command missing, the unattended policy records its validity as not checked, never as valid. Scorer inputs are never invented.\n- The project's verification recipes and surface declarations ([`schemas\u002Fproject.schema.json`](..\u002F..\u002Freferences\u002Fshared\u002Fschemas\u002Fproject.schema.json)).\n  Absent or empty: record the gap; never assume a browser, running service, trace collector or\n  command the project did not declare.\n- At `bound.run` only: a `charter` ([`schemas\u002Fcharter.schema.json`](..\u002F..\u002Freferences\u002Fshared\u002Fschemas\u002Fcharter.schema.json)) listing `spec-approval`, and\n  `ticket-approval` where tickets will be emitted. Absent: `needs-input`.\n\n## Workflow\n\n1. Check how this run was started, before any other step and before any tool call. It is started\n   only when the human's message begins with `\u002Fsuper-bound`, when a controller started the phase\n   operation `bound.run` under a validated grant, when the bypass check in Authority exits 0, or\n   when its unattended check exits 0. A\n   request in prose is not a start, even when it names this skill or the command, or asks for this\n   work without naming either. With neither, stop before reading the repository, checking inputs or\n   answering the task: the only response is to tell the human to type `\u002Fsuper-bound` followed by\n   their request.\n2. Detect before you ask. Read what the repository already states — its dependency manifest, its\n   test runner, its lint configuration, its continuous-integration configuration — report what you\n   found in two lines, and ask only what is left.\n3. When the approved direction spans more than one module, draw the capability map first: a table of\n   stable kebab-case module ids, each with its responsibility and what it depends on. The map is\n   gated like every other step; a human reviews it before any module's specification is written (under the unattended policy that review is an unattended advance, per [the reference](..\u002F..\u002Freferences\u002Fshared\u002Freferences\u002Funattended-lifecycle\u002FREFERENCE.md)).\n4. Write the specification at decision level: problem, solution, non-goals, acceptance criteria,\n   test seams, verification commands, out of scope. No file paths and no code, except a fragment a\n   prototype already settled exactly — a state machine, a reducer, a schema, a type shape. Turn\n   each vague criterion into a frontier question that proposes how the answer would be verified.\n   For each criterion, record its surface and required evidence kinds from the project declaration.\n   Load [verification evidence](..\u002F..\u002Freferences\u002Fshared\u002Freferences\u002Fverification-evidence\u002FREFERENCE.md) for the\n   vocabulary; an undeclared facility becomes a visible gap, never an invented check.\n5. Choose the test seams before the slices. The fewer seams the feature is verified across the\n   better, and the ideal number is one; name the seam you chose and why it is the highest one\n   available. Use the vocabulary the alignment run already established with\n   [the domain-modeling reference pack](..\u002F..\u002Freferences\u002Fshared\u002Freferences\u002Fdomain-modeling\u002FREFERENCE.md) rather than\n   renaming the same things here.\n6. When the caller supplies a draft ticket or scorer input, load the delegation reference and run\n   `.cursor\u002Fbin\u002Fak delegation \u003Cticket> --project \u003Cproject-record>` now. A current agent-kit CLI is a\n   prerequisite: outside the unattended policy a missing command, or a usage error from an older CLI, is reported as\n   `needs-input` naming that prerequisite, not as a scoring failure; under the unattended policy it is a delegation coverage limit (Inputs). Persist the scorer output,\n   readiness and assumptions on the evidence-bearing draft before document review; the draft is not\n   an approved implementation ticket. Under a delegation coverage limit no scorer output is persisted; readiness and assumptions are still persisted.\n7. Run `\u002Fak:doc-review` on the specification and resolve everything it returns before cutting a\n   ticket. A current review receipt bound to this specification with every decision answered\n   satisfies this step; otherwise open decisions return to the human and stop the run.\n   For a single-slice ticket whose every changed path the author claims is text-only, the light\n   route defined in [the delegation reference](..\u002F..\u002Freferences\u002Fshared\u002Freferences\u002Fdelegation\u002FREFERENCE.md) under\n   \"Light route for a text-only single-slice ticket\" governs.\n   While a specification or review decision is open, an evidence-bearing draft, where one exists, is\n   kept and retyped `decision`, and no implementation ticket exists. An open assumption is per\n   slice; that slice becomes a decision ticket at the zero-context gate and unrelated slices\n   proceed.\n8. Take the specification approval. A recorded human approval whose artifact hash equals the\n   current specification hash satisfies this step. Otherwise the plan record takes approval as\n   `specification_approval`, bound to `specification_hash`, so later slicing does not void it.\n   Under a bypass grant, report `needs-decision` naming the specification hash and stop; only the\n   supervisor's answer is the approval.\n9. Load [the delegation reference pack](..\u002F..\u002Freferences\u002Fshared\u002Freferences\u002Fdelegation\u002FREFERENCE.md) and follow its\n   ordered stack, readiness, assumptions, authorship-boundary and advisor procedures for every\n   zero-context slice.\n10. Run `.cursor\u002Fbin\u002Fak delegation \u003Cticket> --project \u003Cproject-record>` after populating its floor, evidenced\n   factors and the `class` seed the reference names; persist its complete JSON with `readiness` and\n   `assumptions` before returning, including on `needs-input`. Never derive the class in this body. Under a delegation coverage limit the ticket carries its unscored assumption in place of the scorer output; readiness and assumptions are still persisted.\n11. Give every ticket its interfaces: what it consumes from earlier tickets with exact signatures,\n    and what it produces that later tickets rely on with exact names, parameters and return types.\n    Write for a skilled developer who knows almost nothing about this toolset or problem domain.\n12. Declare the blocking edges, and then declare what the edges do not cover: exclusive file\n    ownership per ticket, shared generated artifacts, and global migration numbering. Two tickets\n    with no edge between them are still unsafe in parallel when they write the same file.\n13. Read `review.cold_read` from the indexed project record. A missing review object, a missing key,\n    an unknown value, a missing project, or an unindexed project is off. Off keeps the author\n    type-check. An implementer opening the ticket with an empty context window who still cannot do\n    it is not holding an implementation ticket: reshape it, or reclassify it `type: decision` and\n    send it back. Off and shadow keep that action; on uses the independent read. When that read is\n    unavailable, the author check decides. A ticket on the text-only single-slice light route skips\n    the dispatch. In on mode the GS-004g validator still requires `cold_read_ref`, so a light-route\n    implementation ticket cannot be published until GS-004j. Shadow and on dispatch one cold reader\n    per remaining implementation ticket, in parallel, each in its own context. Follow\n    [the delegation reference](..\u002F..\u002Freferences\u002Fshared\u002Freferences\u002Fdelegation\u002FREFERENCE.md) under \"Independent cold\n    read of a ticket\" for the packet, claims, readiness observations, rewrite cap, shadow print,\n    citation, unavailable handling and the green-to-yellow-agent raise.\n14. Self-review the mechanical checks, then publish: every acceptance criterion is covered by a\n    ticket, no ticket carries an unfinished-content marker or a \"same as the earlier ticket\"\n    instruction, and each ticket's produced names and types match the next one's consumed names\n    exactly. Under a bypass grant, report `needs-decision` listing the tickets and their hashes\n    and stop before publishing; only the supervisor's answer approves them.\n\n## Hard gates\n\nGate: a decision ticket is never emitted as executable work. A ticket that fails the zero-context\ncheck is reclassified, never shipped as an implementation ticket because the deadline is close.\nWhen `review.cold_read` is on, that check is the independent cold read, not the author's reread.\nWhen that read is unavailable, the author check decides; cite the read with its reason. When on\nand the read is unavailable, a green class rises to `yellow-agent` by the captain's Q1 decision (GS-004k), unless a live named-human lowering is in force. Only a named human may lower the class, with the reason recorded (ruling `delegation-class-is-authority-not-finding`). Off\nand shadow keep the author type-check as the outcome gate. Off and shadow do not change the class or the scorer inputs.\n\nGate: every ticket carries exact scorer output, all six named `readiness` criteria plus\n`vague_terms`, and `assumptions` items using `text` and `resolved_as`, except an unscored ticket under a delegation coverage limit, which carries every block but `delegation`. Vagueness, an open assumption\nor scorer failure stops it; no total, hand-derived class or request to delegate substitutes (ruling\n`delegation-class-is-authority-not-finding`). No factor or lowering crosses the sensitive floor\n(ruling `sensitive-surface-sets-the-floor`).\n\nGate: each readiness criterion's evidence states what was checked and where. No readiness or stop\nflag is persisted outside the schema: readiness is the six scored criteria with evidence, and the\nstop is stated in the result.\n\nGate: on a ticket whose class makes a human the author, `allowed_changes` remains the full write\nscope for the implementer. Name the agent's permitted file and symbol subset in text, in `goal` or\n`stop_conditions`, alongside non-file assistance such as research; put prohibited agent work in\n`non_goals`. On a decision ticket the boundary lives in `goal` and `non_goals`. Naming a human owner\nalone is not that boundary.\n\nGate: each unresolved vague term becomes a frontier question that proposes the observable, the\nworkload or fixture, the measurement or oracle and the pass condition, as applicable, that would\nverify the answer. Express the pass condition against the value the human supplies, for example\n`p95 of \u003Cobservable> on \u003Cworkload> is at or below the target you name`; never choose a number or\notherwise invent the missing target.\n\nGate: a direction spanning independently deployable stack phases is split in the reference's order,\nwith schema contract separate. Refusal to split emits a decision ticket that itself carries the full\nordered stack as the recommended option, in its `decision` question or its `goal`, with no exception\nalternative; size alone is guidance.\n\nGate: on a supporting host, a ticket whose class requires consultation is not approved until its\n`kb_refs` cites the consultation artifact as the delegation reference defines: a `transcript` or\n`receipt` evidence reference whose one-line `note` names it judgment evidence and says what it was\nused for. A bare path, name or URL is not evidence; an unsupported host cites none (ruling\n`advisor-consultation-follows-class`).\n\nGate: approval binds to the specification's hash, not the whole plan's. A changed specification\ndoes not inherit the old approval; take it again.\n\nGate: while a specification or review decision is open, an evidence-bearing draft, where one exists,\nis kept and retyped `decision`, and no implementation ticket exists. An open assumption is per\nslice; that slice becomes a decision ticket at the zero-context gate and unrelated slices proceed.\n\nGate: no ticket ships with an unfinished-content marker, with \"add appropriate error handling\" or\n\"handle the edge cases\" in place of the specifics, or with a pointer to another ticket in place of\nthe work.\n\nGate: evidence that invalidates a decision settled earlier in this session stops the write. Return a\nblocked-or-replan result naming the settled decision and the new evidence; never resolve it\nsilently.\n\nGate: the consensus plan gate is entered only on genuine architectural disagreement, declared high\nrisk, or a review-driven replan — never automatically on a routine breakdown. It is a protocol this\nskill enters, not a skill it starts:\n[the consensus plan gate protocol](..\u002F..\u002Freferences\u002Fshared\u002Fprotocols\u002Fconsensus-plan-gate\u002FPROTOCOL.md).\n\n| The thought | Why it is wrong | Do this instead |\n|---|---|---|\n| \"The ticket is obvious to me, so it is written clearly enough.\" | The implementer knows almost nothing about this toolset or problem domain. \"Obvious to the author\" names exactly the context the ticket fails to carry. | Write the consumed and produced signatures and the verification command, then run step 13. Off rereads as the author. Shadow and on dispatch a reader who has seen nothing else. |\n| \"This ticket is basically the earlier one — I'll say 'similar to' and save the repetition.\" | A pointer to another ticket is context the implementer's window does not contain. | Repeat the specifics in full in this ticket. |\n| \"I'll put the file paths in the specification so nobody has to guess.\" | A path in the specification settles an implementation decision the specification has not made, and the first refactor makes it wrong while it still reads authoritative. | Keep the specification at decision level; paths belong in the ticket, and only where a prototype settled them. |\n| \"New evidence contradicts what we settled an hour ago — I'll just take the better answer.\" | A decision settled earlier in the session is not the planner's to overturn quietly; the human who settled it is not in the write. | Stop the write and return a blocked-or-replan result naming the settled decision and the evidence against it. |\n| \"Their guidance is about a hundred lines a change, so this has to become three tickets.\" | Change size is a configurable starting point, not a gate, and neither it nor the test split is grounds for a finding on its own (ruling `numeric-heuristics-are-guidance`). | Slice on verifiable behavior. Where the natural slice exceeds the project's own guidance, record the exception in the project record. |\n| \"They insist on one ticket for the whole migration, so I'll keep it together.\" | Refactor, expand, flagged behavior, consumer, backfill and contract are independently deployable delivery boundaries; a request cannot collapse them. | Order the stack with contract separate. On refusal, emit a decision ticket that itself carries the full ordered stack as the recommended option, with no exception alternative. |\n| \"The readiness flag is enough.\" | A flag hides what was checked, and the ticket schema has no field for it. | Persist the six scored criteria with their evidence and state the stop in the result. |\n| \"The owner is human, so authorship is clear.\" | Ownership does not say what agent work is allowed. | Keep `allowed_changes` the implementer's full write scope; name the agent's permitted file and symbol subset and any non-file assistance in `goal` or `stop_conditions`, and prohibited agent work in `non_goals`. |\n\n## Outputs\n\n- `prd` page — the requirements when they are newly stated, published through the knowledgebase\n  adapter's `publishArtifact` under a `kb-document` placement naming kind `prd` and the scope. The\n  knowledgebase resolves the location and this skill supplies no path (ruling\n  `central-kb-owns-project-artifacts`).\n- Plan record, a run artifact with envelope schema `plan-record`\n  ([`schemas\u002Fplan-record.schema.json`](..\u002F..\u002Freferences\u002Fshared\u002Fschemas\u002Fplan-record.schema.json)) — the specification, the seams, the slicing and the dependency\n  graph, published under a `run-artifact` placement and linked from the `prd`.\n- `ticket` ([`schemas\u002Fticket.schema.json`](..\u002F..\u002Freferences\u002Fshared\u002Fschemas\u002Fticket.schema.json)), `type: implementation`, id `bound-\u003Cspec>-\u003Cslice>` — one\n  per slice, with interfaces, ownership, edges, criteria, verification, `readiness`, resolved\n  `assumptions` and the exact ticket-time `delegation` output, or, unscored under a delegation coverage limit, no `delegation` block and the unscored assumption. When `review.cold_read` is on, it\n  cites `cold_read_ref`.\n- `cold-read` ([`schemas\u002Fcold-read.schema.json`](..\u002F..\u002Freferences\u002Fshared\u002Fschemas\u002Fcold-read.schema.json)) — a run artifact per implementation ticket when\n  `review.cold_read` is shadow or on, published under a `run-artifact` placement. Off stores none.\n- `ticket`, `type: decision` — emitted for an open fork, with the three evidence blocks persisted in\n  place of the implementation ticket that could not be written.\n- At `bound.run`: the same artifacts as drafts. That operation drafts to the knowledgebase and does\n  not publish.\n\n## Side effects\n\n`artifact-write`, `scratch-write`, `kb-draft`, `kb-publish`. No `workspace-write`: this skill plans\nthe change and never makes it.\n\n`kb-publish` is a remote side effect. Its idempotency key derives from the run, the operation, the\nknowledgebase record identity and the published artifact's hash; the read-back is the record ref and\nstored hash `publishArtifact` returns, read before the write and confirmed after it\n([`adapters\u002Frunner-contract\u002FCONTRACT.md`](..\u002F..\u002Freferences\u002Fshared\u002Fadapters\u002Frunner-contract\u002FCONTRACT.md), \"Idempotency\"). A publication whose read-back cannot be\nperformed is `failed`, never complete.\n\n## Stop conditions\n\n- `complete` — the specification is approved at its hash, every acceptance criterion is covered by a\n  ticket, every implementation ticket carries the three evidence blocks (an unscored ticket under a delegation coverage limit carries readiness and assumptions, with no `delegation` block), every on-mode\n  implementation ticket cites a finished cold read, or an unavailable read with its reason and, where the ticket is scored and its computed class was green, carries `yellow-agent` or the live named-human lowering that supersedes the raise, and\n  every published artifact's read-back matched what was sent.\n- `needs-input` — a start by none of the typed command, a validated grant, a passing bypass check and the unattended policy's passing `unattended check`, which returns the\n  command to type and nothing else; no approved alignment result, an approval bound to a different\n  revision, missing delegation guidance outside the unattended policy, a project record that fails its schema, a missing grant at `bound.run`, a failed scorer, an unresolved\n  assumption or vague criterion, a document-review decision left open, a settled decision that\n  new evidence invalidated, or an on-mode cold read that still lists an unsettled decision.\n  When assessment ran, the returned draft retains `delegation`, `readiness` and `assumptions`. Under the unattended policy a delegation coverage limit never stops this phase.\n- `cap-reached` — the consensus plan gate reached its round cap, or the runner-supplied ticket\n  budget ran out. Returns the unresolved architectural question or the undecomposed remainder.\n- `cancelled` — the human ended the run before approving the specification.\n- `failed` — a configured knowledgebase is unreachable, or a publication's read-back cannot be\n  performed. A knowledgebase coverage limit — `.cursor\u002Fbin\u002Fak kb check` exit 3 (kb.unbound, kb.unregistered), a publish exit 3 (kb.read-only), kb.in-repo-missing,\n  or a missing or unknown `.cursor\u002Fbin\u002Fak kb` command — never stops this phase under any policy: reads are\n  unavailable, each skipped publish is named in the result as not published, and only exit 1 stops.\n\n## Limits\n\n- Consensus plan-gate rounds: 5 (gate, [`policies\u002Flimits.yaml`](..\u002F..\u002Freferences\u002Fshared\u002Fpolicies\u002Flimits.yaml)).\n- Implementation tickets started per run: the runner-supplied `ticket-budget` (gate when supplied).\n  A cap the runner did not supply is not enforced and not guessed; the run records that it was\n  absent.\n- Test seams a feature is verified across: as few as the feature allows, ideally one (guidance).\n- Change size: roughly one hundred lines where that is natural, and test shape: roughly 80 \u002F 15 \u002F 5\n  across unit, integration and end-to-end tests. Both are configurable starting points carried in\n  the project record, neither is enforced here, and neither is grounds for a finding on its own\n  (ruling `numeric-heuristics-are-guidance`).\n",{"name":5,"license":15,"metadata":24,"description":7},{"ak":25,"ak_catalog_id":5},{"mode":26},"manual","main","e0232821c4abbcd4338d6018c20fb70f1b74336b",".cursor\u002Fskills\u002Fsuper-bound",3,"https:\u002F\u002Fgithub.com\u002FPibomeister\u002Fagent-kit","https:\u002F\u002Fgithub.com\u002FPibomeister","www.eduardopicazoenriquez.com","2026-11-15 00:56:58",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add Pibomeister\u002Fagent-kit --skill super-bound",{"tool":41,"command":42},"bunx","bunx skills add Pibomeister\u002Fagent-kit --skill super-bound",{"tool":44,"command":45},"pnpm","pnpm dlx skills add Pibomeister\u002Fagent-kit --skill super-bound","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FPibomeister\u002Fagent-kit\u002Fblob\u002Fmain\u002F.cursor\u002Fskills\u002Fsuper-bound\u002FSKILL.md",true,[],[50,57,62,67,72,77],{"skillNo":51,"name":52,"nameZh":6,"description":53,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":54,"categories":55,"keywords":56,"publishedAt":19},"01M7D3JZP2026RGY6XX1MC3NQQ","alpha","Human-started command: it runs only when the human's message begins with `\u002Fak:alpha`. On any other request do not load or follow it; tell the human to type that command. Runs the alpha workflow when a human asks for it.","https:\u002F\u002Fgithub.com\u002FPibomeister\u002Fagent-kit\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fvalid\u002Fminimal\u002Fskills\u002Falpha\u002FSKILL.md",[],[],{"skillNo":58,"name":52,"nameZh":6,"description":53,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":59,"categories":60,"keywords":61,"publishedAt":19},"01M7D3JA593Q3RBYJXKVZ37Y2K","https:\u002F\u002Fgithub.com\u002FPibomeister\u002Fagent-kit\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Finvalid\u002F25-article-tier-outside-vocabulary\u002Fskills\u002Falpha\u002FSKILL.md",[],[],{"skillNo":63,"name":52,"nameZh":6,"description":53,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":19},"01M7D3HQDDAZTAPGWCPGDPNVBQ","https:\u002F\u002Fgithub.com\u002FPibomeister\u002Fagent-kit\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Finvalid\u002F24-article-without-triggers\u002Fskills\u002Falpha\u002FSKILL.md",[],[],{"skillNo":68,"name":52,"nameZh":6,"description":53,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":19},"01M7D3HK074TK3ZWK1ZZNQVPB0","https:\u002F\u002Fgithub.com\u002FPibomeister\u002Fagent-kit\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Finvalid\u002F23-enforced-by-without-predicate\u002Fskills\u002Falpha\u002FSKILL.md",[],[],{"skillNo":73,"name":52,"nameZh":6,"description":53,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":19},"01M7D3HGHQM5C5TBSXBCE2WFHW","https:\u002F\u002Fgithub.com\u002FPibomeister\u002Fagent-kit\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Finvalid\u002F22-article-without-source-span\u002Fskills\u002Falpha\u002FSKILL.md",[],[],{"skillNo":78,"name":52,"nameZh":6,"description":53,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":19},"01M7D3HDV6HMK2ZHRM0P368KNT","https:\u002F\u002Fgithub.com\u002FPibomeister\u002Fagent-kit\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Finvalid\u002F21-fragment-redeclares-id\u002Fskills\u002Falpha\u002FSKILL.md",[],[]]