[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DAXGET2QX2AHK7JS3S9GM0":3,"skill-same:01M6DAXGET2QX2AHK7JS3S9GM0":114},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":13,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6DAXGET2QX2AHK7JS3S9GM0","relentless-vision-pursuit",null,"Use for a recurring, generative pursuit run that closes the gap between what a project is today and the ideal its doctrine describes: lane-sequenced audits of every surface against the applicable quality bar, vision-grounded ideation lenses, synthesis into a ranked move list with tier-board movement across runs, and a gated (never auto-released) work plan. Triggers: \"run the vision pursuit\", \"what's the next best step toward the vision\", \"relentlessly improve this project\", \"audit the whole project against the ideal\", \"generate the next round of improvements\".","tzeusy-org\u002Fai-bootstrap","tzeusy-org","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F141543652?v=4","01M6DAM1AP09H27BYGFY9QCNPB","01M6DAM1F4R187EK11XDN9JZKH",0,"MIT","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Frelentless-vision-pursuit\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"relentless vision pursuit","vision","session","triggers","project","doctrine","uv","never","auto","use","python","recurring","closeout","repo","subagent","projects","access","improve","beads","lane","2026-11-10 10:12:30",false,"---\nname: relentless-vision-pursuit\ndescription: >\n  Use for a recurring, generative pursuit run that closes the gap between what\n  a project is today and the ideal its doctrine describes: lane-sequenced audits of\n  every surface against the applicable quality bar, vision-grounded ideation\n  lenses, synthesis into a ranked move list with tier-board movement across\n  runs, and a gated (never auto-released) work plan. Triggers: \"run the vision\n  pursuit\", \"what's the next best step toward the vision\", \"relentlessly\n  improve this project\", \"audit the whole project against the ideal\",\n  \"generate the next round of improvements\".\nmetadata:\n  owner: tze\n  authors:\n    - tze\n    - Claude Fable 5\n    - Claude Fable 5.1\n  status: active\n  last_reviewed: \"2026-10-21\"\ncompatibility: >\n  Needs repo-root access and doctrine (about\u002Fheart-and-soul\u002F). Audit and\n  ideation lanes want a subagent facility with session continuation, plus bd\n  (beads). Both degrade: small projects run everything inline, sequentially,\n  and without bd the ranked move list stays in the dossier. The closeout\n  questionnaire uses ..\u002Fuser-questionnaire\u002F scripts (uv, Python 3.11+).\n---\n\n# Relentless Vision Pursuit\n\nA **recurring, generative** audit loop. The goal is not to verify correctness\n(that is `..\u002Fproject-review\u002FSKILL.md`) but to relentlessly close the gap\nbetween what the project is today and the ideal its doctrine describes. Each\nrun produces *new* moves — never a re-filing of what a prior run already\nfound — and measures movement since the last run.\n\nThe posture, which every dispatched prompt inherits:\n\n- **Judge against the north star**, quoted from the prior dossier or\n  re-derived from `about\u002Fheart-and-soul\u002Fvision.md`. Verdicts are\n  gap-to-ideal, not pass\u002Ffail.\n- **Propose the ideal.** Backward compatibility inside the project's own\n  surface is waived by default — redesigns and removals are in scope; note\n  migration cost, don't let it veto the move. External consumers' contracts\n  are never waived silently.\n- **Fewer new findings after a release is success**, not failure. Report\n  tier movement prominently; never pad the move list to hit a count.\n\n## Do not use when\n\n- Correctness or health question (\"is it wired\", \"score this repo\") →\n  `..\u002Fproject-review\u002FSKILL.md`.\n- One concrete feature to specify → `..\u002Fproject-feature-request\u002FSKILL.md`.\n- Quick candidate brief with no orchestration → `..\u002Fproject-direction\u002FSKILL.md`\n  ideation focus mode.\n- Sequencing already-approved work → `..\u002Fproject-direction\u002FSKILL.md`.\n\n## Phase 0 — Ground and scope (inline, before any lane)\n\n1. **Doctrine.** Read `about\u002Fheart-and-soul\u002F` (vision, non-negotiables,\n   NOT-boundaries) plus any normative design-language or architecture spec\n   the project keeps. Absent → stop and recommend `..\u002Fproject-shape\u002F`\n   bootstrap: a pursuit without a vision is a random walk.\n2. **Surface inventory.** Enumerate from the project's source-of-truth\n   artifact for its type — route table for frontends, command tree for CLIs,\n   public API for libraries, module map from `about\u002Flay-and-land\u002F` otherwise\n   — never a directory listing. Group routes\u002Fmodules into cohesive surfaces\n   and order them for locality (adjacent surfaces share code). That order is\n   the audit lane's walk.\n3. **Already-known ledger** — the dedup input injected verbatim into each\n   lane's opening prompt: prior pursuit dossiers (move lists + tier boards), open\u002Fin-flight\n   beads (`bd list --json`), recently merged work on the audited surfaces,\n   and `about\u002Flegends-and-lore\u002Fideas-ledger.md`. Compress to a bullet list:\n   \"known and in-flight — do not re-report\".\n4. **Tier-board baseline** from the newest prior dossier so this run reports\n   movement. First run: no baseline — say so, don't fabricate one.\n5. If a prior pursuit epic shipped since the last run, start with a scoped\n   `..\u002Fproject-review\u002FSKILL.md` verification pass over the surfaces it\n   touched; only verified landings count as movement.\n\n## Phase 1 — Surface pursuit (audit lane)\n\nOne long-lived audit lane walks every surface in locality order, one per turn,\nthen runs the cross-cutting sweeps chosen for the project:\ndiscoverability\u002Fshell, visual language, interaction speed, accessibility for\nhuman surfaces; architecture seams, test rigor, operability for code\nsurfaces. Non-negotiables baked into every prompt:\n\n- Hold the surface to the **applicable bar**: `\u002Fth-design` (one relevant\n  subskill) for human-facing surfaces, `\u002Fth-engineering` for code-facing\n  ones.\n- Judge against the quoted north star; every finding cites `file:line`.\n- Every surface gets a verdict tier —\n  `world-class | solid | functional | weak | broken` — a gap paragraph, and\n  a ranked move list.\n- The already-known ledger is in the lane's opening prompt; the lane drops\n  duplicates, not the synthesizer.\n\n## Phase 2 — Vision pursuit lenses (ideation lane, concurrent with Phase 1)\n\nIdeation at scale. Lens definitions, fit-trace discipline, and the\nmandate-grounded vs vision-extending classing all come from\n[`..\u002Fproject-direction\u002Freferences\u002Fideation.md`](..\u002Fproject-direction\u002Freferences\u002Fideation.md)\n— do not redefine them here. Beyond its base lenses, derive 3–6\nproject-specific lenses from topology and doctrine (e.g. integrations, the\ncore loop's latency\u002Fcost, data or knowledge growth, proactivity\u002Fautomation,\ncross-component collaboration). One ideation lane runs the lenses in turn;\neach lens turn returns concrete,\nintegration-point-named proposals (which module, schema, or spec would\nchange), scored owner-value vs build-cost, deduped against the ledger.\n\n## Phase 3 — Synthesis (orchestrator, barrier after Phases 1–2)\n\nThe strategic core — keep it on the session's model, inline. Read inputs\nfrom the durable harvest file, never from live lane returns (see execution\ndiscipline §3). Produce:\n\n- Tier board with movement vs baseline (verified movement only; inferred\n  movement labeled).\n- Systemic themes — cross-surface defects with exemplars.\n- One ranked move list (~10–15) mixing surface moves and vision extensions;\n  each move: what, why (doctrine citation), evidence, rough slice plan.\n  Vision-extending moves carry their doctrine-amendment prerequisite.\n\n## Phase 4 — Deliverables\n\nDossier + data JSON, gated beads epic, the owner dossier questionnaire, and a\nmemory line — formats and the gate protocol in\n[`references\u002Fpursuit-deliverables.md`](references\u002Fpursuit-deliverables.md).\nA pursuit run is *planning, never execution*: nothing it files may be\nrunnable until the owner releases the gate.\n\n## Phase 5 — Owner dossier questionnaire (closeout)\n\nThe run ends by handing the owner its hard gates as one\n[`..\u002Fuser-questionnaire\u002FSKILL.md`](..\u002Fuser-questionnaire\u002FSKILL.md) packet,\npublished as a web form: gate-release scope, each vision-extending move's\ndoctrine amendment, any external-contract waiver, and nothing else. Items\nare drafted, adversarially reviewed by a fresh subagent, validated, and\nserved by script; the final report ends with the printed `QUESTIONNAIRE_URL=`\nline. Admission rules, item shapes, and what the next session does with the\nanswers are in\n[`references\u002Fpursuit-deliverables.md`](references\u002Fpursuit-deliverables.md)\n§ Owner dossier questionnaire. A run with no owner gates says so instead of\ninventing items.\n\n## Execution discipline\n\nLoad [`references\u002Fexecution-discipline.md`](references\u002Fexecution-discipline.md)\nbefore dispatching any lane. Four hard rules: lanes not batches (≤3 sessions\nin flight), model routing by task difficulty, checkpoint-to-disk per unit, and\ncadence\u002Fresume hygiene. Violating one is a defect in the run, not a style choice.\n\n## Handoffs\n\n- **Released moves that need behavior specification** → the\n  `..\u002Fproject-feature-request\u002FSKILL.md` funnel as fuzzy input;\n  vision-extending moves enter knowing Gate 2 requires doctrine amendment\n  or rejection.\n- **Gate release** → the owner's move, recorded through the closeout\n  questionnaire; the applying session closes the gate only on an `Agreed`\n  release answer with `apply_now`. Execution belongs to\n  `\u002Fbeads-orchestration` (beads-coordinator), never to this skill.\n- **Owner answers** → the next session runs `questionnaire_web.py ingest`\n  before anything else and routes per the user-questionnaire apply checklist.\n- **Next run** verifies this run's shipped moves via a scoped\n  `..\u002Fproject-review\u002FSKILL.md` pass (Phase 0 step 5).\n","# Relentless Vision Pursuit\n\nA **recurring, generative** audit loop. The goal is not to verify correctness\n(that is `..\u002Fproject-review\u002FSKILL.md`) but to relentlessly close the gap\nbetween what the project is today and the ideal its doctrine describes. Each\nrun produces *new* moves — never a re-filing of what a prior run already\nfound — and measures movement since the last run.\n\nThe posture, which every dispatched prompt inherits:\n\n- **Judge against the north star**, quoted from the prior dossier or\n  re-derived from `about\u002Fheart-and-soul\u002Fvision.md`. Verdicts are\n  gap-to-ideal, not pass\u002Ffail.\n- **Propose the ideal.** Backward compatibility inside the project's own\n  surface is waived by default — redesigns and removals are in scope; note\n  migration cost, don't let it veto the move. External consumers' contracts\n  are never waived silently.\n- **Fewer new findings after a release is success**, not failure. Report\n  tier movement prominently; never pad the move list to hit a count.\n\n## Do not use when\n\n- Correctness or health question (\"is it wired\", \"score this repo\") →\n  `..\u002Fproject-review\u002FSKILL.md`.\n- One concrete feature to specify → `..\u002Fproject-feature-request\u002FSKILL.md`.\n- Quick candidate brief with no orchestration → `..\u002Fproject-direction\u002FSKILL.md`\n  ideation focus mode.\n- Sequencing already-approved work → `..\u002Fproject-direction\u002FSKILL.md`.\n\n## Phase 0 — Ground and scope (inline, before any lane)\n\n1. **Doctrine.** Read `about\u002Fheart-and-soul\u002F` (vision, non-negotiables,\n   NOT-boundaries) plus any normative design-language or architecture spec\n   the project keeps. Absent → stop and recommend `..\u002Fproject-shape\u002F`\n   bootstrap: a pursuit without a vision is a random walk.\n2. **Surface inventory.** Enumerate from the project's source-of-truth\n   artifact for its type — route table for frontends, command tree for CLIs,\n   public API for libraries, module map from `about\u002Flay-and-land\u002F` otherwise\n   — never a directory listing. Group routes\u002Fmodules into cohesive surfaces\n   and order them for locality (adjacent surfaces share code). That order is\n   the audit lane's walk.\n3. **Already-known ledger** — the dedup input injected verbatim into each\n   lane's opening prompt: prior pursuit dossiers (move lists + tier boards), open\u002Fin-flight\n   beads (`bd list --json`), recently merged work on the audited surfaces,\n   and `about\u002Flegends-and-lore\u002Fideas-ledger.md`. Compress to a bullet list:\n   \"known and in-flight — do not re-report\".\n4. **Tier-board baseline** from the newest prior dossier so this run reports\n   movement. First run: no baseline — say so, don't fabricate one.\n5. If a prior pursuit epic shipped since the last run, start with a scoped\n   `..\u002Fproject-review\u002FSKILL.md` verification pass over the surfaces it\n   touched; only verified landings count as movement.\n\n## Phase 1 — Surface pursuit (audit lane)\n\nOne long-lived audit lane walks every surface in locality order, one per turn,\nthen runs the cross-cutting sweeps chosen for the project:\ndiscoverability\u002Fshell, visual language, interaction speed, accessibility for\nhuman surfaces; architecture seams, test rigor, operability for code\nsurfaces. Non-negotiables baked into every prompt:\n\n- Hold the surface to the **applicable bar**: `\u002Fth-design` (one relevant\n  subskill) for human-facing surfaces, `\u002Fth-engineering` for code-facing\n  ones.\n- Judge against the quoted north star; every finding cites `file:line`.\n- Every surface gets a verdict tier —\n  `world-class | solid | functional | weak | broken` — a gap paragraph, and\n  a ranked move list.\n- The already-known ledger is in the lane's opening prompt; the lane drops\n  duplicates, not the synthesizer.\n\n## Phase 2 — Vision pursuit lenses (ideation lane, concurrent with Phase 1)\n\nIdeation at scale. Lens definitions, fit-trace discipline, and the\nmandate-grounded vs vision-extending classing all come from\n[`..\u002Fproject-direction\u002Freferences\u002Fideation.md`](..\u002Fproject-direction\u002Freferences\u002Fideation.md)\n— do not redefine them here. Beyond its base lenses, derive 3–6\nproject-specific lenses from topology and doctrine (e.g. integrations, the\ncore loop's latency\u002Fcost, data or knowledge growth, proactivity\u002Fautomation,\ncross-component collaboration). One ideation lane runs the lenses in turn;\neach lens turn returns concrete,\nintegration-point-named proposals (which module, schema, or spec would\nchange), scored owner-value vs build-cost, deduped against the ledger.\n\n## Phase 3 — Synthesis (orchestrator, barrier after Phases 1–2)\n\nThe strategic core — keep it on the session's model, inline. Read inputs\nfrom the durable harvest file, never from live lane returns (see execution\ndiscipline §3). Produce:\n\n- Tier board with movement vs baseline (verified movement only; inferred\n  movement labeled).\n- Systemic themes — cross-surface defects with exemplars.\n- One ranked move list (~10–15) mixing surface moves and vision extensions;\n  each move: what, why (doctrine citation), evidence, rough slice plan.\n  Vision-extending moves carry their doctrine-amendment prerequisite.\n\n## Phase 4 — Deliverables\n\nDossier + data JSON, gated beads epic, the owner dossier questionnaire, and a\nmemory line — formats and the gate protocol in\n[`references\u002Fpursuit-deliverables.md`](references\u002Fpursuit-deliverables.md).\nA pursuit run is *planning, never execution*: nothing it files may be\nrunnable until the owner releases the gate.\n\n## Phase 5 — Owner dossier questionnaire (closeout)\n\nThe run ends by handing the owner its hard gates as one\n[`..\u002Fuser-questionnaire\u002FSKILL.md`](..\u002Fuser-questionnaire\u002FSKILL.md) packet,\npublished as a web form: gate-release scope, each vision-extending move's\ndoctrine amendment, any external-contract waiver, and nothing else. Items\nare drafted, adversarially reviewed by a fresh subagent, validated, and\nserved by script; the final report ends with the printed `QUESTIONNAIRE_URL=`\nline. Admission rules, item shapes, and what the next session does with the\nanswers are in\n[`references\u002Fpursuit-deliverables.md`](references\u002Fpursuit-deliverables.md)\n§ Owner dossier questionnaire. A run with no owner gates says so instead of\ninventing items.\n\n## Execution discipline\n\nLoad [`references\u002Fexecution-discipline.md`](references\u002Fexecution-discipline.md)\nbefore dispatching any lane. Four hard rules: lanes not batches (≤3 sessions\nin flight), model routing by task difficulty, checkpoint-to-disk per unit, and\ncadence\u002Fresume hygiene. Violating one is a defect in the run, not a style choice.\n\n## Handoffs\n\n- **Released moves that need behavior specification** → the\n  `..\u002Fproject-feature-request\u002FSKILL.md` funnel as fuzzy input;\n  vision-extending moves enter knowing Gate 2 requires doctrine amendment\n  or rejection.\n- **Gate release** → the owner's move, recorded through the closeout\n  questionnaire; the applying session closes the gate only on an `Agreed`\n  release answer with `apply_now`. Execution belongs to\n  `\u002Fbeads-orchestration` (beads-coordinator), never to this skill.\n- **Owner answers** → the next session runs `questionnaire_web.py ingest`\n  before anything else and routes per the user-questionnaire apply checklist.\n- **Next run** verifies this run's shipped moves via a scoped\n  `..\u002Fproject-review\u002FSKILL.md` pass (Phase 0 step 5).\n",{"name":5,"metadata":43,"description":50,"compatibility":51},{"owner":44,"status":45,"authors":46,"last_reviewed":49},"tze","active",[44,47,48],"Claude Fable 5","Claude Fable 5.1","2026-10-21","Use for a recurring, generative pursuit run that closes the gap between what a project is today and the ideal its doctrine describes: lane-sequenced audits of every surface against the applicable quality bar, vision-grounded ideation lenses, synthesis into a ranked move list with tier-board movement across runs, and a gated (never auto-released) work plan. Triggers: \"run the vision pursuit\", \"what's the next best step toward the vision\", \"relentlessly improve this project\", \"audit the whole project against the ideal\", \"generate the next round of improvements\".\n","Needs repo-root access and doctrine (about\u002Fheart-and-soul\u002F). Audit and ideation lanes want a subagent facility with session continuation, plus bd (beads). Both degrade: small projects run everything inline, sequentially, and without bd the ranked move list stays in the dossier. The closeout questionnaire uses ..\u002Fuser-questionnaire\u002F scripts (uv, Python 3.11+).","main","c907d6f0bf96bd61b936e8972e0f1c66ebb8148c","skills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Frelentless-vision-pursuit","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap","https:\u002F\u002Fgithub.com\u002Ftzeusy-org","2026-11-10 23:17:25",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add tzeusy-org\u002Fai-bootstrap --skill relentless-vision-pursuit",{"tool":64,"command":65},"bunx","bunx skills add tzeusy-org\u002Fai-bootstrap --skill relentless-vision-pursuit",{"tool":67,"command":68},"pnpm","pnpm dlx skills add tzeusy-org\u002Fai-bootstrap --skill relentless-vision-pursuit","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Frelentless-vision-pursuit\u002FSKILL.md",true,[72,78,82,86,90,94,98,102,106,110],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"evo-skill-manifest.yaml","REFERENCE","参考文档",12,"https:\u002F\u002Fgithub.com\u002Ftonygomes-wq\u002Fevo\u002Fblob\u002Fmain\u002Fevo-crm-community-main\u002F.claude\u002Fskills\u002Fevo-quick-dev-new-preview\u002Fevo-skill-manifest.yaml",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fexecution-discipline.md",6133,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Frelentless-vision-pursuit\u002Freferences\u002Fexecution-discipline.md",{"path":83,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fpursuit-deliverables.md",5589,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Frelentless-vision-pursuit\u002Freferences\u002Fpursuit-deliverables.md",{"path":87,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":88,"sourceHtmlUrl":89},"steps\u002Fstep-01-clarify-and-route.md",4072,"https:\u002F\u002Fgithub.com\u002Ftonygomes-wq\u002Fevo\u002Fblob\u002Fmain\u002Fevo-crm-community-main\u002F.claude\u002Fskills\u002Fevo-quick-dev-new-preview\u002Fsteps\u002Fstep-01-clarify-and-route.md",{"path":91,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":92,"sourceHtmlUrl":93},"steps\u002Fstep-02-plan.md",1954,"https:\u002F\u002Fgithub.com\u002Ftonygomes-wq\u002Fevo\u002Fblob\u002Fmain\u002Fevo-crm-community-main\u002F.claude\u002Fskills\u002Fevo-quick-dev-new-preview\u002Fsteps\u002Fstep-02-plan.md",{"path":95,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":96,"sourceHtmlUrl":97},"steps\u002Fstep-03-implement.md",1159,"https:\u002F\u002Fgithub.com\u002Ftonygomes-wq\u002Fevo\u002Fblob\u002Fmain\u002Fevo-crm-community-main\u002F.claude\u002Fskills\u002Fevo-quick-dev-new-preview\u002Fsteps\u002Fstep-03-implement.md",{"path":99,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":100,"sourceHtmlUrl":101},"steps\u002Fstep-04-review.md",4450,"https:\u002F\u002Fgithub.com\u002Ftonygomes-wq\u002Fevo\u002Fblob\u002Fmain\u002Fevo-crm-community-main\u002F.claude\u002Fskills\u002Fevo-quick-dev-new-preview\u002Fsteps\u002Fstep-04-review.md",{"path":103,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":104,"sourceHtmlUrl":105},"steps\u002Fstep-05-present.md",654,"https:\u002F\u002Fgithub.com\u002Ftonygomes-wq\u002Fevo\u002Fblob\u002Fmain\u002Fevo-crm-community-main\u002F.claude\u002Fskills\u002Fevo-quick-dev-new-preview\u002Fsteps\u002Fstep-05-present.md",{"path":107,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":108,"sourceHtmlUrl":109},"tech-spec-template.md",3300,"https:\u002F\u002Fgithub.com\u002Ftonygomes-wq\u002Fevo\u002Fblob\u002Fmain\u002Fevo-crm-community-main\u002F.claude\u002Fskills\u002Fevo-quick-dev-new-preview\u002Ftech-spec-template.md",{"path":111,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":112,"sourceHtmlUrl":113},"workflow.md",3580,"https:\u002F\u002Fgithub.com\u002Ftonygomes-wq\u002Fevo\u002Fblob\u002Fmain\u002Fevo-crm-community-main\u002F.claude\u002Fskills\u002Fevo-quick-dev-new-preview\u002Fworkflow.md",[115,137,164,179,198,209],{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":38},"01M6DAZD21TWH2ET70V9FF75CQ","user-run","Use when a step needs privileges this session lacks (docker, sudo, another user's checkout or secrets, host access) and the owner must run it as tze. Writes a reviewable \u002Fhome\u002Forca\u002F.tmp\u002F\u003Cslug>\u002Frun.sh that impersonates tze (USER_TO_IMPERSONATE overrides), tees timestamped logs plus latest.log and collects artifacts there; Claude presents it with a risk and time brief, then continues from the logs. Triggers: \"I'll run it for you\", \"permission denied on docker.sock\", \"needs sudo\", \"sudo: a password is required\", \"run as tze\", \"\u002Fuser-run\".","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fuser-run\u002FSKILL.md",[],[122,123,124,125,126,27,127,128,21,129,45,130,131,132,20,133,34,134,135,136],"user run","user","run","docker","logs","host","as","permission","time","log","artifacts","password","secrets","risk","brief",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":153,"publishedAt":38},"01M6DAZAHTCBAD2WF0GAHWPST8","requesting-code-review","Use when completing tasks, implementing major features, or before merging to verify work meets requirements","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Frequesting-code-review\u002FSKILL.md",[143,148],{"categoryNo":144,"categoryName":145,"taxonomyType":146,"taxonomyTypeDesc":147},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":149,"categoryName":150,"taxonomyType":151,"taxonomyTypeDesc":152},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[154,155,156,157,158,159,45,160,161,27,162,163],"requesting code review","code","review","code review","work","requirements","upstream","superpowers","verify","tasks",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":172,"publishedAt":38},"01M6DAZ7CJ82D81XZB2YHVVY48","receiving-code-review","Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Freceiving-code-review\u002FSKILL.md",[170,171],{"categoryNo":144,"categoryName":145,"taxonomyType":146,"taxonomyTypeDesc":147},{"categoryNo":149,"categoryName":150,"taxonomyType":151,"taxonomyTypeDesc":152},[173,155,156,157,45,160,174,161,27,175,176,177,178],"receiving code review","implementation","code review feedback","technical","feedback","verification",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":38},"01M6DAZ4ER76ADXJ9KRFP7V3Q9","finishing-a-development-branch","Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Ffinishing-a-development-branch\u002FSKILL.md",[],[186,187,188,189,27,190,158,191,192,193,161,194,195,196,45,160,197,174],"branch","development","finishing a development branch","integrate","decide","how","cleanup","pr","merge","tests","structured","options",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":204,"publishedAt":38},"01M6DAYZFWWW2YPKP89QNQR96H","executing-plans","Use when you have a written implementation plan to execute in a separate session with review checkpoints","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Fexecuting-plans\u002FSKILL.md",[],[205,206,207,156,208,45,160,174,161,27,20],"plans","executing plans","plan","execute",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":215,"publishedAt":38},"01M6DAYWM2YQHYCK7C35K1D29J","dispatching-parallel-agents","Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Fdispatching-parallel-agents\u002FSKILL.md",[],[216,217,218,27,161,160,219,45,220,163,221],"parallel agents","parallel","dispatching parallel agents","state","dependencies","shared"]