[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M734CJS4RFTWV217ZW5RBCZC":3,"skill-same:01M734CJS4RFTWV217ZW5RBCZC":56},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":6,"ownerHtmlUrl":30,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":31,"install":32,"resources":45},"01M734CJS4RFTWV217ZW5RBCZC","create-techspec",null,"Creates a Technical Specification by translating PRD business requirements into implementation designs through interactive technical clarification. Use when a PRD exists and needs a technical plan, or when technical architecture decisions need documentation. Do not use for PRD creation, task breakdown, or direct code implementation.","itseffi\u002Fproductize","itseffi","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F15998472?v=4","01M734C5RJ7CKRTPB3FX84VZV7","Effi","01M734C5S6B7FW62ZNWYBZ9GG7",3,"MIT","https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize\u002Fblob\u002Fmain\u002Fskills\u002Fcreate-techspec\u002FSKILL.md",[],[],"2026-11-11 15:11:14",false,"---\nname: create-techspec\ndescription: Creates a Technical Specification by translating PRD business requirements into implementation designs through interactive technical clarification. Use when a PRD exists and needs a technical plan, or when technical architecture decisions need documentation. Do not use for PRD creation, task breakdown, or direct code implementation.\nargument-hint: \"[feature-name] [prd-file]\"\n---\n\n# Create TechSpec\n\nTranslate business requirements into a detailed technical specification.\n\n\u003CHARD-GATE>\nDo NOT write the TechSpec file until ALL phases are complete and the user has approved the final draft.\nDo NOT skip the codebase exploration — every TechSpec MUST be informed by existing architecture.\nDo NOT skip user interactions — the user MUST participate in shaping the TechSpec at every decision point.\nDo NOT require section-by-section approval — generate the complete draft, then let the user review it.\nThis applies to EVERY TechSpec regardless of perceived simplicity.\n\u003C\u002FHARD-GATE>\n\n## Asking Questions\n\nWhen this skill instructs you to ask the user a question, you MUST use your runtime's dedicated interactive question tool — the tool or function that presents a question to the user and **pauses execution until the user responds**. Do not output questions as plain assistant text and continue generating; always use the mechanism that blocks until the user has answered.\n\nIf your runtime does not provide such a tool, present the question as your complete message and stop generating. Do not answer your own question or proceed without user input.\n\n## Anti-Pattern: \"This Is Too Simple To Need Technical Design Review\"\n\nEvery TechSpec goes through the full design review process. A single endpoint, a minor refactor, a configuration change — all of them. \"Simple\" technical changes are where unexamined assumptions about existing architecture cause the most integration failures. The design review can be brief for genuinely simple changes, but you MUST ask technical clarification questions and get approval on the technical approach before writing the artifact.\n\n## Anti-Pattern: End-Of-Flow Bureaucracy\n\nOnce the user has answered the technical clarification questions and approved an approach, do not force them through a second approval loop for System Architecture, Data Models, API Design, or other final document sections. Synthesize the approved direction into the TechSpec directly. The user can review and request edits in the generated file afterward.\n\n## Required Inputs\n\n- Feature name identifying the `.productize\u002Ftasks\u002F\u003Cname>\u002F` directory.\n- Optional: existing `_prd.md` as primary input.\n- Optional: existing `_techspec.md` for update mode.\n\n## Checklist\n\nYou MUST create a task for each phase and complete them in order:\n\n1. **Gather context** — read PRD, ADRs, and explore codebase architecture\n2. **Ask technical questions** — 3-6 targeted questions on architecture, data models, APIs, testing\n3. **Create ADRs** — record significant technical decisions (architecture pattern, technology choices, data model approach)\n4. **Draft the TechSpec** — write using the canonical template from `references\u002Ftechspec-template.md`\n5. **Review with user** — present the draft, iterate until approved\n6. **Save the file** — write to `.productize\u002Ftasks\u002F\u003Cname>\u002F_techspec.md`\n\n## Workflow\n\n1. Gather context.\n   - Read every existing canonical project knowledge document first:\n     - `.productize\u002Fproject\u002Fcontext.md`\n     - `.productize\u002Fproject\u002Fconventions.md`\n     - `.productize\u002Fproject\u002Farchitecture.md`\n     - `.productize\u002Fproject\u002Fdecisions.md`\n     - `.productize\u002Fproject\u002Fconstraints.md`\n   - Read `.productize\u002Fproject\u002Fmanual.md` when present for human-authored additions that are intentionally kept outside the generated read models.\n   - Check for `_prd.md` in `.productize\u002Ftasks\u002F\u003Cname>\u002F`. If it exists, read it as the primary input.\n   - If no PRD exists, ask the user for a description of what needs technical specification.\n   - Read existing ADRs from `.productize\u002Ftasks\u002F\u003Cname>\u002Fadrs\u002F` to understand decisions already made during PRD creation.\n   - Create `.productize\u002Ftasks\u002F\u003Cname>\u002Fadrs\u002F` directory if it does not exist.\n   - Spawn an Agent tool call to explore the codebase for architecture patterns, existing components, dependencies, and technology stack.\n   - If `_techspec.md` already exists, read it and operate in update mode.\n\n2. Ask technical clarification questions.\n   - Focus on HOW to implement, WHERE components live, and WHICH technologies to use.\n   - Cover architecture approach and component boundaries.\n   - Cover data models and storage choices.\n   - Cover API design and integration points.\n   - Cover testing strategy and performance requirements.\n   - Ask only one question per message. If a topic needs more exploration, break it into a sequence of individual questions.\n   - Prefer multiple-choice questions when the options can be predetermined.\n   - Include a fallback option (e.g., \"D) Other — describe\") for flexibility.\n\n3. Create ADRs for significant technical decisions.\n   - For each significant decision (architecture pattern chosen, technology selected, data model approach, etc.):\n     - Read `references\u002Fadr-template.md`.\n     - Determine the next ADR number by listing existing files in `.productize\u002Ftasks\u002F\u003Cname>\u002Fadrs\u002F`.\n     - Fill the template: the chosen design as \"Decision\", rejected alternatives as \"Alternatives Considered\", and trade-offs as \"Consequences\". Set `kind` to `architecture` for architectural decisions or `technical` for other implementation decisions, `status` to `accepted`, `date` to today, and `supersedes` to a YAML list of ADR references replaced by this decision (for example, `ADR-001`) or `[]`. Keep the Markdown Status and Date sections aligned with that metadata.\n     - When `supersedes` is non-empty, update each replaced ADR's metadata status to `superseded` and its Markdown Status to `Superseded by ADR-NNN`, naming the new ADR.\n     - Write each ADR to `.productize\u002Ftasks\u002F\u003Cname>\u002Fadrs\u002Fadr-NNN.md` (zero-padded 3-digit sequential number).\n\n4. Draft the TechSpec.\n   - Read `references\u002Ftechspec-template.md` and fill every applicable section.\n   - **MANDATORY — Architecture Decision Records section:** The generated TechSpec MUST end with an \"Architecture Decision Records\" section listing every ADR created during this process. Each entry must include the ADR number (e.g., ADR-001), title, and a one-line summary formatted as a link to the `adrs\u002F` directory. Even simple features require at least one ADR documenting the primary technical approach chosen and alternatives rejected. If no ADRs were created in step 3, go back and create at least one before generating the document.\n   - Apply YAGNI ruthlessly: remove any component, interface, or abstraction that is not strictly necessary. Do NOT propose new packages or directories when the feature can be implemented by adding a single file to an existing package.\n   - Every PRD goal and user story should map to a technical component.\n   - Reference PRD sections by name but do not duplicate business context.\n   - Include code examples only for core interfaces, limited to 20 lines each. The Core Interfaces section must contain at least one Go interface or struct definition as a code block, even for simple features — show the primary type that other components will depend on.\n   - The Development Sequencing section MUST include a numbered Build Order where every step after the first explicitly states which previous steps it depends on.\n   - Prefer active voice, omit needless words, use definite and specific language over vague generalities. Every sentence should earn its place.\n   - Language: **English**. Tone: clear, technical, consistent with existing project artifacts.\n   - Present the complete draft to the user for review.\n\n5. Review with the user.\n   - Present the draft and ask using the interactive question tool:\n     - \"Here is the TechSpec draft. Please review and let me know:\"\n     - A) Approved — save as is\n     - B) Adjust specific sections (tell me which ones)\n     - C) Rewrite section X (tell me what to change)\n     - D) Discard and start over\n   - If B or C: make the changes and present again.\n   - If D: go back to step 2.\n\n6. Save the TechSpec file.\n   - Write the completed document to `.productize\u002Ftasks\u002F\u003Cname>\u002F_techspec.md`.\n   - Confirm the file path to the user.\n   - Remind the user that the next step is to create tasks using `create-tasks` from this TechSpec.\n\n## Process Flow\n\n```dot\ndigraph create_techspec {\n    \"Gather context (PRD + codebase)\" [shape=box];\n    \"Ask technical questions (one at a time)\" [shape=box];\n    \"Create ADRs for key decisions\" [shape=box];\n    \"Draft TechSpec (canonical template)\" [shape=box];\n    \"User approves draft?\" [shape=diamond];\n    \"Save _techspec.md\" [shape=doublecircle];\n\n    \"Gather context (PRD + codebase)\" -> \"Ask technical questions (one at a time)\";\n    \"Ask technical questions (one at a time)\" -> \"Create ADRs for key decisions\";\n    \"Create ADRs for key decisions\" -> \"Draft TechSpec (canonical template)\";\n    \"Draft TechSpec (canonical template)\" -> \"User approves draft?\";\n    \"User approves draft?\" -> \"Draft TechSpec (canonical template)\" [label=\"no, revise\"];\n    \"User approves draft?\" -> \"Save _techspec.md\" [label=\"approved\"];\n}\n```\n\n## Error Handling\n\n- If the PRD is missing, proceed with user-provided context and note the absence in the Executive Summary.\n- If codebase exploration reveals conflicting architectural patterns, document both and recommend one with rationale.\n- If the user rejects the design proposal, incorporate all feedback and present a revised proposal.\n- If the target directory does not exist, create it.\n- If operating in update mode, preserve sections the user has not asked to change.\n\n## Key Principles\n\n- **One question at a time** — Do not overwhelm with multiple questions in a single message\n- **Multiple choice preferred** — Easier for users to answer than open-ended when possible\n- **YAGNI ruthlessly** — Remove unnecessary components, abstractions, and interfaces from all designs\n- **Draft then review** — Generate the complete TechSpec draft first, then iterate with the user until approved\n- **Technical focus only** — Never ask business questions; that belongs in the PRD\n- **Trade-offs are mandatory** — Every Executive Summary must state the primary technical trade-off of the chosen approach\n- **PRD as input** — When `_prd.md` exists, use it as primary context; every PRD goal should map to a technical component\n- **Pipeline awareness** — The TechSpec feeds into `create-tasks`; focus on HOW, not WHAT or WHY\n- **Template compliance** — Every TechSpec MUST follow the canonical template\n- **Language consistency** — Write all TechSpec content in English\n","# Create TechSpec\n\nTranslate business requirements into a detailed technical specification.\n\n\u003CHARD-GATE>\nDo NOT write the TechSpec file until ALL phases are complete and the user has approved the final draft.\nDo NOT skip the codebase exploration — every TechSpec MUST be informed by existing architecture.\nDo NOT skip user interactions — the user MUST participate in shaping the TechSpec at every decision point.\nDo NOT require section-by-section approval — generate the complete draft, then let the user review it.\nThis applies to EVERY TechSpec regardless of perceived simplicity.\n\u003C\u002FHARD-GATE>\n\n## Asking Questions\n\nWhen this skill instructs you to ask the user a question, you MUST use your runtime's dedicated interactive question tool — the tool or function that presents a question to the user and **pauses execution until the user responds**. Do not output questions as plain assistant text and continue generating; always use the mechanism that blocks until the user has answered.\n\nIf your runtime does not provide such a tool, present the question as your complete message and stop generating. Do not answer your own question or proceed without user input.\n\n## Anti-Pattern: \"This Is Too Simple To Need Technical Design Review\"\n\nEvery TechSpec goes through the full design review process. A single endpoint, a minor refactor, a configuration change — all of them. \"Simple\" technical changes are where unexamined assumptions about existing architecture cause the most integration failures. The design review can be brief for genuinely simple changes, but you MUST ask technical clarification questions and get approval on the technical approach before writing the artifact.\n\n## Anti-Pattern: End-Of-Flow Bureaucracy\n\nOnce the user has answered the technical clarification questions and approved an approach, do not force them through a second approval loop for System Architecture, Data Models, API Design, or other final document sections. Synthesize the approved direction into the TechSpec directly. The user can review and request edits in the generated file afterward.\n\n## Required Inputs\n\n- Feature name identifying the `.productize\u002Ftasks\u002F\u003Cname>\u002F` directory.\n- Optional: existing `_prd.md` as primary input.\n- Optional: existing `_techspec.md` for update mode.\n\n## Checklist\n\nYou MUST create a task for each phase and complete them in order:\n\n1. **Gather context** — read PRD, ADRs, and explore codebase architecture\n2. **Ask technical questions** — 3-6 targeted questions on architecture, data models, APIs, testing\n3. **Create ADRs** — record significant technical decisions (architecture pattern, technology choices, data model approach)\n4. **Draft the TechSpec** — write using the canonical template from `references\u002Ftechspec-template.md`\n5. **Review with user** — present the draft, iterate until approved\n6. **Save the file** — write to `.productize\u002Ftasks\u002F\u003Cname>\u002F_techspec.md`\n\n## Workflow\n\n1. Gather context.\n   - Read every existing canonical project knowledge document first:\n     - `.productize\u002Fproject\u002Fcontext.md`\n     - `.productize\u002Fproject\u002Fconventions.md`\n     - `.productize\u002Fproject\u002Farchitecture.md`\n     - `.productize\u002Fproject\u002Fdecisions.md`\n     - `.productize\u002Fproject\u002Fconstraints.md`\n   - Read `.productize\u002Fproject\u002Fmanual.md` when present for human-authored additions that are intentionally kept outside the generated read models.\n   - Check for `_prd.md` in `.productize\u002Ftasks\u002F\u003Cname>\u002F`. If it exists, read it as the primary input.\n   - If no PRD exists, ask the user for a description of what needs technical specification.\n   - Read existing ADRs from `.productize\u002Ftasks\u002F\u003Cname>\u002Fadrs\u002F` to understand decisions already made during PRD creation.\n   - Create `.productize\u002Ftasks\u002F\u003Cname>\u002Fadrs\u002F` directory if it does not exist.\n   - Spawn an Agent tool call to explore the codebase for architecture patterns, existing components, dependencies, and technology stack.\n   - If `_techspec.md` already exists, read it and operate in update mode.\n\n2. Ask technical clarification questions.\n   - Focus on HOW to implement, WHERE components live, and WHICH technologies to use.\n   - Cover architecture approach and component boundaries.\n   - Cover data models and storage choices.\n   - Cover API design and integration points.\n   - Cover testing strategy and performance requirements.\n   - Ask only one question per message. If a topic needs more exploration, break it into a sequence of individual questions.\n   - Prefer multiple-choice questions when the options can be predetermined.\n   - Include a fallback option (e.g., \"D) Other — describe\") for flexibility.\n\n3. Create ADRs for significant technical decisions.\n   - For each significant decision (architecture pattern chosen, technology selected, data model approach, etc.):\n     - Read `references\u002Fadr-template.md`.\n     - Determine the next ADR number by listing existing files in `.productize\u002Ftasks\u002F\u003Cname>\u002Fadrs\u002F`.\n     - Fill the template: the chosen design as \"Decision\", rejected alternatives as \"Alternatives Considered\", and trade-offs as \"Consequences\". Set `kind` to `architecture` for architectural decisions or `technical` for other implementation decisions, `status` to `accepted`, `date` to today, and `supersedes` to a YAML list of ADR references replaced by this decision (for example, `ADR-001`) or `[]`. Keep the Markdown Status and Date sections aligned with that metadata.\n     - When `supersedes` is non-empty, update each replaced ADR's metadata status to `superseded` and its Markdown Status to `Superseded by ADR-NNN`, naming the new ADR.\n     - Write each ADR to `.productize\u002Ftasks\u002F\u003Cname>\u002Fadrs\u002Fadr-NNN.md` (zero-padded 3-digit sequential number).\n\n4. Draft the TechSpec.\n   - Read `references\u002Ftechspec-template.md` and fill every applicable section.\n   - **MANDATORY — Architecture Decision Records section:** The generated TechSpec MUST end with an \"Architecture Decision Records\" section listing every ADR created during this process. Each entry must include the ADR number (e.g., ADR-001), title, and a one-line summary formatted as a link to the `adrs\u002F` directory. Even simple features require at least one ADR documenting the primary technical approach chosen and alternatives rejected. If no ADRs were created in step 3, go back and create at least one before generating the document.\n   - Apply YAGNI ruthlessly: remove any component, interface, or abstraction that is not strictly necessary. Do NOT propose new packages or directories when the feature can be implemented by adding a single file to an existing package.\n   - Every PRD goal and user story should map to a technical component.\n   - Reference PRD sections by name but do not duplicate business context.\n   - Include code examples only for core interfaces, limited to 20 lines each. The Core Interfaces section must contain at least one Go interface or struct definition as a code block, even for simple features — show the primary type that other components will depend on.\n   - The Development Sequencing section MUST include a numbered Build Order where every step after the first explicitly states which previous steps it depends on.\n   - Prefer active voice, omit needless words, use definite and specific language over vague generalities. Every sentence should earn its place.\n   - Language: **English**. Tone: clear, technical, consistent with existing project artifacts.\n   - Present the complete draft to the user for review.\n\n5. Review with the user.\n   - Present the draft and ask using the interactive question tool:\n     - \"Here is the TechSpec draft. Please review and let me know:\"\n     - A) Approved — save as is\n     - B) Adjust specific sections (tell me which ones)\n     - C) Rewrite section X (tell me what to change)\n     - D) Discard and start over\n   - If B or C: make the changes and present again.\n   - If D: go back to step 2.\n\n6. Save the TechSpec file.\n   - Write the completed document to `.productize\u002Ftasks\u002F\u003Cname>\u002F_techspec.md`.\n   - Confirm the file path to the user.\n   - Remind the user that the next step is to create tasks using `create-tasks` from this TechSpec.\n\n## Process Flow\n\n```dot\ndigraph create_techspec {\n    \"Gather context (PRD + codebase)\" [shape=box];\n    \"Ask technical questions (one at a time)\" [shape=box];\n    \"Create ADRs for key decisions\" [shape=box];\n    \"Draft TechSpec (canonical template)\" [shape=box];\n    \"User approves draft?\" [shape=diamond];\n    \"Save _techspec.md\" [shape=doublecircle];\n\n    \"Gather context (PRD + codebase)\" -> \"Ask technical questions (one at a time)\";\n    \"Ask technical questions (one at a time)\" -> \"Create ADRs for key decisions\";\n    \"Create ADRs for key decisions\" -> \"Draft TechSpec (canonical template)\";\n    \"Draft TechSpec (canonical template)\" -> \"User approves draft?\";\n    \"User approves draft?\" -> \"Draft TechSpec (canonical template)\" [label=\"no, revise\"];\n    \"User approves draft?\" -> \"Save _techspec.md\" [label=\"approved\"];\n}\n```\n\n## Error Handling\n\n- If the PRD is missing, proceed with user-provided context and note the absence in the Executive Summary.\n- If codebase exploration reveals conflicting architectural patterns, document both and recommend one with rationale.\n- If the user rejects the design proposal, incorporate all feedback and present a revised proposal.\n- If the target directory does not exist, create it.\n- If operating in update mode, preserve sections the user has not asked to change.\n\n## Key Principles\n\n- **One question at a time** — Do not overwhelm with multiple questions in a single message\n- **Multiple choice preferred** — Easier for users to answer than open-ended when possible\n- **YAGNI ruthlessly** — Remove unnecessary components, abstractions, and interfaces from all designs\n- **Draft then review** — Generate the complete TechSpec draft first, then iterate with the user until approved\n- **Technical focus only** — Never ask business questions; that belongs in the PRD\n- **Trade-offs are mandatory** — Every Executive Summary must state the primary technical trade-off of the chosen approach\n- **PRD as input** — When `_prd.md` exists, use it as primary context; every PRD goal should map to a technical component\n- **Pipeline awareness** — The TechSpec feeds into `create-tasks`; focus on HOW, not WHAT or WHY\n- **Template compliance** — Every TechSpec MUST follow the canonical template\n- **Language consistency** — Write all TechSpec content in English\n",{"name":5,"description":7,"argument-hint":24},"[feature-name] [prd-file]","main","f177680a573a242a81bd0a776f9681f620e6d74c","skills\u002Fcreate-techspec",0,"https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize","https:\u002F\u002Fgithub.com\u002Fitseffi","2026-08-07 20:07:32",{"source":8,"skillName":5,"commands":33,"prompt":43,"zipAvailable":44},[34,37,40],{"tool":35,"command":36},"npx","npx skills add itseffi\u002Fproductize --skill create-techspec",{"tool":38,"command":39},"bunx","bunx skills add itseffi\u002Fproductize --skill create-techspec",{"tool":41,"command":42},"pnpm","pnpm dlx skills add itseffi\u002Fproductize --skill create-techspec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize\u002Fblob\u002Fmain\u002Fskills\u002Fcreate-techspec\u002FSKILL.md",true,[46,52],{"path":47,"resourceType":48,"resourceTypeDesc":49,"sizeBytes":50,"sourceHtmlUrl":51},"references\u002Fadr-template.md","REFERENCE","参考文档",1305,"https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize\u002Fblob\u002Fmain\u002Fskills\u002Fcreate-techspec\u002Freferences\u002Fadr-template.md",{"path":53,"resourceType":48,"resourceTypeDesc":49,"sizeBytes":54,"sourceHtmlUrl":55},"references\u002Ftechspec-template.md",3230,"https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize\u002Fblob\u002Fmain\u002Fskills\u002Fcreate-techspec\u002Freferences\u002Ftechspec-template.md",[57,64,71,78,85,92],{"skillNo":58,"name":59,"nameZh":6,"description":60,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":61,"categories":62,"keywords":63,"publishedAt":19},"01M7357QB5M87V95F82E73V2TF","workflow-memory","Maintains workflow-scoped task memory for Productize runs using .productize\u002Ftasks\u002F\u003Cname>\u002Fmemory\u002F files. Use when a task prompt provides workflow memory paths and requires the agent to read, update, compact, and promote durable context across PRD task executions. Do not use for PR review remediation, global user preferences, or programmatic event-log summarization.","https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow-memory\u002FSKILL.md",[],[],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":70,"publishedAt":19},"01M7357K97HSYEHAQTW5ZKM4CE","review-round","Performs a comprehensive code review of a PRD implementation and generates a review round directory with issue files compatible with fix-reviews. Use when reviewing implemented PRD tasks, creating a manual review round without an external provider, or performing a quality audit of code changes. Do not use for fetching reviews from external providers, fixing existing review issues, executing PRD tasks, or editing source code.","https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize\u002Fblob\u002Fmain\u002Fskills\u002Freview-round\u002FSKILL.md",[],[],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":19},"01M7357F2NZE5NSYM2SJXEGBFZ","productize","Productize root skill for building, shipping, operating, and growing AI products inside a coding harness. Routes work across thesis framing, discovery, research, positioning, finance, decision making, requirements, design, metrics, AI-builder execution, code implementation, verification, stakeholder narratives, growth, launch, operation, and learning workflows. Use when the user wants to build a product from zero, improve an existing product, or needs product work that spans multiple lifecycle stages before code, launch, operation, or growth execution.","https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize\u002Fblob\u002Fmain\u002Fskills\u002Fproductize\u002FSKILL.md",[],[],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":19},"01M7357B48F8MK86EQF135FJQ6","productize-wwas","Why-What-Acceptance. Use when writing backlog items in Why-What-Acceptance format, breaking features into independent valuable work, or adding strategic context to delivery items.","https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize\u002Fblob\u002Fmain\u002Fskills\u002Fproductize-wwas\u002FSKILL.md",[],[],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":19},"01M735783CDA9MQ0SPR9X6QZSE","productize-writing-plans","Create comprehensive implementation plans with bite-sized tasks. Use when you have requirements before touching code.","https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize\u002Fblob\u002Fmain\u002Fskills\u002Fproductize-writing-plans\u002FSKILL.md",[],[],{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":19},"01M735750V5Q6WRBX1ZFGNRMEB","productize-write-spec","Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea into a structured document, scoping goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into phases.","https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize\u002Fblob\u002Fmain\u002Fskills\u002Fproductize-write-spec\u002FSKILL.md",[],[]]