/workflow-schema-tuning
Use when modifying `resources/workflow-schema.json` in cc-wf-studio to influence how AI agents generate workflows via the cc-workflow-ai-editor skill. Triggers include "AIが特定のノードタイプを選んでくれない", "ワークフロー生成のバイアスを調整したい", "スキーマの description を変えたい", "新しいノードタイプを追加したい",
$ npx -y skills add breaking-brake/cc-wf-studio --skill workflow-schema-tuning --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/workflow-schema-tuning
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when modifying `resources/workflow-schema.json` in cc-wf-studio to influence how AI agents generate workflows via the cc-workflow-ai-editor skill. Triggers include "AIが特定のノードタイプを選んでくれない", "ワークフロー生成のバイアスを調整したい", "スキーマの description を変えたい", "新しいノードタイプを追加したい",
SKILL.md
workflow-schema-tuning.SKILL.mdname: workflow-schema-tuning
description: Use when modifying `resources/workflow-schema.json` in cc-wf-studio to influence how AI agents generate workflows via the cc-workflow-ai-editor skill. Triggers include "AIが特定のノードタイプを選んでくれない", "ワークフロー生成のバイアスを調整したい", "スキーマの description を変えたい", "新しいノードタイプを追加したい", "嘘の制約がスキーマに混じっていないか確認したい". Covers what the schema actually does (instructions to AI, not runtime constraints), the design philosophy (align direction, do not prescribe rules), the build pipeline (.json → .toon auto-generated), and known bias sources to audit.
Workflow Schema Tuning
The schema (`resources/workflow-schema.json`) is the primary spec **delivered to the AI editor at runtime** via the `get_workflow_schema` MCP tool. It is not a runtime validator — the runtime barely validates anything. **Whatever the schema says, the AI believes.** Treat schema edits as prompt engineering, not type definitions.
Core principle: align direction, do not prescribe rules
AI agents already know how to choose between node types intuitively (e.g., when to delegate to a sub-agent vs. handle in-context). The fix for bad output is almost never "add more rules" — it is "remove what is biasing the AI in the wrong direction."
**Defaults**:
- Prefer minimal description text that states each node's *positional role* (立ち位置). Example: "A step executed by the main orchestrating agent" vs. "A step executed by an isolated sub-agent." The contrast does the work.
- Avoid `aiGenerationGuidance` lists of "when to use / when not to use / anti-patterns." They treat the AI as a rules engine, bloat tokens, and fail on unanticipated cases.
- **Test minimal first.** Only add guidance after a concrete failure where the minimal change is provably insufficient.
**Anti-pattern**: writing detailed `upgradeToSubAgentWhen` / `stayInPromptWhen` lists. If you find yourself writing 3+ bullets explaining when to use a node, the description itself is probably wrong.
Schema architecture
| File | Role | Editable? | |---|---|---| | `resources/workflow-schema.json` | Single source of truth | YES | | `resources/workflow-schema.toon` | Token-efficient format consumed by AI via MCP | NO — auto-generated | | `resources/ai-editing-skill-template.md` | Skill template loaded at AI editor launch | YES | | `scripts/generate-toon-schema.ts` | TOON generator | YES (rare) |
After editing `.json`, regenerate `.toon`:
npm run generate:toon
The full build (`npm run build`) does this automatically as the first step.
Where biases hide (audit checklist)
When the AI consistently picks the wrong node type, look here in priority order:
1. **`ai-editing-skill-template.md` step 4** — strongest pull. A line like "use built-in sub-agents by default" overrides every other signal in the schema. Keep this neutral. 2. **`nodeTypes.<type>.description`** — the AI's first impression of what each node *means*. Keep terse, contrastive, role-focused. 3. **`nodeTypes.<type>.aiGenerationGuidance`** — when present, this is read closely. Audit for stale "default" framings or anti-patterns that no longer apply. 4. **`examples[]`** — the AI learns strongly from examples. If every example uses one node type, expect that node to dominate output. 5. **Top-level constraints** (`connections.overview.forbidden`, `exportValidationRules`, `postGenerationChecklist`) — these can encode false constraints (e.g., "no cycles allowed" when the runtime allows them, since the runtime is an AI that uses judgment, not a deterministic executor). **Removing false constraints is itself a valid improvement.**
Workflow for making changes
1. **Diagnose**: identify the symptom (wrong node type chosen, false constraint cited in AI's reasoning, etc.). 2. **Locate the bias**: walk the audit checklist above. Look for a single source pulling the AI in the wrong direction before adding new content. 3. **Minimal edit**: prefer removing biased text or fixing one description over adding new sections. 4. **Regenerate TOON**: `npm run generate:toon`. 5. **Validate**: `npm run check && npm run build`. 6. **Test**: `npm run debug` launches a fresh Extension Development Host. Trigger the AI editor with a node-type-agnostic prompt (no hints like "use a sub-agent for X") and inspect the generated workflow. 7. **Iterate**: if the minimal change is insufficient, add the smallest additional signal — not a guidance section.
Important constraints
- The framework is **multi-agent** (Claude Code, Codex, "other"). Schema text must be agent-agnostic. Avoid Claude-specific phrasing like "isolated Claude session" — use "isolated AI agent session" or "isolated sub-agent."
- The runtime is an AI agent making judgments, **not a deterministic program**. Constraints that make sense in code (no cycles, no infinite loops) often do not apply here. Verify before transcribing programming-style constraints.
- After `generate:toon`, confirm the change took effect by grepping the relevant string in `workflow-schema.toon`. The MCP delivers TOON, not JSON.
Commit conventions for schema changes
Per the project's conventional commit policy:
- Description fixes / bias removal → `improvement:` (patch bump)
- Build/tooling-only changes → `chore:` (no release)
- Keep subjects ≤50 chars, body 3–5 bullets, "what changed" only
- Split unrelated concerns into separate commits to make diffs reviewable
Read more
name: workflow-schema-tuning description: Use when modifying `resources/workflow-schema.json` in cc-wf-studio to influence how AI agents generate workflows via the cc-workflow-ai-editor skill. Triggers include "AIが特定のノードタイプを選んでくれない", "ワークフロー生成のバイアスを調整したい", "スキーマの description を変えたい", "新しいノードタイプを追加したい", "嘘の制約がスキーマに混じっていないか確認したい". Covers what the schema actually does (instructions to AI, not runtime constraints), the design philosophy (align direction, do not prescribe rules), the build pipeline (.json → .toon auto-generated), and known bias sources to audit.
Workflow Schema Tuning
The schema (`resources/workflow-schema.json`) is the primary spec **delivered to the AI editor at runtime** via the `get_workflow_schema` MCP tool. It is not a runtime validator — the runtime barely validates anything. **Whatever the schema says, the AI believes.** Treat schema edits as prompt engineering, not type definitions.
Core principle: align direction, do not prescribe rules
AI agents already know how to choose between node types intuitively (e.g., when to delegate to a sub-agent vs. handle in-context). The fix for bad output is almost never "add more rules" — it is "remove what is biasing the AI in the wrong direction."
**Defaults**:
- Prefer minimal description text that states each node's *positional role* (立ち位置). Example: "A step executed by the main orchestrating agent" vs. "A step executed by an isolated sub-agent." The contrast does the work.
- Avoid `aiGenerationGuidance` lists of "when to use / when not to use / anti-patterns." They treat the AI as a rules engine, bloat tokens, and fail on unanticipated cases.
- **Test minimal first.** Only add guidance after a concrete failure where the minimal change is provably insufficient.
**Anti-pattern**: writing detailed `upgradeToSubAgentWhen` / `stayInPromptWhen` lists. If you find yourself writing 3+ bullets explaining when to use a node, the description itself is probably wrong.
Schema architecture
| File | Role | Editable? | |---|---|---| | `resources/workflow-schema.json` | Single source of truth | YES | | `resources/workflow-schema.toon` | Token-efficient format consumed by AI via MCP | NO — auto-generated | | `resources/ai-editing-skill-template.md` | Skill template loaded at AI editor launch | YES | | `scripts/generate-toon-schema.ts` | TOON generator | YES (rare) |
After editing `.json`, regenerate `.toon`:
npm run generate:toon
The full build (`npm run build`) does this automatically as the first step.
Where biases hide (audit checklist)
When the AI consistently picks the wrong node type, look here in priority order:
1. **`ai-editing-skill-template.md` step 4** — strongest pull. A line like "use built-in sub-agents by default" overrides every other signal in the schema. Keep this neutral. 2. **`nodeTypes.<type>.description`** — the AI's first impression of what each node *means*. Keep terse, contrastive, role-focused. 3. **`nodeTypes.<type>.aiGenerationGuidance`** — when present, this is read closely. Audit for stale "default" framings or anti-patterns that no longer apply. 4. **`examples[]`** — the AI learns strongly from examples. If every example uses one node type, expect that node to dominate output. 5. **Top-level constraints** (`connections.overview.forbidden`, `exportValidationRules`, `postGenerationChecklist`) — these can encode false constraints (e.g., "no cycles allowed" when the runtime allows them, since the runtime is an AI that uses judgment, not a deterministic executor). **Removing false constraints is itself a valid improvement.**
Workflow for making changes
1. **Diagnose**: identify the symptom (wrong node type chosen, false constraint cited in AI's reasoning, etc.). 2. **Locate the bias**: walk the audit checklist above. Look for a single source pulling the AI in the wrong direction before adding new content. 3. **Minimal edit**: prefer removing biased text or fixing one description over adding new sections. 4. **Regenerate TOON**: `npm run generate:toon`. 5. **Validate**: `npm run check && npm run build`. 6. **Test**: `npm run debug` launches a fresh Extension Development Host. Trigger the AI editor with a node-type-agnostic prompt (no hints like "use a sub-agent for X") and inspect the generated workflow. 7. **Iterate**: if the minimal change is insufficient, add the smallest additional signal — not a guidance section.
Important constraints
- The framework is **multi-agent** (Claude Code, Codex, "other"). Schema text must be agent-agnostic. Avoid Claude-specific phrasing like "isolated Claude session" — use "isolated AI agent session" or "isolated sub-agent."
- The runtime is an AI agent making judgments, **not a deterministic program**. Constraints that make sense in code (no cycles, no infinite loops) often do not apply here. Verify before transcribing programming-style constraints.
- After `generate:toon`, confirm the change took effect by grepping the relevant string in `workflow-schema.toon`. The MCP delivers TOON, not JSON.
Commit conventions for schema changes
Per the project's conventional commit policy:
- Description fixes / bias removal → `improvement:` (patch bump)
- Build/tooling-only changes → `chore:` (no release)
- Keep subjects ≤50 chars, body 3–5 bullets, "what changed" only
- Split unrelated concerns into separate commits to make diffs reviewable
You think visually. AI thinks in .md. CC Workflow Studio speaks both. Design workflows on a canvas. Export as Markdown your AI agent already understands. No more prompt-guessing. Why CC Workflow Studio? - Speaker Deck Link
Repo: breaking-brake/cc-wf-studio
Other skills on cc-wf-studio.
- /jira-driven-planning
Jiraチケットの要件とConfluenceの関連ドキュメントを基に、Frontend/Backend/Infrastructureに分割した実装計画を策定するプランニングスキル。Jiraチケット情報とConfluence検索結果が前段で取得済みであることを前提とし、構造化された実装計画を出力する。「プランニング」「実装計画策定」「タスク分割」などの文脈で使用。
Open skill - /next-idea
Run one unattended IDEATION iteration of the autonomous value-creation loop — invent improvements a user of cc-wf-studio would notice, judge them against the value bar, and file the winners as locked `idea` issues. Never implements anything; the next-task skill builds from the
Open skill - /next-qa-idea
Run one unattended IDEATION iteration of the quality-assurance loop — find the highest-value untested behavior in the codebase, judge it against the QA value bar, and file ONE locked `qa` issue specifying the test to write. Never writes code or tests; the next-qa skill builds
Open skill - /next-qa
Run one unattended iteration of the QUALITY-ASSURANCE loop — steward any in-flight QA PR, then build ONE queued `qa` issue (test infrastructure, unit tests, regression tests for known bugs) on a branch off auto-qa and open a PR that squash-merges on green CI. Adds tests and
Open skill - /next-task
Run one unattended IMPLEMENTATION iteration of the autonomous value-creation loop — steward any in-flight PR, fix interrupts (red CI / security / human bugs), or else build ONE queued `idea` issue on a branch off auto-dev and open a PR that squash-merges on green CI. Ideation
Open skill - /pr-review-analysis
Analyze PR review comments from a GitHub PR URL. Fetch review comments, verify each finding against the actual codebase, assess validity (correct/incorrect/partial), present a structured summary with recommended actions, and optionally reply to each comment on GitHub. Use when
Open skill

