workflow-schema-tuning
This skill tunes `workflow-schema.json` in cc-wf-studio to reshape how the cc-workflow-ai-editor generates workflows by modifying the schema delivered to AI agents at runtime. Use it when AI agents consistently misselect node types, you need to add or reframe node options, or you suspect contradictory guidance is biasing generation. The schema functions as prompt engineering, not validation, so edits steer agent behavior through minimal, role-focused descriptions rather than rule lists. After changes, regenerate the token-efficient `.toon` format via `npm run generate:toon`.
git clone --depth 1 https://github.com/breaking-brake/cc-wf-studio /tmp/workflow-schema-tuning && cp -r /tmp/workflow-schema-tuning/.claude/skills/workflow-schema-tuning ~/.claude/skills/workflow-schema-tuningSKILL.md
# 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`: ```bash 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
Jiraチケットの要件とConfluenceの関連ドキュメントを基に、Frontend/Backend/Infrastructureに分割した実装計画を策定するプランニングスキル。Jiraチケット情報とConfluence検索結果が前段で取得済みであることを前提とし、構造化された実装計画を出力する。「プランニング」「実装計画策定」「タスク分割」などの文脈で使用。
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 given a PR review URL or when asked to check/analyze PR feedback.
Clean up merged feature branches after PR to main is merged. Use when the user says "ブランチ削除", "cleanup", "マージ後の片付け", or wants to delete a merged branch.
Create a PR to the main branch for feature/fix changes in this pnpm + Changesets monorepo. Use when the user says "PRを作成", "mainにPR", or wants to submit changes for review. Always run this in the monorepo-aware way — identify the affected package(s) and make sure a changeset exists, because the release pipeline is Changesets-driven.
AI workflow editor for CC Workflow Studio. Create and edit visual AI agent workflows through interactive conversation using MCP tools (get_workflow_schema, get_current_workflow, apply_workflow, update_nodes). Use when the user wants to create a new workflow, modify an existing workflow, or edit the workflow canvas in CC Workflow Studio via the built-in MCP server.
Use the `ccwf` CLI (from @cc-wf-studio/cli) to render, validate, preview, export, or run cc-wf-studio workflow JSON files from the terminal. Apply whenever the user mentions viewing, visualizing, checking, executing, or converting a workflow under `.vscode/workflows/` (or any `*workflow*.json`), wants a Mermaid diagram of a workflow, asks to "see" / "preview" / "open" a workflow, or wants to run a workflow as a Claude Code Skill without opening VSCode.