pipeline — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited pipeline (Agent Skill) and scored it 87/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 3 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 3 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill is the entry point for the pipeline family.
It does not execute the full workflow itself. Its job is to route the task to the right pipeline:
pipeline-litepipeline-deeppipeline-hardCanonical wording, trigger table, and minimum fields: read skills/pipeline/references/first-response-packets.md before composing the first response when any trigger below appears (F-020 dedup executed 2026-06-09).
For direct pipeline requests, include the relevant first response packets before implementation steps when a trigger appears:
skills/pipeline/references/ai-minimalism.md.pipeline-update / pipeline update requests; read skills/pipeline/references/skill-update-intake.md before mode selection. This is not a fourth pipeline mode.--body-file, query exact env names only, and avoid shell-inline bodies.done after prod/billing/webhook/worker/integration changes — do not close on builder/model done or green tests alone; require current-agent readback/smoke, logs from every touched service, observation window, success threshold, rollback threshold, or explicit handoff.file:line plus source and confidence; if the line was not read, lower confidence and keep it out of blockers unless P0.references/ plus one pointer line, and if over budget require same-update dedup or explicit approved budget raise recorded in STATE.md.When the user says pipeline-update or pipeline update, treat it as a source-intake path for improving the pipeline skill family itself.
Read skills/pipeline/references/skill-update-intake.md before mode selection. The intake may inspect the source material and produce an adoption plan before Run Control Choices, because it is router/source-audit work, not pipeline-deep or pipeline-hard execution. If the accepted implementation later enters pipeline-deep or pipeline-hard, apply the normal Run Control gate before that mode's phases.
Default stance: augment, clarify, or move reusable practices into references. Do not replace working pipeline behavior, silently install third-party skills, or expand always-loaded instructions unless the user explicitly approves the replacement and the eval plan covers the behavior change.
When routing to pipeline-deep or pipeline-hard, include Run Control Choices in the first response if either choice is missing from the user request:
Model Collaboration Profile - who participates.Autonomy Level - how independently agents work without the human operator.Before or alongside Run Control Choices, include any triggered first-response packets that can be identified from the user request. Run Control Choices must not suppress required first-response packets; for example, a large existing cross-cutting task still needs the Code Routing Map packet before waiting for run-control answers.
First response must ask both menus before Phase 0 or Phase 1 work. Do not start branch work, requirements artifacts, oracle work, implementation planning, or any repo-mutating tool work until the user answers or accepts the recommended defaults. Bounded read-only discovery (reading source to classify the request) is permitted before the chat-state record exists.
Once the user answers, hold the normalized run_control (collaboration_profile, autonomy, cross_check_initial, premortem_plan_review) in chat state. Persist that chat state into state.json as soon as it is created in Phase 0 — state.json must never be written without orchestration.run_control fields populated. Until the chat-state record exists, do not invoke handoff, delegation, or long-running execution tools.
Alias normalization before asking (F-065):
heavy is a run-control alias (normalizes to C4 A3), not a mode selector by itself. Mode is still chosen by task shape and hard-mode triggers per ## Triggered By Router Or Escalation in pipeline-hard/SKILL.md.heavy, режим heavy, heavy mode, тяжелый режим, autonom+heavy, autonomous heavy, and autonom heavy mean C4 A3 unless the user explicitly names a different A#.ok means C4 A3.heavy by falling back to memory or older defaults.Use this compact wording:
Run Control Choices:
Кто работает? Ответ: C1-C4
C1 Один основной агент
C2 Primary + Secondary checkpoints (legacy: Claude-main + Codex checkpoints)
C3 Dual-head quality
C4 Heavy executor + Guardrail reviewer (Recommended; legacy: Codex-heavy + Claude guardrails)
Автономность? Ответ: A1-A4
A1 Interactive
A2 Guided autonomous
A3 Full autonomous (Recommended)
A4 Overnight
Опционально:
X Cross-check в начале
P Premortem plan review перед реализацией
-P Skip optional premortem если задача low-risk
Быстрый ответ:
Ответь коротко: `C# A#` (+ `X` и/или `P` если нужны)
- `ok` = `C4 A3`
- `heavy` = `C4 A3`
- `quality` = `C3 A2`
- `night` = `C4 A4`
- `heavy P` = `C4 A3 P`
Подсказка:
- `C` = collaboration
- `A` = autonomy
- `X` = cross-check
- `P` = premortem plan reviewIf the user already specified one choice but not the other, still ask the missing choice and show the already selected one for confirmation. If both choices are explicit, record them and proceed.
F-067 partial-choice handling rule: If one control is present and the other is missing, show the present control as selected ("[Кто работает: C4 — Heavy executor + Guardrail reviewer]") and ask only for the missing control. Do not re-ask the menu the user already answered. If the user answers legacy digits like 4 2, treat them as C4 A2, then record normalized state values. Parse exact tokens in this order: if the answer includes exact token -P, record premortem_plan_review=skipped only for optional premortem and do not bypass a mandatory high-risk safety gate without a residual-risk note; else if it includes exact token P, record premortem_plan_review=forced; else keep premortem_plan_review=auto.
Read skills/pipeline/references/run-control-inheritance.md when review, testing, implementation, resume, or handoff discovers work outside the accepted scope.
Default direction is defer-by-default: do not silently expand scope. Classify discovered work as blocking current acceptance, non-blocking bug, or new feature/scope. Only accepted blocking discovered work inherits the current run_control; non-blocking bugs are recorded/deferred unless explicitly accepted, and new features require explicit acceptance or a new pipeline. pre-existing, unrelated, and out of scope are not completion excuses; if a discovered issue blocks required verification or honest acceptance, fix it in the current run even if it existed before. Context packs and handoffs must carry run_control so child work cannot reroute or downgrade itself.
Read skills/pipeline/references/premortem-plan-review.md when a plan is medium/high-risk, broad, autonomous, Codex-heavy, or tied to launch, pricing, contracts, migration, or user-facing behavior.
Premortem asks: by the chosen horizon, this plan failed; what specifically happened? It is not a separate mode. The selected run_control remains sticky. Use it to find concrete holes, choose top 1-3 accepted mitigations, and record the rest as deferred/backlog unless explicitly accepted.
Read skills/pipeline/references/discipline-rules.md §Fresh Baseline Batch-Fix Rules and apply each rule in the first response when its trigger appears (dedup executed 2026-06-09).
Read skills/pipeline/references/discipline-rules.md §Final Polish Rules before reviews, agent dispatch, and final summaries (dedup executed 2026-06-09).
Use pipeline when:
pipelinepipeline-update or pipeline updateDo not use pipeline for:
cmd | grep, stdout redirection, or Bash pipeline explanationsChoose the pipeline-update intake path first when the request is about improving this skill family. After the intake:
pipeline-lite for a small, clear skill wording, eval, metadata, or active-copy sync change;pipeline-deep when the external material is large, the desired behavior is unclear, or compatibility with autonomy/collaboration modes needs design;pipeline-hard only when the user explicitly wants the full advanced workflow or hard-mode triggers apply.Choose pipeline-lite when:
Choose pipeline-deep when:
Choose pipeline-hard when:
pipeline-hardpipeline-hardpipeline-lite or pipeline-deep task discovers hard-mode triggers and preserving work while escalating is safer than continuing in the current modeautomatic hard routing requires a short rationale naming the hard-mode triggers. Do not choose hard merely because a task is large or important. If the task is large but does not need the full advanced workflow, choose pipeline-deep.
pipeline-lite:
pipeline-deep:
pipeline-hard:
If the task is understandable and local, use pipeline-lite.
If the task needs serious thinking before coding, use pipeline-deep.
If hard-mode triggers are present, use pipeline-hard.
When unsure between lite and deep, prefer pipeline-deep.
When unsure between deep and hard, prefer pipeline-deep and ask whether the user wants the full advanced workflow.
When a direct pipeline request mentions a user-facing frontend, UI, React/Vue/Svelte page, form, browser route, or user journey, include browser or user-journey evidence in the first task brief instead of deferring it until final verification.
The brief must cover route, viewport, user steps, expected visible result, and negative check.
before listing implementation steps, include this Browser evidence packet:
Do not write only generic test/manual check wording. List all four accepted evidence route options before choosing one: Playwright MCP/CLI / agent-browser / project e2e / documented manual browser evidence.
Accepted route summary: Playwright, agent-browser, project e2e, or documented manual browser check. When naming the exact tool, prefer Playwright MCP/CLI where available.
If browser automation is unavailable, include a Manual fallback record with exact route, viewport, steps, observed visible result, unchecked items, and residual risk.
Usually this is not applicable for backend-only, CLI-only, docs-only, copy-only, or API-only work with no visible user surface. If the change affects browser-visible behavior, or a runnable route can prove acceptance better than code inspection alone, record browser evidence or a concrete skip reason.
Do not route to a separate mode for Claude -> Codex orchestration. Keep the selected mode as pipeline-deep or pipeline-hard, then use skills/pipeline/references/shared.md §Codex-Orchestrated Planning and Execution inside the spec, planning, and execution phases when appropriate.
If Codex CLI is unavailable but a Codex-assisted variant would otherwise fit, stay in the selected mode and continue with local planning/review. Record the missing tool as residual risk instead of blocking the whole workflow.
For changes to this skill family, active-copy sync, agents/openai.yaml, or third-party skill review, read skills/pipeline/references/packaging.md.
pipeline-litepipeline-deeppipeline-hardpipeline-update intake, then pipeline-lite or pipeline-deep only after the adoption plan is clear.pipeline-hard merely because a task sounds important. Hard needs explicit request, router hard triggers, or escalation from lite/deep.pipeline-lite and pipeline-deep when the task is ambiguous. Ask one clarifying question, or choose pipeline-deep when discovery is clearly needed.pipeline as a general project-management label. It is only the router for this local pipeline-lite / pipeline-deep / pipeline-hard skill family.pipeline but the task is already tiny and clear, route to pipeline-lite and keep ceremony low.pipeline and the task is broad, raw, or contract-heavy, route to pipeline-deep unless hard-mode triggers are present.pipeline-deep or pipeline-hard execution and record the missing tool in residual risk.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.