본문으로 건너뛰기
cccskills
무료GitHub에 공개

attack-loop

Run a bounded implement-attack-repair loop for a user-specified task. Use when work needs repeated independent criticism: perform the task, dispatch a fresh attacker, verify significant findings, repair them, and stop on a clean attack or the user's round limit.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

btseytlin/ultrapack스타 46(GitHub 46 + cccskills 0)

실행 점수 미검증

설치 방법 보기

포함된 파일(2)

  • SKILL.md5.3 KB
  • agents/openai.yaml206 B

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Attack loop

Use this standalone workflow when a task needs independent adversarial passes without a make task file.

Require a bounded contract

Require these inputs in the user's request:

  • Target work — free-form description of what to do.
  • Maximum rounds — positive whole number of attacker passes.
  • Stop condition — observable condition that defines a clean completion.

Ask before acting if any input is missing or ambiguous. Do not invent defaults.

Pick an authority level before the initial work and state it in the first update:

  • Read-only — inspect and report; do not change files or external state.
  • Write and probe — change workspace files and run temporary verification probes.
  • Full task authority — take actions the request already authorizes, including external writes.

Change authority between rounds only when the request authorizes it. Report each change. Stop when the next needed action exceeds authority.

Example:

Use $attack-loop to add CSV import validation. Run at most 3 rounds. Stop when malformed rows fail loudly and a fresh attack finds no confirmed defect.

Run one independent attack per round

  1. Perform or repair the target work under the current authority.
  2. Dispatch one fresh attacker. Pass the absolute working directory, target work, constraints, stop condition, current authority, and raw current artifacts or diff.
  3. Do not pass controller rationale, proposed fixes, or earlier attacker reports. The attacker must form an independent view from the current state.
  4. Give the attacker only the current authority. It may run probes but must not repair the deliverable or alter external state solely to manufacture a finding.
  5. Have the attacker attack, not confirm. Adapt uverify's categories: valid-input edge cases, invalid-input rejection, stated invariants and contracts, real callers and outputs, state/order/retry behavior, and the shortest end-to-end smoke path.
  6. Require each attack to name the hypothesized bite and run an appropriate probe or inspection. Capture real output. An unavailable probe is a coverage gap, never a passing result.

Require this attacker report:

Attacks run:
- <hypothesis> — held | broke: <evidence>

Findings:
- F<n> — <severity, violated condition, concrete bad path, evidence, expected behavior>

Coverage gaps:
- <unrun necessary attack and blocker>

An attacker may return no findings. Do not require a defect, reword a prior concern, elevate a style preference, or call missing tests a bug without a violated requirement. Unsupported risks belong under coverage gaps or no report.

Defend findings fairly

For every finding, restate it, verify it against the current artifact, and classify it before changing anything:

  • Fix — reproduced break, violated contract or invariant, or highly certain defect with a concrete bad path; material and in scope.
  • Record — unsupported, duplicate, cosmetic, hypothetical, or out of scope; do not repair it merely to extend the loop.
  • Defer — potentially material but blocked by missing authority, infrastructure, or user direction; do not treat the round as clean.

For a reproduced failure, use udebug before editing: reproduce, trace root cause, test one hypothesis, then make one root-cause repair. Re-run the reproduction and relevant checks after the repair. Sweep for the same defect pattern when the root cause can recur.

Do not accept a finding blindly. Do not add a workaround, fallback, dependency, or refactor unless the verified defect requires it and the task scope permits it.

Stop only on evidence

Start another round after every repair. Stop early only when both hold:

  • The explicit stop condition has direct evidence.
  • The latest fresh attacker found no confirmed significant defect and no blocking coverage gap.

Stop as limit reached after the maximum round count. Do not call this a clean completion unless both conditions above already hold.

Stop as blocked when authority is insufficient, required evidence cannot be obtained, the task needs a material user decision, or udebug reaches three failed repairs for one defect.

If the stop condition passes before an attack, still run one fresh attack before declaring completion.

Report every round and the outcome

Before work, state target work, maximum rounds, stop condition, and authority.

After every attack, report one compact update:

Round <n>/<max> — <authority>
- Confirmed: <finding IDs and decisions>
- Recorded or deferred: <IDs and reason>
- Next: repair | next attack | clean | limit reached | blocked

Finish with:

  • Outcome: clean, limit reached, or blocked.
  • Stop-condition evidence.
  • Authority timeline.
  • Round ledger: attacks, confirmed findings, repairs, and verification.
  • Deferred coverage gaps and required next action.

Never claim success from passing unit tests, a clean diff, an attacker assertion, or an unrun smoke path.

Terminal state

Report the final outcome and leave the user with evidence for any remaining action. Do not create a task file or invoke ureview as part of this standalone loop.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

e

무료

Explain a file, error, design, diff, or concept like a helpful engineering colleague: grounded in evidence, concise, and with useful follow-up threads. Use when the user asks for a clear explanation of the current work or codebase.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

btseytlin/ultrapack462026년 10월 15일 업데이트

expand

무료

Turn one user criticism into a principle-level fix: find the violated principle, every similar occurrence, and fix the shared cause. Use only when the user explicitly invokes expand, $expand, /up:expand, or /skill:expand.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

btseytlin/ultrapack462026년 10월 15일 업데이트

Use when a task needs an isolated checkout. Verify the worktree location, keep mutable environments and build outputs local, and run only authorized setup and checks.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

btseytlin/ultrapack462026년 10월 15일 업데이트

handsoff

무료

Contract for hands-off mode — the ultrapack workflow variant that minimizes user prompts after Design, takes the safest reversible path, and logs every auto-choice for one end-of-task review. Referenced by the workflow entry point and child skills (udesign, uplan, uexecute, uverify, ureview). Read when the task file's **Mode:** header is `hands-off`.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

btseytlin/ultrapack462026년 10월 15일 업데이트

Use when the user explicitly asks to launch and supervise a job. Require an authorized launch, monitoring, recovery, and teardown contract. Detect failures without inventing permission to restart or spend money.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

btseytlin/ultrapack462026년 10월 15일 업데이트

make

무료

Orchestrate the full Ultrapack workflow in Codex and Pi: create or resume a task file, design, plan, execute, verify, review, and validate the observable goal. Use when the user asks to build, fix, or deliver a non-trivial change with the complete workflow.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

btseytlin/ultrapack462026년 10월 15일 업데이트

btseytlin의 스킬 모두 보기

이 스킬의 문제 신고