[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69B4AVTPFEJ7GJM8P2714ZT":3,"skill-same:01M69B4AVTPFEJ7GJM8P2714ZT":61},{"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":27,"linkOnly":28,"markdownContent":29,"markdownBody":30,"frontMatter":31,"refName":32,"commitSha":33,"skillDirectory":34,"forksCount":35,"repositoryHtmlUrl":36,"repositoryHomepageUrl":6,"ownerHtmlUrl":37,"ownerBlogUrl":38,"ownerDescription":39,"updatedAt":40,"install":41,"resources":54},"01M69B4AVTPFEJ7GJM8P2714ZT","feature-inventory",null,"Catalogs existing features from a codebase (API endpoints, user flows, UI screens, observable behaviors) and generates structured feature specs with REQ-XXX IDs, user scenarios, and success criteria.\nTriggers: \"inventory features\", \"catalog existing functionality\", \"list what the app does\", \"extract requirements from code\", \"generate feature specs from research\", \"write a spec\", \"create feature specification\", \"define requirements\".\nNOT for: implementation planning (use creating-implementation-plan), implementation (use implementing-code).","microsoft\u002Fgithub-copilot-modernization","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69B2DAY0HTBHWQN4WF3JDBQ",55,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fgithub-copilot-modernization\u002Fblob\u002Fmain\u002Fplugins\u002Fgithub-copilot-modernization\u002Fskills\u002Ffeature-inventory\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[24,25,26],"feature inventory","spec","research","2026-11-10 10:12:30",false,"---\nname: feature-inventory\ndescription: |\n  Catalogs existing features from a codebase (API endpoints, user flows, UI screens, observable behaviors) and generates structured feature specs with REQ-XXX IDs, user scenarios, and success criteria.\n  Triggers: \"inventory features\", \"catalog existing functionality\", \"list what the app does\", \"extract requirements from code\", \"generate feature specs from research\", \"write a spec\", \"create feature specification\", \"define requirements\".\n  NOT for: implementation planning (use creating-implementation-plan), implementation (use implementing-code).\n---\n\n\n## User Input\n\nYou **MUST** consider the user input before proceeding (if not empty).\n\nThe text in the task description **is** the feature description. Assume you always have it available. Do not ask the user to repeat it unless they provided an empty command.\n\n## Outline\n\nGiven that feature description, do this:\n\n## Output\n\nAll outputs are written under your task's `Artifact path:` (from task metadata).\n\n```\nspec.md                     ← main artifact (feature specification)\nrequirements-checklist.md   ← quality checklist (if applicable)\n```\n\n## Workflow\n\n1. Load constitution document (if available) to understand principles and constraints.\n\n2. **Load `clarification.md` if it exists** (`{{BASE_PATH}}\u002Fclarification.md` or path from `dependencyArtifacts`). Treat every field that has an explicit value (i.e., `resolution: user` or `resolution: default`) as **already resolved** — do NOT re-ask the user about it and do NOT count it against the `[NEEDS CLARIFICATION]` budget below. Items listed under `blocking_gaps` should be treated as known risks but still do not count against the budget (they are surfaced separately by the coordinator).\n\n3. Read `knowledge-graph.json` (and, if needed, the query guidance in `skills\u002Fbuilding-java-knowledge-graph\u002FSKILL.md`) to understand the architecture and dependencies related to this feature. Also check for research files if available.\n\n4. Load `skills\u002Fwriting-feature-spec\u002Ftemplates\u002Fspec-template.md` for required sections.\n\n5. Execute:\n    1. Parse feature description from task\n       If empty: ERROR \"No feature description provided\"\n    2. Extract key concepts: actors, actions, data, constraints\n    3. **Assign unique requirement IDs** (CRITICAL for traceability):\n       - Format: `REQ-XXX` where XXX is a 3-digit sequence number (001, 002, ...)\n       - Example: `REQ-001`, `REQ-002`, `REQ-003`\n       - Each requirement MUST have unique ID across entire feature\n    4. For unclear aspects:\n       - Make informed guesses based on context and industry standards\n       - **Items already answered in `clarification.md` are NOT unclear** — use the user's answer (or the recorded default) and do not mark them.\n       - Only mark with [NEEDS CLARIFICATION: specific question] if:\n         - The choice significantly impacts feature scope or user experience\n         - Multiple reasonable interpretations exist with different implications\n         - No reasonable default exists\n       - **LIMIT: Maximum 3 [NEEDS CLARIFICATION] markers total**\n       - Prioritize clarifications by impact: scope > security\u002Fprivacy > user experience > technical details\n    5. Fill User Scenarios & Testing section\n       If no clear user flow: ERROR \"Cannot determine user scenarios\"\n    6. Generate Functional Requirements\n       Each requirement must be testable\n       Use reasonable defaults for unspecified details (document assumptions in Assumptions section)\n    7. Define Success Criteria\n       Create measurable, technology-agnostic outcomes\n       Include both quantitative metrics (time, performance, volume) and qualitative measures (user satisfaction, task completion)\n       Each criterion must be verifiable without implementation details\n    8. Identify Key Entities (if data involved)\n    9. Return: SUCCESS (spec ready for planning)\n\n6. Write the specification to the assigned artifact path using the template structure, replacing placeholders with concrete details derived from the feature description while preserving section order and headings.\n\n7. Report completion with spec file path, checklist results, and readiness for the next phase.\n\n## Research-Driven Mode\n\nWhen pre-built research files are available (provided by a design\u002Fexplore phase), use this alternate workflow instead of reading source code directly:\n\n### ⚠️ NO Direct Codebase Exploration\nWhen research files exist, do NOT read project source files directly (source code, build files, config files). All codebase analysis is already in the research files.\n\n### Research File Inputs\n\nLook for these files in the current working directory or as referenced in the task:\n- `project-structure.md` — functional domain list (REQUIRED)\n- `tech-stack.md` — technology inventory (REQUIRED)\n- `data-model.md` — key entities summary (optional)\n- `architecture-summary.md` — substitute for direct knowledge graph reading (optional)\n- Any additional `*.md` research files (optional)\n\n### Domain-Driven Generation\nUse the functional domain list from `project-structure.md` to drive:\n- **User Scenarios**: For each domain, generate 1–3 user stories (P1\u002FP2\u002FP3, Given-When-Then)\n- **Requirements**: For each domain, generate 2–4 REQ-XXX items referencing constitution principles\n- **Key Entities**: Use entities from `data-model.md` directly (top 6–8)\n\n### Incremental Section Writing\nWrite the spec **section by section**, appending each to the assigned artifact before moving to the next:\n1. Header + Scope Baseline → create\u002Fwrite artifact\n2. User Scenarios & Testing → append\n3. Requirements (Functional per domain + Non-Functional) → append\n4. Success Criteria → append\n\n### Checklist Generation\nAfter spec is complete, append a quality checklist section at the end of the artifact:\n# Requirements Quality Checklist\n\n## Requirement ID Coverage\n- [ ] All requirements use REQ-XXX format\n- [ ] IDs are unique and sequential\n\n## Testability\n- [ ] Every requirement is independently testable\n- [ ] Acceptance criteria are concrete (Given-When-Then)\n\n## Completeness\n- [ ] Scope Baseline section complete\n- [ ] User Scenarios prioritized (P1, P2, P3)\n- [ ] Functional requirements cover all in-scope items\n- [ ] Success criteria are measurable\n\n## Constitution Alignment\n- [ ] All constitution principles referenced\n- [ ] Migration mode constraints respected\n\n---\n\n## General Guidelines\n\n- Focus on **WHAT** users need and **WHY**.\n- Avoid HOW to implement (no tech stack, APIs, code structure).\n- Written for business stakeholders, not developers.\n- DO NOT create any checklists that are embedded in the spec. That will be a separate command.\n\n### Section Requirements\n\n- **Mandatory sections**: Must be completed for every feature\n- **Optional sections**: Include only when relevant to the feature\n- When a section doesn't apply, remove it entirely (don't leave as \"N\u002FA\")\n\n### For AI Generation\n\nWhen creating this spec from a user prompt:\n\n1. **Make informed guesses**: Use context, industry standards, and common patterns to fill gaps\n2. **Document assumptions**: Record reasonable defaults in the Assumptions section\n3. **Limit clarifications**: Maximum 3 [NEEDS CLARIFICATION] markers - use only for critical decisions that:\n   - Significantly impact feature scope or user experience\n   - Have multiple reasonable interpretations with different implications\n   - Lack any reasonable default\n4. **Prioritize clarifications**: scope > security\u002Fprivacy > user experience > technical details\n5. **Think like a tester**: Every vague requirement should fail the \"testable and unambiguous\" checklist item\n6. **Common areas needing clarification** (only if no reasonable default exists):\n   - Feature scope and boundaries (include\u002Fexclude specific use cases)\n   - User types and permissions (if multiple conflicting interpretations possible)\n   - Security\u002Fcompliance requirements (when legally\u002Ffinancially significant)\n\n**Examples of reasonable defaults** (don't ask about these):\n\n- Data retention: Industry-standard practices for the domain\n- Performance targets: Standard web\u002Fmobile app expectations unless specified\n- Error handling: User-friendly messages with appropriate fallbacks\n- Authentication method: Standard session-based or OAuth2 for web apps\n- Integration patterns: RESTful APIs unless specified otherwise\n\n### Success Criteria Guidelines\n\nSuccess criteria must be:\n\n1. **Measurable**: Include specific metrics (time, percentage, count, rate)\n2. **Technology-agnostic**: No mention of frameworks, languages, databases, or tools\n3. **User-focused**: Describe outcomes from user\u002Fbusiness perspective, not system internals\n4. **Verifiable**: Can be tested\u002Fvalidated without knowing implementation details\n\n**Good examples**:\n\n- \"Users can complete checkout in under 3 minutes\"\n- \"System supports 10,000 concurrent users\"\n- \"95% of searches return results in under 1 second\"\n- \"Task completion rate improves by 40%\"\n\n**Bad examples** (implementation-focused):\n\n- \"API response time is under 200ms\" (too technical, use \"Users see results instantly\")\n- \"Database can handle 1000 TPS\" (implementation detail, use user-facing metric)\n- \"React components render efficiently\" (framework-specific)\n- \"Redis cache hit rate above 80%\" (technology-specific)\n\n## Resources\n\n### Templates\n- `templates\u002Fspec-template.md` — Specification document template with all mandatory sections\n","## User Input\n\nYou **MUST** consider the user input before proceeding (if not empty).\n\nThe text in the task description **is** the feature description. Assume you always have it available. Do not ask the user to repeat it unless they provided an empty command.\n\n## Outline\n\nGiven that feature description, do this:\n\n## Output\n\nAll outputs are written under your task's `Artifact path:` (from task metadata).\n\n```\nspec.md                     ← main artifact (feature specification)\nrequirements-checklist.md   ← quality checklist (if applicable)\n```\n\n## Workflow\n\n1. Load constitution document (if available) to understand principles and constraints.\n\n2. **Load `clarification.md` if it exists** (`{{BASE_PATH}}\u002Fclarification.md` or path from `dependencyArtifacts`). Treat every field that has an explicit value (i.e., `resolution: user` or `resolution: default`) as **already resolved** — do NOT re-ask the user about it and do NOT count it against the `[NEEDS CLARIFICATION]` budget below. Items listed under `blocking_gaps` should be treated as known risks but still do not count against the budget (they are surfaced separately by the coordinator).\n\n3. Read `knowledge-graph.json` (and, if needed, the query guidance in `skills\u002Fbuilding-java-knowledge-graph\u002FSKILL.md`) to understand the architecture and dependencies related to this feature. Also check for research files if available.\n\n4. Load `skills\u002Fwriting-feature-spec\u002Ftemplates\u002Fspec-template.md` for required sections.\n\n5. Execute:\n    1. Parse feature description from task\n       If empty: ERROR \"No feature description provided\"\n    2. Extract key concepts: actors, actions, data, constraints\n    3. **Assign unique requirement IDs** (CRITICAL for traceability):\n       - Format: `REQ-XXX` where XXX is a 3-digit sequence number (001, 002, ...)\n       - Example: `REQ-001`, `REQ-002`, `REQ-003`\n       - Each requirement MUST have unique ID across entire feature\n    4. For unclear aspects:\n       - Make informed guesses based on context and industry standards\n       - **Items already answered in `clarification.md` are NOT unclear** — use the user's answer (or the recorded default) and do not mark them.\n       - Only mark with [NEEDS CLARIFICATION: specific question] if:\n         - The choice significantly impacts feature scope or user experience\n         - Multiple reasonable interpretations exist with different implications\n         - No reasonable default exists\n       - **LIMIT: Maximum 3 [NEEDS CLARIFICATION] markers total**\n       - Prioritize clarifications by impact: scope > security\u002Fprivacy > user experience > technical details\n    5. Fill User Scenarios & Testing section\n       If no clear user flow: ERROR \"Cannot determine user scenarios\"\n    6. Generate Functional Requirements\n       Each requirement must be testable\n       Use reasonable defaults for unspecified details (document assumptions in Assumptions section)\n    7. Define Success Criteria\n       Create measurable, technology-agnostic outcomes\n       Include both quantitative metrics (time, performance, volume) and qualitative measures (user satisfaction, task completion)\n       Each criterion must be verifiable without implementation details\n    8. Identify Key Entities (if data involved)\n    9. Return: SUCCESS (spec ready for planning)\n\n6. Write the specification to the assigned artifact path using the template structure, replacing placeholders with concrete details derived from the feature description while preserving section order and headings.\n\n7. Report completion with spec file path, checklist results, and readiness for the next phase.\n\n## Research-Driven Mode\n\nWhen pre-built research files are available (provided by a design\u002Fexplore phase), use this alternate workflow instead of reading source code directly:\n\n### ⚠️ NO Direct Codebase Exploration\nWhen research files exist, do NOT read project source files directly (source code, build files, config files). All codebase analysis is already in the research files.\n\n### Research File Inputs\n\nLook for these files in the current working directory or as referenced in the task:\n- `project-structure.md` — functional domain list (REQUIRED)\n- `tech-stack.md` — technology inventory (REQUIRED)\n- `data-model.md` — key entities summary (optional)\n- `architecture-summary.md` — substitute for direct knowledge graph reading (optional)\n- Any additional `*.md` research files (optional)\n\n### Domain-Driven Generation\nUse the functional domain list from `project-structure.md` to drive:\n- **User Scenarios**: For each domain, generate 1–3 user stories (P1\u002FP2\u002FP3, Given-When-Then)\n- **Requirements**: For each domain, generate 2–4 REQ-XXX items referencing constitution principles\n- **Key Entities**: Use entities from `data-model.md` directly (top 6–8)\n\n### Incremental Section Writing\nWrite the spec **section by section**, appending each to the assigned artifact before moving to the next:\n1. Header + Scope Baseline → create\u002Fwrite artifact\n2. User Scenarios & Testing → append\n3. Requirements (Functional per domain + Non-Functional) → append\n4. Success Criteria → append\n\n### Checklist Generation\nAfter spec is complete, append a quality checklist section at the end of the artifact:\n# Requirements Quality Checklist\n\n## Requirement ID Coverage\n- [ ] All requirements use REQ-XXX format\n- [ ] IDs are unique and sequential\n\n## Testability\n- [ ] Every requirement is independently testable\n- [ ] Acceptance criteria are concrete (Given-When-Then)\n\n## Completeness\n- [ ] Scope Baseline section complete\n- [ ] User Scenarios prioritized (P1, P2, P3)\n- [ ] Functional requirements cover all in-scope items\n- [ ] Success criteria are measurable\n\n## Constitution Alignment\n- [ ] All constitution principles referenced\n- [ ] Migration mode constraints respected\n\n---\n\n## General Guidelines\n\n- Focus on **WHAT** users need and **WHY**.\n- Avoid HOW to implement (no tech stack, APIs, code structure).\n- Written for business stakeholders, not developers.\n- DO NOT create any checklists that are embedded in the spec. That will be a separate command.\n\n### Section Requirements\n\n- **Mandatory sections**: Must be completed for every feature\n- **Optional sections**: Include only when relevant to the feature\n- When a section doesn't apply, remove it entirely (don't leave as \"N\u002FA\")\n\n### For AI Generation\n\nWhen creating this spec from a user prompt:\n\n1. **Make informed guesses**: Use context, industry standards, and common patterns to fill gaps\n2. **Document assumptions**: Record reasonable defaults in the Assumptions section\n3. **Limit clarifications**: Maximum 3 [NEEDS CLARIFICATION] markers - use only for critical decisions that:\n   - Significantly impact feature scope or user experience\n   - Have multiple reasonable interpretations with different implications\n   - Lack any reasonable default\n4. **Prioritize clarifications**: scope > security\u002Fprivacy > user experience > technical details\n5. **Think like a tester**: Every vague requirement should fail the \"testable and unambiguous\" checklist item\n6. **Common areas needing clarification** (only if no reasonable default exists):\n   - Feature scope and boundaries (include\u002Fexclude specific use cases)\n   - User types and permissions (if multiple conflicting interpretations possible)\n   - Security\u002Fcompliance requirements (when legally\u002Ffinancially significant)\n\n**Examples of reasonable defaults** (don't ask about these):\n\n- Data retention: Industry-standard practices for the domain\n- Performance targets: Standard web\u002Fmobile app expectations unless specified\n- Error handling: User-friendly messages with appropriate fallbacks\n- Authentication method: Standard session-based or OAuth2 for web apps\n- Integration patterns: RESTful APIs unless specified otherwise\n\n### Success Criteria Guidelines\n\nSuccess criteria must be:\n\n1. **Measurable**: Include specific metrics (time, percentage, count, rate)\n2. **Technology-agnostic**: No mention of frameworks, languages, databases, or tools\n3. **User-focused**: Describe outcomes from user\u002Fbusiness perspective, not system internals\n4. **Verifiable**: Can be tested\u002Fvalidated without knowing implementation details\n\n**Good examples**:\n\n- \"Users can complete checkout in under 3 minutes\"\n- \"System supports 10,000 concurrent users\"\n- \"95% of searches return results in under 1 second\"\n- \"Task completion rate improves by 40%\"\n\n**Bad examples** (implementation-focused):\n\n- \"API response time is under 200ms\" (too technical, use \"Users see results instantly\")\n- \"Database can handle 1000 TPS\" (implementation detail, use user-facing metric)\n- \"React components render efficiently\" (framework-specific)\n- \"Redis cache hit rate above 80%\" (technology-specific)\n\n## Resources\n\n### Templates\n- `templates\u002Fspec-template.md` — Specification document template with all mandatory sections\n",{"name":5,"description":7},"main","a9c9469d86e9dc078018e8fb391abc7744088078","plugins\u002Fgithub-copilot-modernization\u002Fskills\u002Ffeature-inventory",15,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fgithub-copilot-modernization","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-09-24 00:17:59",{"source":8,"skillName":5,"commands":42,"prompt":52,"zipAvailable":53},[43,46,49],{"tool":44,"command":45},"npx","npx skills add microsoft\u002Fgithub-copilot-modernization --skill feature-inventory",{"tool":47,"command":48},"bunx","bunx skills add microsoft\u002Fgithub-copilot-modernization --skill feature-inventory",{"tool":50,"command":51},"pnpm","pnpm dlx skills add microsoft\u002Fgithub-copilot-modernization --skill feature-inventory","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fgithub-copilot-modernization\u002Fblob\u002Fmain\u002Fplugins\u002Fgithub-copilot-modernization\u002Fskills\u002Ffeature-inventory\u002FSKILL.md",true,[55],{"path":56,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":59,"sourceHtmlUrl":60},"templates\u002Fspec-template.md","REFERENCE","参考文档",4265,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fgithub-copilot-modernization\u002Fblob\u002Fmain\u002Fplugins\u002Fgithub-copilot-modernization\u002Fskills\u002Ffeature-inventory\u002Ftemplates\u002Fspec-template.md",[62,74,83,92,101,109],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":71,"publishedAt":27},"01M69B5DBRA354JMQRZP3D1X3X","verify-test-baseline","Generate and run post-migration tests from the frozen baseline specification.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fgithub-copilot-modernization\u002Fblob\u002Fmain\u002Fplugins\u002Fgithub-copilot-modernization\u002Fskills\u002Fverify-test-baseline\u002FSKILL.md",[68],{"categoryNo":69,"categoryName":70,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[72,73],"test","verify test baseline",{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":27},"01M69B5BJWPCN41J5ZAR2XFMBR","team-request","How team members request infrastructure connection info and handle secrets in team mode","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fgithub-copilot-modernization\u002Fblob\u002Fmain\u002Fplugins\u002Fgithub-copilot-modernization\u002Fskills\u002Fteam-request\u002FSKILL.md",[],[81,82],"team request","infrastructure",{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":27},"01M69B58TZ7SNTPB6C508M5HWX","team-charters","Provides role charters (mission, ownership, core principles, quality bar) for a multi-agent coding team. Each charter defines the role's mission, ownership scope, core principle (boundary constraints), and quality bar. Most roles also include communication rules. Consumed by the coordinator during task decomposition to assign work to the correct role.\nTriggers: \"look up role charter\", \"what does the architect own\", \"check role boundaries\", \"find team roles\", \"which role handles X\", \"list agent charters\", \"role responsibilities\".\nNOT for: task decomposition (use breaking-down-tasks), implementation (use implementing-code), architecture analysis (use analyzing-architecture).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fgithub-copilot-modernization\u002Fblob\u002Fmain\u002Fplugins\u002Fgithub-copilot-modernization\u002Fskills\u002Fteam-charters\u002FSKILL.md",[],[90,91],"team charters","architecture",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":27},"01M69B56JVPKCS2WWVSCZXHEZJ","struts-to-spring","Migration guideline for transforming Apache Struts 2 applications to Spring Boot 3.x and Spring MVC.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fgithub-copilot-modernization\u002Fblob\u002Fmain\u002Fplugins\u002Fgithub-copilot-modernization\u002Fskills\u002Fstruts-to-spring\u002FSKILL.md",[],[99,100],"struts to spring","boot",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":27},"01M69B54QQ6K8SDZ8MJYEKBYHJ","spring-boot-scaffolding","Reference guide for creating a new Spring Boot project during rewrite migration.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fgithub-copilot-modernization\u002Fblob\u002Fmain\u002Fplugins\u002Fgithub-copilot-modernization\u002Fskills\u002Fspring-boot-scaffolding\u002FSKILL.md",[],[100,108],"spring boot scaffolding",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":27},"01M69B52T5G9CZWHYXWP22WEKY","sharing-learnings","How to record project learnings so that later-phase workers and future agent runs can consume them.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fgithub-copilot-modernization\u002Fblob\u002Fmain\u002Fplugins\u002Fgithub-copilot-modernization\u002Fskills\u002Fsharing-learnings\u002FSKILL.md",[],[116],"sharing learnings"]