[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CR66E8EVCWNMJQVC0K39VD":3,"skill-same:01M6CR66E8EVCWNMJQVC0K39VD":81},{"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":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":70},"01M6CR66E8EVCWNMJQVC0K39VD","be-code",null,"TDD-implement a CQRS\u002FWebFlux feature: RED-GREEN cycle through command executors, query processors, and router\u002Fhandler code. Consumes a be-crud scaffold, plan.json, or an existing work document with test scenarios; drafts scenarios manually if none exist. Use be-crud first when no scaffold exists yet.","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\u002Fbackend-webflux-plugin\u002Fskills\u002Fbe-code\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"be code","code","feature","path","test scenarios","handler","doc","edit","drafts","write","read","command","plan","work","router","crud","Bash","query","cycle","green","2026-11-10 10:12:30",false,"---\nname: be-code\ndescription: \"TDD-implement a CQRS\u002FWebFlux feature: RED-GREEN cycle through command executors, query processors, and router\u002Fhandler code. Consumes a be-crud scaffold, plan.json, or an existing work document with test scenarios; drafts scenarios manually if none exist. Use be-crud first when no scaffold exists yet.\"\nargument-hint: \"\u003Cfeature-name or work-doc-path> [--yes]\"\nuser-invocable: true\nallowed-tools: Read, Write, Edit, Glob, Grep, Bash, Agent\n---\n\n# Implement Feature with TDD\n\nImplement a feature using strict Test-Driven Development. This skill orchestrates the full TDD workflow: context gathering, scenario writing, and RED-GREEN cycle execution.\n\nThis skill holds an exclusive cross-skill lock (`{workDocDir}\u002F.progress\u002F.lock`) for the duration of the run and can demote a feature's pipeline status, discarding verification\u002Freview progress (see Step 3.5). Ground every claim in the Step 6 report in evidence — build output, `git status`\u002F`git diff` — never narrate completion from memory, and never leave the lock file behind on failure or cancellation (see Error Handling) — and whenever the lock is released, on any path, remove the directory its `snapshotDir` names if the implement agent recorded one (its revert snapshot, outside the repository).\n\nFiles under `references\u002F` write the plugin root as `{pluginRoot}`, which is `${CLAUDE_PLUGIN_ROOT}`.\n\n## Instructions\n\n### Step 0: Validate Configuration\n\n1. Read `.claude\u002Fbackend-webflux-plugin.json`\n2. If missing, tell the user to run `\u002Fbackend-webflux-plugin:be-init` first and stop\n\n### Step 1: Parse Argument\n\nStrip a trailing `--yes` flag first (it is not part of the path or feature name). The argument can be:\n\n- **File path**: If argument looks like a path (contains `\u002F` or `.md`), treat it as a work document path. Extract `feature-name` from the filename by removing the `.md` extension and directory prefix (e.g., `work\u002Ffeatures\u002Femployee.md` → `employee`). This `feature-name` is used for lock files and progress file lookups.\n- **Feature name**: Otherwise, treat it as a feature description\n\nValidate `feature-name` (however derived above): reject and stop with an error if it contains `\u002F`, `\\`, `..`, or any character outside `[a-z0-9-]`. It is used directly to build progress-file and lock-file paths under `{workDocDir}\u002F.progress\u002F` in later steps — an unvalidated value could escape that directory.\n\n### Step 1.5: Check Plan\n\nIf the argument is a feature name (not a file path):\n\n1. Check if `docs\u002Fspecs\u002F{feature}\u002F.implementation\u002Fbackend\u002Fplan.json` exists\n   - If exists: `planAvailable = true`, read plan.json\n   - If not exists: `planAvailable = false`\n2. If `planAvailable`:\n   - List all entities from `plan.json.entities[]`\n   - Validate each entity's `name`: reject and skip that entity if it contains `\u002F`, `\\`, `..`, or any character outside `[A-Za-z0-9]`. `plan.json` comes from another agent reading a spec file this skill does not control the provenance of, so it gets no more trust than direct user input — and the derived kebab-case form is used to build work-document and progress-file paths below.\n   - For each remaining entity, check if `{workDocDir}\u002F{kebab-case-entity}.md` exists\n   - Build two lists: `entitiesWithWorkDoc` and `entitiesWithoutWorkDoc`\n3. If `planAvailable` and multiple entities exist:\n   > \"Plan contains {count} entities: {entity names}\"\n   > \"Options:\"\n   > \"1. Process all entities sequentially (dependency order)\"\n   > \"2. Select a specific entity to implement\"\n   - If user chooses 2: ask which entity, set `targetEntity = {chosen entity}`\n   - If user chooses 1: `targetEntity = null` (process all in `entityDependencyOrder`)\n\n### Step 2: Gather Context\n\n1. Read `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fcore-conventions.md` for architecture and conventions (a trimmed,\n   execution-facing subset of ${CLAUDE_PLUGIN_ROOT}\u002FCLAUDE.md — see that file's own header for\n   what it omits)\n2. If the argument is a work document path:\n   - Read the document\n   - Extract `- [ ]` scenarios\n   - Skip to Step 3.5 (single work document mode)\n3. If the argument is a feature name and `planAvailable`:\n   - Determine entity list to process:\n     - If `targetEntity` is set: process only that entity\n     - If `targetEntity` is null: process all entities in `plan.json.entityDependencyOrder`\n   - For each entity to process:\n     - Check if `{workDocDir}\u002F{kebab-case-entity}.md` exists\n     - If exists: extract `- [ ]` scenarios\n     - If not exists: mark for auto-generation in Step 3\n   - **Multi-entity iteration**: Steps 3 through 3.7 execute once (scenarios, lock, the per-entity demotion check in Step 3.6a, pipeline init for the confirmed entities). Steps 4 through 6 (the TDD cycle, build, and report) then execute once for the whole batch, not per entity — see Step 4's \"Multi-entity batching\" note. Step 7 (pipeline-state bookkeeping) still executes per entity in dependency order.\n4. If the argument is a feature name and not `planAvailable`:\n   - First, check if `{workDocDir}\u002F{feature-name}.md` exists\n     - If found: treat it as the work document — read it, extract `- [ ]` scenarios, and skip to Step 3.5 (same as file path mode)\n   - If no matching work document:\n     - Explore existing code: scan `{sourceDir}\u002F{basePackage}\u002F` for related entities, controllers, commands, queries\n     - Read existing work documents in `{workDocDir}\u002F` for patterns\n     - Check for any related PRD\u002FTSD documents\n\n### Step 3: Write Test Scenarios\n\n#### When `planAvailable` and work document does not exist\n\nAuto-generate an enriched work document from plan.json for each entity that lacks one:\n\n1. Read `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fwork-document-template.md` for the document format — including the `Data profile:` line at the top: resolve it as `be-crud` Step 1 does (`config.dataProfile`, or `r2dbc` when that is `both` and nothing says otherwise) and record it; the implement agent reads it to choose the entity-conventions file\n2. For each entity in plan.json that has no existing work document, generate `{workDocDir}\u002F{kebab-case-entity}.md` with:\n   - **Entity section**: fields table from `plan.json.entities[].fields[]` with types, constraints, and source references\n   - **Commands section**: from `plan.json.commands[]` for this entity, including validation steps from BR-nnn\n   - **Queries section**: from `plan.json.queries[]` with filter\u002Fsort\u002Fpagination details\n   - **API Endpoints section**: from `plan.json.endpoints[]` with HTTP methods, paths, status codes\n   - **Validation Rules section**: from `plan.json.validationRules[]` with regex patterns and source references\n   - **Exceptions section**: from `plan.json.exceptions[]` with E-nnn codes, HTTP status, and conditions\n   - **Test Scenarios section**: from `plan.json.testScenarios[]` as `- [ ]` items with source references in comments\n     ```\n     ### POST \u002F{domain}\u002F{entities}\n\n     - [ ] valid request returns 201 Created  \u003C!-- TS-001, AC-001 -->\n     - [ ] invalid email format returns 400 Bad Request  \u003C!-- TS-002, BR-001 -->\n     - [ ] duplicate email returns 409 Conflict  \u003C!-- TS-003, BR-002 -->\n     ```\n   - **Test Data section**: auto-generate generator class stubs based on entity fields\n3. Present the generated work document to the user for confirmation:\n   > \"Work document generated from plan.json for {EntityName}:\"\n   > \"{scenario count} test scenarios from spec (TS-nnn references preserved)\"\n   > \"Review and confirm to proceed with TDD implementation.\"\n4. Wait for user approval before proceeding\n5. If user requests changes, apply them to the work document\n\n#### When not `planAvailable` and no work document\n\nFollow the original manual flow:\n\n1. Read `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Ftest-scenario-template.md` for the scenario format\n2. Draft test scenarios following ${CLAUDE_PLUGIN_ROOT}\u002FCLAUDE.md scenario writing rules:\n   - Single sentence, English, present tense\n   - Start with lowercase (usable as snake_case method name)\n   - Use `- [ ]` checkbox format\n   - Most important scenario first\n3. Mark uncertain scenarios with `?`:\n   ```\n   - [ ] valid request returns 201 Created\n   - [ ] duplicate email returns 409 Conflict\n   - [ ] ? empty display name returns 400 Bad Request\n   ```\n4. Present the scenario list to the user for approval:\n   > \"Here are the test scenarios for {feature}:\"\n   > {scenario list}\n   > \"Please review. I'll remove scenarios marked with `?` unless you confirm them.\"\n5. Wait for user approval before proceeding\n6. Save approved scenarios to `{workDocDir}\u002F{feature-name}.md`, with the template's `Data profile:` line resolved exactly as the plan path above does — the implement agent reads it to choose the entity-conventions file, and a document without it leaves the profile to a guess\n\n### Step 3.5: Demotion Check\n\n`--yes` answers this step's and Step 3.6a's confirmation with yes — for an unattended caller (`be-jira-auto`) that has already decided the re-entry; without it the prompts below are asked.\n\n**Work-document mode** (file path, or a feature name with a work document and no plan): If `{workDocDir}\u002F.progress\u002F{feature-name}.json` exists:\n\n1. Read `pipeline.status`\n2. If status is anything past `\"implementing\"` — `\"implemented\"`, `\"verified\"`, `\"verify-failed\"`, `\"reviewed\"`, `\"review-failed\"`, `\"fixing\"`, `\"resolved\"`, `\"escalated\"`, `\"done\"` — (${CLAUDE_PLUGIN_ROOT}\u002FCLAUDE.md § Demotion Warning: any earlier-stage skill resetting a later status asks first):\n   > \"This feature is currently '{status}'. Re-running TDD implementation will reset the pipeline status to 'implementing', discarding verification\u002Freview progress.\"\n   > \"Continue?\"\n   If the user declines, stop here.\n3. `fixing` and `escalated` are covered by item 2 — one confirmation, not two. `resolved` counts only when the `previousStatus` recorded beside it (`pipeline.debug` or `pipeline.build` — whichever has the newer `timestamp`, the one that produced this `resolved`) is itself past `implementing` — be-debug resolving a mid-implementation failure leaves nothing to discard, and the prompt would be false.\n\n**Plan-driven mode** (one entity or many): Skip this step here. Step 3.7 writes `{kebab-case-entity}.json`, not `{feature-name}.json`, so a check on the feature name would never see the entity's status — the demotion check is performed per entity in Step 3.6a, after the lock and before Step 3.7 writes any progress file.\n\n### Step 3.6: Acquire Lock\n\n0. `mkdir -p {workDocDir}\u002F.progress` — on the \"start TDD without `be-crud`\" path nothing has created it yet, and a lock cannot be written into a directory that does not exist\n1. Check if `{workDocDir}\u002F.progress\u002F.lock` exists\n2. If it exists and `lockedAt` is less than 30 minutes ago: warn the user that another operation (`{operation}`) is in progress and stop\n3. If it exists and `lockedAt` is older than 30 minutes: remove the stale lock (first the directory its `snapshotDir` names, if any)\n4. Write lock file: `{ \"lockedAt\": \"{ISO 8601}\", \"operation\": \"be-code\", \"feature\": \"{feature-name}\", \"runId\": \"{a fresh random id, kept in memory for the release}\" }`\n\n**Multi-entity mode**: The lock is acquired once here and held for the entire multi-entity operation. It is released once in Step 7 after all entities are processed.\n\n### Step 3.6a: Per-entity Demotion Check\n\nPlan-driven mode only (work-document runs did this in Step 3.5). Before Step 3.7 writes any\nprogress file, loop over every entity being processed (`targetEntity` alone, or all of\n`entityDependencyOrder`) and check `{workDocDir}\u002F.progress\u002F{kebab-case-entity}.json`:\n1. If it exists, read `pipeline.status`\n2. If status is anything past `\"implementing\"` (the Step 3.5 list): warn the user (same messages as Step 3.5) and ask for confirmation for this entity\n3. If the user declines for a specific entity: leave it out of the batch and proceed to the next entity's check\n\nBuild `confirmedEntities` from every entity that was not declined, in dependency\norder. If `confirmedEntities` ends up empty, do not launch the implement agent and\ndo not run Step 5's build (there is nothing new to build) — go directly to Step 6\nand produce its combined report with an empty \"Entities implemented\" list and the\nfull \"Entities skipped\" list (Step 6's own format already covers this; do not skip\nStep 6 itself, since it is the only step that renders that report). Step 7 then\nruns with an empty `confirmedEntities` loop — it has nothing to update, so it just\nreleases the lock.\n\n### Step 3.7: Initialize Pipeline State\n\nFor each entity in `confirmedEntities` (plan-driven mode — a declined entity is not touched) or the one work-document feature, create or update `{workDocDir}\u002F.progress\u002F{kebab-case-entity}.json` (`{feature-name}.json` in work-document mode — the name Step 3.5 checked):\n\n1. Create `{workDocDir}\u002F.progress\u002F` directory if it does not exist\n2. If progress file does not exist, create it:\n   ```json\n   {\n     \"feature\": \"{kebab-case-entity}\",\n     \"workDocument\": \"{workDocDir}\u002F{kebab-case-entity}.md\",\n     \"createdAt\": \"{ISO 8601}\",\n     \"updatedAt\": \"{ISO 8601}\",\n     \"pipeline\": {\n       \"status\": \"implementing\",\n       \"scenarios\": { \"total\": {count}, \"completed\": 0 }\n     }\n   }\n   ```\n3. If progress file exists: **read-modify-write** — update only `pipeline.status` to `\"implementing\"` and refresh scenario counts. **Preserve all existing fields** including `specSource`, `pipeline.verification`, `pipeline.review`, etc.\n\n**Multi-entity mode: initialize only the entities Step 3.6a confirmed.** This step writes\n`\"implementing\"`; a check that ran after it would read the status it just wrote, never warn, and\ndemote a `done`\u002F`verified` entity without the consent ${CLAUDE_PLUGIN_ROOT}\u002FCLAUDE.md § Demotion Warning requires. An\nentity the user declined keeps its progress file untouched.\n\n### Step 4: TDD Cycle\n\n**Multi-entity batching**: When processing multiple entities (plan-driven mode),\nSteps 4-6 run **once for the whole batch**, not once per entity — launching a\nseparate `implement` agent per entity repeats that agent's own Phase 0 context load\n(conventions, templates) for no benefit, since it never changes across entities in\nthe same run. Step 7 (pipeline-state bookkeeping) still runs per entity, since each\nentity has its own progress file.\n\n**Subagent Isolation**: Pass only the specified parameters below. Do not include conversation history or user feedback from prior steps.\n\n**Baseline for evidence**: Before launching the agent, run `git status --porcelain`\nonce for the whole batch. Record this output as the baseline — Step 6 diffs against\nit to ground the Files created\u002Fmodified lists in evidence instead of memory.\n\nLaunch the `implement` agent (`subagent_type: \"backend-webflux-plugin:implement\"` — qualified: `backend-springboot-plugin` ships an agent of the same name, and a bare name may resolve to it when both are installed) **once** with:\n\n- **Single-entity mode** (file path argument, or plan-driven with exactly one\n  entity): `workDocument`: path to the work document.\n- **Multi-entity mode**: `workDocuments`: ordered array of work document paths, one\n  per entity in `confirmedEntities` (dependency order), e.g.\n  `[\"{workDocDir}\u002Fleave-type.md\", \"{workDocDir}\u002Fleave-request.md\"]`.\n- `config`: the parsed plugin config\n- `projectRoot`: current project root\n\nThe implement agent loads its Phase 0 context once, then processes each document's\nscenarios in order (all of document 1's scenarios, then document 2's, ...):\n1. Select the next `- [ ]` scenario in the current document\n2. Write test (RED)\n3. Implement minimum code (GREEN)\n4. Mark as `- [x]`\n5. Repeat until the current document is complete, then move to the next document\n\n### Step 5: Final Build\n\nSkip this step when `confirmedEntities` was empty (nothing was implemented — see\nStep 4) and report `Build: not run — no entities to build` in Step 6 instead.\n\nOtherwise, after the implement agent returns (single document, or the whole batch,\ncomplete — or stopped early per its own 3-consecutive-failure rule), run a full\nbuild:\n\n```bash\n{config.buildCommand}\n```\n\nSet Bash tool timeout to 600000ms.\n\n### Step 6: Report\n\nDerive the \"Files created\" and \"Files modified\" lists from `git status --porcelain` (compared against the Step 4 baseline) and `git diff --stat` — never from memory or the implement agent's self-report. A `??` entry is a created file; an `M` entry is a modified file. If `git` is unavailable or the working tree is outside version control, state \"not verified: file lists\" instead of guessing.\n\nDisplay implementation summary in the working language.\n\n**Single-entity mode:**\n\n```\nFeature Implementation Complete: {feature-name}\n=======================================\n\nScenarios: {completed}\u002F{total}\n  {list each scenario with status}\n\nFiles created:\n  {list of new files}\n\nFiles modified:\n  {list of modified files}\n\nBuild: {PASS \u002F FAIL}\n```\n\n**Multi-entity mode** — one combined report covering every entity in\n`confirmedEntities`, plus any skipped in the demotion check:\n\n```\nFeature Implementation Complete: {feature} ({entityCount} entities)\n=======================================\n\nEntities implemented (in dependency order):\n  1. {Entity1} — {completed}\u002F{total} scenarios\n  2. {Entity2} — {completed}\u002F{total} scenarios\n\nEntities skipped (demotion declined):\n  {Entity} — existing status was '{status}', or \"(none)\"\n\nFiles created:\n  {list of new files, across all entities}\n\nFiles modified:\n  {list of modified files, across all entities}\n\nBuild: {PASS \u002F FAIL}\n```\n\nIf the build failed, suggest running `\u002Fbackend-webflux-plugin:be-build` for auto-diagnosis.\n\n### Step 7: Update Pipeline State\n\nFor each entity in `confirmedEntities` (or the single entity in single-entity mode),\nupdate `{workDocDir}\u002F.progress\u002F{kebab-case-entity}.json`:\n\n1. Read progress file\n2. Update `pipeline.scenarios.completed` with final count of `- [x]` items in that entity's own work document\n3. Update `pipeline.status`:\n   - All scenarios complete + build passes → `\"implemented\"`\n   - All scenarios complete + build fails → `\"implementing\"` — code that does not build is not implemented, and `\"implemented\"` is the state `be-review` accepts; report the build failure and point at `be-build`\n   - Some scenarios remain → `\"implementing\"`\n4. Update `updatedAt` timestamp\n5. Write back (read-modify-write — preserve all existing fields including `specSource`)\n\nAfter every entity's (or the single entity's) progress file is updated, release the\nlock: delete `{workDocDir}\u002F.progress\u002F.lock` — release per ${CLAUDE_PLUGIN_ROOT}\u002FCLAUDE.md § State File Safety.\n\nSuggest next step:\n- **All entities implemented + build passes**: `\u002Fbackend-webflux-plugin:be-verify {entity}` for each entity\n- **all scenarios done but the build fails** (status stays `implementing`): `\u002Fbackend-webflux-plugin:be-build`\n- **implementing**: resume with `\u002Fbackend-webflux-plugin:be-code {workDoc}`\n\n### Error Handling\n\nWhen a step fails or the user cancels, read `${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Fbe-code\u002Freferences\u002Ferror-handling.md` and follow it.\n\n## Example: Single-Entity, Non-Plan-Driven Run\n\nA worked single-entity run: `${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Fbe-code\u002Freferences\u002Fexample.md`.\n\n","# Implement Feature with TDD\n\nImplement a feature using strict Test-Driven Development. This skill orchestrates the full TDD workflow: context gathering, scenario writing, and RED-GREEN cycle execution.\n\nThis skill holds an exclusive cross-skill lock (`{workDocDir}\u002F.progress\u002F.lock`) for the duration of the run and can demote a feature's pipeline status, discarding verification\u002Freview progress (see Step 3.5). Ground every claim in the Step 6 report in evidence — build output, `git status`\u002F`git diff` — never narrate completion from memory, and never leave the lock file behind on failure or cancellation (see Error Handling) — and whenever the lock is released, on any path, remove the directory its `snapshotDir` names if the implement agent recorded one (its revert snapshot, outside the repository).\n\nFiles under `references\u002F` write the plugin root as `{pluginRoot}`, which is `${CLAUDE_PLUGIN_ROOT}`.\n\n## Instructions\n\n### Step 0: Validate Configuration\n\n1. Read `.claude\u002Fbackend-webflux-plugin.json`\n2. If missing, tell the user to run `\u002Fbackend-webflux-plugin:be-init` first and stop\n\n### Step 1: Parse Argument\n\nStrip a trailing `--yes` flag first (it is not part of the path or feature name). The argument can be:\n\n- **File path**: If argument looks like a path (contains `\u002F` or `.md`), treat it as a work document path. Extract `feature-name` from the filename by removing the `.md` extension and directory prefix (e.g., `work\u002Ffeatures\u002Femployee.md` → `employee`). This `feature-name` is used for lock files and progress file lookups.\n- **Feature name**: Otherwise, treat it as a feature description\n\nValidate `feature-name` (however derived above): reject and stop with an error if it contains `\u002F`, `\\`, `..`, or any character outside `[a-z0-9-]`. It is used directly to build progress-file and lock-file paths under `{workDocDir}\u002F.progress\u002F` in later steps — an unvalidated value could escape that directory.\n\n### Step 1.5: Check Plan\n\nIf the argument is a feature name (not a file path):\n\n1. Check if `docs\u002Fspecs\u002F{feature}\u002F.implementation\u002Fbackend\u002Fplan.json` exists\n   - If exists: `planAvailable = true`, read plan.json\n   - If not exists: `planAvailable = false`\n2. If `planAvailable`:\n   - List all entities from `plan.json.entities[]`\n   - Validate each entity's `name`: reject and skip that entity if it contains `\u002F`, `\\`, `..`, or any character outside `[A-Za-z0-9]`. `plan.json` comes from another agent reading a spec file this skill does not control the provenance of, so it gets no more trust than direct user input — and the derived kebab-case form is used to build work-document and progress-file paths below.\n   - For each remaining entity, check if `{workDocDir}\u002F{kebab-case-entity}.md` exists\n   - Build two lists: `entitiesWithWorkDoc` and `entitiesWithoutWorkDoc`\n3. If `planAvailable` and multiple entities exist:\n   > \"Plan contains {count} entities: {entity names}\"\n   > \"Options:\"\n   > \"1. Process all entities sequentially (dependency order)\"\n   > \"2. Select a specific entity to implement\"\n   - If user chooses 2: ask which entity, set `targetEntity = {chosen entity}`\n   - If user chooses 1: `targetEntity = null` (process all in `entityDependencyOrder`)\n\n### Step 2: Gather Context\n\n1. Read `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fcore-conventions.md` for architecture and conventions (a trimmed,\n   execution-facing subset of ${CLAUDE_PLUGIN_ROOT}\u002FCLAUDE.md — see that file's own header for\n   what it omits)\n2. If the argument is a work document path:\n   - Read the document\n   - Extract `- [ ]` scenarios\n   - Skip to Step 3.5 (single work document mode)\n3. If the argument is a feature name and `planAvailable`:\n   - Determine entity list to process:\n     - If `targetEntity` is set: process only that entity\n     - If `targetEntity` is null: process all entities in `plan.json.entityDependencyOrder`\n   - For each entity to process:\n     - Check if `{workDocDir}\u002F{kebab-case-entity}.md` exists\n     - If exists: extract `- [ ]` scenarios\n     - If not exists: mark for auto-generation in Step 3\n   - **Multi-entity iteration**: Steps 3 through 3.7 execute once (scenarios, lock, the per-entity demotion check in Step 3.6a, pipeline init for the confirmed entities). Steps 4 through 6 (the TDD cycle, build, and report) then execute once for the whole batch, not per entity — see Step 4's \"Multi-entity batching\" note. Step 7 (pipeline-state bookkeeping) still executes per entity in dependency order.\n4. If the argument is a feature name and not `planAvailable`:\n   - First, check if `{workDocDir}\u002F{feature-name}.md` exists\n     - If found: treat it as the work document — read it, extract `- [ ]` scenarios, and skip to Step 3.5 (same as file path mode)\n   - If no matching work document:\n     - Explore existing code: scan `{sourceDir}\u002F{basePackage}\u002F` for related entities, controllers, commands, queries\n     - Read existing work documents in `{workDocDir}\u002F` for patterns\n     - Check for any related PRD\u002FTSD documents\n\n### Step 3: Write Test Scenarios\n\n#### When `planAvailable` and work document does not exist\n\nAuto-generate an enriched work document from plan.json for each entity that lacks one:\n\n1. Read `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fwork-document-template.md` for the document format — including the `Data profile:` line at the top: resolve it as `be-crud` Step 1 does (`config.dataProfile`, or `r2dbc` when that is `both` and nothing says otherwise) and record it; the implement agent reads it to choose the entity-conventions file\n2. For each entity in plan.json that has no existing work document, generate `{workDocDir}\u002F{kebab-case-entity}.md` with:\n   - **Entity section**: fields table from `plan.json.entities[].fields[]` with types, constraints, and source references\n   - **Commands section**: from `plan.json.commands[]` for this entity, including validation steps from BR-nnn\n   - **Queries section**: from `plan.json.queries[]` with filter\u002Fsort\u002Fpagination details\n   - **API Endpoints section**: from `plan.json.endpoints[]` with HTTP methods, paths, status codes\n   - **Validation Rules section**: from `plan.json.validationRules[]` with regex patterns and source references\n   - **Exceptions section**: from `plan.json.exceptions[]` with E-nnn codes, HTTP status, and conditions\n   - **Test Scenarios section**: from `plan.json.testScenarios[]` as `- [ ]` items with source references in comments\n     ```\n     ### POST \u002F{domain}\u002F{entities}\n\n     - [ ] valid request returns 201 Created  \u003C!-- TS-001, AC-001 -->\n     - [ ] invalid email format returns 400 Bad Request  \u003C!-- TS-002, BR-001 -->\n     - [ ] duplicate email returns 409 Conflict  \u003C!-- TS-003, BR-002 -->\n     ```\n   - **Test Data section**: auto-generate generator class stubs based on entity fields\n3. Present the generated work document to the user for confirmation:\n   > \"Work document generated from plan.json for {EntityName}:\"\n   > \"{scenario count} test scenarios from spec (TS-nnn references preserved)\"\n   > \"Review and confirm to proceed with TDD implementation.\"\n4. Wait for user approval before proceeding\n5. If user requests changes, apply them to the work document\n\n#### When not `planAvailable` and no work document\n\nFollow the original manual flow:\n\n1. Read `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Ftest-scenario-template.md` for the scenario format\n2. Draft test scenarios following ${CLAUDE_PLUGIN_ROOT}\u002FCLAUDE.md scenario writing rules:\n   - Single sentence, English, present tense\n   - Start with lowercase (usable as snake_case method name)\n   - Use `- [ ]` checkbox format\n   - Most important scenario first\n3. Mark uncertain scenarios with `?`:\n   ```\n   - [ ] valid request returns 201 Created\n   - [ ] duplicate email returns 409 Conflict\n   - [ ] ? empty display name returns 400 Bad Request\n   ```\n4. Present the scenario list to the user for approval:\n   > \"Here are the test scenarios for {feature}:\"\n   > {scenario list}\n   > \"Please review. I'll remove scenarios marked with `?` unless you confirm them.\"\n5. Wait for user approval before proceeding\n6. Save approved scenarios to `{workDocDir}\u002F{feature-name}.md`, with the template's `Data profile:` line resolved exactly as the plan path above does — the implement agent reads it to choose the entity-conventions file, and a document without it leaves the profile to a guess\n\n### Step 3.5: Demotion Check\n\n`--yes` answers this step's and Step 3.6a's confirmation with yes — for an unattended caller (`be-jira-auto`) that has already decided the re-entry; without it the prompts below are asked.\n\n**Work-document mode** (file path, or a feature name with a work document and no plan): If `{workDocDir}\u002F.progress\u002F{feature-name}.json` exists:\n\n1. Read `pipeline.status`\n2. If status is anything past `\"implementing\"` — `\"implemented\"`, `\"verified\"`, `\"verify-failed\"`, `\"reviewed\"`, `\"review-failed\"`, `\"fixing\"`, `\"resolved\"`, `\"escalated\"`, `\"done\"` — (${CLAUDE_PLUGIN_ROOT}\u002FCLAUDE.md § Demotion Warning: any earlier-stage skill resetting a later status asks first):\n   > \"This feature is currently '{status}'. Re-running TDD implementation will reset the pipeline status to 'implementing', discarding verification\u002Freview progress.\"\n   > \"Continue?\"\n   If the user declines, stop here.\n3. `fixing` and `escalated` are covered by item 2 — one confirmation, not two. `resolved` counts only when the `previousStatus` recorded beside it (`pipeline.debug` or `pipeline.build` — whichever has the newer `timestamp`, the one that produced this `resolved`) is itself past `implementing` — be-debug resolving a mid-implementation failure leaves nothing to discard, and the prompt would be false.\n\n**Plan-driven mode** (one entity or many): Skip this step here. Step 3.7 writes `{kebab-case-entity}.json`, not `{feature-name}.json`, so a check on the feature name would never see the entity's status — the demotion check is performed per entity in Step 3.6a, after the lock and before Step 3.7 writes any progress file.\n\n### Step 3.6: Acquire Lock\n\n0. `mkdir -p {workDocDir}\u002F.progress` — on the \"start TDD without `be-crud`\" path nothing has created it yet, and a lock cannot be written into a directory that does not exist\n1. Check if `{workDocDir}\u002F.progress\u002F.lock` exists\n2. If it exists and `lockedAt` is less than 30 minutes ago: warn the user that another operation (`{operation}`) is in progress and stop\n3. If it exists and `lockedAt` is older than 30 minutes: remove the stale lock (first the directory its `snapshotDir` names, if any)\n4. Write lock file: `{ \"lockedAt\": \"{ISO 8601}\", \"operation\": \"be-code\", \"feature\": \"{feature-name}\", \"runId\": \"{a fresh random id, kept in memory for the release}\" }`\n\n**Multi-entity mode**: The lock is acquired once here and held for the entire multi-entity operation. It is released once in Step 7 after all entities are processed.\n\n### Step 3.6a: Per-entity Demotion Check\n\nPlan-driven mode only (work-document runs did this in Step 3.5). Before Step 3.7 writes any\nprogress file, loop over every entity being processed (`targetEntity` alone, or all of\n`entityDependencyOrder`) and check `{workDocDir}\u002F.progress\u002F{kebab-case-entity}.json`:\n1. If it exists, read `pipeline.status`\n2. If status is anything past `\"implementing\"` (the Step 3.5 list): warn the user (same messages as Step 3.5) and ask for confirmation for this entity\n3. If the user declines for a specific entity: leave it out of the batch and proceed to the next entity's check\n\nBuild `confirmedEntities` from every entity that was not declined, in dependency\norder. If `confirmedEntities` ends up empty, do not launch the implement agent and\ndo not run Step 5's build (there is nothing new to build) — go directly to Step 6\nand produce its combined report with an empty \"Entities implemented\" list and the\nfull \"Entities skipped\" list (Step 6's own format already covers this; do not skip\nStep 6 itself, since it is the only step that renders that report). Step 7 then\nruns with an empty `confirmedEntities` loop — it has nothing to update, so it just\nreleases the lock.\n\n### Step 3.7: Initialize Pipeline State\n\nFor each entity in `confirmedEntities` (plan-driven mode — a declined entity is not touched) or the one work-document feature, create or update `{workDocDir}\u002F.progress\u002F{kebab-case-entity}.json` (`{feature-name}.json` in work-document mode — the name Step 3.5 checked):\n\n1. Create `{workDocDir}\u002F.progress\u002F` directory if it does not exist\n2. If progress file does not exist, create it:\n   ```json\n   {\n     \"feature\": \"{kebab-case-entity}\",\n     \"workDocument\": \"{workDocDir}\u002F{kebab-case-entity}.md\",\n     \"createdAt\": \"{ISO 8601}\",\n     \"updatedAt\": \"{ISO 8601}\",\n     \"pipeline\": {\n       \"status\": \"implementing\",\n       \"scenarios\": { \"total\": {count}, \"completed\": 0 }\n     }\n   }\n   ```\n3. If progress file exists: **read-modify-write** — update only `pipeline.status` to `\"implementing\"` and refresh scenario counts. **Preserve all existing fields** including `specSource`, `pipeline.verification`, `pipeline.review`, etc.\n\n**Multi-entity mode: initialize only the entities Step 3.6a confirmed.** This step writes\n`\"implementing\"`; a check that ran after it would read the status it just wrote, never warn, and\ndemote a `done`\u002F`verified` entity without the consent ${CLAUDE_PLUGIN_ROOT}\u002FCLAUDE.md § Demotion Warning requires. An\nentity the user declined keeps its progress file untouched.\n\n### Step 4: TDD Cycle\n\n**Multi-entity batching**: When processing multiple entities (plan-driven mode),\nSteps 4-6 run **once for the whole batch**, not once per entity — launching a\nseparate `implement` agent per entity repeats that agent's own Phase 0 context load\n(conventions, templates) for no benefit, since it never changes across entities in\nthe same run. Step 7 (pipeline-state bookkeeping) still runs per entity, since each\nentity has its own progress file.\n\n**Subagent Isolation**: Pass only the specified parameters below. Do not include conversation history or user feedback from prior steps.\n\n**Baseline for evidence**: Before launching the agent, run `git status --porcelain`\nonce for the whole batch. Record this output as the baseline — Step 6 diffs against\nit to ground the Files created\u002Fmodified lists in evidence instead of memory.\n\nLaunch the `implement` agent (`subagent_type: \"backend-webflux-plugin:implement\"` — qualified: `backend-springboot-plugin` ships an agent of the same name, and a bare name may resolve to it when both are installed) **once** with:\n\n- **Single-entity mode** (file path argument, or plan-driven with exactly one\n  entity): `workDocument`: path to the work document.\n- **Multi-entity mode**: `workDocuments`: ordered array of work document paths, one\n  per entity in `confirmedEntities` (dependency order), e.g.\n  `[\"{workDocDir}\u002Fleave-type.md\", \"{workDocDir}\u002Fleave-request.md\"]`.\n- `config`: the parsed plugin config\n- `projectRoot`: current project root\n\nThe implement agent loads its Phase 0 context once, then processes each document's\nscenarios in order (all of document 1's scenarios, then document 2's, ...):\n1. Select the next `- [ ]` scenario in the current document\n2. Write test (RED)\n3. Implement minimum code (GREEN)\n4. Mark as `- [x]`\n5. Repeat until the current document is complete, then move to the next document\n\n### Step 5: Final Build\n\nSkip this step when `confirmedEntities` was empty (nothing was implemented — see\nStep 4) and report `Build: not run — no entities to build` in Step 6 instead.\n\nOtherwise, after the implement agent returns (single document, or the whole batch,\ncomplete — or stopped early per its own 3-consecutive-failure rule), run a full\nbuild:\n\n```bash\n{config.buildCommand}\n```\n\nSet Bash tool timeout to 600000ms.\n\n### Step 6: Report\n\nDerive the \"Files created\" and \"Files modified\" lists from `git status --porcelain` (compared against the Step 4 baseline) and `git diff --stat` — never from memory or the implement agent's self-report. A `??` entry is a created file; an `M` entry is a modified file. If `git` is unavailable or the working tree is outside version control, state \"not verified: file lists\" instead of guessing.\n\nDisplay implementation summary in the working language.\n\n**Single-entity mode:**\n\n```\nFeature Implementation Complete: {feature-name}\n=======================================\n\nScenarios: {completed}\u002F{total}\n  {list each scenario with status}\n\nFiles created:\n  {list of new files}\n\nFiles modified:\n  {list of modified files}\n\nBuild: {PASS \u002F FAIL}\n```\n\n**Multi-entity mode** — one combined report covering every entity in\n`confirmedEntities`, plus any skipped in the demotion check:\n\n```\nFeature Implementation Complete: {feature} ({entityCount} entities)\n=======================================\n\nEntities implemented (in dependency order):\n  1. {Entity1} — {completed}\u002F{total} scenarios\n  2. {Entity2} — {completed}\u002F{total} scenarios\n\nEntities skipped (demotion declined):\n  {Entity} — existing status was '{status}', or \"(none)\"\n\nFiles created:\n  {list of new files, across all entities}\n\nFiles modified:\n  {list of modified files, across all entities}\n\nBuild: {PASS \u002F FAIL}\n```\n\nIf the build failed, suggest running `\u002Fbackend-webflux-plugin:be-build` for auto-diagnosis.\n\n### Step 7: Update Pipeline State\n\nFor each entity in `confirmedEntities` (or the single entity in single-entity mode),\nupdate `{workDocDir}\u002F.progress\u002F{kebab-case-entity}.json`:\n\n1. Read progress file\n2. Update `pipeline.scenarios.completed` with final count of `- [x]` items in that entity's own work document\n3. Update `pipeline.status`:\n   - All scenarios complete + build passes → `\"implemented\"`\n   - All scenarios complete + build fails → `\"implementing\"` — code that does not build is not implemented, and `\"implemented\"` is the state `be-review` accepts; report the build failure and point at `be-build`\n   - Some scenarios remain → `\"implementing\"`\n4. Update `updatedAt` timestamp\n5. Write back (read-modify-write — preserve all existing fields including `specSource`)\n\nAfter every entity's (or the single entity's) progress file is updated, release the\nlock: delete `{workDocDir}\u002F.progress\u002F.lock` — release per ${CLAUDE_PLUGIN_ROOT}\u002FCLAUDE.md § State File Safety.\n\nSuggest next step:\n- **All entities implemented + build passes**: `\u002Fbackend-webflux-plugin:be-verify {entity}` for each entity\n- **all scenarios done but the build fails** (status stays `implementing`): `\u002Fbackend-webflux-plugin:be-build`\n- **implementing**: resume with `\u002Fbackend-webflux-plugin:be-code {workDoc}`\n\n### Error Handling\n\nWhen a step fails or the user cancels, read `${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Fbe-code\u002Freferences\u002Ferror-handling.md` and follow it.\n\n## Example: Single-Entity, Non-Plan-Driven Run\n\nA worked single-entity run: `${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Fbe-code\u002Freferences\u002Fexample.md`.\n\n",{"name":5,"description":7,"allowed-tools":48,"argument-hint":49,"user-invocable":50},"Read, Write, Edit, Glob, Grep, Bash, Agent","\u003Cfeature-name or work-doc-path> [--yes]",true,"main","64e41a7f9c83f3469e662235cfcba152764ceb92","backend-webflux-plugin\u002Fskills\u002Fbe-code",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":59,"prompt":69,"zipAvailable":50},[60,63,66],{"tool":61,"command":62},"npx","npx skills add ohmyhotelco\u002Fhare-cc-plugins --skill be-code",{"tool":64,"command":65},"bunx","bunx skills add ohmyhotelco\u002Fhare-cc-plugins --skill be-code",{"tool":67,"command":68},"pnpm","pnpm dlx skills add ohmyhotelco\u002Fhare-cc-plugins --skill be-code","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fohmyhotelco\u002Fhare-cc-plugins\u002Fblob\u002Fmain\u002Fbackend-webflux-plugin\u002Fskills\u002Fbe-code\u002FSKILL.md",[71,77],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Ferror-handling.md","REFERENCE","参考文档",2161,"https:\u002F\u002Fgithub.com\u002Fohmyhotelco\u002Fhare-cc-plugins\u002Fblob\u002Fmain\u002Fbackend-webflux-plugin\u002Fskills\u002Fbe-code\u002Freferences\u002Ferror-handling.md",{"path":78,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fexample.md",2875,"https:\u002F\u002Fgithub.com\u002Fohmyhotelco\u002Fhare-cc-plugins\u002Fblob\u002Fmain\u002Fbackend-webflux-plugin\u002Fskills\u002Fbe-code\u002Freferences\u002Fexample.md",[82,106,130,154,172,192],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":43},"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",[],[89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,24,104,105],"shared","hp shared","state","stack","plugin","how","for","report","code conventions","commands","how to","conventions","false","frontmatter","file","hand","check",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":120,"publishedAt":43},"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",[112,117],{"categoryNo":113,"categoryName":114,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":118,"categoryName":119,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000015","视觉设计",[89,121,95,122,97,123,124,125,126,101,24,104,127,105,37,91,93,128,34,129],"fe shared","mode","frontend","design","design principles","files","react","principles","build",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":142,"publishedAt":43},"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",[136,139],{"categoryNo":137,"categoryName":138,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":140,"categoryName":141,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000023","Skill与智能体开发",[89,143,144,126,101,145,146,104,92,147,102,148,149,150,95,151,152,91,93,153],"spring","be spring shared","commit","architecture","coding standards","coding","standards","tech","Rules","cqrs","naming",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":43},"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",[],[161,162,163,25,164,165,33,166,32,30,167,168,103,169,170,171],"pp","pp translate","translate","name","editing","spec","sync","use","language","true","changes",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":179,"publishedAt":43},"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",[178],{"categoryNo":140,"categoryName":141,"taxonomyType":115,"taxonomyTypeDesc":116},[180,161,181,167,182,183,25,184,185,186,187,168,39,188,189,190,191,164,33,170],"pp sync stitch","stitch","projects","get","project","re","local","MCP","id","wireframes","website","screen",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":196,"categories":197,"keywords":199,"publishedAt":43},"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",[198],{"categoryNo":140,"categoryName":141,"taxonomyType":115,"taxonomyTypeDesc":116},[161,200,167,201,25,185,202,203,187,168,204,164,33,32,30,205,170],"notion","pp sync notion","search","manual","specification","grep"]