[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71F9WP4BAV5CMHCRC5FWR97":3,"skill-same:01M71F9WP4BAV5CMHCRC5FWR97":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":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":74},"01M71F9WP4BAV5CMHCRC5FWR97","jira-ticket",null,"Use when creating a Jira ticket — the user types \u002Fjira-ticket, asks to \"open a ticket\", \"file a bug\", \"create an issue\", or asks you to record work in Jira. The Jira project comes from `--project` \u002F `$AIPLAYBOOK_JIRA_PROJECT`. Builds the ticket from the canonical template, fills what it can infer from the session, and refuses to emit one that misses a required section. Pairs with the jira-ticket-standard rule, which blocks the raw MCP call.","Wizarck\u002Fai-playbook","Wizarck","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F23051550?v=4","01M71B3AAVR67GRWFV5ZXXZP31","arturo6ramirez","01M71F5FHXDSX3G2F52R1YS77J",6,"MIT","https:\u002F\u002Fgithub.com\u002FWizarck\u002Fai-playbook\u002Fblob\u002Fmain\u002Fskills\u002Fjira-ticket\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],"jira","jira ticket","ticket","with","can","standard","one","file","you","when","use","MCP","open","call","session","section","project","infer","types","which","2026-11-10 10:12:30",false,"---\nname: jira-ticket\ndescription: Use when creating a Jira ticket — the user types \u002Fjira-ticket, asks to \"open a ticket\", \"file a bug\", \"create an issue\", or asks you to record work in Jira. The Jira project comes from `--project` \u002F `$AIPLAYBOOK_JIRA_PROJECT`. Builds the ticket from the canonical template, fills what it can infer from the session, and refuses to emit one that misses a required section. Pairs with the jira-ticket-standard rule, which blocks the raw MCP call.\nlicense: MIT\nmetadata:\n  author: ai-playbook\n  version: \"1.0\"\n---\n\n# jira-ticket — author a ticket that survives contact with the backlog\n\nYou are filling in a form whose contract is machine-checked. The contract is\n`specs\u002Fjira-ticket-standard.yaml`; the human face of it is\n`templates\u002Fjira-ticket.md.tmpl`; the canonical worked example is\n`tests\u002Ffixtures\u002Fjira_ticket_example.md`.\n\n**Draft first, then submit.** The PreToolUse hook will reject a non-conformant\n`createJiraIssue` call, and a rejected call costs a round trip. Assemble the\nwhole description, check it against the checklist below, and only then call the\nMCP tool.\n\n## Your job is to fill it in, not to hand over a blank form\n\nA skill that only refuses is a linter, and if using it is slower than calling\nthe MCP tool directly, nobody uses it. So do the work:\n\n- **Infer `Contexto \u002F Problema` from the session.** You almost always know why\n  this ticket exists — you just hit the bug, or read the code, or measured the\n  thing. Cite the evidence you already have: `file.py:line`, a measurement, a\n  failing test, the commit that introduced it.\n- **Infer `Alcance \u002F Entregables`** from what was actually discussed. Name real\n  paths.\n- **Propose the metric and its type**, then say which you chose and why in one\n  line. Users correct a proposal far more readily than they fill a blank.\n- **Only leave `\u003C\u003C...>>` where you genuinely cannot know** — and then ask, in one\n  question, for exactly those. Never submit with a sentinel still in place; the\n  validator rejects it, by design.\n\n## The required shape\n\nRead `templates\u002Fjira-ticket.md.tmpl` for the skeletons. In short:\n\n| Issue type | Sections |\n|---|---|\n| Feature \u002F Big Improvement · Small Improvement | Contexto \u002F Problema · Alcance \u002F Entregables · Plan de prueba (A\u002FB\u002FC) · Métricas |\n| Bug | Contexto \u002F Problema · Repro · Esperado vs Actual · Test de regresión · Métricas |\n| Subtask · Epic | Contexto \u002F Problema · Alcance \u002F Entregables |\n\nHeadings are Spanish, matched case- and accent-insensitively, tolerant of a `2.`\nprefix and a trailing `(parenthetical)`.\n\n**The five metric types, and nothing else:**\n\n- `cobertura \u002F compliance` — what fraction of X satisfies Y\n- `calidad \u002F exactitud` — how often the thing is RIGHT; false positives, accuracy\n- `tendencia \u002F burn-down` — a count moving over time, in the direction you claimed\n- `rendimiento \u002F eficiencia` — time, throughput, resource use\n- `coste` — money, tokens, CI minutes\n\nEach metric line reads `- \u003Cwhat you measure> → \u003Ctype>`.\n\n## Your failure mode is plausibility\n\nThe validator checks shape. You are the only thing checking *substance*, and the\ncharacteristic way this goes wrong is that every section is present, well\nwritten, and says nothing. Four specific traps, each observed:\n\n1. **A metric with no measurement behind it.** \"Mejora de la calidad del código →\n   calidad \u002F exactitud\" names a type and measures nothing. Ask: *who runs what\n   command, and what number comes out?* If there is no answer, the honest move is\n   `N\u002FA — \u003Cpor qué>` for that section, which is allowed and counted.\n\n2. **A B that is not a negative control.** \"Comprobar que falla\" is a wish. B must\n   name the **exact assertion you invert** and the error you expect —\n   \"quito la sección `## Métricas` del payload y el hook devuelve `deny` con\n   `missing-section`\". A test plan whose A passes proves only that you did not\n   test; B is the half that proves the gate bites. Boilerplate phrasings are\n   rejected by name in the contract, so writing one costs you a round trip.\n\n3. **A C that names nothing.** \"No romper nada\" is not a regression test. Name a\n   path or an id — `tests\u002Ftest_jira_ticket_standard.py` — or write\n   `ninguno aún — \u003Cpor qué>` and mean it.\n\n4. **Header stuffing.** Every heading present, every body \"TBD\"\u002F\"pendiente\".\n   This is the failure the whole standard exists to catch. If you find yourself\n   writing filler to satisfy a section, that is the signal to use the escape\n   hatch honestly instead.\n\n## The escape hatch\n\n`N\u002FA — \u003Crazón>` is valid **per section**, never for a whole ticket. Its usage\nrate is reported by `check`. A high rate is information about the template, not\nan infraction — but a reason that says \"no aplica\" is not a reason.\n\n## Before you call the MCP tool\n\n- Every required section present, with real content.\n- No `\u003C\u003C...>>` left anywhere.\n- Every metric line parses as `- \u003Cmétrica> → \u003Ctipo>`, type from the five.\n- B names the assertion that flips. C names a test or admits none, with a reason.\n- Epic parent set (`parent`) and labels chosen.\n\nThen call `createJiraIssue`. If the hook blocks you, it returns every problem at\nonce — fix them all in one pass rather than resubmitting per finding.\n\n## Checking existing tickets\n\n```\npython .ai-playbook\u002Fscripts\u002Frules\u002Fjira-ticket-standard.rule.py explain \u003CKEY>\npython .ai-playbook\u002Fscripts\u002Frules\u002Fjira-ticket-standard.rule.py check --since 2026-08-02\n```\n\n`explain` shows the match section by section — use it when a rejection surprises\nyou, because the answer is usually a heading the resolver did not recognise\nrather than a section you forgot.\n\n## When NOT to fire\n\n- **Tracker stubs from `issue_sync`.** Those carry `ai-playbook-managed` and are\n  exempt: their content of record is the OpenSpec proposal, and duplicating an\n  A\u002FB\u002FC into the stub creates a second copy that drifts from the first.\n- **Editing a ticket's fields other than the description** — nothing to validate.\n- **Other Jira projects.** The contract applies only to the Jira project set by\n  `--project` \u002F `$AIPLAYBOOK_JIRA_PROJECT`.\n\n## See also\n\n- `specs\u002Fjira-ticket-standard.yaml` — the contract, including the closed list.\n- `docs\u002Frules\u002Fjira-ticket-standard.rule.md` — the binding rule and the enforcement\n  topology, including what it deliberately cannot cover.\n- `templates\u002Fjira-ticket.md.tmpl` — the skeletons.\n","# jira-ticket — author a ticket that survives contact with the backlog\n\nYou are filling in a form whose contract is machine-checked. The contract is\n`specs\u002Fjira-ticket-standard.yaml`; the human face of it is\n`templates\u002Fjira-ticket.md.tmpl`; the canonical worked example is\n`tests\u002Ffixtures\u002Fjira_ticket_example.md`.\n\n**Draft first, then submit.** The PreToolUse hook will reject a non-conformant\n`createJiraIssue` call, and a rejected call costs a round trip. Assemble the\nwhole description, check it against the checklist below, and only then call the\nMCP tool.\n\n## Your job is to fill it in, not to hand over a blank form\n\nA skill that only refuses is a linter, and if using it is slower than calling\nthe MCP tool directly, nobody uses it. So do the work:\n\n- **Infer `Contexto \u002F Problema` from the session.** You almost always know why\n  this ticket exists — you just hit the bug, or read the code, or measured the\n  thing. Cite the evidence you already have: `file.py:line`, a measurement, a\n  failing test, the commit that introduced it.\n- **Infer `Alcance \u002F Entregables`** from what was actually discussed. Name real\n  paths.\n- **Propose the metric and its type**, then say which you chose and why in one\n  line. Users correct a proposal far more readily than they fill a blank.\n- **Only leave `\u003C\u003C...>>` where you genuinely cannot know** — and then ask, in one\n  question, for exactly those. Never submit with a sentinel still in place; the\n  validator rejects it, by design.\n\n## The required shape\n\nRead `templates\u002Fjira-ticket.md.tmpl` for the skeletons. In short:\n\n| Issue type | Sections |\n|---|---|\n| Feature \u002F Big Improvement · Small Improvement | Contexto \u002F Problema · Alcance \u002F Entregables · Plan de prueba (A\u002FB\u002FC) · Métricas |\n| Bug | Contexto \u002F Problema · Repro · Esperado vs Actual · Test de regresión · Métricas |\n| Subtask · Epic | Contexto \u002F Problema · Alcance \u002F Entregables |\n\nHeadings are Spanish, matched case- and accent-insensitively, tolerant of a `2.`\nprefix and a trailing `(parenthetical)`.\n\n**The five metric types, and nothing else:**\n\n- `cobertura \u002F compliance` — what fraction of X satisfies Y\n- `calidad \u002F exactitud` — how often the thing is RIGHT; false positives, accuracy\n- `tendencia \u002F burn-down` — a count moving over time, in the direction you claimed\n- `rendimiento \u002F eficiencia` — time, throughput, resource use\n- `coste` — money, tokens, CI minutes\n\nEach metric line reads `- \u003Cwhat you measure> → \u003Ctype>`.\n\n## Your failure mode is plausibility\n\nThe validator checks shape. You are the only thing checking *substance*, and the\ncharacteristic way this goes wrong is that every section is present, well\nwritten, and says nothing. Four specific traps, each observed:\n\n1. **A metric with no measurement behind it.** \"Mejora de la calidad del código →\n   calidad \u002F exactitud\" names a type and measures nothing. Ask: *who runs what\n   command, and what number comes out?* If there is no answer, the honest move is\n   `N\u002FA — \u003Cpor qué>` for that section, which is allowed and counted.\n\n2. **A B that is not a negative control.** \"Comprobar que falla\" is a wish. B must\n   name the **exact assertion you invert** and the error you expect —\n   \"quito la sección `## Métricas` del payload y el hook devuelve `deny` con\n   `missing-section`\". A test plan whose A passes proves only that you did not\n   test; B is the half that proves the gate bites. Boilerplate phrasings are\n   rejected by name in the contract, so writing one costs you a round trip.\n\n3. **A C that names nothing.** \"No romper nada\" is not a regression test. Name a\n   path or an id — `tests\u002Ftest_jira_ticket_standard.py` — or write\n   `ninguno aún — \u003Cpor qué>` and mean it.\n\n4. **Header stuffing.** Every heading present, every body \"TBD\"\u002F\"pendiente\".\n   This is the failure the whole standard exists to catch. If you find yourself\n   writing filler to satisfy a section, that is the signal to use the escape\n   hatch honestly instead.\n\n## The escape hatch\n\n`N\u002FA — \u003Crazón>` is valid **per section**, never for a whole ticket. Its usage\nrate is reported by `check`. A high rate is information about the template, not\nan infraction — but a reason that says \"no aplica\" is not a reason.\n\n## Before you call the MCP tool\n\n- Every required section present, with real content.\n- No `\u003C\u003C...>>` left anywhere.\n- Every metric line parses as `- \u003Cmétrica> → \u003Ctipo>`, type from the five.\n- B names the assertion that flips. C names a test or admits none, with a reason.\n- Epic parent set (`parent`) and labels chosen.\n\nThen call `createJiraIssue`. If the hook blocks you, it returns every problem at\nonce — fix them all in one pass rather than resubmitting per finding.\n\n## Checking existing tickets\n\n```\npython .ai-playbook\u002Fscripts\u002Frules\u002Fjira-ticket-standard.rule.py explain \u003CKEY>\npython .ai-playbook\u002Fscripts\u002Frules\u002Fjira-ticket-standard.rule.py check --since 2026-08-02\n```\n\n`explain` shows the match section by section — use it when a rejection surprises\nyou, because the answer is usually a heading the resolver did not recognise\nrather than a section you forgot.\n\n## When NOT to fire\n\n- **Tracker stubs from `issue_sync`.** Those carry `ai-playbook-managed` and are\n  exempt: their content of record is the OpenSpec proposal, and duplicating an\n  A\u002FB\u002FC into the stub creates a second copy that drifts from the first.\n- **Editing a ticket's fields other than the description** — nothing to validate.\n- **Other Jira projects.** The contract applies only to the Jira project set by\n  `--project` \u002F `$AIPLAYBOOK_JIRA_PROJECT`.\n\n## See also\n\n- `specs\u002Fjira-ticket-standard.yaml` — the contract, including the closed list.\n- `docs\u002Frules\u002Fjira-ticket-standard.rule.md` — the binding rule and the enforcement\n  topology, including what it deliberately cannot cover.\n- `templates\u002Fjira-ticket.md.tmpl` — the skeletons.\n",{"name":5,"license":15,"metadata":49,"description":7},{"author":50,"version":51},"ai-playbook","1.0","main","08fe7aa0f06bc1a3f592ec82360e46b854846968","skills\u002Fjira-ticket",1,"https:\u002F\u002Fgithub.com\u002FWizarck\u002Fai-playbook","https:\u002F\u002Fgithub.com\u002FWizarck","https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Framirezarturo\u002F","Geek by birth, with not much to say but plenty to talk about.","2026-11-09 19:34:21",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add Wizarck\u002Fai-playbook --skill jira-ticket",{"tool":67,"command":68},"bunx","bunx skills add Wizarck\u002Fai-playbook --skill jira-ticket",{"tool":70,"command":71},"pnpm","pnpm dlx skills add Wizarck\u002Fai-playbook --skill jira-ticket","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FWizarck\u002Fai-playbook\u002Fblob\u002Fmain\u002Fskills\u002Fjira-ticket\u002FSKILL.md",true,[],[76,97,116,137,156,169],{"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},"01M71FATTWS9W3BME3S94SA1QR","sweep","Use when the user wants to find code that has quietly stopped being used — types \u002Fsweep, asks for a \"dead code sweep\", \"repo entropy\", \"what can we delete\", \"orphan files\", \"unused code\", or asks to review a sweep ledger. Adjudicates candidates a deterministic scanner already produced; it never deletes anything and never re-derives findings from raw source. Pairs with ponytail, which gates what gets written rather than what rots.","https:\u002F\u002Fgithub.com\u002FWizarck\u002Fai-playbook\u002Fblob\u002Fmain\u002Fskills\u002Fsweep\u002FSKILL.md",[],[78,83,43,84,85,42,86,87,88,89,90,91,92,34,33,93,28,94,95,96],"deterministic","never","entropy","for","repo","re","ponytail","orphan","files","unused","code","gates","review","candidates",{"skillNo":98,"name":89,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":44},"01M71FAQKVDA209G7G5NMY9H1E","Use when the user wants the laziest solution that actually works — types \u002Fponytail, says \"be lazy\", \"lazy mode\", \"simplest solution\", \"minimal solution\", \"yagni\", \"do less\", or \"shortest path\", or complains about over-engineering, bloat, boilerplate, or unnecessary dependencies. Supports intensity levels lite, full, ultra (default). Pairs with caveman, which compresses prose, not code.","https:\u002F\u002Fgithub.com\u002FWizarck\u002Fai-playbook\u002Fblob\u002Fmain\u002Fskills\u002Fponytail\u002FSKILL.md",[],[89,103,104,43,105,42,106,107,108,109,34,33,93,27,110,111,112,113,114,115],"notice","do","lazy","mode","default","minimal","intensity","yagni","about","dependencies","2026","playbook","boilerplate",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":125,"publishedAt":44},"01M71FAMS250NKNF1PET9KNBBV","ponytail-review","Use when the user wants a code review focused exclusively on over-engineering — says \"review for over-engineering\", \"what can we delete\", \"is this over-engineered\", \"simplify review\", or invokes \u002Fponytail-review. Complements correctness\u002Fsecurity review; this one only hunts complexity in the current diff. Gated by the ponytail review_ponytail component.","https:\u002F\u002Fgithub.com\u002FWizarck\u002Fai-playbook\u002Fblob\u002Fmain\u002Fskills\u002Fponytail-review\u002FSKILL.md",[122],{"categoryNo":123,"categoryName":124,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",[126,89,95,127,128,86,129,130,34,33,131,132,93,30,28,133,134,135,136,114],"ponytail review","complexity","diff","code review","only","simplify","correctness","delete","component","security review","gated",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":44},"01M71FAG53ZPCSWE272P6S9JFN","ponytail-debt","Use when the user wants to harvest every `ponytail:` comment in the codebase into a tracked debt ledger — says \"ponytail debt\", \"\u002Fponytail-debt\", \"what did ponytail defer\", \"list the shortcuts\", \"ponytail ledger\", or \"what did we mark to do later\". One-shot report, changes nothing. Gated by the ponytail debt_ponytail component.","https:\u002F\u002Fgithub.com\u002FWizarck\u002Fai-playbook\u002Fblob\u002Fmain\u002Fskills\u002Fponytail-debt\u002FSKILL.md",[],[144,89,145,146,104,147,148,134,149,150,136,151,152,114,153,154,34,33,155,30],"ponytail debt","debt","shortcuts","mark","to do","changes","later","report","codebase","harvest","list","ledger",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":162,"publishedAt":44},"01M71FACJW88WCS2JGX3MQ3KV9","ponytail-audit","Use when the user wants a whole-repo audit for over-engineering — says \"audit this codebase\", \"audit for over-engineering\", \"what can I delete from this repo\", \"find bloat\", or invokes \u002Fponytail-audit. Like ponytail-review but scans the entire tree, not a diff. One-shot report, applies no fixes. Gated by the ponytail audit_ponytail component.","https:\u002F\u002Fgithub.com\u002FWizarck\u002Fai-playbook\u002Fblob\u002Fmain\u002Fskills\u002Fponytail-audit\u002FSKILL.md",[],[163,89,164,165,128,166,86,87,34,33,167,30,28,95,133,134,136,168,151,152],"ponytail audit","audit","tree","fixes","entire","find",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":175,"publishedAt":44},"01M71FA9THHXDX79PQTJ9CZX9E","openspec-propose","Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.","https:\u002F\u002Fgithub.com\u002FWizarck\u002Fai-playbook\u002Fblob\u002Fmain\u002Fskills\u002Fopenspec-propose\u002FSKILL.md",[],[176,177,27,178,179,180,181,182,183,86,184,185,186,187,188,189,34,33,190,191],"openspec","openspec propose","ready","proposal","change","cli","get","build","complete","design","new","implementation","generated","describe","artifacts","tasks"]