本文へ移動
cccskills
無料GitHub で公開

ultrawork

This skill should be used when the user says "/ultrawork", "ultrawork", or wants to run the full specify → execute pipeline automatically with a single command. Automated end-to-end workflow that chains specify and execute skills.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md4.6 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

/ultrawork Skill - Automated Development Pipeline

You are initiating an ultrawork session — a fully automated pipeline that chains:

  1. /specify — Systematic requirements derivation producing requirements.md
  2. /blueprint — Contract-first planning producing plan.json from requirements
  3. /execute — Reads plan.json, dispatches workers, and implements

How It Works

The ultrawork pipeline runs automatically through Stop hooks:

  • When specify finishes L4 with user approval → Hook triggers /execute {spec-path}
  • /execute then derives plan.json from the approved spec and runs tasks to completion
  • When all tasks complete → Pipeline ends

You don't need to manually trigger the next step — the hooks handle transitions.

v2 schema note

In spec-v2, spec.json contains only requirements + sub-requirements (with GWT) + verification journeys. It does not contain tasks[]. Task breakdown lives in a sibling plan.json derived by /execute. Ultrawork is just the glue: specify produces the spec, execute produces and runs the plan.

Your Role

  1. Extract the feature name from user's request
  2. Initialize ultrawork state (handled by UserPromptSubmit hook)
  3. Start the specify skill with the feature name
  4. Follow specify's layer flow normally (approve at L2, L3, L4)
  5. The rest happens automatically via hooks

Execution

Step 1: Parse User Request

Extract a short, kebab-case name for the feature:

  • "Add user authentication" → user-auth
  • "Implement payment processing" → payment-processing
  • "Fix login bug" → fix-login-bug

Note: State initialization is handled automatically by UserPromptSubmit hook (ultrawork-init-hook.sh).

Step 2: Announce Ultrawork Mode

Ultrawork Mode Activated

Feature: {name}
Pipeline: specify (spec.json v2) → execute (plan.json + run)

Starting specify L0...

Step 3: Invoke Specify

Skill("specify", args="{name}")

The specify skill will:

  1. L0: Goal mirror + confirmed_goal
  2. L1: Codebase research
  3. L2: Decisions + constraints (user approves)
  4. L3: Requirements + sub-requirements with GWT (user approves)
  5. L4: Verification journeys (user approves)
  6. Write approved spec.json at .hoyeon/specs/{name}/spec.json

Step 4: Let Hooks Handle the Rest

After specify completes with an approved spec:

  • ultrawork-stop-hook.sh detects an approved spec.json (meta.approved_by populated)
  • Hook automatically injects /execute .hoyeon/specs/{name}/spec.json
  • /execute prompts (via AskUserQuestion) for dispatch/work/verify mode selections, derives plan.json, and runs tasks to completion

User Interruption

User can stop the pipeline at any time by saying:

  • "stop"
  • "pause"
  • "wait"

This will halt the current phase and await further instructions.

State Tracking

The hook tracks progress in .hoyeon/state.local.json:

{
  "session-id": {
    "ultrawork": {
      "name": "feature-name",
      "phase": "specify",
      "iteration": 0
    }
  }
}

Phases: specify → executing → done

Example Flow

User: "/ultrawork add dark mode support"

[Hook auto-initializes state for "dark-mode"]

[You]
1. Parse: feature name = "dark-mode"

2. Announce:
   Ultrawork Mode Activated
   Feature: dark-mode
   Pipeline: specify → execute
   Starting specify L0...

3. Invoke: Skill("specify", args="dark-mode")

[Specify L0→L1→L2(approve)→L3(approve)→L4(approve)]
[spec.json written and approved at .hoyeon/specs/dark-mode/spec.json]
[Hook detects approved spec → triggers "/execute .hoyeon/specs/dark-mode/spec.json"]
[/execute prompts for dispatch/work/verify, derives plan.json, runs tasks]
[All tasks completed]
[Pipeline ends]

Important Notes

  • State is auto-initialized by UserPromptSubmit hook — no manual setup needed
  • Do NOT manually call /execute — hooks handle this
  • Follow specify's layer flow — approve at L2/L3/L4 gates
  • spec.json has no tasks in v2 — /execute derives plan.json as a sibling file
  • Mode selection is interactive — /execute asks for dispatch/work/verify via AskUserQuestion (no CLI flags)
  • The pipeline is autonomous — just start it and let it run
  • User can interrupt at any time for manual control

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Analyze an open-source project from What/Why perspective (not how-it's-implemented). Use when the user says "/analyze-oss", "분석해줘 이 오픈소스", "이 레포 뭐하는거야", "analyze this repo", "what does X do", "이거 왜 쓰는거야", "이 라이브러리 분석", provides a GitHub URL and wants understanding, or asks to deeply understand an OSS project's purpose, value, target users, and usage flow. Clones the repo to ~/opensource-analysis/<repo-name>/ (git pull if already exists), dispatches parallel subagents per analysis lens, then synthesizes a What/Why-focused report in chat. Supports optional user-specific follow-up questions.

日本語の概要は準備中です。原文の説明を表示しています。

team-attention/hoyeon1732026年5月21日 更新

blueprint

無料

"/blueprint", "blueprint", "task graph", "contract derivation", "execution plan", "plan tasks from requirements", "contract-first planning" Turn requirements.md into an executable blueprint (plan.json + contracts.md). Five phases: Contracts → Tasks → Journeys → Verify Plan → Commit. Sits between /specify and /execute. Scope-adaptive (greenfield → bugfix). Uses hoyeon-cli (plan.json only; requirements.md is read as-is via Read tool).

日本語の概要は準備中です。原文の説明を表示しています。

team-attention/hoyeon1732026年5月21日 更新

Recon-first browser automation. Orchestrator explores the site first via chromux, saves a guide file with insights, then delegates execution to browser-explorer agent. Use when: "/browser-work", "브라우저 작업", "사이트에서 해줘", "웹에서 해줘", "LinkedIn에서", "크롬으로", "browser task", "automate this site".

日本語の概要は準備中です。原文の説明を表示しています。

team-attention/hoyeon1732026年5月21日 更新

bugfix

無料

Root cause based one-shot bug fix. debugger diagnosis → requirements.md generation → /execute. /bugfix "error description" Full investigation pipeline: debugger + gap-analyzer + standard verify. QA suggestion after successful fix.

日本語の概要は準備中です。原文の説明を表示しています。

team-attention/hoyeon1732026年5月21日 更新

check

無料

This skill should be used when the user wants to verify their changes before pushing, or update the project's rule checklists. Phase 1: validate changed files against .hoyeon/rules/ checklists and report PASS/WARN. Phase 2 (conditional): propose rule additions when unmatched patterns are detected. Essential before git push. Trigger phrases: "check", "checklist", "verify changes", "what did I miss", "pre-push check", "cascading changes", "any more changes needed", "update checklist", "update rules", "rules update", "체크", "체크리스트", "변경 확인", "빠뜨린 거 없나", "push 전 확인", "뭐 더 건드려야 해?", "연쇄 변경 확인", "규칙 갱신".

日本語の概要は準備中です。原文の説明を表示しています。

team-attention/hoyeon1732026年5月21日 更新

clarify

無料

"/clarify", "clarify this", "keep asking until clear", "remove ambiguity", "clarify requirements", "clarify design", "clarify the plan", "질문 계속해", "모호한 게 없게", "명확해질 때까지", "계속 물어봐", "Q&A로 정리", "질문답변 기록", "요구사항 명확화", "설계 명확화". Relentless ambiguity-resolution interview that records Q&A under .hoyeon/clarify/<topic>/ and hands off to specify/blueprint/docs when clear.

日本語の概要は準備中です。原文の説明を表示しています。

team-attention/hoyeon1732026年5月21日 更新

team-attention のスキルをすべて見る

このスキルの問題を報告する