codex-orchestrator 2.0.11 → 2.0.12

package/internal-workflow/skills/implementation-spec-maker/references/source-modes.md

@@ -1,32 +0,0 @@
-# Source Modes
-
-Read the section matching the active source. Apply the common source-authority and evidence rules from `SKILL.md` in every mode.
-
-## Plan-Based
-
-- Treat the approved plan as architectural authority.
-- Preserve its scope, vertical-slice boundaries, guardrails, rejected paths, required docs, validation, and blocking assumptions.
-- Block when missing guardrails would let implementation drift or require redesign.
-
-## Issue-Based
-
-- Treat one issue's acceptance criteria as the execution contract; parent material supplies product context, not sibling-ticket authority.
-- Read comments for changed decisions, blockers, credentials, external contracts, live prerequisites, and rejected approaches.
-- Preserve relevant `Implementation preparation`, `External contracts`, `Verification`, and `Blocked by` content.
-- Use `source_type: "issue"` when no plan exists. Do not block merely because `source_plan` is absent.
-- Block when acceptance criteria are ambiguous, non-verifiable, or contradicted by repository evidence.
-
-## Contract Discovery
-
-- Specify discovery only: exact sources/tools to inspect, evidence to collect, decision record to update, and issue fields/comments to update.
-- Confirm the API surface, auth/secret source, license or terms constraints, acquisition path, deterministic fixture strategy, live-validation prerequisite, and rejected acquisition paths that matter to later implementation.
-- Do not include downstream implementation slices while material external behavior remains unconfirmed.
-
-## Revision
-
-- Reconcile the entire existing spec against new authority and current repository evidence.
-- Treat a changed claim, mechanism/owner, source of truth, evidence unit/cardinality, or blocked/failure meaning as a semantic change; invalidate the affected approval coverage instead of translating it into broader wording.
-- Preserve still-valid completed `[x]` items exactly.
-- Reopen invalid completed items to `[ ]` and add a short `Revision Note:` with evidence.
-- Never silently delete progress or defect history.
-- Mark the spec blocked when completed history or its contract ledger cannot be trusted.

package/internal-workflow/skills/implementation-spec-maker/references/spec-template.md

@@ -1,146 +0,0 @@
-# Implementation Spec Template
-
-Use the base template for every spec. Add conditional blocks only when their trigger applies, and remove every instruction or placeholder before review.
-
-## Base Template
-
-```markdown
----
-title: "<title>"
-created_at: "<ISO timestamp>"
-source_type: "plan | issue | contract-discovery | revised-spec"
-source_plan: "<absolute path or None>"
-source_issues:
-  - "<URL/reference or None>"
-status: "draft | ready | blocked"
-execution_model: "single-agent | multi-agent"
-spec_mode: "compact | full"
-implementation_size: "small | medium | large"
-expected_repositories: <positive integer>
-review_profile: "simple | medium | high"
-review_reasons:
-  - "<signal: evidence>"
-review_outcome: "Pending"
-review_verdict: "Not run"
-review_coverage: "Not reviewed"
-review_passes: "0"
----
-
-## 1. Execution Context
-- **Goal:** <one observable outcome>
-- **Source Material:** <exact references>
-- **Approved Scope:** <strict allowed work>
-- **Out of Scope:** <explicit exclusions or None>
-- **Minimum Solution:** <direct path through existing owners and public seams>
-- **Added Complexity:** None | <repeat one entry per mechanism: `<mechanism>` — required for `<invariant or evidenced failure>`; without it `<concrete breakage>`>
-- **Primary Risk:** <main correctness or coordination risk>
-
-## 2. Preconditions And Evidence
-- **Required Services / Env / Fixtures:** <exact requirements or None>
-- **Blocking Unknowns:** <exact unknowns when blocked, otherwise None>
-- **Confirmed Targets:** <minimal evidence-backed paths and symbols>
-- **Confirmed Commands:** <exact commands>
-- **Protected Paths / Rejected Approaches:** <items or None>
-- **Source of Truth:** <existing owner whenever behavior/data can drift; otherwise omit>
-- **New Boundaries:** <only when ownership or a public seam changes; otherwise omit>
-
-## 3. Execution Slices
-
-### Slice 1 — <narrow end-to-end behavior>
-- [ ] **Test/Proof First:** <failing behavior test or exact observable proof>
-- [ ] **Target:** `<exact/path:symbol>` — <specific action>
-- [ ] **Validation:** <target-level check>
-- [ ] **Exit Gate:** <command or proof that the slice works end-to-end>
-
-<repeat only for independently verifiable behavior slices>
-
-## 4. Validation And Done Criteria
-- [ ] **Lint/Format:** <exact command or Not applicable with reason>
-- [ ] **Typecheck/Build:** <exact command or Not applicable with reason>
-- [ ] **Tests:** <exact command or Not applicable with reason>
-- [ ] **Architecture Check:** <exact command or Not applicable with reason>
-- [ ] **Live/Manual Proof:** <exact flow or Not applicable with reason>
-- [ ] **Behavior Proof:** <observable acceptance proof>
-- [ ] **Reconciliation:** every unchecked item is unfinished, blocked with evidence, or intentionally not applicable.
-- [ ] **Final Handoff Requirements:** <high only: extended `$spec-implementer` Final Risk Handoff plus task-specific deviations; omit for ordinary medium work>
-```
-
-## Conditional Blocks
-
-### Contract Test Ledger
-
-Add for contract-heavy behavior using the shared Contract Test Ledger referenced by `SKILL.md`. Keep one row per material invariant and place it before execution slices.
-
-### Review Checkpoint And Focus
-
-Add a checkpoint only when the risky target becomes stable before later slices. Otherwise put this compact block in final review coverage:
-
-```markdown
-## Review Focus
-- **Mandatory Lenses:** <applicable lenses>
-- **Targeted Recipes:** <applicable recipes or None>
-- **Bug Classes:** <concrete failures to hunt>
-```
-
-### Risk Controls
-
-Add in `full` mode only for applicable ambiguity:
-
-```markdown
-## Risk Controls
-- **Source of Truth:** <owner>
-- **Safety / Contract / State Constraints:** <only applicable constraints>
-- **Forbidden Scope:** <tempting but rejected paths>
-- **Review Timing:** <stable early checkpoint or concrete final-review focus>
-```
-
-### Write Scope Summary
-
-Add for multi-agent work, generated artifacts, broad runtime changes, or when phase targets do not make the write set auditable.
-
-```markdown
-## Write Scope Summary
-- `<path>` — <Create | Update | Delete>; <responsibility>
-```
-
-### Integrator Coordination Contract
-
-Require only when `execution_model: "multi-agent"`:
-
-```markdown
-## Integrator Coordination Contract
-| Agent | Exclusive Write Scope | Handoff | Merge Phase |
-| --- | --- | --- | --- |
-| <agent> | <disjoint paths> | <artifact> | <order> |
-
-- **Integrator Owner:** <owner>
-- **Forbidden Overlap:** <paths/contracts>
-- **Final Duties:** <integration, validation, reconciliation>
-```
-
-### Halt Conditions
-
-Add only when the common contradiction/guessing stop rule is insufficient. Use 3–6 task-specific conditions.
-
-### Defect Closure Notes
-
-Add only when review returns defects:
-
-```markdown
-## Defect Closure Notes
-- **Review Summary:** <pass counts and coverage>
-- **Verified Defects:** <stable IDs or None>
-- **Accepted Risks:** <stable IDs, authority, and reason or None>
-- **Open Defects:** <stable IDs or None>
-```
-
-## Terminal Review Metadata
-
-Replace the temporary frontmatter values after the owner review loop returns a real terminal outcome:
-
-```yaml
-review_outcome: "Approved | Blocked | Waived"
-review_verdict: "Approved | Needs Work | Rejected | Not run"
-review_coverage: "<covered lenses or Not reviewed>"
-review_passes: "<total; full/closure/fresh counts>"
-```

package/internal-workflow/skills/implementation-spec-review/SKILL.md

@@ -1,131 +0,0 @@
----
-name: "implementation-spec-review"
-description: "Review compact or full implementation specs for deterministic executability, proportional scope, validation coverage, safety, and zero-guess execution before coding starts."
----
-
-# Implementation Spec Review
-
-Decide whether a saved implementation spec can be executed safely without
-guessing. Review execution quality, not the product idea. Do not rewrite the
-spec unless explicitly asked.
-
-Read:
-
-- `references/review-loop.md` when called by `$implementation-spec-maker`;
-- `../../docs/agents/confidence-rubric.md` for defect confidence;
-- `../../docs/agents/contract-test-ledger.md` only when the spec changes a
-  material behavior contract.
-
-## Independent Dimensions
-
-Keep these classifications independent:
-
-- `spec_mode: compact | full` — document/coordination density;
-- `implementation_size: small | medium | large` — delivery shape;
-- `review_profile: simple | medium | high` — consequence and uncertainty;
-- `expected_repositories` — approved repository count.
-
-Compact may describe broad or high-risk work when ownership, sequencing, and
-proof remain deterministic. Full is justified only when concrete coordination,
-contract, safety, ownership, or validation ambiguity cannot fit clearly in the
-compact form. Never request full-mode tables or ceremony merely from size or
-risk labels.
-
-## Adapter Contract
-
-When called by the maker, use the mode and lenses supplied by
-`references/review-loop.md`, reuse supplied defect IDs, and return actual
-coverage. A reviewer child executes this Adapter inline and never spawns a
-grandchild. If root receives a direct review request, it launches the
-profile-selected reviewer instead of self-reviewing.
-
-A standalone reviewer performs one bounded Full over all applicable lenses and
-returns only `Approved | Needs Work | Rejected`; it does not invent owner state
-or claim Closure.
-
-## Minimum Solution First
-
-Begin every Full review with the evidence-backed scope delta, before checking whether the proposed implementation is detailed enough:
-
-1. Identify behavior already implemented and require preservation/regression proof instead of reimplementation.
-2. Challenge every new endpoint, service, durable state, configuration input, schema/public contract, repository, and data owner against an existing owner or seam.
-3. Require one approved requirement or concrete failure path for each surviving mechanism. If deletion still satisfies behavior, invariants, and proof, report the mechanism as excess.
-4. Treat invented product values, copy, eligibility policy, thresholds, and defaults as authority gaps when they shape observable behavior; detailed implementation does not resolve them.
-
-Prefer the smallest repair in this order: delete excess, reuse an existing owner/seam, narrowly extend an existing contract, then add a new mechanism only when the earlier options cannot satisfy a named invariant.
-
-## Review Lenses
-
-Scale depth to the profile and inspect only applicable lenses:
-
-- **Determinism and evidence:** execution-critical paths, symbols, commands,
-  contracts, fixtures, and claims are confirmed rather than invented.
-- **Scope and minimum solution:** the spec preserves approved scope,
-  distinguishes `preserve + regression proof` from new work, uses existing
-  owners/seams, and ties every added mechanism to a requirement or concrete
-  failure path.
-- **Sequencing and ownership:** phases are safe, sources of truth are explicit
-  where drift is possible, and multi-agent write scopes are disjoint.
-- **Validation:** each behavior has an observable proof; contract-risk work maps
-  each material invariant to its first failing test or exact blocked proof.
-- **Preconditions and stop conditions:** required services, data, env, fixtures,
-  and destructive/sensitive constraints are explicit when applicable.
-- **Review focus:** ordinary work relies on one final review; only an explicit
-  stable high-risk slice gets an intermediate checkpoint.
-- **Revision integrity:** current content matches its authority and preserves
-  still-valid completed work.
-- **Completion:** another agent can tell what to do, what proves success, when
-  to stop, and what remains blocked.
-
-Before accepting the supplied scope delta, independently recover each material claim from the raw authority and compare its mechanism/owner, source of truth, evidence unit/cardinality, and blocked/failure meaning. Report compressed or missing decisions. Challenge each material proof with: can this source observe the exact claim, and can the gate pass while the claim is false? Shared proofs across platforms, providers, tenants, regions, or modes require evidenced equivalence in mechanism, truth source, granularity, timing/redaction, and failure semantics.
-
-## Proportional Expectations
-
-Approve a compact spec when targets, ordered work, observable proof, and stop
-conditions are exact enough for the task. Do not require source-of-truth tables,
-file matrices, long halt lists, multi-agent contracts, or defect sections when
-no concrete ambiguity needs them.
-
-A lean full spec normally adds only applicable `Risk Controls`, exact phase
-targets/proof, and—when needed—write-scope or integrator coordination. Missing
-ownership, validation, safety, or handoff detail is a defect; missing formatting
-ceremony is not.
-
-Prefer deleting or narrowing an unsafe proposal before adding flags, telemetry,
-fallbacks, compatibility paths, or rollout machinery. Optional improvements
-remain optional unless source authority approves them.
-
-Do not approve a duplicate public seam merely because it is internally consistent. Do not ask for more detailed recovery, configuration, analytics, or compatibility machinery until the mechanism itself passes the deletion challenge.
-
-## Defects And Decision
-
-- **Blocker:** unsafe or impossible to execute as written.
-- **Execution risk:** executable but likely to drift or require rework.
-- **Improvement:** useful but not required for safe execution.
-
-Reject exact-looking but ungrounded paths/contracts, unresolved placeholders or
-alternative commands, validation that cannot prove the intended behavior,
-overlapping multi-agent ownership, missing material safety constraints, or any
-step that requires invention.
-
-Use:
-
-- `Approved` when the current spec is deterministic, bounded, proportional, and
-  executable without guessing;
-- `Needs Work` for repairable ambiguity, weak proof, or excess ceremony;
-- `Rejected` when execution would be unsafe or depend on invented decisions.
-
-## Output
-
-Answer in Russian and keep technical terms in English. Return:
-
-1. `Вердикт` and one-sentence reason.
-2. `Режим и покрытие` with Full/Closure and actual lenses.
-3. Short `Determinism / Evidence / Validation / Safety` scores from 0 to 2.
-4. Evidence-backed defects first, with supplied ID or `NEW-<LENS>-NN`, class,
-   confidence, failure, evidence, smallest repair, and affected section.
-5. Exact changes needed before execution, or `Ничего`.
-6. Only genuinely blocking questions, or `Нет`.
-
-Do not repeat the spec, propose broad redesign, or turn optional cleanup into a
-mandatory gate.

package/internal-workflow/skills/implementation-spec-review/agents/openai.yaml

@@ -1,6 +0,0 @@
-interface:
-  display_name: "Implementation Spec Review"
-  short_description: "Review one implementation spec"
-  default_prompt: "Review the supplied spec through the assigned package-owned operation and return its exact JSON report."
-policy:
-  allow_implicit_invocation: false

package/internal-workflow/skills/implementation-spec-review/evals/evals.json

@@ -1,78 +0,0 @@
-{
-  "schema_version": 1,
-  "skill": "implementation-spec-review",
-  "cases": [
-    {
-      "id": "artifact-profile-by-consequence",
-      "prompt": "Review one broad but reversible spec and one narrow spec with irreversible data impact and unclear recovery ownership.",
-      "expected": ["broad reversible may remain medium", "narrow dangerous uncertain spec is high"],
-      "forbidden": ["classify from file count or spec mode"]
-    },
-    {
-      "id": "artifact-scope-conservation",
-      "prompt": "A review can repair the spec either by deleting an unnecessary mechanism or by adding flags, telemetry, and fallback infrastructure.",
-      "expected": ["prefer the smallest scope-preserving repair"],
-      "forbidden": ["add unapproved operational machinery"]
-    },
-    {
-      "id": "artifact-approval-invalidation",
-      "prompt": "An approved spec receives a substantive execution change after review.",
-      "expected": ["invalidate approval for the changed revision", "review only invalidated coverage"],
-      "forbidden": ["execute under stale approval", "restart unrelated coverage"]
-    },
-    {
-      "id": "artifact-existing-seam-extension",
-      "prompt": "A spec proposes a second public access endpoint and new client loader although the existing versioned endpoint can accept optional fields without breaking callers.",
-      "expected": ["report excess scope", "prefer a narrow extension of the existing endpoint and loader"],
-      "forbidden": ["approve the duplicate seam because its contract is detailed", "add compatibility machinery for the duplicate endpoint"]
-    },
-    {
-      "id": "artifact-already-implemented-preservation",
-      "prompt": "Repository evidence proves the target screen already displays the current plan and remaining time, but the spec lists both as new implementation work.",
-      "expected": ["reclassify existing behavior as preserve plus regression proof", "limit implementation to the actual remaining delta"],
-      "forbidden": ["plan a second implementation", "ignore current code evidence"]
-    },
-    {
-      "id": "artifact-invented-product-policy",
-      "prompt": "The source requires configurable lookback and cooldown periods but supplies no values; the spec invents defaults and builds configuration, validation, and analytics around them.",
-      "expected": ["treat material values as an authority gap", "block before expanding the technical contract"],
-      "forbidden": ["approve invented defaults", "reward extra implementation detail as determinism"]
-    },
-    {
-      "id": "artifact-closure-complexity-guard",
-      "prompt": "A repair for one failure-contract defect adds a service, durable state machine, configuration input, and public DTO. Review the repair in Closure.",
-      "expected": ["verify the supplied defect", "challenge each added mechanism against existing seams", "report scope change without starting a separate simplification review"],
-      "forbidden": ["verify only the old defect ID", "automatically launch a fresh Full"]
-    },
-    {
-      "id": "artifact-local-repair-review-budget",
-      "prompt": "A consolidated repair changes only wording and one existing validation command while preserving scope, owners, public contracts, and mandatory-lens coverage.",
-      "expected": ["use coordinator verification for ordinary findings", "reuse valid Full coverage"],
-      "forbidden": ["launch Closure for ordinary findings", "launch a fresh Full because the revision changed"]
-    },
-    {
-      "id": "artifact-authority-compression",
-      "prompt": "Raw authority replaces a per-item provider mechanism with aggregate reporting, but the revised spec calls it only privacy-preserving processing and keeps per-item timestamp proof.",
-      "expected": ["recover the concrete authority change", "reject the incompatible proof cardinality", "require a fresh Full"],
-      "forbidden": ["trust the compressed scope delta", "approve a per-item proof for an aggregate claim"]
-    },
-    {
-      "id": "artifact-variant-false-symmetry",
-      "prompt": "Two platforms share one product goal but use different mechanisms, sources of truth, reporting delays, and redaction rules; the spec gives them one identical exit gate.",
-      "expected": ["split the variant proof contracts unless equivalence is evidenced", "test whether each source can observe its exact claim"],
-      "forbidden": ["approve symmetry from the shared product goal"]
-    },
-    {
-      "id": "artifact-closure-semantic-change",
-      "prompt": "During Closure a repair changes the source of truth and proof from individual records to an aggregate report while leaving the implementation owner unchanged.",
-      "expected": ["invalidate affected coverage", "start a fresh Full for the semantic change"],
-      "forbidden": ["verify only the old defect", "treat unchanged code ownership as sufficient"]
-    },
-    {
-      "id": "artifact-proof-only-repair",
-      "prompt": "Full review finds aggregate proof for an unchanged per-item claim; the repair substitutes an existing compatible per-item proof without changing authority, claim, owner, or source of truth.",
-      "expected": ["reuse valid Full coverage", "verify the affected proof through coordinator verification or normal Closure triggers"],
-      "forbidden": ["start a fresh Full for the proof correction"]
-    }
-  ]
-}

package/internal-workflow/skills/implementation-spec-review/references/review-loop.md

@@ -1,121 +0,0 @@
-# Implementation Spec Review Loop
-
-This reference owns review orchestration for specs created by
-`implementation-spec-maker`. Read it when the maker requests artifact review.
-The reviewer skill remains the Adapter; the shared review mechanics live in
-`../../../docs/agents/review-protocol.md`.
-
-## Contract
-
-Input:
-
-- saved spec and pinned revision;
-- source authority and approved decisions;
-- evidence needed to verify execution claims;
-- optional user-raised review profile.
-
-Output:
-
-- `outcome: Approved | Blocked | Waived`;
-- `adapter_verdict: Approved | Needs Work | Rejected | Not run`;
-- `review_profile: simple | medium | high` and evidence-backed reasons;
-- mandatory-lens coverage and unresolved defects.
-
-The Adapter returns only its verdict. The root maps preflight, convergence, and
-waiver state to the artifact outcome.
-
-## Preflight And Profile
-
-Before launching a reviewer, confirm source authority, approved scope, current
-spec revision, and mandatory external evidence. Save a useful blocked spec when
-a product or contract decision is missing; do not launch review to discover a
-known authority gap.
-
-Require an evidence-backed scope delta before review: approved behavior, current capability/owner/seam, and the smallest remaining implementation delta for each material requirement. Already implemented behavior is preservation/regression scope. Unresolved product values, copy, policy, thresholds, or ownership choices that materially shape behavior block preflight instead of receiving invented defaults.
-
-`medium` is the default. Use:
-
-- `simple` for one narrow owner with direct proof and no material uncertainty;
-- `medium` for all ordinary specs, including multi-file, API, persistence, or
-  stateful work with clear ownership and bounded proof;
-- `high` only when a sensitive mechanism has both a material failure
-  consequence and an uncertainty amplifier such as unclear ownership,
-  cross-trust effects, non-local recovery, or an unproven external contract.
-
-File count and implementation size never select `high`. The user may raise but
-not lower an evidence-backed profile.
-
-## Scope And Capsule
-
-Review the smallest approved solution. Risk may strengthen proof but does not
-authorize flags, telemetry, compatibility paths, generic fallbacks, or rollout
-machinery unless the source or a concrete failure requires them.
-
-Give each reviewer a bounded capsule containing the current spec, authority,
-approved scope, scope delta, current owners/seams, evidence, review question,
-assigned lenses, and current defect records. Name behavior that already exists
-and the justification for every proposed new endpoint, service, durable state,
-configuration input, schema/public contract, repository, or data owner. For
-Closure also include the repaired sections, affected contracts, and repair
-complexity delta. Do not pass raw parent history or unrelated inventories.
-
-## Topology
-
-- `simple`: one `reviewer_fast`, one bounded Full.
-- `medium`: one `reviewer_standard`, one bounded Full.
-- `high`: two parallel `reviewer_deep` sessions with disjoint primary lenses:
-  Architecture/Execution and Failure/Contracts.
-
-Root launches and aggregates reviewers. A reviewer child runs the
-`implementation-spec-review` Adapter inline and never spawns another reviewer.
-Reuse valid coverage for the same revision and question. Parallel high-profile
-reviewers are one Full review round, not sequential rounds.
-
-After one consolidated repair, coordinator verification is enough for ordinary
-medium/low findings. Use shared-protocol Closure only for critical/high defects,
-protected trust/data/concurrency/shared-contract impact, or invalidated
-mandatory coverage.
-
-The default budget is one Full round, one consolidated repair, and at most one
-Closure round. Closure verifies its supplied defects and runs a bounded
-complexity guard over the repair delta:
-
-1. Did the repair add a new integration boundary or durable mechanism?
-2. Can it be removed or replaced by an existing owner/seam?
-3. Did it change approved scope?
-
-This guard is part of Closure, not a separate simplification review. A further
-targeted Closure is exceptional and requires a newly introduced critical/high
-defect plus materially changed target or evidence; otherwise coordinator
-verification or the shared no-progress/blocked outcome applies.
-
-Start a fresh Full only when an authority or approved-contract change
-invalidates existing mandatory coverage by changing the observable claim,
-primary mechanism/owner, source of truth, required evidence unit/cardinality,
-variant-equivalence assumption, blocked/failure meaning, approved scope,
-repository/data owner, public API, or durable workflow. Closure cannot absorb
-such a semantic change. A repair that only replaces incompatible proof with
-proof matching an unchanged reviewed claim uses coordinator verification or
-Closure under the normal triggers; wording, command, and other local repairs
-also reuse valid coverage.
-
-## Approval
-
-Return `Approved` only when the current saved revision matches source authority,
-mandatory lenses are covered, and every blocking defect is verified. Any
-substantive edit invalidates approval; lifecycle metadata alone does not.
-
-Return `Blocked` when authority/evidence is missing, repair needs a product or
-ownership decision, no substantive repair exists, or shared no-progress rules
-apply. Return `Waived` only after explicit user instruction and keep skipped
-coverage visible; an open blocker still maps the artifact to `Blocked`.
-
-Map outcomes to spec status:
-
-- `Approved` -> `ready`;
-- `Blocked` -> `blocked`;
-- eligible `Waived` -> `ready` with visible waiver metadata.
-
-Report profile, outcome, Adapter verdict, mandatory coverage, verified/open
-defects, and skipped checks. Do not report counters or session history for a
-normal one-review flow.

package/internal-workflow/skills/small-task-implementer/SKILL.md

@@ -1,112 +0,0 @@
----
-name: small-task-implementer
-description: Implement small low-risk coding tasks with narrow edits and targeted validation. Use for tiny local fixes, UI/copy changes, config/build corrections, or simple tests that do not change a shared API, DTO, schema, persistence, auth, or other review-gated contract.
----
-
-# Small Task Implementer
-
-Use this skill for fast, bounded implementation when creating a PRD and approved ticket-delivery flow would be disproportionate.
-
-## Fit Gate
-
-Proceed only when all are true:
-
-- The requested behavior is clear or can be inferred from local code/tests without a product decision.
-- The change is expected to touch one small area or a few tightly related files.
-- There is a narrow validation path: targeted test, lint/typecheck, build check, UI proof, or direct command.
-- The task does not require a new plan, PRD, issue breakdown, implementation spec, migration, rollout, or multi-agent orchestration.
-- The change does not alter a shared API, DTO, schema, persistence, auth,
-  permission, payment, cache, concurrency, background-job, navigation, or other
-  contract covered by `docs/agents/review-gates.md`.
-
-For a tiny local behavior change that still fits this gate, `$tdd` is an
-independent proof method: activate it when the global TDD Fit Gate passes. Do
-not relabel a feature as a bug or use `$code-debugger` unless repository
-evidence confirms a defect.
-
-Escalate out of the tiny-task route when the work has more than one coherent
-behavior, a broad ownership boundary, material rollback/recovery risk, unclear
-product intent, no credible affected validation, or genuine multi-agent/live
-coordination. Statefulness alone does not require escalation into planning or
-orchestration; a clear API, persistence, cache, queue, or DTO change normally
-becomes direct medium implementation.
-
-Escalation rule:
-
-- For clear authority and one coherent outcome, escalate to direct medium root
-implementation under `$tdd`, affected validation, and one final review when
-`review-gates.md` applies.
-- Use optional `$grilling`, then `$spec-to-tickets` and `$tickets-orchestrator`,
-  only for unresolved product decisions or a real approved ticket graph,
-  delivery dependency, or explicit orchestration request.
-- For one risky behavior or technical contract, prefer one approved ticket and mark `compact spec` or `standard spec` only when the ticket plus repository evidence cannot remove execution ambiguity.
-- For several tickets sharing one unresolved contract or validation path, make the contract-defining ticket block its consumers; merge tickets that cannot be specified or verified independently instead of creating a wave-level implementation spec.
-- Escalate if the bug requires Bugfix Quality Gate analysis across multiple paths, states, async events, persistence, auth, cache, retries, workers, or contracts.
-
-## Workflow
-
-1. Inspect local context just enough to confirm fit.
-   - Read repo instructions and the smallest relevant code/test files.
-   - Check `git status --short` before editing.
-   - Preserve unrelated dirty work.
-
-2. Write a compact contract in the working update or internal task notes:
-
-```text
-Behavior:
-Scope boundary:
-Validation:
-```
-
-3. Implement the smallest complete change.
-   - Prefer existing patterns and owner modules.
-   - Avoid unrelated refactors, abstractions, cleanup, and compatibility paths.
-   - Before adding a helper, module, layer, or seam, apply the deletion test; keep it only if it improves current locality or leverage.
-   - Do not add pass-through modules, one-adapter seams, or tests coupled to Implementation details; escalate if no natural public test seam exists.
-   - Add or update a focused test only when behavior risk justifies it and the repo has a natural seam.
-   - For pure copy/docs/config changes, do not invent tests; run the cheapest relevant syntax/lint/check instead.
-
-4. Run targeted validation.
-   - Use the narrowest meaningful command first.
-   - If validation is unavailable or too expensive, state the concrete reason and residual risk.
-   - Do not run full CI unless local policy or the changed surface makes it necessary.
-
-5. Stop and escalate if implementation reveals hidden risk.
-   - Examples: shared contract drift, duplicate source of truth, missing test
-     seam, material concurrency/recovery uncertainty, or product ambiguity.
-   - Leave a short explanation of what was discovered and which heavier flow should take over.
-
-## Output
-
-Final response must stay compact:
-
-```text
-Small Task Result
-
-Changed:
-- ...
-
-Proof:
-- ...
-
-Skipped:
-- none / ...
-
-Risk:
-- low / reason
-```
-
-If escalated, use:
-
-```text
-Escalated
-
-Reason:
-- ...
-
-Recommended flow:
-- Direct medium implementation / canonical ticket delivery
-
-Evidence:
-- ...
-```

package/internal-workflow/skills/small-task-implementer/agents/openai.yaml

@@ -1,6 +0,0 @@
-interface:
-  display_name: "Small Task Implementer"
-  short_description: "Fast bounded local low-risk code changes"
-  default_prompt: "Use $small-task-implementer to make this small local low-risk change with targeted validation, escalating shared contracts to the direct medium route."
-policy:
-  allow_implicit_invocation: true