一键导入
fizzy-product-manager
Product management knowledge for Fizzy Kanban boards — Kanban principles, API workflows, triage, hygiene, and reporting
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Product management knowledge for Fizzy Kanban boards — Kanban principles, API workflows, triage, hygiene, and reporting
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Orchestrate a plan → review → implement delivery loop across three PLUGGABLE agent roles — planner, reviewer, implementer — where any agent can fill any role in any order. One agent drafts an artifact (SRS / design / per-task plan), a second adversarially reviews it through a shared markdown thread until convergence (Final ACK), and a third implements; the orchestrator (the agent running this skill) relays handoffs, monitors the review thread, and reviews the resulting PR. Use when the user asks to "run the planner / reviewer / implementer loop", "tri-agent loop", "plan-review-implement", "use X to plan, Y to review, Z to implement" (any permutation, e.g. Claude plans, Codex reviews, Cursor implements), or wants the docs-first / Codex-reviewed / Cursor-implemented workflow from feedback_planner_reviewer_codex_loop generalized to arbitrary agents.
Interview the user relentlessly about a plan, design, or approach until every branch of the decision tree is explicit and defensible. Turns the agent from order-taker into peer programmer — one who pushes back, names hidden assumptions, recommends instead of just asking, and refuses to start implementation while a load-bearing decision is still in the user's head. Use when the user says "grill me", "stress-test this plan", "interview me on this design", "challenge my approach", "are there gaps in my plan?", or wants a peer-review pass before committing to a direction.
Compact the current conversation into a structured handoff document (saved to the OS temp directory) so a fresh agent can continue the work without losing context. Use when the user invokes /handoff, says "create a handoff doc", "write a handoff document", "compact this for another agent", "pass off to another session", "what will the next session focus on", or generally wants to checkpoint the conversation state before a context-window break. Always references existing artifacts (design docs, plans, PRs, commits, memory entries) by path/URL — never duplicates their content. Includes a mandatory "suggested skills" section. Redacts API keys, passwords, PII.
Harness two AI agents (typically Claude + OpenAI Codex, or two Claudes, or an agent + human reviewer) into a Reviewer / Implementor pair that collaborate asynchronously through a shared markdown thread. One agent reviews / critiques / asks pointed questions; the other implements / responds / drives the code changes; the file mediates. Use when the user says "pair another agent on this", "harness Codex on this", "review this with Codex", "open a Codex thread", "respond to Codex", "open a peer review", "monitor this review file", names a *-review-thread.md or *-dialogue-thread.md, or wants to coordinate structured async back-and-forth between two AI agents on a code or design question. Seeds the file from a template if missing, appends a numbered Claude response under its own section header, arms a file-mtime monitor so each peer append triggers a fresh read + response, drives the pyramid-principle response shape (position first, justification second), detects consensus markers like "Final ACK" / "No further ob
Convert the current plan, spec, design doc, or conversation context into a single self-contained, share-able HTML file with rich visual structure (tables, SVG diagrams, code blocks, responsive layout, in-page navigation). Supports four output shapes — editorial, technical-doc, dashboard, and slide-deck. Use when the user invokes /html-output, asks to "export as HTML", "render this as HTML", "structure your response as HTML" (Karpathy-style), "make a web version", "share this as a link", "present this as slides / a slideshow / a deck", or wants a long plan or spec converted from markdown into something visually scannable or presentable.
Software Requirements Specification documentation following IEEE 830 standard. Use when generating formal SRS documents or compiling gathered requirements into structured documentation.
| name | fizzy-product-manager |
| description | Product management knowledge for Fizzy Kanban boards — Kanban principles, API workflows, triage, hygiene, and reporting |
| metadata | {"tags":"fizzy, kanban, product-management, api, triage, boards, cards"} |
Use this skill whenever you are managing Fizzy Kanban boards, triaging cards, running board health checks, generating reports, or performing any product management task via the Fizzy API.
The full Fizzy API specification is at docs/fizzy-api.md. Load it when you need complete endpoint details, request/response schemas, or parameter references.
When applying Kanban methodology to board management, load the ./rules/kanban-principles.md file.
When you need Tap Games-specific board templates, ticket templates, working procedure, or code-aware triage defaults, load the ./rules/tap-games-context.md file.
When processing the triage queue (Maybe? cards), load the ./rules/card-triage.md file for the decision framework and batch workflow.
For routine board maintenance and health checks, load the ./rules/board-hygiene.md file for the 7-step weekly checklist.
When generating board status reports, activity summaries, or workload breakdowns, load the ./rules/board-reports.md file.
For multi-step curl workflows (triage sessions, health checks, bulk operations), load the ./rules/api-recipes.md file.
When executing the Fizzy → Jira migration for Tap Games, load the ./rules/jira-migration.md file. It is the single-use runbook for the cutover into the TG project on globalcompetitionworld.atlassian.net. Remove the file (and this pointer) after Phase 4 completes.
Read individual rule files for detailed explanations, API examples, and workflows:
TG project on GCW) cutover runbook