[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C0V071YQDRJPCY0KJPNS3A":3,"skill-same:01M6C0V071YQDRJPCY0KJPNS3A":72},{"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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":14,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6C0V071YQDRJPCY0KJPNS3A","create-plan",null,"Create detailed implementation plans through interactive research. Use when the user asks to plan a feature\u002Fepic\u002Frefactor before implementing, or invokes \u002Fcreate-plan with a ticket\u002Fspec.","matheusnorjosa\u002Faprender_sistema","matheusnorjosa","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F117673804?v=4","01M6C0S19FG12BDFBTRWY9TTEQ","Matheus Norjosa","01M6C0S1DF0YB17TKGEYC70GSP",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcreate-plan\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"create","create plan","plan","feature","when","to plan","implementing","path","opus","with","EPIC","ticket","plans","spec","implementation","use","user","interactive","refactor","research","2026-11-10 10:12:30",false,"---\nname: create-plan\ndescription: Create detailed implementation plans through interactive research. Use when the user asks to plan a feature\u002Fepic\u002Frefactor before implementing, or invokes \u002Fcreate-plan with a ticket\u002Fspec.\nargument-hint: \"[optional: ticket #1234 or spec path]\"\nmodel: opus\n---\n\n# Create Plan\n\nYou are tasked with creating detailed implementation plans through an interactive, iterative process. You should be skeptical, thorough, and work collaboratively with the user to produce high-quality technical specifications.\n\n## Initial Response\n\nWhen this command is invoked:\n\n1. **Check if parameters were provided**:\n   - If a file path or ticket reference was provided as a parameter, skip the default message\n   - Immediately read any provided files FULLY\n   - Begin the research process\n\n2. **If no parameters provided**, respond with:\n```\nI'll help you create a detailed implementation plan. Let me start by understanding what we're building.\n\nPlease provide:\n1. The task\u002Fticket description (or reference to a ticket file)\n2. Any relevant context, constraints, or specific requirements\n3. Links to related research or previous implementations\n\nTip: You can also invoke this command with a GitHub issue or spec directly: `\u002Fcreate-plan #1234` or `\u002Fcreate-plan v2\u002Fdocs\u002Fspecs\u002Fbackend\u002Fimports.spec.md`\nFor deeper analysis, try: `\u002Fcreate-plan think deeply about #1234`\n```\n\nThen wait for the user's input.\n\n## Process Steps\n\n### Step 0: Discuss Phase\n\nBefore any research or planning, identify gray areas that need user decisions.\n\n1. **Scan for ambiguity** — Read the task\u002Fticket and identify:\n   - Decisions that affect architecture (which approach? which library?)\n   - UX choices (behavior on edge cases, error states)\n   - Scope boundaries (what's in, what's deliberately out)\n\n2. **Present gray areas** — Show max 5 items:\n```\nBefore I research, I need your input on these decisions:\n\n1. [Decision A] — Option X vs Option Y\n2. [Decision B] — Include or exclude?\n3. [Decision C] — Approach 1 vs Approach 2\n\nWhich would you like to discuss? (or \"skip\" to let me decide)\n```\n\n3. **Capture decisions** — Record each decision in the plan under a `## Decisions` section. Mark user choices explicitly and \"Claude's discretion\" for delegated items.\n\n4. **Scope guardrail** — If the user suggests additions beyond the original scope, flag it:\n```\n\"[Feature X] would be a new capability — that's its own phase\u002Fticket.\nLet's keep this focused on [original scope].\"\n```\n\n### Step 1: Context Gathering & Initial Analysis\n\n1. **Read all mentioned files immediately and FULLY**:\n   - **Primary context source**: living specs in `v2\u002Fdocs\u002Fspecs\u002F` (SDD model, ADR-017) —\n     start at `v2\u002Fdocs\u002Fspecs\u002FINDEX_SDD.md`, then read the relevant spec\n     (`specs\u002Fdomain\u002F`, `specs\u002Fbackend\u002F`, `specs\u002Ffrontend\u002F`, `specs\u002Finfra\u002F`)\n   - Ticket files, research documents, related plans\n   - CONTEXT.md files in relevant directories (services\u002F, dev_tools\u002F), if present\n   - **IMPORTANT**: Use the Read tool WITHOUT limit\u002Foffset parameters\n   - **CRITICAL**: DO NOT spawn sub-tasks before reading these files yourself\n\n2. **Spawn initial research tasks to gather context**:\n   Before asking the user any questions, use specialized agents to research in parallel:\n   - Use `Explore` agents to find related code, patterns, and potential conflicts\n   - Use Context7 MCP to fetch current docs for libraries involved\n   - Check existing tests that cover the area being modified\n\n3. **Present findings** to the user before proceeding to planning\n\n### Step 2: Write the Plan\n\nWrite the plan to `thoughts\u002Fshared\u002Fplans\u002FPLAN-{name}.md`.\nUse the structure and context-rot rules in `reference\u002Fplan-template.md`.\n\n### Step 3: Review & Iteration\n\nPresent the plan to the user. Iterate until approved.\nOn approval, the plan is ready for `\u002Fimplement-plan`.\n\n## AS-Specific Rules\n\n- Always check `aprender-domain` skill for RF\u002FRD\u002FPA\u002FCP compliance\n- Always check `django-patterns` skill for Django\u002FDRF conventions\n- Plans touching availability must reference RD-01~08\n- Plans touching approval must reference PA-01~07\n- Plans must specify which tests to run for verification\n- Plans for epics should use wave-based execution (Wave 1, 2, 3...)\n","# Create Plan\n\nYou are tasked with creating detailed implementation plans through an interactive, iterative process. You should be skeptical, thorough, and work collaboratively with the user to produce high-quality technical specifications.\n\n## Initial Response\n\nWhen this command is invoked:\n\n1. **Check if parameters were provided**:\n   - If a file path or ticket reference was provided as a parameter, skip the default message\n   - Immediately read any provided files FULLY\n   - Begin the research process\n\n2. **If no parameters provided**, respond with:\n```\nI'll help you create a detailed implementation plan. Let me start by understanding what we're building.\n\nPlease provide:\n1. The task\u002Fticket description (or reference to a ticket file)\n2. Any relevant context, constraints, or specific requirements\n3. Links to related research or previous implementations\n\nTip: You can also invoke this command with a GitHub issue or spec directly: `\u002Fcreate-plan #1234` or `\u002Fcreate-plan v2\u002Fdocs\u002Fspecs\u002Fbackend\u002Fimports.spec.md`\nFor deeper analysis, try: `\u002Fcreate-plan think deeply about #1234`\n```\n\nThen wait for the user's input.\n\n## Process Steps\n\n### Step 0: Discuss Phase\n\nBefore any research or planning, identify gray areas that need user decisions.\n\n1. **Scan for ambiguity** — Read the task\u002Fticket and identify:\n   - Decisions that affect architecture (which approach? which library?)\n   - UX choices (behavior on edge cases, error states)\n   - Scope boundaries (what's in, what's deliberately out)\n\n2. **Present gray areas** — Show max 5 items:\n```\nBefore I research, I need your input on these decisions:\n\n1. [Decision A] — Option X vs Option Y\n2. [Decision B] — Include or exclude?\n3. [Decision C] — Approach 1 vs Approach 2\n\nWhich would you like to discuss? (or \"skip\" to let me decide)\n```\n\n3. **Capture decisions** — Record each decision in the plan under a `## Decisions` section. Mark user choices explicitly and \"Claude's discretion\" for delegated items.\n\n4. **Scope guardrail** — If the user suggests additions beyond the original scope, flag it:\n```\n\"[Feature X] would be a new capability — that's its own phase\u002Fticket.\nLet's keep this focused on [original scope].\"\n```\n\n### Step 1: Context Gathering & Initial Analysis\n\n1. **Read all mentioned files immediately and FULLY**:\n   - **Primary context source**: living specs in `v2\u002Fdocs\u002Fspecs\u002F` (SDD model, ADR-017) —\n     start at `v2\u002Fdocs\u002Fspecs\u002FINDEX_SDD.md`, then read the relevant spec\n     (`specs\u002Fdomain\u002F`, `specs\u002Fbackend\u002F`, `specs\u002Ffrontend\u002F`, `specs\u002Finfra\u002F`)\n   - Ticket files, research documents, related plans\n   - CONTEXT.md files in relevant directories (services\u002F, dev_tools\u002F), if present\n   - **IMPORTANT**: Use the Read tool WITHOUT limit\u002Foffset parameters\n   - **CRITICAL**: DO NOT spawn sub-tasks before reading these files yourself\n\n2. **Spawn initial research tasks to gather context**:\n   Before asking the user any questions, use specialized agents to research in parallel:\n   - Use `Explore` agents to find related code, patterns, and potential conflicts\n   - Use Context7 MCP to fetch current docs for libraries involved\n   - Check existing tests that cover the area being modified\n\n3. **Present findings** to the user before proceeding to planning\n\n### Step 2: Write the Plan\n\nWrite the plan to `thoughts\u002Fshared\u002Fplans\u002FPLAN-{name}.md`.\nUse the structure and context-rot rules in `reference\u002Fplan-template.md`.\n\n### Step 3: Review & Iteration\n\nPresent the plan to the user. Iterate until approved.\nOn approval, the plan is ready for `\u002Fimplement-plan`.\n\n## AS-Specific Rules\n\n- Always check `aprender-domain` skill for RF\u002FRD\u002FPA\u002FCP compliance\n- Always check `django-patterns` skill for Django\u002FDRF conventions\n- Plans touching availability must reference RD-01~08\n- Plans touching approval must reference PA-01~07\n- Plans must specify which tests to run for verification\n- Plans for epics should use wave-based execution (Wave 1, 2, 3...)\n",{"name":5,"model":27,"description":7,"argument-hint":44},"[optional: ticket #1234 or spec path]","main","9e3a882d83e0853bdc570ae9d89c02d2a53bed82",".claude\u002Fskills\u002Fcreate-plan","https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema","https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa","Dev Python | IA | Automation | HTML | CSS | Data | Process | Projects","2026-11-11 08:34:26",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add matheusnorjosa\u002Faprender_sistema --skill create-plan",{"tool":58,"command":59},"bunx","bunx skills add matheusnorjosa\u002Faprender_sistema --skill create-plan",{"tool":61,"command":62},"pnpm","pnpm dlx skills add matheusnorjosa\u002Faprender_sistema --skill create-plan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcreate-plan\u002FSKILL.md",true,[66],{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"reference\u002Fplan-template.md","REFERENCE","参考文档",1161,"https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcreate-plan\u002Freference\u002Fplan-template.md",[73,111,132,153,165,196],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":89,"publishedAt":39},"01M6C0WHSP7S2QMJGGMQRXJ6PD","writing-standards","Apply AS v2 technical-writing standards (clarity, brevity, active voice, Python\u002FDjango conventions). Use when writing a README, a docstring (PEP 257), a commit message, a PR description, an error message, or any technical doc.","https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwriting-standards\u002FSKILL.md",[79,84],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,23],"writing","writing standards","standards","python","commit","pr","pr description","commit message","doc","voice","clarity","django","technical","README","message","active","as","error","technical-writing","brevity","docstring",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":39},"01M6C0WG2SBP9PJG1YQFGGVJAR","verification-gate","Verify before claiming success. Use when about to say something works\u002Fis done, after implementing a feature, after a bugfix, or before pushing — run the proof command and confirm output first.","https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fverification-gate\u002FSKILL.md",[],[118,119,120,121,122,123,124,34,125,126,127,22,128,129,130,131,25,23],"verification","verification gate","gate","run","first","verify","command","verify before claiming","say","done","proof","bugfix","output","about",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":141,"publishedAt":39},"01M6C0WE010G12KH45YZW6M7K5","test-driven-development","Write the failing test before the implementation in AS v2 (pytest + Django\u002FDRF). Use when implementing a feature or fixing a bug, before any production code is written.","https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftest-driven-development\u002FSKILL.md",[138],{"categoryNo":139,"categoryName":140,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000008","测试与质量",[142,143,144,145,146,147,101,148,34,149,33,150,22,106,151,25,23,152],"test","test driven development","development","driven","code","Production","write","bug","pytest","drf","failing",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":39},"01M6C0WC6Y81XRVBJQSTKA96XQ","subagent-development","Orquestra subagents no AS v2 — decompõe a tarefa em domínios independentes, paraleliza e revisa em 2 estágios. Use ao delegar exploração, implementação ou validação cross-arquivo para acelerar o trabalho e poupar o contexto principal.","https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsubagent-development\u002FSKILL.md",[],[144,160,161,162,163,34,164,106],"subagent","subagent development","para","subagents","ao",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":39},"01M6C0W9W8D6JJWXW28Q7ZHAC9","security-scan","Automated security scanning for AS v2. Use before commits or when reviewing changes for vulnerabilities. Runs dependency audit (pip-audit, npm audit), secret detection (grep patterns), and code pattern scanning (SQL injection, XSS, eval, pickle, hardcoded secrets). Integrates with project hooks system.","https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsecurity-scan\u002FSKILL.md",[],[172,173,174,175,176,146,177,178,179,180,181,182,183,184,185,186,187,188,34,189,190,191,106,28,192,193,194,195,23],"security","security scan","scan","vulnerabilities","sql","npm","audit","dependency audit","detection","injection","xss","secrets","pip-audit","commits","system","grep","eval","hooks","security scanning","project","true","pip","for","changes",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":205,"publishedAt":39},"01M6C0W7RE3G3C2852YXQKR5J9","resume-handoff","Resume work from a saved handoff document, validating its state against the current codebase before continuing. Use when resuming work from a saved handoff after a context clear or in a new session (path, session name, or GitHub issue).","https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fresume-handoff\u002FSKILL.md",[202],{"categoryNo":203,"categoryName":204,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000038","人力资源",[206,207,208,209,210,211,212,213,214,34,215,216,217,218,219,220,221,222,23,223],"handoff","resume handoff","resume","github","state","new session","work","context","session","github issue","issue","document","clear","name","saved","codebase","resuming","new"]