[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FNTSCFW0RGR0EKTTBTPKZX":3,"skill-same:01M6FNTSCFW0RGR0EKTTBTPKZX":62},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":45,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":48,"install":49,"resources":61},"01M6FNTSCFW0RGR0EKTTBTPKZX","pp-spec",null,"Use when starting a new feature or project that needs a functional specification before implementation.","ohmyhotelco\u002Fhare-cc-plugins","ohmyhotelco","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F258133233?v=4","01M6CR4HP2N9F9ZWNX1KRHQ2W1","01M6CR4HSJC5J80RVQMD5K9QRN",2,"MIT","https:\u002F\u002Fgithub.com\u002Fohmyhotelco\u002Fhare-cc-plugins\u002Fblob\u002Fmain\u002Fplanning-plugin\u002Fskills\u002Fpp-spec\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33],"pp","spec","pp spec","feature","project","use","Bash","specification","new feature","functional","read","write","edit","grep","implementation","true","2026-11-10 10:12:30",false,"---\nname: pp-spec\ndescription: Use when starting a new feature or project that needs a functional specification before implementation.\nargument-hint: \"[feature description]\"\nuser-invocable: true\nallowed-tools: Read, Write, Edit, Glob, Grep, Bash, Agent\n---\n\n# Functional Specification Generator\n\nGenerate a comprehensive functional specification for: **$ARGUMENTS**\n\n## Instructions\n\nFollow these steps in order. After each major step, update the progress file.\n\n### Step 0: Read Configuration\n\n1. Read `.claude\u002Fplanning-plugin.json` from the current project directory\n2. If the file does not exist, stop with a guidance message:\n   > \"Planning Plugin is not configured for this project. Run `\u002Fplanning-plugin:pp-init` to set up.\"\n3. Extract `workingLanguage` (default: `\"en\"` if field is absent)\n4. Extract `supportedLanguages` (default: `[\"en\", \"ko\", \"vi\"]`)\n5. Determine target languages: `supportedLanguages` minus `workingLanguage`\n6. Language name mapping: `en` = English, `ko` = Korean, `vi` = Vietnamese\n\n**Communication language**: All user-facing output in this skill (summaries, questions, feedback presentations, next-step guidance) must be in {workingLanguage_name}.\n\n### Step 1: Initialize\n\n1. Derive a kebab-case feature name from the user's description (e.g., \"social login\" → `social-login`)\n2. **If the feature directory already exists**, read the progress file and use its `workingLanguage` value (ignore `planning-plugin.json` for existing specs). Ask the user whether to resume or start fresh.\n3. Create the output directory structure:\n   ```\n   docs\u002Fspecs\u002F{feature}\u002F{workingLanguage}\u002F\n   docs\u002Fspecs\u002F{feature}\u002F.progress\u002F\n   ```\n   Also create directories for each target language:\n   ```\n   docs\u002Fspecs\u002F{feature}\u002F{target_lang}\u002F\n   ```\n4. Create the initial progress file at `docs\u002Fspecs\u002F{feature}\u002F.progress\u002F{feature}.json`:\n   ```json\n   {\n     \"feature\": \"{feature}\",\n     \"status\": \"analyzing\",\n     \"workingLanguage\": \"{workingLanguage}\",\n     \"currentRound\": 0,\n     \"rounds\": [],\n     \"translations\": {\n       \"{target_lang_1}\": { \"synced\": false, \"lastSyncedAt\": null },\n       \"{target_lang_2}\": { \"synced\": false, \"lastSyncedAt\": null }\n     }\n   }\n   ```\n\n### Step 2: Context Analysis & Requirements Gathering\n\nLaunch the **analyst** agent using the Agent tool:\n\n```\nAgent(subagent_type: \"planning-plugin:analyst\", prompt: \"Analyze the project at {cwd} and gather requirements for the feature: {feature description}. Follow your two-phase process: first analyze the project context, then ask structured questions across all 8 categories. Communicate with the user in {workingLanguage_name}.\")\n```\n\n**Important interaction pattern:**\n- The analyst will first present context analysis results and initial questions\n- Present the analyst's questions to the user and collect answers\n- Feed answers back to the analyst for completeness scoring\n- Repeat until overall score >= 7 or the user explicitly says to proceed\n- If the user wants to skip questions, mark them as TBD\n\nUpdate progress status to `\"drafting\"` when requirements gathering is complete.\n\n### Step 3: Generate Draft\n\nUsing the analyst's collected requirements and the 3 templates in `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002F`:\n\n1. Read all 3 templates: `spec-overview.md`, `screens.md`, `test-scenarios.md`\n2. Fill in all sections with the gathered requirements\n3. For each screen definition in `screens.md`, generate an **ASCII layout diagram** in the Layout section using the format shown in the template: named regions in `[ brackets ]` inside box-drawn containers, with components listed as `- ComponentName`. The diagram must be consistent with the Components table — every component in the table should appear in the diagram, and vice versa.\n4. Write all spec content in {workingLanguage_name}. Keep section heading labels in English (## 1. Overview etc.) as structural markers.\n5. For sections with insufficient information, add TBD markers with context\n6. Write 3 files to `docs\u002Fspecs\u002F{feature}\u002F{workingLanguage}\u002F`:\n   - `{feature}-spec.md` — from `spec-overview.md` template (overview, user stories, functional requirements, spec file index, open questions, review history)\n   - `screens.md` — from `screens.md` template (screen definitions, error handling)\n   - `test-scenarios.md` — from `test-scenarios.md` template (NFR + test scenarios)\n7. Set the document status to `DRAFT` in `{feature}-spec.md`\n\n### Step 3.5: Shared Layout Detection & Creation\n\nAfter generating the 3 draft files, detect whether the feature uses a shared layout shell and optionally create `docs\u002Fspecs\u002F_shared\u002Fen\u002Fscreens.md`.\n\n**3.5a. Detect shared layout pattern** — Analyze the analyst's `user_flow` category answers for:\n- A persistent shell (sidebar\u002Fnavigation + header) that spans multiple screens\n- A content area where different screens render inside the shell\n- **Skip this step entirely** if the feature has only a single screen, consists of standalone screens (login, landing, error pages), or each screen has its own independent full layout\n\n**3.5b. No pattern detected** — Do nothing. Leave the `\u003C!-- @layout: ... -->` comment block in `screens.md` as-is from the template. Proceed to Step 4.\n\n**3.5c. Pattern detected — `docs\u002Fspecs\u002F_shared\u002Fen\u002Fscreens.md` already exists**:\n1. Inform the user: \"A shared layout already exists. Referencing it via `@layout:` directive.\"\n2. Extract layout-id(s) from the existing file by parsing `### Screen:` headings → convert to kebab-case\n3. In the feature's `screens.md`, activate the `@layout:` directive (uncomment and set the correct `_shared\u002F{layout-id}`)\n4. Remove shell components (sidebar, header, navigation) from the feature screens' ASCII diagrams and Components tables — only for screens that render inside the shell. Standalone screens (login, 404, etc.) retain their own layout.\n\n**3.5d. Pattern detected — `docs\u002Fspecs\u002F_shared\u002Fen\u002Fscreens.md` does NOT exist**:\n1. Ask the user for confirmation: \"The screens share a sidebar + header shell. Would you like to create a shared layout that other features can also reuse? (y\u002Fn)\"\n2. **If declined**: Leave `@layout:` directive commented out. The feature will use local layout detection during DSL generation (existing behavior). Proceed to Step 4.\n3. **If approved**:\n   a. Create `docs\u002Fspecs\u002F_shared\u002Fen\u002F` directory\n   b. Generate `docs\u002Fspecs\u002F_shared\u002Fen\u002Fscreens.md` using the analyst's layout data. Generation rules:\n      - Follow the same format as `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fscreens.md`\n      - Define **exactly one layout screen**\n      - **Must include a `Slot` type component** (required by dsl-generator's layout-only mode)\n      - ASCII diagram must show the content insertion point (e.g., `(Each screen renders here)`)\n      - Component names and navigation items must be derived from the analyst's actual layout description (not hardcoded)\n      - No Error Handling section needed (layout screens have no business logic errors)\n      - **Always create under `en\u002F` directory** regardless of `workingLanguage` (UI DSL always reads from English)\n   c. In the feature's `screens.md`, activate the `@layout:` directive with the generated layout-id\n   d. Remove shell components from the feature screens that render inside the shell\n   e. Inform the user: \"After finalizing the spec, run `\u002Fplanning-plugin:pp-design _shared` first, then `\u002Fplanning-plugin:pp-design {feature}`.\"\n\n### Step 4: Sequential Review Cycle\n\nUpdate progress status to `\"reviewing\"` and increment `currentRound`.\n\nUpdate the metadata blockquote at the top of `{feature}-spec.md` in the {workingLanguage} directory:\n- Change `Status` to `REVIEWING`\n- Change `Last Updated` to the current timestamp (ISO 8601 format, e.g. 2026-03-04T09:00:00Z)\n\n**4a. Planner Review:**\n\nLaunch the **planner** agent:\n```\nAgent(subagent_type: \"planning-plugin:planner\", prompt: \"Review the functional specification at docs\u002Fspecs\u002F{feature}\u002F{workingLanguage}\u002F. The spec is split into multiple files — read all of them: {feature}-spec.md (overview, user stories, functional requirements, open questions), screens.md (screen definitions, error handling), test-scenarios.md. The specification is written in {workingLanguage_name}. Provide your review in {workingLanguage_name}. Evaluate user journey completeness, business logic clarity, error UX, integration consistency, and scope feasibility. Return your review as structured JSON.\")\n```\n\n**4b. Tester Review:**\n\nLaunch the **tester** agent, including the planner's feedback:\n```\nAgent(subagent_type: \"planning-plugin:tester\", prompt: \"Review the functional specification at docs\u002Fspecs\u002F{feature}\u002F{workingLanguage}\u002F. The spec is split into multiple files — read all of them: {feature}-spec.md (overview, user stories, functional requirements, open questions), screens.md (screen definitions, error handling), test-scenarios.md. The specification is written in {workingLanguage_name}. Provide your review in {workingLanguage_name}. The planner agent already reviewed it and found: {planner_feedback_summary}. Focus on testability, edge cases, and areas the planner may have missed. Return your review as structured JSON.\")\n```\n\n**4c. Present Combined Feedback:**\n\nRead `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Freview-reception-rules.md` and apply the review reception discipline.\n\nShow the user a summary of both reviews:\n- Overall scores (planner: X\u002F10, tester: Y\u002F10)\n- Each issue presented with a technical assessment (per review-reception-rules.md):\n  - Flag issues that conflict with previous round decisions (check progress file's `rounds` array)\n  - Flag issues where the reviewer may have misread the spec section\n  - Classify each suggestion's impact (improves spec \u002F neutral \u002F scope creep risk)\n  - Flag redundant issues (overlaps within same round or already addressed in prior rounds)\n- Proposed test cases from the tester\n- Approved sections\n\nResponse discipline: No performative agreement (\"Great point!\", \"Excellent observation!\"). Present technical assessments directly.\n\n**4d. Convergence Check:**\n\nFirst, compute `roundsInCycle`: read `reviewCycleStart` from the progress file (if absent or null, treat as 0), then `roundsInCycle = currentRound - reviewCycleStart`.\n\nApply these rules **in strict priority order** (first matching rule wins):\n1. **Both planner AND tester scores >= 8**: Suggest finalization — \"Both reviewers are satisfied (planner: X\u002F10, tester: Y\u002F10). Ready to finalize?\"\n2. **Either score \u003C 8 AND roundsInCycle \u003C 3**: Do NOT suggest finalization. Suggest another review round — \"Tester score is below 8 (planner: X\u002F10, tester: Y\u002F10, cycle round N\u002F3). Another review round is recommended.\"\n3. **roundsInCycle >= 3 with either score still \u003C 8**: Suggest finalization with caveats — \"After 3 rounds in this review cycle, scores are (planner: X\u002F10, tester: Y\u002F10). Here are the remaining open questions. Ready to finalize as-is?\"\n\n**Hard rule**: Never suggest or offer finalization if any score is below 8 AND fewer than 3 rounds have been completed in the current review cycle. This rule cannot be overridden by score trends or other factors.\n\n**4e. User Decision:**\n\nAsk the user what to do with each issue:\n- **Accept**: Apply the suggestion to the spec\n- **Reject**: Dismiss the issue with a note\n- **Modify**: Apply a modified version of the suggestion\n- **Defer**: Move to Open Questions section\n\nApply accepted changes to the appropriate file in the {workingLanguage} spec directory based on which section the issue targets (e.g., FR issues → `{feature}-spec.md`, screen\u002Ferror handling issues → `screens.md`).\n\nWhen applying changes, follow the review-reception-rules.md application discipline:\n- Re-read the target section before applying\n- If the suggestion would create inconsistency with other sections, note this to the user before applying\n- If multiple accepted suggestions target the same section, apply them as a coherent edit rather than sequential independent patches\n\nUpdate progress file with round results. Append an entry to the `rounds` array:\n```json\n{\n  \"round\": 1,\n  \"plannerScore\": 7,\n  \"testerScore\": 6,\n  \"issues\": [\n    {\n      \"id\": \"PL-001\",\n      \"section\": \"{feature}-spec.md > FR-001\",\n      \"decision\": \"Accept\",\n      \"suggestion\": \"Add password reset flow with email verification.\"\n    }\n  ]\n}\n```\nEach issue must include `id`, `section`, `decision` (Accept\u002FReject\u002FModify\u002FDefer), and `suggestion` (original text, or user's modified version for Modify decisions) for verification gate traceability.\n\n**4f. Repeat or Finalize:**\n\nBased on convergence check and user decision, either:\n- Go back to Step 4a for another round\n- Proceed to Step 5\n\n### Step 5: Generate Translations\n\nBefore launching translators, ask the user:\n> \"Translation will sync the spec to all target languages. This launches parallel translator agents and may take several minutes. How would you like to proceed?\"\n> 1. **Translate and finalize** — run translation now, then verify and finalize\n> 2. **Skip translation and finalize** — proceed directly to verification and finalization (run `\u002Fplanning-plugin:pp-translate {feature}` later to sync translations)\n\nIf the user selects option 2 (skip), jump directly to Step 5.5 (Pre-Finalization Verification).\n\nIf the user selects option 1 (translate and finalize):\n\nFor each target language, launch a **translator** agent in parallel using the Agent tool:\n\n```\nAgent(subagent_type: \"planning-plugin:translator\", prompt: \"Translate the spec directory at docs\u002Fspecs\u002F{feature}\u002F{workingLanguage}\u002F to {target_language_name}. Read each markdown file ({feature}-spec.md, screens.md, test-scenarios.md) and write translated versions to docs\u002Fspecs\u002F{feature}\u002F{target_lang}\u002F. Source language: {workingLanguage}. Full translation.\")\n```\n\nAfter all complete, update the progress file's translation status with `synced: true` and timestamps.\n\n### Step 5.5: Pre-Finalization Verification\n\nRead `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fverification-rules.md` and execute the verification gate.\n\n1. Read the progress file and collect all issues with \"Accept\" or \"Modify\" decisions from ALL rounds\n2. For each collected issue, read the relevant spec file section and verify the change is present in the text\n3. Present the verification summary showing verified\u002Funverified counts with evidence (e.g., `✓ PL-001: Found in {feature}-spec.md > FR-005`)\n4. If unverified items exist:\n   - Present each with its original suggestion\n   - Ask the user to: **resolve now** (apply the missing change) \u002F **defer** (move to Open Questions) \u002F **dismiss** (user explains how it was addressed differently)\n   - Record the resolution in the progress file\n5. Only proceed to Step 6 after all items are verified, deferred, or dismissed\n\nThis gate supplements the convergence check — both must pass before finalization.\n\n### Step 6: Finalize\n\n1. Update the metadata blockquote in `{feature}-spec.md` across all language versions that have spec files ({workingLanguage} directory always exists; only include target language directories where `{feature}-spec.md` actually exists — skip directories that are empty because translation was skipped):\n   - Change `Status` to `FINALIZED`\n   - Change `Last Updated` to the current timestamp (ISO 8601 format, e.g. 2026-03-04T09:00:00Z)\n2. Update the progress file:\n   ```json\n   { \"status\": \"finalized\" }\n   ```\n3. Present a summary:\n   - Total review rounds completed\n   - Final scores\n   - Key decisions made\n   - Any remaining open questions\n4. Suggest next steps:\n   - If `docs\u002Fspecs\u002F_shared\u002Fen\u002Fscreens.md` was created during this spec run (Step 3.5d):\n     > \"Run `\u002Fplanning-plugin:pp-design _shared` first to generate the shared layout DSL, then `\u002Fplanning-plugin:pp-design {feature}` to generate the feature DSL.\"\n   - Otherwise:\n     > \"Run `\u002Fplanning-plugin:pp-design {feature}` to generate UI DSL and Stitch wireframes, then `\u002Fplanning-plugin:pp-prototype {feature}` to generate the React prototype\"\n   - \"Run `\u002Fplanning-plugin:pp-review {feature}` anytime to re-review\"\n   - \"Edit the {workingLanguage} spec directly and run `\u002Fplanning-plugin:pp-translate {feature}` to sync translations\"\n   - \"Run `\u002Fplanning-plugin:pp-sync-notion {feature}` to manually re-sync Notion pages\"\n\n### Step 7: Sync to Notion (if configured)\n\n1. Read `.claude\u002Fplanning-plugin.json` and check `notionParentPageUrl` — if empty or missing, skip this step silently\n2. Read progress file for existing Notion page data (`notion` field)\n3. For each language (working language + all target languages where `{feature}-spec.md` actually exists inside the language directory — skip languages whose directories are empty because translation was skipped), sequentially launch the **sync-notion** agent:\n   ```\n   Agent(subagent_type: \"planning-plugin:sync-notion\", prompt: \"Sync the {langName} specification for feature '{feature}' to Notion.\n     feature: {feature}. lang: {lang}. langName: {langName}.\n     specDir: docs\u002Fspecs\u002F{feature}\u002F{lang}\u002F.\n     progressFile: docs\u002Fspecs\u002F{feature}\u002F.progress\u002F{feature}.json.\n     notionParentPageUrl: {notionParentPageUrl}.\n     existingPages: {JSON of notion.{lang} from progress or null}.\n     Read the 3 spec files, prepare content, and create\u002Fupdate Notion pages.\")\n   ```\n4. Include Notion page URLs from agent results in the finalization summary\n\n## Error Handling\n\n- If an agent fails, report the error and ask the user whether to retry or skip that step\n- If the user interrupts mid-flow, save current state to the progress file so it can be resumed\n- If the feature directory already exists, ask the user whether to resume or start fresh\n","# Functional Specification Generator\n\nGenerate a comprehensive functional specification for: **$ARGUMENTS**\n\n## Instructions\n\nFollow these steps in order. After each major step, update the progress file.\n\n### Step 0: Read Configuration\n\n1. Read `.claude\u002Fplanning-plugin.json` from the current project directory\n2. If the file does not exist, stop with a guidance message:\n   > \"Planning Plugin is not configured for this project. Run `\u002Fplanning-plugin:pp-init` to set up.\"\n3. Extract `workingLanguage` (default: `\"en\"` if field is absent)\n4. Extract `supportedLanguages` (default: `[\"en\", \"ko\", \"vi\"]`)\n5. Determine target languages: `supportedLanguages` minus `workingLanguage`\n6. Language name mapping: `en` = English, `ko` = Korean, `vi` = Vietnamese\n\n**Communication language**: All user-facing output in this skill (summaries, questions, feedback presentations, next-step guidance) must be in {workingLanguage_name}.\n\n### Step 1: Initialize\n\n1. Derive a kebab-case feature name from the user's description (e.g., \"social login\" → `social-login`)\n2. **If the feature directory already exists**, read the progress file and use its `workingLanguage` value (ignore `planning-plugin.json` for existing specs). Ask the user whether to resume or start fresh.\n3. Create the output directory structure:\n   ```\n   docs\u002Fspecs\u002F{feature}\u002F{workingLanguage}\u002F\n   docs\u002Fspecs\u002F{feature}\u002F.progress\u002F\n   ```\n   Also create directories for each target language:\n   ```\n   docs\u002Fspecs\u002F{feature}\u002F{target_lang}\u002F\n   ```\n4. Create the initial progress file at `docs\u002Fspecs\u002F{feature}\u002F.progress\u002F{feature}.json`:\n   ```json\n   {\n     \"feature\": \"{feature}\",\n     \"status\": \"analyzing\",\n     \"workingLanguage\": \"{workingLanguage}\",\n     \"currentRound\": 0,\n     \"rounds\": [],\n     \"translations\": {\n       \"{target_lang_1}\": { \"synced\": false, \"lastSyncedAt\": null },\n       \"{target_lang_2}\": { \"synced\": false, \"lastSyncedAt\": null }\n     }\n   }\n   ```\n\n### Step 2: Context Analysis & Requirements Gathering\n\nLaunch the **analyst** agent using the Agent tool:\n\n```\nAgent(subagent_type: \"planning-plugin:analyst\", prompt: \"Analyze the project at {cwd} and gather requirements for the feature: {feature description}. Follow your two-phase process: first analyze the project context, then ask structured questions across all 8 categories. Communicate with the user in {workingLanguage_name}.\")\n```\n\n**Important interaction pattern:**\n- The analyst will first present context analysis results and initial questions\n- Present the analyst's questions to the user and collect answers\n- Feed answers back to the analyst for completeness scoring\n- Repeat until overall score >= 7 or the user explicitly says to proceed\n- If the user wants to skip questions, mark them as TBD\n\nUpdate progress status to `\"drafting\"` when requirements gathering is complete.\n\n### Step 3: Generate Draft\n\nUsing the analyst's collected requirements and the 3 templates in `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002F`:\n\n1. Read all 3 templates: `spec-overview.md`, `screens.md`, `test-scenarios.md`\n2. Fill in all sections with the gathered requirements\n3. For each screen definition in `screens.md`, generate an **ASCII layout diagram** in the Layout section using the format shown in the template: named regions in `[ brackets ]` inside box-drawn containers, with components listed as `- ComponentName`. The diagram must be consistent with the Components table — every component in the table should appear in the diagram, and vice versa.\n4. Write all spec content in {workingLanguage_name}. Keep section heading labels in English (## 1. Overview etc.) as structural markers.\n5. For sections with insufficient information, add TBD markers with context\n6. Write 3 files to `docs\u002Fspecs\u002F{feature}\u002F{workingLanguage}\u002F`:\n   - `{feature}-spec.md` — from `spec-overview.md` template (overview, user stories, functional requirements, spec file index, open questions, review history)\n   - `screens.md` — from `screens.md` template (screen definitions, error handling)\n   - `test-scenarios.md` — from `test-scenarios.md` template (NFR + test scenarios)\n7. Set the document status to `DRAFT` in `{feature}-spec.md`\n\n### Step 3.5: Shared Layout Detection & Creation\n\nAfter generating the 3 draft files, detect whether the feature uses a shared layout shell and optionally create `docs\u002Fspecs\u002F_shared\u002Fen\u002Fscreens.md`.\n\n**3.5a. Detect shared layout pattern** — Analyze the analyst's `user_flow` category answers for:\n- A persistent shell (sidebar\u002Fnavigation + header) that spans multiple screens\n- A content area where different screens render inside the shell\n- **Skip this step entirely** if the feature has only a single screen, consists of standalone screens (login, landing, error pages), or each screen has its own independent full layout\n\n**3.5b. No pattern detected** — Do nothing. Leave the `\u003C!-- @layout: ... -->` comment block in `screens.md` as-is from the template. Proceed to Step 4.\n\n**3.5c. Pattern detected — `docs\u002Fspecs\u002F_shared\u002Fen\u002Fscreens.md` already exists**:\n1. Inform the user: \"A shared layout already exists. Referencing it via `@layout:` directive.\"\n2. Extract layout-id(s) from the existing file by parsing `### Screen:` headings → convert to kebab-case\n3. In the feature's `screens.md`, activate the `@layout:` directive (uncomment and set the correct `_shared\u002F{layout-id}`)\n4. Remove shell components (sidebar, header, navigation) from the feature screens' ASCII diagrams and Components tables — only for screens that render inside the shell. Standalone screens (login, 404, etc.) retain their own layout.\n\n**3.5d. Pattern detected — `docs\u002Fspecs\u002F_shared\u002Fen\u002Fscreens.md` does NOT exist**:\n1. Ask the user for confirmation: \"The screens share a sidebar + header shell. Would you like to create a shared layout that other features can also reuse? (y\u002Fn)\"\n2. **If declined**: Leave `@layout:` directive commented out. The feature will use local layout detection during DSL generation (existing behavior). Proceed to Step 4.\n3. **If approved**:\n   a. Create `docs\u002Fspecs\u002F_shared\u002Fen\u002F` directory\n   b. Generate `docs\u002Fspecs\u002F_shared\u002Fen\u002Fscreens.md` using the analyst's layout data. Generation rules:\n      - Follow the same format as `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fscreens.md`\n      - Define **exactly one layout screen**\n      - **Must include a `Slot` type component** (required by dsl-generator's layout-only mode)\n      - ASCII diagram must show the content insertion point (e.g., `(Each screen renders here)`)\n      - Component names and navigation items must be derived from the analyst's actual layout description (not hardcoded)\n      - No Error Handling section needed (layout screens have no business logic errors)\n      - **Always create under `en\u002F` directory** regardless of `workingLanguage` (UI DSL always reads from English)\n   c. In the feature's `screens.md`, activate the `@layout:` directive with the generated layout-id\n   d. Remove shell components from the feature screens that render inside the shell\n   e. Inform the user: \"After finalizing the spec, run `\u002Fplanning-plugin:pp-design _shared` first, then `\u002Fplanning-plugin:pp-design {feature}`.\"\n\n### Step 4: Sequential Review Cycle\n\nUpdate progress status to `\"reviewing\"` and increment `currentRound`.\n\nUpdate the metadata blockquote at the top of `{feature}-spec.md` in the {workingLanguage} directory:\n- Change `Status` to `REVIEWING`\n- Change `Last Updated` to the current timestamp (ISO 8601 format, e.g. 2026-03-04T09:00:00Z)\n\n**4a. Planner Review:**\n\nLaunch the **planner** agent:\n```\nAgent(subagent_type: \"planning-plugin:planner\", prompt: \"Review the functional specification at docs\u002Fspecs\u002F{feature}\u002F{workingLanguage}\u002F. The spec is split into multiple files — read all of them: {feature}-spec.md (overview, user stories, functional requirements, open questions), screens.md (screen definitions, error handling), test-scenarios.md. The specification is written in {workingLanguage_name}. Provide your review in {workingLanguage_name}. Evaluate user journey completeness, business logic clarity, error UX, integration consistency, and scope feasibility. Return your review as structured JSON.\")\n```\n\n**4b. Tester Review:**\n\nLaunch the **tester** agent, including the planner's feedback:\n```\nAgent(subagent_type: \"planning-plugin:tester\", prompt: \"Review the functional specification at docs\u002Fspecs\u002F{feature}\u002F{workingLanguage}\u002F. The spec is split into multiple files — read all of them: {feature}-spec.md (overview, user stories, functional requirements, open questions), screens.md (screen definitions, error handling), test-scenarios.md. The specification is written in {workingLanguage_name}. Provide your review in {workingLanguage_name}. The planner agent already reviewed it and found: {planner_feedback_summary}. Focus on testability, edge cases, and areas the planner may have missed. Return your review as structured JSON.\")\n```\n\n**4c. Present Combined Feedback:**\n\nRead `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Freview-reception-rules.md` and apply the review reception discipline.\n\nShow the user a summary of both reviews:\n- Overall scores (planner: X\u002F10, tester: Y\u002F10)\n- Each issue presented with a technical assessment (per review-reception-rules.md):\n  - Flag issues that conflict with previous round decisions (check progress file's `rounds` array)\n  - Flag issues where the reviewer may have misread the spec section\n  - Classify each suggestion's impact (improves spec \u002F neutral \u002F scope creep risk)\n  - Flag redundant issues (overlaps within same round or already addressed in prior rounds)\n- Proposed test cases from the tester\n- Approved sections\n\nResponse discipline: No performative agreement (\"Great point!\", \"Excellent observation!\"). Present technical assessments directly.\n\n**4d. Convergence Check:**\n\nFirst, compute `roundsInCycle`: read `reviewCycleStart` from the progress file (if absent or null, treat as 0), then `roundsInCycle = currentRound - reviewCycleStart`.\n\nApply these rules **in strict priority order** (first matching rule wins):\n1. **Both planner AND tester scores >= 8**: Suggest finalization — \"Both reviewers are satisfied (planner: X\u002F10, tester: Y\u002F10). Ready to finalize?\"\n2. **Either score \u003C 8 AND roundsInCycle \u003C 3**: Do NOT suggest finalization. Suggest another review round — \"Tester score is below 8 (planner: X\u002F10, tester: Y\u002F10, cycle round N\u002F3). Another review round is recommended.\"\n3. **roundsInCycle >= 3 with either score still \u003C 8**: Suggest finalization with caveats — \"After 3 rounds in this review cycle, scores are (planner: X\u002F10, tester: Y\u002F10). Here are the remaining open questions. Ready to finalize as-is?\"\n\n**Hard rule**: Never suggest or offer finalization if any score is below 8 AND fewer than 3 rounds have been completed in the current review cycle. This rule cannot be overridden by score trends or other factors.\n\n**4e. User Decision:**\n\nAsk the user what to do with each issue:\n- **Accept**: Apply the suggestion to the spec\n- **Reject**: Dismiss the issue with a note\n- **Modify**: Apply a modified version of the suggestion\n- **Defer**: Move to Open Questions section\n\nApply accepted changes to the appropriate file in the {workingLanguage} spec directory based on which section the issue targets (e.g., FR issues → `{feature}-spec.md`, screen\u002Ferror handling issues → `screens.md`).\n\nWhen applying changes, follow the review-reception-rules.md application discipline:\n- Re-read the target section before applying\n- If the suggestion would create inconsistency with other sections, note this to the user before applying\n- If multiple accepted suggestions target the same section, apply them as a coherent edit rather than sequential independent patches\n\nUpdate progress file with round results. Append an entry to the `rounds` array:\n```json\n{\n  \"round\": 1,\n  \"plannerScore\": 7,\n  \"testerScore\": 6,\n  \"issues\": [\n    {\n      \"id\": \"PL-001\",\n      \"section\": \"{feature}-spec.md > FR-001\",\n      \"decision\": \"Accept\",\n      \"suggestion\": \"Add password reset flow with email verification.\"\n    }\n  ]\n}\n```\nEach issue must include `id`, `section`, `decision` (Accept\u002FReject\u002FModify\u002FDefer), and `suggestion` (original text, or user's modified version for Modify decisions) for verification gate traceability.\n\n**4f. Repeat or Finalize:**\n\nBased on convergence check and user decision, either:\n- Go back to Step 4a for another round\n- Proceed to Step 5\n\n### Step 5: Generate Translations\n\nBefore launching translators, ask the user:\n> \"Translation will sync the spec to all target languages. This launches parallel translator agents and may take several minutes. How would you like to proceed?\"\n> 1. **Translate and finalize** — run translation now, then verify and finalize\n> 2. **Skip translation and finalize** — proceed directly to verification and finalization (run `\u002Fplanning-plugin:pp-translate {feature}` later to sync translations)\n\nIf the user selects option 2 (skip), jump directly to Step 5.5 (Pre-Finalization Verification).\n\nIf the user selects option 1 (translate and finalize):\n\nFor each target language, launch a **translator** agent in parallel using the Agent tool:\n\n```\nAgent(subagent_type: \"planning-plugin:translator\", prompt: \"Translate the spec directory at docs\u002Fspecs\u002F{feature}\u002F{workingLanguage}\u002F to {target_language_name}. Read each markdown file ({feature}-spec.md, screens.md, test-scenarios.md) and write translated versions to docs\u002Fspecs\u002F{feature}\u002F{target_lang}\u002F. Source language: {workingLanguage}. Full translation.\")\n```\n\nAfter all complete, update the progress file's translation status with `synced: true` and timestamps.\n\n### Step 5.5: Pre-Finalization Verification\n\nRead `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fverification-rules.md` and execute the verification gate.\n\n1. Read the progress file and collect all issues with \"Accept\" or \"Modify\" decisions from ALL rounds\n2. For each collected issue, read the relevant spec file section and verify the change is present in the text\n3. Present the verification summary showing verified\u002Funverified counts with evidence (e.g., `✓ PL-001: Found in {feature}-spec.md > FR-005`)\n4. If unverified items exist:\n   - Present each with its original suggestion\n   - Ask the user to: **resolve now** (apply the missing change) \u002F **defer** (move to Open Questions) \u002F **dismiss** (user explains how it was addressed differently)\n   - Record the resolution in the progress file\n5. Only proceed to Step 6 after all items are verified, deferred, or dismissed\n\nThis gate supplements the convergence check — both must pass before finalization.\n\n### Step 6: Finalize\n\n1. Update the metadata blockquote in `{feature}-spec.md` across all language versions that have spec files ({workingLanguage} directory always exists; only include target language directories where `{feature}-spec.md` actually exists — skip directories that are empty because translation was skipped):\n   - Change `Status` to `FINALIZED`\n   - Change `Last Updated` to the current timestamp (ISO 8601 format, e.g. 2026-03-04T09:00:00Z)\n2. Update the progress file:\n   ```json\n   { \"status\": \"finalized\" }\n   ```\n3. Present a summary:\n   - Total review rounds completed\n   - Final scores\n   - Key decisions made\n   - Any remaining open questions\n4. Suggest next steps:\n   - If `docs\u002Fspecs\u002F_shared\u002Fen\u002Fscreens.md` was created during this spec run (Step 3.5d):\n     > \"Run `\u002Fplanning-plugin:pp-design _shared` first to generate the shared layout DSL, then `\u002Fplanning-plugin:pp-design {feature}` to generate the feature DSL.\"\n   - Otherwise:\n     > \"Run `\u002Fplanning-plugin:pp-design {feature}` to generate UI DSL and Stitch wireframes, then `\u002Fplanning-plugin:pp-prototype {feature}` to generate the React prototype\"\n   - \"Run `\u002Fplanning-plugin:pp-review {feature}` anytime to re-review\"\n   - \"Edit the {workingLanguage} spec directly and run `\u002Fplanning-plugin:pp-translate {feature}` to sync translations\"\n   - \"Run `\u002Fplanning-plugin:pp-sync-notion {feature}` to manually re-sync Notion pages\"\n\n### Step 7: Sync to Notion (if configured)\n\n1. Read `.claude\u002Fplanning-plugin.json` and check `notionParentPageUrl` — if empty or missing, skip this step silently\n2. Read progress file for existing Notion page data (`notion` field)\n3. For each language (working language + all target languages where `{feature}-spec.md` actually exists inside the language directory — skip languages whose directories are empty because translation was skipped), sequentially launch the **sync-notion** agent:\n   ```\n   Agent(subagent_type: \"planning-plugin:sync-notion\", prompt: \"Sync the {langName} specification for feature '{feature}' to Notion.\n     feature: {feature}. lang: {lang}. langName: {langName}.\n     specDir: docs\u002Fspecs\u002F{feature}\u002F{lang}\u002F.\n     progressFile: docs\u002Fspecs\u002F{feature}\u002F.progress\u002F{feature}.json.\n     notionParentPageUrl: {notionParentPageUrl}.\n     existingPages: {JSON of notion.{lang} from progress or null}.\n     Read the 3 spec files, prepare content, and create\u002Fupdate Notion pages.\")\n   ```\n4. Include Notion page URLs from agent results in the finalization summary\n\n## Error Handling\n\n- If an agent fails, report the error and ask the user whether to retry or skip that step\n- If the user interrupts mid-flow, save current state to the progress file so it can be resumed\n- If the feature directory already exists, ask the user whether to resume or start fresh\n",{"name":5,"description":7,"allowed-tools":39,"argument-hint":40,"user-invocable":41},"Read, Write, Edit, Glob, Grep, Bash, Agent","[feature description]",true,"main","eaef2a5b6092b72972ff2f25ef79803753bc9bbf","planning-plugin\u002Fskills\u002Fpp-spec",0,"https:\u002F\u002Fgithub.com\u002Fohmyhotelco\u002Fhare-cc-plugins","https:\u002F\u002Fgithub.com\u002Fohmyhotelco","2026-11-11 08:26:27",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":41},[51,54,57],{"tool":52,"command":53},"npx","npx skills add ohmyhotelco\u002Fhare-cc-plugins --skill pp-spec",{"tool":55,"command":56},"bunx","bunx skills add ohmyhotelco\u002Fhare-cc-plugins --skill pp-spec",{"tool":58,"command":59},"pnpm","pnpm dlx skills add ohmyhotelco\u002Fhare-cc-plugins --skill pp-spec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fohmyhotelco\u002Fhare-cc-plugins\u002Fblob\u002Fmain\u002Fplanning-plugin\u002Fskills\u002Fpp-spec\u002FSKILL.md",[],[63,88,114,138,152,171],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":34},"01M6M5QVXQNQMJBP1JZP9T440T","hp-shared","Shared conventions for every homepage-plugin agent and skill — stack, code conventions, state-file writes, check commands and how to report them. Preloaded into agents through their `skills:` frontmatter; not meant to be invoked by hand.","https:\u002F\u002Fgithub.com\u002Fohmyhotelco\u002Fhare-cc-plugins\u002Fblob\u002Fmain\u002Fhomepage-plugin\u002Fskills\u002Fhp-shared\u002FSKILL.md",[],[70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87],"shared","hp shared","state","stack","plugin","how","for","report","code conventions","commands","how to","conventions","false","frontmatter","file","code","hand","check",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":102,"publishedAt":34},"01M6M5PZTN1M0G4AHJV08VF1HV","fe-shared","Shared conventions for every frontend-react-plugin agent and skill — code conventions, state files and locks, accepted deviations, design principles, build working directory, router-mode command matrix, TypeScript check. Preloaded into agents through their `skills:` frontmatter; not meant to be invoked by hand.","https:\u002F\u002Fgithub.com\u002Fohmyhotelco\u002Fhare-cc-plugins\u002Fblob\u002Fmain\u002Ffrontend-react-plugin\u002Fskills\u002Ffe-shared\u002FSKILL.md",[94,99],{"categoryNo":95,"categoryName":96,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":100,"categoryName":101,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000015","视觉设计",[70,103,76,104,78,105,106,107,108,82,85,86,109,87,110,72,74,111,112,113],"fe shared","mode","frontend","design","design principles","files","react","router","principles","command","build",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":126,"publishedAt":34},"01M6M5GAW7ZZ3580DVCMH51SFQ","be-spring-shared","Shared conventions for every backend-springboot-plugin agent and skill — tech stack, CQRS architecture, naming, coding standards, TDD, commit and build rules, state files. Preloaded into agents through their `skills:` frontmatter; not meant to be invoked by hand.","https:\u002F\u002Fgithub.com\u002Fohmyhotelco\u002Fhare-cc-plugins\u002Fblob\u002Fmain\u002Fbackend-springboot-plugin\u002Fskills\u002Fbe-spring-shared\u002FSKILL.md",[120,123],{"categoryNo":121,"categoryName":122,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":124,"categoryName":125,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000023","Skill与智能体开发",[70,127,128,108,82,129,130,86,73,131,83,132,133,134,76,135,136,72,74,137],"spring","be spring shared","commit","architecture","coding standards","coding","standards","tech","Rules","cqrs","naming",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":144,"publishedAt":34},"01M6FNV58QMW8K71SA9FGTXMF4","pp-translate","Use after directly editing the working language spec to sync changes to other supported languages.","https:\u002F\u002Fgithub.com\u002Fohmyhotelco\u002Fhare-cc-plugins\u002Fblob\u002Fmain\u002Fplanning-plugin\u002Fskills\u002Fpp-translate\u002FSKILL.md",[],[18,145,146,21,147,148,28,19,29,30,149,23,84,150,33,151],"pp translate","translate","name","editing","sync","language","changes",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":159,"publishedAt":34},"01M6FNV0PGRKR2MW0AEPS6XP0Q","pp-sync-stitch","Use when wireframes were manually edited on the Stitch website and need to be re-fetched to the local project.","https:\u002F\u002Fgithub.com\u002Fohmyhotelco\u002Fhare-cc-plugins\u002Fblob\u002Fmain\u002Fplanning-plugin\u002Fskills\u002Fpp-sync-stitch\u002FSKILL.md",[158],{"categoryNo":124,"categoryName":125,"taxonomyType":97,"taxonomyTypeDesc":98},[160,18,161,149,162,163,21,22,164,165,166,23,24,167,168,169,170,147,28,33],"pp sync stitch","stitch","projects","get","re","local","MCP","id","wireframes","website","screen",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":178,"publishedAt":34},"01M6FNTWW2KHS9XRAR72X33G0B","pp-sync-notion","Use when a specification needs to be published or re-synced to Notion after finalization or manual edits.","https:\u002F\u002Fgithub.com\u002Fohmyhotelco\u002Fhare-cc-plugins\u002Fblob\u002Fmain\u002Fplanning-plugin\u002Fskills\u002Fpp-sync-notion\u002FSKILL.md",[177],{"categoryNo":124,"categoryName":125,"taxonomyType":97,"taxonomyTypeDesc":98},[18,179,149,180,21,164,181,182,166,23,25,147,28,29,30,31,33],"notion","pp sync notion","search","manual"]