[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M719N08Q4JASGK1370ADPAYR":3,"skill-same:01M719N08Q4JASGK1370ADPAYR":75},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":74},"01M719N08Q4JASGK1370ADPAYR","lifecycle-agent-orchestrator-setup",null,"Interactive setup for connecting project-specific skills to the lifecycle agent orchestrator. Scans the project for existing architecture docs, coding standards, domain knowledge, and other skill-like files, then helps the user choose between config-based mapping (lao.config.yaml) or convention-based directory structure. Generates the chosen structure and validates it. Trigger when the user says \"set up the orchestrator\", \"configure project skills\", \"bootstrap the orchestrator\", \"connect my project\", or \"lao-setup\".","sandeep-mewara\u002Flifecycle-agent-orchestrator","sandeep-mewara","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F22136242?v=4","01M719M4609V9R414KB797CMRG","Sandeep Mewara","01M719M4700Q6AQQYT5EE5Z2DG",1,"MIT","https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Flao-setup\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"lifecycle agent orchestrator setup","lifecycle","agent orchestrator","setup","orchestrator","my","coding standards","config","directory","structure","architecture","configure","when","connect","files","knowledge","up","choose","project","SET","2026-11-10 10:12:30",false,"---\nname: lifecycle-agent-orchestrator-setup\naliases: [lao-setup]\ndescription: >\n  Interactive setup for connecting project-specific skills to the lifecycle agent orchestrator.\n  Scans the project for existing architecture docs, coding standards, domain knowledge,\n  and other skill-like files, then helps the user choose between config-based mapping\n  (lao.config.yaml) or convention-based directory structure. Generates the chosen\n  structure and validates it. Trigger when the user says \"set up the orchestrator\", \"configure\n  project skills\", \"bootstrap the orchestrator\", \"connect my project\", or\n  \"lao-setup\".\n---\n\n# Lifecycle Agent Orchestrator — Project Setup\n\nYou are running the interactive project setup for the lifecycle agent orchestrator. Your job\nis to scan the user's project, help them connect their existing files to the\norchestrator, and validate the result.\n\n## Process\n\nFollow these steps in order. Present clear output at each step and wait for\nhuman confirmation before proceeding to the next.\n\n### Step 1 — Scan the project\n\nScan the project root for files that look like potential skill content.\n\n**Language detection:** Detect the project's languages by checking **all**\nrules and collecting every match (a project can match more than one):\n- `pyproject.toml`, `setup.py`, or `requirements.txt` → `python`\n- `pom.xml`, `build.gradle`, or `build.gradle.kts` → `java`\n- `*.csproj` or `*.sln` → `csharp`\n- `package.json` with `react` in dependencies, or `next.config.*` → `react`\n- If no match → ask the user during Step 3\n\nInclude the detected languages in the scan results summary:\n\n**Overlay candidates:** Markdown files whose names contain lifecycle-relevant keywords\n(`architecture`, `coding-standards`, `testing-conventions`, `code-review`,\n`shipping`, `design`, `conventions`, `standards`, `patterns`, `intake`,\n`acceptance`, `product-management`). Search common locations:\n- `docs\u002F`, `wiki\u002F`, `.cursor\u002Frules\u002F`, project root\n- Exclude `node_modules\u002F`, `.git\u002F`, `vendor\u002F`, `build\u002F`, `dist\u002F`\n\n**Domain candidates:** Markdown files with YAML frontmatter containing both\n`name` and `description` fields. These could be domain context files.\n\n**Extra role candidates:** Markdown files with YAML frontmatter containing both\n`name` and `description` that don't match any base role keyword.\n\nPresent findings in a clear summary:\n\n```\n=== Project Scan Results ===\n\nDetected languages: python (from pyproject.toml), react (from package.json)\n\nPotential overlays (files that could customize base roles):\n  docs\u002Farchitecture\u002Fstandards.md → architecture\n  .cursor\u002Frules\u002Fcoding.md → coding-standards\n  docs\u002Freview-checklist.md → code-review\n\nPotential domain context (cross-cutting knowledge):\n  docs\u002Fdomain\u002Fauth-system.md (has frontmatter: name, description, applies_to)\n  docs\u002Fdomain\u002Fdata-model.md (has frontmatter: name, description)\n  src\u002Fpayments\u002FDESIGN.md (has frontmatter: name, description)\n\nPotential extra roles:\n  tools\u002Fcompliance\u002FSKILL.md (name: compliance-review)\n\nNo matches:\n  (Files that looked promising but didn't have the right structure)\n```\n\nIf the project already has a `lao.config.yaml`, report it:\n```\nFound existing lao.config.yaml — this project is already configured.\nRun \u002Flao to start the pipeline, or continue to re-scan and update.\n```\n\nIf a convention directory (`skills\u002F`) already exists with role subdirectories, report it:\n```\nFound convention directory: skills\u002F\nThis project already uses convention-based discovery.\nContinue to review and validate, or switch to config-based setup.\n```\n\n### Step 2 — Choose discovery method\n\nPresent the two options and ask the user which to use:\n\n```\nHow would you like to connect these files?\n\nOption A: Config file (lao.config.yaml)\n  Maps your existing files wherever they are. No moving or copying.\n  Best for: existing projects, established directory structures, monorepos.\n\nOption B: Convention directory (skills\u002F)\n  Creates a standard directory and copies\u002Fsymlinks files.\n  Best for: new projects, teams starting fresh, simple layouts.\n\nWhich option? (A\u002FB)\n```\n\nIf the scan found nothing, say so and still offer both options — the user might\nwant to create files from scratch.\n\n### Step 3 — Gather details\n\n**If Option A (config):**\n\n1. Ask for the project name (suggest based on directory name or package.json)\n2. Confirm the detected languages (or ask if detection found none):\n   ```\n   Detected languages: python, react. Correct? (y\u002Fn)\n   ```\n   If user says no, ask which languages apply (any combination of\n   `python`, `java`, `csharp`, `react`, or omit for auto-detection).\n3. Walk through each scan finding and ask whether to include it:\n   ```\n   Include docs\u002Farchitecture\u002Fstandards.md as architecture overlay? (y\u002Fn)\n   Include docs\u002Fdomain\u002Fauth-system.md as domain context? (y\u002Fn)\n   ```\n4. Ask if there are additional files not found by the scan that should be included\n5. For domain files without `applies_to` frontmatter, note they'll default to `all`\n\n**If Option B (convention):**\n\n1. For each overlay candidate: ask whether to create the overlay directory under\n   `skills\u002F` and copy the content, or create an empty `PROJECT.md` template to fill in later\n2. For domain candidates: ask whether to copy into `skills\u002Fdomain\u002F` or create templates\n3. For extra roles: ask whether to include; confirm `applies_to` scoping for each\n\n### Step 4 — Generate\n\n**If Option A (config):**\n\nGenerate `lao.config.yaml` at the project root with the confirmed mappings.\nUse the annotated format from `examples\u002Flao.config.yaml` as reference. Include\nonly sections that have entries (omit empty `overlays:`, `domain:`, `extra_roles:`).\n\n**If Option B (convention):**\n\nCreate the `skills\u002F` directory tree. For each confirmed item:\n- Overlays: create `skills\u002F\u003Crole>\u002FPROJECT.md` with a starter template that includes\n  an `## Overrides` section and references the base skill\n- Domain files: copy the file into `skills\u002Fdomain\u002F` or create a template with proper\n  frontmatter (`name`, `description`, `applies_to`)\n- Extra roles: create `skills\u002F\u003Crole>\u002FSKILL.md` with frontmatter template including\n  `applies_to` (ask user which phases\u002Froles it applies to; warn that omitting\n  `applies_to` means the role will not be loaded at any phase)\n\n### Step 5 — Validate\n\nRun the validation logic appropriate to the chosen method:\n\n**Config:** Parse the generated `lao.config.yaml`, verify all paths exist,\ncheck overlay keys match base roles, validate domain frontmatter, check extra\nrole keys don't match base roles. Report results in the same format as\n`validate-project-skills.sh --config`.\n\n**Convention:** Walk the generated directory, verify overlays match base roles,\ncheck frontmatter on extra roles and domain files (including `applies_to` on\nextra roles — warn if missing). Report results in the same format as\n`validate-project-skills.sh`.\n\nIf validation fails, help the user fix the issues before proceeding.\n\n### Step 6 — Next steps\n\nPrint a summary and guide the user to their next action:\n\n```\n=== Setup Complete ===\n\nProject: \u003Cproject-name>\nLanguages: python, react\nMethod: lao.config.yaml (or: convention directory)\nOverlays: architecture, coding-standards, code-review\nDomain context: auth-system (all), data-model (all)\nExtra roles: compliance-review\n\nNext steps:\n  1. Run \u002Flao-dry-run to test the full pipeline with your project skills\n  2. Run \u002Flao to start real work\n  3. Edit your overlays\u002Fdomain files to add project-specific knowledge\n\nValidation commands (from terminal):\n  .\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fscripts\u002Fvalidate-project-skills.sh --config lao.config.yaml\n  .\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fscripts\u002Fvalidate-project-skills.sh --scan .\n```\n\n## Base Roles Reference\n\nThese are the base role names used for overlay key matching:\n\n| Role | Description |\n|---|---|\n| `architecture` | System design, ADRs, architectural review |\n| `coding-standards` | Coding conventions and standards enforcement |\n| `testing-conventions` | Test patterns, quality, and coverage standards |\n| `code-review` | PR and code review with severity classification |\n| `shipping` | PR creation, Jira updates, ship workflow |\n| `product-management` | PRD creation and Jira ticket generation |\n| `intake` | Story reader and scope extractor |\n| `experience-design` | UX research, design options, specifications |\n| `security` | Security review and threat analysis |\n| `acceptance-validation` | Acceptance criteria verification gate |\n| `lao` | Full pipeline coordinator (rarely overlaid) |\n| `lao-dry-run` | Dry-run mode (rarely overlaid) |\n\n## Template: Overlay PROJECT.md\n\nWhen generating overlay files for convention mode, use this starter template:\n\n```markdown\n---\nname: \u003Crole>-overlay\ndescription: Project-specific \u003Crole> rules for \u003Cproject-name>\n---\n\n# \u003CRole> — Project Overlay\n\n> **Base skill:** `\u003Crole>` from lifecycle-agent-orchestrator v\u003Cversion>\n> **Path:** `\u003Cresolved-path-to-plugin>\u002Fskills\u002F\u003Crole>\u002FSKILL.md`\n> **Portable:** run `\u002Flao` and ask \"show me the \u003Crole> base skill\"\n> Only add project-specific deltas here — the base rules apply automatically.\n\n## Project Context\n\n\u003C!-- Describe your project's specific context for this role -->\n\n## Overrides\n\n\u003C!-- Document any base skill rules you are overriding and why -->\n\n## Additional Rules\n\n\u003C!-- Add project-specific rules not covered by the base skill -->\n```\n\nWhen generating this template, resolve the placeholders:\n- `\u003Cversion>`: read from the plugin's `.claude-plugin\u002Fplugin.json` → `version` field.\n- `\u003Cresolved-path-to-plugin>`: determine the absolute filesystem path where the\n  lifecycle-agent-orchestrator plugin is installed on this machine. You are currently reading\n  this SKILL.md from that location — use the parent directory of `skills\u002F` as the\n  plugin root. The resolved path is machine-specific; the portable `\u002Flao`\n  fallback works on any machine.\n\n## Template: Domain File\n\nWhen generating domain context files, use this starter template:\n\n```markdown\n---\nname: \u003Ctopic-name>\ndescription: \u003Cone-line description of what this domain file covers>\napplies_to: all\n---\n\n# \u003CTopic Name>\n\n## Overview\n\n\u003C!-- Describe the domain concept, system, or pattern -->\n\n## Key Decisions\n\n\u003C!-- Document important decisions and constraints -->\n\n## References\n\n\u003C!-- Links to external docs, diagrams, or specs -->\n```\n\n## Template: Extra Role SKILL.md\n\nWhen generating extra role files, use this starter template:\n\n```markdown\n---\nname: \u003Crole-name>\ndescription: \u003Cone-line description of what this role does>\napplies_to: [\u003Crole1>, \u003Crole2>]\n---\n\n# \u003CRole Name>\n\n## Purpose\n\n\u003C!-- Describe what this role checks, enforces, or produces -->\n\n## When Active\n\n\u003C!-- This role is loaded during phases whose base skill matches applies_to -->\n\n## Checklist \u002F Rules\n\n\u003C!-- Define the specific checks, standards, or outputs for this role -->\n```\n\n**Important:** If `applies_to` is omitted, the role will not be loaded at any\nphase. Always ask the user which phases\u002Froles this extra role is relevant to\nand populate `applies_to` accordingly. Valid values: `all`, or any combination\nof base role names (`product-management`, `architecture`, `code-review`, etc.).\n\n## Hard Rules\n\n- **Always scan before asking.** Don't ask the user to list files — find them.\n- **Never overwrite existing files** without explicit confirmation.\n- **Respect .gitignore** — don't scan ignored directories.\n- **One method only** — if the user picks config, don't also create convention dirs (and vice versa).\n- **Validate before declaring success** — always run validation in Step 5.\n","# Lifecycle Agent Orchestrator — Project Setup\n\nYou are running the interactive project setup for the lifecycle agent orchestrator. Your job\nis to scan the user's project, help them connect their existing files to the\norchestrator, and validate the result.\n\n## Process\n\nFollow these steps in order. Present clear output at each step and wait for\nhuman confirmation before proceeding to the next.\n\n### Step 1 — Scan the project\n\nScan the project root for files that look like potential skill content.\n\n**Language detection:** Detect the project's languages by checking **all**\nrules and collecting every match (a project can match more than one):\n- `pyproject.toml`, `setup.py`, or `requirements.txt` → `python`\n- `pom.xml`, `build.gradle`, or `build.gradle.kts` → `java`\n- `*.csproj` or `*.sln` → `csharp`\n- `package.json` with `react` in dependencies, or `next.config.*` → `react`\n- If no match → ask the user during Step 3\n\nInclude the detected languages in the scan results summary:\n\n**Overlay candidates:** Markdown files whose names contain lifecycle-relevant keywords\n(`architecture`, `coding-standards`, `testing-conventions`, `code-review`,\n`shipping`, `design`, `conventions`, `standards`, `patterns`, `intake`,\n`acceptance`, `product-management`). Search common locations:\n- `docs\u002F`, `wiki\u002F`, `.cursor\u002Frules\u002F`, project root\n- Exclude `node_modules\u002F`, `.git\u002F`, `vendor\u002F`, `build\u002F`, `dist\u002F`\n\n**Domain candidates:** Markdown files with YAML frontmatter containing both\n`name` and `description` fields. These could be domain context files.\n\n**Extra role candidates:** Markdown files with YAML frontmatter containing both\n`name` and `description` that don't match any base role keyword.\n\nPresent findings in a clear summary:\n\n```\n=== Project Scan Results ===\n\nDetected languages: python (from pyproject.toml), react (from package.json)\n\nPotential overlays (files that could customize base roles):\n  docs\u002Farchitecture\u002Fstandards.md → architecture\n  .cursor\u002Frules\u002Fcoding.md → coding-standards\n  docs\u002Freview-checklist.md → code-review\n\nPotential domain context (cross-cutting knowledge):\n  docs\u002Fdomain\u002Fauth-system.md (has frontmatter: name, description, applies_to)\n  docs\u002Fdomain\u002Fdata-model.md (has frontmatter: name, description)\n  src\u002Fpayments\u002FDESIGN.md (has frontmatter: name, description)\n\nPotential extra roles:\n  tools\u002Fcompliance\u002FSKILL.md (name: compliance-review)\n\nNo matches:\n  (Files that looked promising but didn't have the right structure)\n```\n\nIf the project already has a `lao.config.yaml`, report it:\n```\nFound existing lao.config.yaml — this project is already configured.\nRun \u002Flao to start the pipeline, or continue to re-scan and update.\n```\n\nIf a convention directory (`skills\u002F`) already exists with role subdirectories, report it:\n```\nFound convention directory: skills\u002F\nThis project already uses convention-based discovery.\nContinue to review and validate, or switch to config-based setup.\n```\n\n### Step 2 — Choose discovery method\n\nPresent the two options and ask the user which to use:\n\n```\nHow would you like to connect these files?\n\nOption A: Config file (lao.config.yaml)\n  Maps your existing files wherever they are. No moving or copying.\n  Best for: existing projects, established directory structures, monorepos.\n\nOption B: Convention directory (skills\u002F)\n  Creates a standard directory and copies\u002Fsymlinks files.\n  Best for: new projects, teams starting fresh, simple layouts.\n\nWhich option? (A\u002FB)\n```\n\nIf the scan found nothing, say so and still offer both options — the user might\nwant to create files from scratch.\n\n### Step 3 — Gather details\n\n**If Option A (config):**\n\n1. Ask for the project name (suggest based on directory name or package.json)\n2. Confirm the detected languages (or ask if detection found none):\n   ```\n   Detected languages: python, react. Correct? (y\u002Fn)\n   ```\n   If user says no, ask which languages apply (any combination of\n   `python`, `java`, `csharp`, `react`, or omit for auto-detection).\n3. Walk through each scan finding and ask whether to include it:\n   ```\n   Include docs\u002Farchitecture\u002Fstandards.md as architecture overlay? (y\u002Fn)\n   Include docs\u002Fdomain\u002Fauth-system.md as domain context? (y\u002Fn)\n   ```\n4. Ask if there are additional files not found by the scan that should be included\n5. For domain files without `applies_to` frontmatter, note they'll default to `all`\n\n**If Option B (convention):**\n\n1. For each overlay candidate: ask whether to create the overlay directory under\n   `skills\u002F` and copy the content, or create an empty `PROJECT.md` template to fill in later\n2. For domain candidates: ask whether to copy into `skills\u002Fdomain\u002F` or create templates\n3. For extra roles: ask whether to include; confirm `applies_to` scoping for each\n\n### Step 4 — Generate\n\n**If Option A (config):**\n\nGenerate `lao.config.yaml` at the project root with the confirmed mappings.\nUse the annotated format from `examples\u002Flao.config.yaml` as reference. Include\nonly sections that have entries (omit empty `overlays:`, `domain:`, `extra_roles:`).\n\n**If Option B (convention):**\n\nCreate the `skills\u002F` directory tree. For each confirmed item:\n- Overlays: create `skills\u002F\u003Crole>\u002FPROJECT.md` with a starter template that includes\n  an `## Overrides` section and references the base skill\n- Domain files: copy the file into `skills\u002Fdomain\u002F` or create a template with proper\n  frontmatter (`name`, `description`, `applies_to`)\n- Extra roles: create `skills\u002F\u003Crole>\u002FSKILL.md` with frontmatter template including\n  `applies_to` (ask user which phases\u002Froles it applies to; warn that omitting\n  `applies_to` means the role will not be loaded at any phase)\n\n### Step 5 — Validate\n\nRun the validation logic appropriate to the chosen method:\n\n**Config:** Parse the generated `lao.config.yaml`, verify all paths exist,\ncheck overlay keys match base roles, validate domain frontmatter, check extra\nrole keys don't match base roles. Report results in the same format as\n`validate-project-skills.sh --config`.\n\n**Convention:** Walk the generated directory, verify overlays match base roles,\ncheck frontmatter on extra roles and domain files (including `applies_to` on\nextra roles — warn if missing). Report results in the same format as\n`validate-project-skills.sh`.\n\nIf validation fails, help the user fix the issues before proceeding.\n\n### Step 6 — Next steps\n\nPrint a summary and guide the user to their next action:\n\n```\n=== Setup Complete ===\n\nProject: \u003Cproject-name>\nLanguages: python, react\nMethod: lao.config.yaml (or: convention directory)\nOverlays: architecture, coding-standards, code-review\nDomain context: auth-system (all), data-model (all)\nExtra roles: compliance-review\n\nNext steps:\n  1. Run \u002Flao-dry-run to test the full pipeline with your project skills\n  2. Run \u002Flao to start real work\n  3. Edit your overlays\u002Fdomain files to add project-specific knowledge\n\nValidation commands (from terminal):\n  .\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fscripts\u002Fvalidate-project-skills.sh --config lao.config.yaml\n  .\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fscripts\u002Fvalidate-project-skills.sh --scan .\n```\n\n## Base Roles Reference\n\nThese are the base role names used for overlay key matching:\n\n| Role | Description |\n|---|---|\n| `architecture` | System design, ADRs, architectural review |\n| `coding-standards` | Coding conventions and standards enforcement |\n| `testing-conventions` | Test patterns, quality, and coverage standards |\n| `code-review` | PR and code review with severity classification |\n| `shipping` | PR creation, Jira updates, ship workflow |\n| `product-management` | PRD creation and Jira ticket generation |\n| `intake` | Story reader and scope extractor |\n| `experience-design` | UX research, design options, specifications |\n| `security` | Security review and threat analysis |\n| `acceptance-validation` | Acceptance criteria verification gate |\n| `lao` | Full pipeline coordinator (rarely overlaid) |\n| `lao-dry-run` | Dry-run mode (rarely overlaid) |\n\n## Template: Overlay PROJECT.md\n\nWhen generating overlay files for convention mode, use this starter template:\n\n```markdown\n---\nname: \u003Crole>-overlay\ndescription: Project-specific \u003Crole> rules for \u003Cproject-name>\n---\n\n# \u003CRole> — Project Overlay\n\n> **Base skill:** `\u003Crole>` from lifecycle-agent-orchestrator v\u003Cversion>\n> **Path:** `\u003Cresolved-path-to-plugin>\u002Fskills\u002F\u003Crole>\u002FSKILL.md`\n> **Portable:** run `\u002Flao` and ask \"show me the \u003Crole> base skill\"\n> Only add project-specific deltas here — the base rules apply automatically.\n\n## Project Context\n\n\u003C!-- Describe your project's specific context for this role -->\n\n## Overrides\n\n\u003C!-- Document any base skill rules you are overriding and why -->\n\n## Additional Rules\n\n\u003C!-- Add project-specific rules not covered by the base skill -->\n```\n\nWhen generating this template, resolve the placeholders:\n- `\u003Cversion>`: read from the plugin's `.claude-plugin\u002Fplugin.json` → `version` field.\n- `\u003Cresolved-path-to-plugin>`: determine the absolute filesystem path where the\n  lifecycle-agent-orchestrator plugin is installed on this machine. You are currently reading\n  this SKILL.md from that location — use the parent directory of `skills\u002F` as the\n  plugin root. The resolved path is machine-specific; the portable `\u002Flao`\n  fallback works on any machine.\n\n## Template: Domain File\n\nWhen generating domain context files, use this starter template:\n\n```markdown\n---\nname: \u003Ctopic-name>\ndescription: \u003Cone-line description of what this domain file covers>\napplies_to: all\n---\n\n# \u003CTopic Name>\n\n## Overview\n\n\u003C!-- Describe the domain concept, system, or pattern -->\n\n## Key Decisions\n\n\u003C!-- Document important decisions and constraints -->\n\n## References\n\n\u003C!-- Links to external docs, diagrams, or specs -->\n```\n\n## Template: Extra Role SKILL.md\n\nWhen generating extra role files, use this starter template:\n\n```markdown\n---\nname: \u003Crole-name>\ndescription: \u003Cone-line description of what this role does>\napplies_to: [\u003Crole1>, \u003Crole2>]\n---\n\n# \u003CRole Name>\n\n## Purpose\n\n\u003C!-- Describe what this role checks, enforces, or produces -->\n\n## When Active\n\n\u003C!-- This role is loaded during phases whose base skill matches applies_to -->\n\n## Checklist \u002F Rules\n\n\u003C!-- Define the specific checks, standards, or outputs for this role -->\n```\n\n**Important:** If `applies_to` is omitted, the role will not be loaded at any\nphase. Always ask the user which phases\u002Froles this extra role is relevant to\nand populate `applies_to` accordingly. Valid values: `all`, or any combination\nof base role names (`product-management`, `architecture`, `code-review`, etc.).\n\n## Hard Rules\n\n- **Always scan before asking.** Don't ask the user to list files — find them.\n- **Never overwrite existing files** without explicit confirmation.\n- **Respect .gitignore** — don't scan ignored directories.\n- **One method only** — if the user picks config, don't also create convention dirs (and vice versa).\n- **Validate before declaring success** — always run validation in Step 5.\n",{"name":5,"aliases":49,"description":7},[50],"lao-setup","main","7df021855a805acbcdc470d3b4419009e57f0330","plugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Flao-setup",0,"https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator","https:\u002F\u002Flearnbyinsight.com\u002F2026\u002F04\u002F19\u002Fthe-lifecycle-is-the-product-ai-development-engine\u002F","https:\u002F\u002Fgithub.com\u002Fsandeep-mewara","https:\u002F\u002Flearnbyinsight.com\u002F","A software professional for more than 15+ years learning ...","2026-04-20 00:49:35",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add sandeep-mewara\u002Flifecycle-agent-orchestrator --skill lifecycle-agent-orchestrator-setup",{"tool":67,"command":68},"bunx","bunx skills add sandeep-mewara\u002Flifecycle-agent-orchestrator --skill lifecycle-agent-orchestrator-setup",{"tool":70,"command":71},"pnpm","pnpm dlx skills add sandeep-mewara\u002Flifecycle-agent-orchestrator --skill lifecycle-agent-orchestrator-setup","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Flao-setup\u002FSKILL.md",true,[],[76,92,111,118,142,166],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":44},"01M719NW8TNRJGM3T22XC1HS1Y","extra-role","A custom project-specific role for testing","https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Ftests\u002Ffixtures\u002Fvalid-project\u002Fextra-role\u002FSKILL.md",[],[83,84,85,86,34,87,88,89,42,90,91],"role","extra","extra role","review","code-review","code","for","testing","custom",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":103,"publishedAt":44},"01M719NTA6SXBZ2VG2YX7PT1G8","compliance-review","Ensures regulatory compliance for financial services","https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Ftests\u002Ffixtures\u002Fvalid-config\u002Ftools\u002Fcompliance\u002FSKILL.md",[98],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[104,105,86,106,34,87,88,107,108,109,89,110],"compliance","compliance review","financial services","security","regulatory compliance","regulatory","services",{"skillNo":112,"name":78,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":116,"publishedAt":44},"01M719NS3WX4TRDAX41V5PSSF2","A custom role missing applies_to for testing","https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Ftests\u002Ffixtures\u002Fmissing-applies-to-extra\u002Fextra-role\u002FSKILL.md",[],[83,85,84,89,91,117,90],"missing",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":128,"publishedAt":44},"01M719NMWH7M49CSX17DBJYCE1","testing-conventions","Enforces testing standards when writing unit tests, integration tests, or agent evaluation tests. Covers test directory structure, naming conventions, fixture and setup patterns, mocking strategy, async testing, coverage requirements, and LLM-as-judge evaluation. Language-specific conventions (Python\u002Fpytest, Java\u002FJUnit, C#\u002FxUnit, React\u002FVitest) are loaded from bundled reference packs. Use this skill when writing tests, creating test files, setting up fixtures, mocking services, or reviewing test code for standards compliance.","https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Ftesting-conventions\u002FSKILL.md",[124,127],{"categoryNo":125,"categoryName":126,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[129,130,90,131,88,132,33,36,32,133,134,135,136,137,38,40,138,139,140,141],"conventions","testing conventions","testing standards","react","LLM-as-Judge","Evaluation","judge","patterns","pytest","fixture","unit","coverage","writing",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":149,"publishedAt":44},"01M719NGZVGA0C0NY8G66FNHB8","shipping","Shipping workflow for platform services. Use this skill when creating pull requests, pushing code for review, updating Jira tickets to reflect PR status, or completing the ship cycle for a feature or bugfix. Trigger this skill when the user says things like \"open a PR,\" \"create a pull request,\" \"ship this,\" \"push for review,\" \"update the ticket,\" \"mark this as ready for review,\" or \"I'm done with this feature\" — even if they don't explicitly say \"shipping.\" Also trigger when the user wants to transition a Jira ticket status after code changes are ready.","https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Fshipping\u002FSKILL.md",[148],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[144,150,151,152,153,154,155,156,157,158,159,160,161,162,86,163,88,164,165,36],"ticket","cycle","ready","open","transition","status","bugfix","jira","update","request","pull requests","reflect","create","creating pull requests","done","workflow",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":177,"publishedAt":44},"01M719NCJ3BNN5AXQ1V1FDYCJS","security-standards","Enforces security standards when writing or reviewing code that handles authentication, secrets, sensitive data, API boundaries, or compliance concerns. Covers secrets manager integration, encryption at rest and in transit, IAM authentication and least-privilege authorization, OWASP Top 10 secure coding (including prompt injection), dependency vulnerability management, API security (auth, validation, rate limiting), PII and sensitive data protection in logs and traces, and regulatory compliance (CCPA\u002FGDPR). Use this skill when adding endpoints, handling user data, managing secrets, reviewing for vulnerabilities, configuring auth, working with LLM prompts that accept user input, setting up deployment security, or assessing compliance. Also use when DAST findings need remediation.","https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Fsecurity\u002FSKILL.md",[172,173,176],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":174,"categoryName":175,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},[107,178,179,180,181,182,183,184,185,186,187,88,188,36,141,189,40,190,191,192],"security standards","standards","vulnerability","remediation","dependency","owasp top 10","top","iam","logs","api","encryption","prompt injection","authentication","auth","pii"]