[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M719NGZVGA0C0NY8G66FNHB8":3,"skill-same:01M719NGZVGA0C0NY8G66FNHB8":78},{"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":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":53,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M719NGZVGA0C0NY8G66FNHB8","shipping",null,"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.","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\u002Fshipping\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"review","status","bugfix","jira","update","request","transition","pull requests","reflect","create","creating pull requests","code","done","workflow","when","open","ticket","cycle","ready","2026-11-10 10:12:30",false,"---\nname: shipping\ndescription: >\n  Shipping workflow for platform services. Use this skill when creating pull requests,\n  pushing code for review, updating Jira tickets to reflect PR status, or completing the ship cycle\n  for a feature or bugfix. Trigger this skill when the user says things like \"open a PR,\" \"create a\n  pull request,\" \"ship this,\" \"push for review,\" \"update the ticket,\" \"mark this as ready for review,\"\n  or \"I'm done with this feature\" — even if they don't explicitly say \"shipping.\" Also trigger when\n  the user wants to transition a Jira ticket status after code changes are ready.\n---\n\n# Shipping\n\nYou handle the shipping workflow: creating pull requests and keeping Jira tickets in sync. The goal is to make shipping frictionless while ensuring nothing gets lost between code and project tracking.\n\nSee PROJECT.md for the specific repository, branch conventions, Jira project, CI pipeline, and deployment details.\n\n---\n\n## Workflow Overview\n\nThe shipping workflow has two parts that usually happen together:\n\n1. **Open a PR** — via `gh` CLI command or GitHub MCP\n2. **Update Jira** — via Jira MCP (transition status, add comment with PR link)\n\nYou can run either part independently. If the user says \"open a PR\" without mentioning Jira, just do the PR. If they say \"update the ticket,\" just do the Jira update. When they say \"ship this\" or \"I'm done,\" do both.\n\n---\n\n## Step 1: Pre-Ship Checks\n\nBefore creating a PR, verify the basics. Don't skip these — a failed PR wastes everyone's time.\n\n**Check the working tree:**\n- Run `git status` — are there uncommitted changes? If so, ask the user if they want to commit first.\n- Run `git diff \u003Cbase-branch>...HEAD` — confirm there are actual changes to ship.\n- Check the branch name follows the project's convention (see PROJECT.md). If it doesn't, mention it but don't block — the user may have a reason.\n\n**Check the basics:**\n- Are there tests for the new code? A quick `git diff --name-only \u003Cbase-branch>...HEAD` to see if test files are in the diff.\n- Does the branch have a clean commit history? Multiple \"WIP\" or \"fix typo\" commits are fine — squash happens at merge.\n\n**Extract context:**\n- Identify the Jira ticket from the branch name (e.g., `feature\u002FPROJ-1234` → `PROJ-1234`).\n- Run `git log \u003Cbase-branch>...HEAD --oneline` to understand the full set of changes for the PR description.\n\nIf a pre-ship check reveals a problem (no tests, uncommitted changes, no changes vs base), tell the user clearly and ask how they want to proceed. Don't block them — they may be opening a draft PR intentionally.\n\n---\n\n## Step 2: Create the Pull Request\n\nYou have two methods available. Use whichever is appropriate for the context.\n\n### Method A: `gh` CLI (preferred for local workflow)\n\nUse the `gh` CLI when working locally and the branch is already pushed (or needs to be pushed).\n\n```bash\n# Push the branch if not already pushed\ngit push -u origin HEAD\n\n# Create the PR\ngh pr create --title \"\u003Ctitle>\" --body \"\u003Cbody>\" --base \u003Cbase-branch>\n```\n\n### Method B: GitHub MCP (preferred when working with remote context)\n\nUse the GitHub MCP tool when:\n- You're working in a context where `gh` CLI may not be available\n- You need more control over PR parameters (draft, maintainer_can_modify)\n- The repo context is remote (e.g., different org or fork)\n\n### PR Title and Description\n\n**Title format:** Keep it short (under 70 chars). Include the Jira ticket if available.\n- `PROJ-1234: Add year-end summary report generation`\n- `PROJ-5678: Fix null pointer in profile fetch`\n\n**Description template:**\n\n```markdown\n## Summary\n[1-3 bullet points describing what changed and why]\n\n## Jira\n[PROJ-XXXX](https:\u002F\u002Fyour-jira.atlassian.net\u002Fbrowse\u002FPROJ-XXXX)\n\n## Changes\n- [Key change 1]\n- [Key change 2]\n\n## Testing\n- [ ] Unit tests added\u002Fupdated\n- [ ] Integration tests pass\n- [ ] Manual testing done (describe if applicable)\n\n## Checklist\n- [ ] No PII or secrets in code or logs\n- [ ] Follows project conventions\n- [ ] New endpoints have auth checks\n- [ ] Observability added for new critical paths\n```\n\nAdapt this template to the actual changes — don't include sections that aren't relevant. A one-line bugfix doesn't need a full checklist. Use judgment. See PROJECT.md for project-specific checklist items.\n\n---\n\n## Step 3: Update Jira Ticket\n\nAfter the PR is created, update the Jira ticket to reflect the current status. This keeps the team's project board accurate.\n\n### Determine the Jira ticket\n\nIn order of preference:\n1. The user explicitly provides the ticket key\n2. Extract from the branch name (e.g., `feature\u002FPROJ-1234` → `PROJ-1234`)\n3. Extract from commit messages (look for ticket key patterns)\n4. Ask the user — don't guess\n\n### Transition the ticket status\n\nUse the Jira MCP to discover valid transitions, then apply the appropriate one.\n\n**Typical transitions:**\n- When PR is opened → transition to **\"In Review\"** or **\"Ready for Review\"** (depends on project workflow)\n- When PR is merged → transition to **\"Done\"** or **\"Closed\"** (usually handled by CI automation, but confirm)\n\nAlways check available transitions first — don't assume a transition name exists. Workflow configurations vary across projects.\n\n**Before transitioning:** Tell the user what transition you're about to make and get confirmation. Changing ticket status is visible to the team.\n\n### Add a comment with the PR link\n\nAdd a comment linking the PR to the ticket:\n\n```markdown\n## PR Opened\n\n**PR:** [#\u003Cnumber> \u003Ctitle>](\u003Cpr-url>)\n**Branch:** `\u003Cbranch-name>`\n**Base:** `\u003Cbase-branch>`\n\n### Changes\n- \u003Csummary of changes from PR description>\n```\n\nThis creates a traceable link between the ticket and the code change.\n\n### Update other fields (if applicable)\n\nWhen the user requests specific field updates:\n- **Fix version** — if the user specifies which release this targets\n- **Labels** — if the team uses labels for tracking (e.g., `needs-review`)\n- **Assignee** — if the reviewer should be assigned\n\nDon't update fields the user didn't ask to update. Don't guess field values.\n\n---\n\n## Confirmation and Summary\n\nAfter completing the workflow, provide a clear summary of what was done:\n\n```\n## Shipped\n\n**PR:** [#\u003Cnumber> \u003Ctitle>](\u003Cpr-url>)\n**Branch:** `\u003Cbranch>` → `\u003Cbase>`\n**Jira:** [PROJ-XXXX](\u003Cjira-url>) — transitioned to \"\u003Cstatus>\", comment added with PR link\n\n### What's next\n- PR needs review from the team\n- CI pipeline will run (see PROJECT.md for pipeline details)\n- After merge, automation handles ticket transition (if configured)\n```\n\n---\n\n## Handling Edge Cases\n\n**No Jira ticket found:**\n- Create the PR anyway — not every change has a ticket.\n- Mention that no Jira ticket was updated. Ask if there's a ticket they want to link.\n\n**PR already exists for this branch:**\n- Check with `gh pr list --head \u003Cbranch>` or the GitHub MCP.\n- If a PR exists, tell the user and offer to update it instead of creating a duplicate.\n\n**Branch not pushed:**\n- Push first with `git push -u origin HEAD`, then create the PR.\n- If the push fails (e.g., remote branch conflicts), surface the error and let the user resolve it.\n\n**Draft PR:**\n- If the user says \"open a draft\" or the work is explicitly incomplete, create the PR as draft.\n- In the Jira comment, note that it's a draft PR.\n\n**Multiple tickets in one PR:**\n- If the branch or commits reference multiple tickets, ask which ticket(s) to update.\n- Add the PR comment to all relevant tickets.\n\n**Jira transition fails:**\n- If the transition isn't available (e.g., ticket is already in the target status), tell the user what status the ticket is currently in and what transitions are available.\n- Don't retry silently — the user needs to know.\n\n---\n\n## What NOT to Do\n\n- **Don't push to the default branch directly.** All changes go through PRs.\n- **Don't merge the PR.** Your job is to open it. Merging is a team decision after review.\n- **Don't transition tickets without confirmation.** Status changes are visible to the team and affect sprint boards. Always confirm with the user first.\n- **Don't fabricate PR descriptions.** Base the description on actual changes (`git log`, `git diff`). Don't invent requirements or changes that aren't in the diff.\n- **Don't update Jira fields you weren't asked to update.** Updating the wrong field (e.g., story points, priority) can disrupt sprint planning.\n- **Don't include secrets, tokens, or PII in PR descriptions or Jira comments.** Even if they appear in the code (which they shouldn't), don't propagate them to PR or Jira text.\n","# Shipping\n\nYou handle the shipping workflow: creating pull requests and keeping Jira tickets in sync. The goal is to make shipping frictionless while ensuring nothing gets lost between code and project tracking.\n\nSee PROJECT.md for the specific repository, branch conventions, Jira project, CI pipeline, and deployment details.\n\n---\n\n## Workflow Overview\n\nThe shipping workflow has two parts that usually happen together:\n\n1. **Open a PR** — via `gh` CLI command or GitHub MCP\n2. **Update Jira** — via Jira MCP (transition status, add comment with PR link)\n\nYou can run either part independently. If the user says \"open a PR\" without mentioning Jira, just do the PR. If they say \"update the ticket,\" just do the Jira update. When they say \"ship this\" or \"I'm done,\" do both.\n\n---\n\n## Step 1: Pre-Ship Checks\n\nBefore creating a PR, verify the basics. Don't skip these — a failed PR wastes everyone's time.\n\n**Check the working tree:**\n- Run `git status` — are there uncommitted changes? If so, ask the user if they want to commit first.\n- Run `git diff \u003Cbase-branch>...HEAD` — confirm there are actual changes to ship.\n- Check the branch name follows the project's convention (see PROJECT.md). If it doesn't, mention it but don't block — the user may have a reason.\n\n**Check the basics:**\n- Are there tests for the new code? A quick `git diff --name-only \u003Cbase-branch>...HEAD` to see if test files are in the diff.\n- Does the branch have a clean commit history? Multiple \"WIP\" or \"fix typo\" commits are fine — squash happens at merge.\n\n**Extract context:**\n- Identify the Jira ticket from the branch name (e.g., `feature\u002FPROJ-1234` → `PROJ-1234`).\n- Run `git log \u003Cbase-branch>...HEAD --oneline` to understand the full set of changes for the PR description.\n\nIf a pre-ship check reveals a problem (no tests, uncommitted changes, no changes vs base), tell the user clearly and ask how they want to proceed. Don't block them — they may be opening a draft PR intentionally.\n\n---\n\n## Step 2: Create the Pull Request\n\nYou have two methods available. Use whichever is appropriate for the context.\n\n### Method A: `gh` CLI (preferred for local workflow)\n\nUse the `gh` CLI when working locally and the branch is already pushed (or needs to be pushed).\n\n```bash\n# Push the branch if not already pushed\ngit push -u origin HEAD\n\n# Create the PR\ngh pr create --title \"\u003Ctitle>\" --body \"\u003Cbody>\" --base \u003Cbase-branch>\n```\n\n### Method B: GitHub MCP (preferred when working with remote context)\n\nUse the GitHub MCP tool when:\n- You're working in a context where `gh` CLI may not be available\n- You need more control over PR parameters (draft, maintainer_can_modify)\n- The repo context is remote (e.g., different org or fork)\n\n### PR Title and Description\n\n**Title format:** Keep it short (under 70 chars). Include the Jira ticket if available.\n- `PROJ-1234: Add year-end summary report generation`\n- `PROJ-5678: Fix null pointer in profile fetch`\n\n**Description template:**\n\n```markdown\n## Summary\n[1-3 bullet points describing what changed and why]\n\n## Jira\n[PROJ-XXXX](https:\u002F\u002Fyour-jira.atlassian.net\u002Fbrowse\u002FPROJ-XXXX)\n\n## Changes\n- [Key change 1]\n- [Key change 2]\n\n## Testing\n- [ ] Unit tests added\u002Fupdated\n- [ ] Integration tests pass\n- [ ] Manual testing done (describe if applicable)\n\n## Checklist\n- [ ] No PII or secrets in code or logs\n- [ ] Follows project conventions\n- [ ] New endpoints have auth checks\n- [ ] Observability added for new critical paths\n```\n\nAdapt this template to the actual changes — don't include sections that aren't relevant. A one-line bugfix doesn't need a full checklist. Use judgment. See PROJECT.md for project-specific checklist items.\n\n---\n\n## Step 3: Update Jira Ticket\n\nAfter the PR is created, update the Jira ticket to reflect the current status. This keeps the team's project board accurate.\n\n### Determine the Jira ticket\n\nIn order of preference:\n1. The user explicitly provides the ticket key\n2. Extract from the branch name (e.g., `feature\u002FPROJ-1234` → `PROJ-1234`)\n3. Extract from commit messages (look for ticket key patterns)\n4. Ask the user — don't guess\n\n### Transition the ticket status\n\nUse the Jira MCP to discover valid transitions, then apply the appropriate one.\n\n**Typical transitions:**\n- When PR is opened → transition to **\"In Review\"** or **\"Ready for Review\"** (depends on project workflow)\n- When PR is merged → transition to **\"Done\"** or **\"Closed\"** (usually handled by CI automation, but confirm)\n\nAlways check available transitions first — don't assume a transition name exists. Workflow configurations vary across projects.\n\n**Before transitioning:** Tell the user what transition you're about to make and get confirmation. Changing ticket status is visible to the team.\n\n### Add a comment with the PR link\n\nAdd a comment linking the PR to the ticket:\n\n```markdown\n## PR Opened\n\n**PR:** [#\u003Cnumber> \u003Ctitle>](\u003Cpr-url>)\n**Branch:** `\u003Cbranch-name>`\n**Base:** `\u003Cbase-branch>`\n\n### Changes\n- \u003Csummary of changes from PR description>\n```\n\nThis creates a traceable link between the ticket and the code change.\n\n### Update other fields (if applicable)\n\nWhen the user requests specific field updates:\n- **Fix version** — if the user specifies which release this targets\n- **Labels** — if the team uses labels for tracking (e.g., `needs-review`)\n- **Assignee** — if the reviewer should be assigned\n\nDon't update fields the user didn't ask to update. Don't guess field values.\n\n---\n\n## Confirmation and Summary\n\nAfter completing the workflow, provide a clear summary of what was done:\n\n```\n## Shipped\n\n**PR:** [#\u003Cnumber> \u003Ctitle>](\u003Cpr-url>)\n**Branch:** `\u003Cbranch>` → `\u003Cbase>`\n**Jira:** [PROJ-XXXX](\u003Cjira-url>) — transitioned to \"\u003Cstatus>\", comment added with PR link\n\n### What's next\n- PR needs review from the team\n- CI pipeline will run (see PROJECT.md for pipeline details)\n- After merge, automation handles ticket transition (if configured)\n```\n\n---\n\n## Handling Edge Cases\n\n**No Jira ticket found:**\n- Create the PR anyway — not every change has a ticket.\n- Mention that no Jira ticket was updated. Ask if there's a ticket they want to link.\n\n**PR already exists for this branch:**\n- Check with `gh pr list --head \u003Cbranch>` or the GitHub MCP.\n- If a PR exists, tell the user and offer to update it instead of creating a duplicate.\n\n**Branch not pushed:**\n- Push first with `git push -u origin HEAD`, then create the PR.\n- If the push fails (e.g., remote branch conflicts), surface the error and let the user resolve it.\n\n**Draft PR:**\n- If the user says \"open a draft\" or the work is explicitly incomplete, create the PR as draft.\n- In the Jira comment, note that it's a draft PR.\n\n**Multiple tickets in one PR:**\n- If the branch or commits reference multiple tickets, ask which ticket(s) to update.\n- Add the PR comment to all relevant tickets.\n\n**Jira transition fails:**\n- If the transition isn't available (e.g., ticket is already in the target status), tell the user what status the ticket is currently in and what transitions are available.\n- Don't retry silently — the user needs to know.\n\n---\n\n## What NOT to Do\n\n- **Don't push to the default branch directly.** All changes go through PRs.\n- **Don't merge the PR.** Your job is to open it. Merging is a team decision after review.\n- **Don't transition tickets without confirmation.** Status changes are visible to the team and affect sprint boards. Always confirm with the user first.\n- **Don't fabricate PR descriptions.** Base the description on actual changes (`git log`, `git diff`). Don't invent requirements or changes that aren't in the diff.\n- **Don't update Jira fields you weren't asked to update.** Updating the wrong field (e.g., story points, priority) can disrupt sprint planning.\n- **Don't include secrets, tokens, or PII in PR descriptions or Jira comments.** Even if they appear in the code (which they shouldn't), don't propagate them to PR or Jira text.\n",{"name":5,"description":7},"main","7df021855a805acbcdc470d3b4419009e57f0330","plugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Fshipping",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":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add sandeep-mewara\u002Flifecycle-agent-orchestrator --skill shipping",{"tool":64,"command":65},"bunx","bunx skills add sandeep-mewara\u002Flifecycle-agent-orchestrator --skill shipping",{"tool":67,"command":68},"pnpm","pnpm dlx skills add sandeep-mewara\u002Flifecycle-agent-orchestrator --skill shipping","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Fshipping\u002FSKILL.md",true,[72],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Fpr-template.md","REFERENCE","参考文档",603,"https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Fshipping\u002Freferences\u002Fpr-template.md",[79,95,114,121,149,176],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":43},"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",[],[86,87,88,24,89,90,35,91,92,93,94],"role","extra","extra role","architecture","code-review","custom","testing","project","for",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":106,"publishedAt":43},"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",[101],{"categoryNo":102,"categoryName":103,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[107,108,24,90,89,35,109,110,111,94,112,113],"compliance","compliance review","security","regulatory compliance","regulatory","financial services","services",{"skillNo":115,"name":81,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":43},"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",[],[87,88,86,92,94,120,91],"missing",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":131,"publishedAt":43},"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",[127,130],{"categoryNo":128,"categoryName":129,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[92,132,133,134,35,135,136,137,138,139,140,141,142,143,144,145,146,147,148,38],"testing conventions","conventions","testing standards","react","structure","directory","LLM-as-Judge","pytest","patterns","judge","Evaluation","writing","files","up","fixture","unit","coverage",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":160,"publishedAt":43},"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",[155,156,159],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":157,"categoryName":158,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":102,"categoryName":103,"taxonomyType":104,"taxonomyTypeDesc":105},[161,109,162,163,164,165,145,166,167,168,169,170,171,172,173,35,174,38,143,175],"standards","security standards","authentication","auth","pii","top","remediation","dependency","owasp top 10","iam","logs","api","vulnerability","encryption","prompt injection",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":189,"publishedAt":43},"01M719N83RCT50QAV6BPH608WW","product-manager","Product management workflows: write PRDs and spec documents, create user stories with acceptance criteria and T-shirt sizing, plan and prioritize roadmaps by quarter, run competitor and market analysis with live web research, and review Figma designs against PRD requirements for UX consistency. Use this skill whenever the user mentions PRDs, product requirements, user stories, acceptance criteria, story points, roadmaps, feature prioritization, competitor analysis, market research, or reviewing designs against specs — even if they don't explicitly say \"product management.\" Also trigger when the user wants to create Jira-ready tickets, publish specs to Confluence, or audit Figma mockups for missing states.","https:\u002F\u002Fgithub.com\u002Fsandeep-mewara\u002Flifecycle-agent-orchestrator\u002Fblob\u002Fmain\u002Fplugins\u002Flifecycle-agent-orchestrator\u002Fskills\u002Fproduct-management\u002FSKILL.md",[182,183,186],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":184,"categoryName":185,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000031","产品经理",{"categoryNo":187,"categoryName":188,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000032","设计师",[190,191,192,193,194,195,196,197,33,198,24,38,199,200,201,202,203,204,42,205],"manager","Product Manager","product","analysis","audit","plan","prioritization","feature prioritization","publish","workflows","documents","acceptance","states","figma","market analysis","product management workflows"]