From zen
Coordinates zen Issue-driven development workflow including branch creation, PR management, and GitHub Projects integration. Activates when user mentions "start issue", "create PR", "next steps", "workflow", "zen", "branch naming", "commit format", "Issue作業", "ブランチ", "コミット規約", "PR作成", "作業開始", "ワークフロー", "次のステップ", "ブランチ命名", or asks about development workflow. Use for workflow state detection, phase transitions, and command suggestions.
npx claudepluginhub b16b1rd/cc-zen-workflowThis skill uses the workspace's default tool permissions.
This skill provides context for zen workflow operations.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
This skill provides context for zen workflow operations.
When activated, this skill provides:
Workflow Awareness
Command Guidance
Best Practices
Coding Principles
Common Principles
Detect current state from:
{type}/issue-{number}-*
{type} values: feat, fix, docs, refactor, chore, style, teststyle is used for code style/formatting changes (no logic changes)| State | Suggestion |
|---|---|
| On main/develop, no Issue | /zen:issue:create or /zen:issue:list |
| On feature branch, no PR | /zen:pr:create after work |
| PR open, draft | /zen:pr:review then /zen:pr:ready |
| Long session (30+ minutes elapsed) | /zen:issue:update |
| Sprint with Todo Issues available | /zen:sprint:execute to run Issues sequentially |
| Sprint with multiple independent Issues | /zen:sprint:team-execute to run Issues in parallel with worktrees |
Key Principle: Always apply
question_self_check(see references/common-principles.md) before asking questions. Most questions can be avoided through context inference and using sensible defaults.
Ask immediately (do not defer) when:
If questions arise during work, record them in the work memory comment under "要確認事項" (Items to Confirm):
### 要確認事項
1. [ ] {confirmation_item_1}
2. [ ] {confirmation_item_2}
| Phase | Typical Questions | Notes |
|---|---|---|
| Issue Start (Phase 1.3) | 0-1 questions | Only for score C/D Issues with insufficient information |
| Implementation (Phase 5) | 0 questions | Use defaults and infer from context; record ambiguities in work memory |
| PR Review (review/fix loop) | 0-1 questions | Only for critical architectural decisions |
Target: Minimize questions through context inference and sensible defaults. Record non-blocking questions in work memory for batch review.
Automatically detect work state at session start and notify if interrupted work exists.
See references/session-detection.md for details.
{type}/issue-{number}-* pattern)See references/phase-mapping.md for phase list.
See references/work-memory-format.md for work memory format.
Principles to avoid common failure patterns in AI coding agents.
| Principle | Summary | When to Apply |
|---|---|---|
| assumption_surfacing | Surface assumptions explicitly and confirm before proceeding | Implementation planning & coding |
| confusion_management | Stop and confirm when contradictions or unknowns are detected | Issue quality check & planning |
| push_back_when_warranted | Push back when problems are found | PR review |
| simplicity_enforcement | Avoid excessive complexity | Implementation |
| scope_discipline | Only change what was requested | Implementation |
| dead_code_hygiene | Identify and confirm removal of dead code | Implementation |
| inline_planning | Present plan before implementing | Implementation planning |
| issue_accountability | Always address discovered issues; never dismiss as "out of scope" | All phases |
See references/coding-principles.md for details.
Note: The question_self_check principle has been consolidated into Common Principles. See the section below.
Principles to reduce excessive AskUserQuestion usage.
| Principle | Summary | When to Apply |
|---|---|---|
| question_self_check | Self-check whether the question is truly necessary | All phases |
| default_value_usage | Use defaults when clearly available instead of confirming | Configuration lookup |
| context_inference | Infer from context instead of asking | All phases |
See references/common-principles.md for details.
All gh commands that accept --body or --comment parameters MUST use safe patterns to avoid shell injection:
--body-file with mktemp for multi-line contentreferences/gh-cli-patterns.md for detailed safe patternsNever pass user-generated content directly via --body or --comment flags.
This skill works with:
/zen:* commands