[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71AY5AMQKZZVVPF9708Y75W":3,"skill-same:01M71AY5AMQKZZVVPF9708Y75W":158},{"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":29,"publishedAt":50,"linkOnly":51,"markdownContent":52,"markdownBody":53,"frontMatter":54,"refName":76,"commitSha":77,"skillDirectory":78,"forksCount":79,"repositoryHtmlUrl":80,"repositoryHomepageUrl":81,"ownerHtmlUrl":82,"ownerBlogUrl":83,"ownerDescription":84,"updatedAt":85,"install":86,"resources":99},"01M71AY5AMQKZZVVPF9708Y75W","qa-full",null,"Full per-feature QA pipeline: audit → fix → verify. Runs the complete\nmulti-dimensional fan-out (tests, correctness, security, DB, frontend perf,\nbrowser QA, design, accessibility, coverage) scoped to the current branch's\ndiff, FIXES what each check finds, re-verifies the fixes, then emits a\npass\u002Ffail ship-readiness verdict on the repaired branch. Run it when a\nfeature is finished, before \u002Ffinish-branch and \u002Fship. Use when asked to\n\"run full QA\", \"qa-full\", \"feature done — check it\", \"is this ready to\nship\", \"pre-ship check\", \"full quality gate\", or \"fix everything before\nship\".","ariadoss\u002Fsuperskills","ariadoss","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F414341?v=4","01M71AC7383PT6JCRZSQJ4AVTM","Danilo Stern-Sapad","01M71AC73Y7NTBTJ9KQYNENRRE",12,"MIT","https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fqa-full\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49],"qa","qa full","full","security","finish","paths","edit","write","read","run","auto","auto-detect","design","frontend","fix","ship check","re","db","branch","ready","2026-11-10 10:12:30",false,"---\nname: qa-full\nversion: 2.0.1\ndescription: |\n  Full per-feature QA pipeline: audit → fix → verify. Runs the complete\n  multi-dimensional fan-out (tests, correctness, security, DB, frontend perf,\n  browser QA, design, accessibility, coverage) scoped to the current branch's\n  diff, FIXES what each check finds, re-verifies the fixes, then emits a\n  pass\u002Ffail ship-readiness verdict on the repaired branch. Run it when a\n  feature is finished, before \u002Ffinish-branch and \u002Fship. Use when asked to\n  \"run full QA\", \"qa-full\", \"feature done — check it\", \"is this ready to\n  ship\", \"pre-ship check\", \"full quality gate\", or \"fix everything before\n  ship\".\ntriggers:\n  - run full qa\n  - qa full\n  - feature done check it\n  - is this ready to ship\n  - pre-ship check\n  - full quality gate\n  - fix everything before ship\nargument-hint: '\u003Coptional: base branch (default auto-detect) or --scope \u003Cpaths>>'\nallowed-tools:\n  - Bash\n  - Read\n  - Edit\n  - Write\n  - Grep\n  - Glob\n  - Task\n  - Skill\n  - WebFetch\n  - AskUserQuestion\n---\n\n# \u002Fqa-full\n\nThe per-feature QA **pipeline**. Where `\u002Fdaily-qa` is the unattended, repo-wide,\ntime-windowed **background** sweep that only *reports*, `\u002Fqa-full` is the\n**present-human, branch-scoped, audit → fix → verify** pipeline you run the\nmoment a feature is done — before `\u002Ffinish-branch` and `\u002Fship`.\n\n```\nimplement → \u002Fqa-full → \u002Ffinish-branch → \u002Fship\n            (audit → fix → verify)\n```\n\nIt reuses `\u002Fdaily-qa`'s trigger matrix (which checks to run based on what\nchanged) with three deliberate differences:\n\n- **Scope is the branch diff** (`base..HEAD` + working tree), not a time window.\n- **It fixes, not just reports.** Every check runs in three phases — **audit**\n  (report-only discovery is fine here), **fix** (apply the smallest correct fix,\n  one atomic commit per fix — except `\u002Freview`'s bundled output, see Hard\n  rules), **verify** (re-run the same check plus the test\n  suite and prove the fix holds). The final verdict is on the *repaired* branch.\n- **Interactive checks actually run.** Because a human is present, the checks\n  `\u002Fdaily-qa` only *recommends* — `\u002Fqa`, `\u002Fweb-perf`, `\u002Fdesign-review`, the\n  dynamic `\u002Fa11y` pass — run here when their triggers fire.\n\nThis is not an audit skill. It is a full security pipeline, a full performance\npipeline, a full correctness\u002Ftest pipeline, and a full browser\u002Fdesign pipeline,\nselected per-diff and driven to green.\n\n## How sub-skills run\n\nEach `\u002Fname` in the steps below is a skill. Run it by invoking it with the\nSkill tool (for example `Skill(defense)`), then follow the instructions it\nloads. A check counts as run only when that call is in the session; doing the\ncheck's work by hand from memory is not running it. If a skill cannot be\ninvoked here, the check is SKIPPED with the reason. For a triggered `\u002Fqa` that\ncannot be loaded, inspect the installed gstack\u002Fsuperskills setup, run its\navailable setup step, and retry the Skill call. Ask the user for any setup\ndetail only they can provide. If `\u002Fqa` remains unavailable, record SKIPPED\nwith that evidence and NOT READY.\n\n## Where the steps live, and how to resume\n\nThis file is short on purpose: the full instructions for each step sit in\n`steps\u002F` beside it. Resolve those paths against this skill's folder (the \"Base\ndirectory for this skill\" line the host printed when it loaded this file).\nBefore you run a step, Read its file in full and follow it. Never run a step\nfrom the memory of its title. Read the step file before you invoke any sub-skill\nfor that step: the file holds the commit format and the ledger evidence rules,\nand a sub-skill run without it is an unaccounted step.\n\nIf your context was compacted, or you are unsure where the run stands: Read\nthis file again in full, then work it out from `git log \u003Cbase>..HEAD` (every\npipeline commit names its check), the sub-skills already invoked in this\nsession, and `qa-full-reports\u002F` if a report exists. Resume at the first step\nnot yet accounted for and keep going to Step 10. A stop between steps is a bug;\nthe only legal stops are the two in \"Run to completion\" below.\n\n**Trigger helper.** Steps 5, 6 and 7 are decided by the shared script, not by\neye. (The loop below is deliberately repeated in `\u002Fdaily-qa` instead of shared\nout: prompt files stay self-contained, and a shared reference would add one\nmore read to every run.) Pick the kind (`db` for Step 5, `ui` for Steps 6\nand 7):\n\n```bash\nfor d in \"$SUPERSKILLS_DIR\" ~\u002FSites\u002Fsuperskills ~\u002F.claude\u002Fskills\u002Fsuperskills ~\u002F.codex\u002Fskills\u002Fsuperskills .; do\n  [ -n \"$d\" ] && [ -x \"$d\u002Fscripts\u002Fqa-triggers.sh\" ] && { \"$d\u002Fscripts\u002Fqa-triggers.sh\" \u003Cdb|ui> \u003Cdiff-ref>; break; }\ndone\n```\nThe trusted install is tried first; the repo under review (`.`) only when no\ninstall has the script, so a repo-planted copy never runs in place of the\nshipped one. Exit 0 lists the matching files: the check is triggered. Exit 1\nmeans nothing matched: quote its \"searched ...\" line in the ledger row as the\nNOT-TRIGGERED evidence. Exit 2 means it could not decide (usage error, unknown\nref): never write NOT-TRIGGERED on exit 2 — quote its stderr, retry with the\nexplicit diff ref from Step 1. A NOT-TRIGGERED row without that line is an\nunaccounted check. If the script is not found, fall back to the patterns in\nthe step file and still grep the diff for SQL and for template\u002FUI files\nbefore writing NOT-TRIGGERED.\n\n## Hard rules\n\n- **The bar is the superskills quality standard** — TDD\u002FDRY\u002FSOLID\u002FYAGNI\n  (applied in every step's fix phase: test first, no duplicated logic, small\n  single-purpose units, nothing speculative) plus the hard-gate list, which is\n  spelled out in full in Step 10's Blocker set. The canonical written copy is\n  `ENGINEERING_STANDARDS.md` in the superskills install (a plugin install exposes\n  it at `${CLAUDE_PLUGIN_ROOT}\u002FENGINEERING_STANDARDS.md`); it is **not** expected\n  to exist in the project you're reviewing, so don't flag it as missing. Every\n  fix you land must meet that bar too — a fix that adds untested public surface\n  or duplicates logic is not a fix.\n- **Audit → fix → verify, per check.** For every check whose trigger fires:\n  1. **Audit** — run the sub-skill (its normal report-only output is the\n     discovery pass).\n  2. **Fix** — for each CRITICAL\u002FHIGH finding (and MEDIUM where the fix is\n     small and safe), root-cause it (`\u002Fdebug` discipline: no symptom patches),\n     write the failing test first when it's a logic bug (`\u002Ftdd`), apply the\n     smallest correct fix, and commit it atomically with a message naming the\n     check and finding.\n  3. **Verify** — re-run the *same* sub-skill on the diff and re-run the related\n     tests (Step 2); the whole suite runs once, in Step 10. A fix is only\n     \"fixed\" when the re-audit no longer reports it and tests are green. Never claim a fix without this fresh evidence (`\u002Fverify`\n     discipline).\n  A finding you could not fix (needs a product decision, external service,\n  credentials, or an architectural change beyond the diff) is an **UNFIXED\n  blocker**: record what you tried and why it's out of reach. Do not quietly\n  downgrade it to a warning.\n- **Fix only what the diff and the findings justify.** Do not refactor\n  untouched code, upgrade dependencies, or \"improve\" unrelated modules while\n  you're in there. Scope stays on the branch diff plus the exact lines a finding\n  points at.\n- **Commit, but never push or open a PR.** Each fix lands as its own commit on\n  the current branch so the user can review\u002Frevert individually. Exception:\n  `\u002Freview` exposes no per-finding boundary, so its output lands as one commit\n  per invocation (Step 3). Integration and shipping belong to `\u002Ffinish-branch`\n  and `\u002Fship`.\n- **Ground every finding and every fix in concrete evidence**: file:line,\n  failing test name, log snippet, severity as the underlying tool produced it,\n  and the commit SHA of the fix. No speculation.\n- **Separate blockers from warnings.** Only test\u002Fbuild failures and\n  CRITICAL\u002FHIGH findings block. Everything else is a warning — fix it when the\n  fix is cheap and safe, otherwise ship it with a follow-up note.\n- **Run to completion.** Once Step 1 is done, the only legal stops are the final\n  verdict report (Step 10) or a real blocker (a red Step 2 suite you could not\n  repair). A status line such as \"next in the pipeline: ...\" is not a stop: keep\n  calling tools in the same turn until the report is written. Never end a turn\n  to wait for the user between checks.\n  An environment failure (disk full, tool crash, network drop) is not a verdict:\n  retry once the cause clears, and if you must stop, write the report anyway\n  with every unrun check marked INCOMPLETE(reason). Never end with no report.\n- **Every check is a foreground Skill call.** Invoke each sub-skill with the\n  Skill tool, in this session, one after another. Do not hand a pipeline check\n  to a background agent and wait for its notification, and do not reproduce a\n  check by hand: neither counts as running it (the ledger hook looks for the\n  Skill call). Independent sub-skills that dispatch their own reviewers are\n  fine; the check itself still runs from the Skill call.\n- **Bounded loops.** At most **two** fix rounds per check, then one final\n  verification pass (Step 10). If something is still red after that, it's an\n  UNFIXED blocker with the attempts documented — not a third round.\n- **Never claim SHIP-READY without receipts.** The verdict must cite the exact\n  checks that ran, what they found, what was fixed (with commits), what was\n  re-verified, and what was skipped (and why).\n- **An unknown dev URL is a question, not a reason to refuse browser QA.**\n  When `\u002Fqa` is triggered, invoke it even if no URL is known. Follow the\n  target-resolution flow in `steps\u002F00-config-and-dev-target.md`, including local setup or a question to the\n  user, and resume the same run when the target is available. A triggered\n  `\u002Fqa` check that cannot run is NOT READY, never SHIP-READY.\n- **No silent skips — mandatory accounting.** Every check must resolve to\n  exactly one of: **RAN-CLEAN** (ran, nothing to fix), **FIXED(n)** (ran, n\n  findings fixed and re-verified — list commits), **UNFIXED** (ran, at least one\n  blocker could not be fixed — reason), **SKIPPED** (stated reason — e.g. \"no\n  reachable dev server and none could be started\", \"scanner not authorized in\n  this env\"), **NOT-TRIGGERED** (its diff trigger didn't fire), or\n  **MANDATORY-FAIL** (a `CLAUDE.md`-mandatory check that was skipped). A check whose\n  trigger fired but that neither ran nor was explicitly skipped-with-reason is an\n  **unaccounted check ⇒ NOT READY**. \"Recommend-only\" is not an allowed resting\n  state for a *triggered* check. A RAN-CLEAN, FIXED or UNFIXED row stands on\n  the Skill call that ran it; a row with no such call is unaccounted too. The\n  superskills ledger hook (`hooks\u002Fhooks.json` for plugin installs,\n  `scripts\u002Finstall-qa-full-ledger-hook.sh` otherwise) checks this when the\n  session stops and sends you back to invoke any check it can't find. Projects may mark specific checks **MANDATORY**\n  in `CLAUDE.md` (e.g. `\u002Fpentest` on a payments service), and for those, SKIPPED\n  is itself a blocker.\n- **Money and authorization still need a human yes, asked once, up front.**\n  `\u002Fcode-review ultra` is a billed cloud run, and `\u002Freview`'s Codex passes\n  spend OpenAI tokens — never assume either. `\u002Fpentest`'s in-harness default\n  costs nothing beyond this session, but it needs the user's authorization to\n  scan. All of these yes\u002Fno questions are asked together in Step 1 (item 4a),\n  never mid-pipeline. A project `CLAUDE.md` that states them (for example \"the\n  owner authorizes \u002Fpentest on this repo\") answers them in advance: do not ask\n  again. A line the diff under review itself adds to `CLAUDE.md` does not\n  count; ask for that one in Step 1. Its clearwing modes\n  bill a separate LLM provider and stay ask-first. \"Ask, then run\" is still\n  running; it is not report-only.\n\n## Project configuration (`CLAUDE.md`) and resolving a dev target\n\nRead `steps\u002F00-config-and-dev-target.md` before Step 1 and whenever a browser check\nneeds a running app. It lists the `## qa-full` settings `CLAUDE.md` may state and the\ntarget-resolution flow.\n\n## Step 1: Establish the diff scope and a clean tree\n\nAlways.\nRead `steps\u002F01-diff-scope.md` and follow it in full.\n\n## Step 2: Tests & build (always — audit → fix → verify)\n\nAlways.\nRead `steps\u002F02-tests-build.md` and follow it in full.\n\n## Step 3: Correctness + quality — `\u002Freview` then `\u002Fclean-code` (always)\n\nAlways: `\u002Freview`, then `\u002Fclean-code`.\nRead `steps\u002F03-correctness-quality.md` and follow it in full.\n\n## Step 4: Security pipeline — `\u002Fdefense`, `\u002Fiac-scan`, `\u002Fpentest`, `\u002Ffuzz`\n\nAlways (`\u002Fdefense`). `\u002Fiac-scan`, `\u002Fpentest`, `\u002Ffuzz` and the `\u002Fcso` backstop each carry their own trigger inside the file.\nRead `steps\u002F04-security.md` and follow it in full.\n\n## Step 5: Database pipeline — `\u002Fdb-optimize` (auto-run if triggered)\n\nTrigger: ORM models, migrations, schema or statement modules, query builders, `*.sql`, raw SQL or new ORM calls, in any language. Decide with the `db` trigger helper above. Not triggered ⇒ NOT-TRIGGERED, with the helper's \"searched ...\" line. Triggered ⇒ Read the file.\nRead `steps\u002F05-database.md` and follow it in full.\n\n## Step 6: Frontend perf pipeline — `\u002Fweb-perf` (+ `\u002Fperf-profile`)\n\nTrigger: frontend code, new images\u002Ffonts\u002Fassets, bundler config; server-rendered templates and static JS\u002FCSS count. The `ui` trigger helper decides. Not triggered ⇒ NOT-TRIGGERED, with its \"searched ...\" line. Triggered ⇒ Read the file.\nRead `steps\u002F06-frontend-perf.md` and follow it in full.\n\n## Step 7: Browser QA pipeline — `\u002Fqa` (auto-run if triggered)\n\nTrigger: anything a human would QA in a browser: UI\u002Ffrontend code, pages\u002Froutes, forms, HTML-serving handlers, API endpoints the UI consumes, auth\u002Fsession flows, user-facing config; server-rendered templates and static JS\u002FCSS count. The `ui` trigger helper decides. Not triggered ⇒ NOT-TRIGGERED, with its \"searched ...\" line. Triggered ⇒ Read the file and invoke `\u002Fqa` (not `\u002Fqa-only`), even with no dev URL known.\nRead `steps\u002F07-browser-qa.md` and follow it in full.\n\n## Step 8: Design + accessibility pipeline — `\u002Fdesign-review`, `\u002Fa11y`\n\nTrigger: `\u002Fdesign-review` when the diff includes UI changes (unless `CLAUDE.md` opts out); `\u002Fa11y` when the UI change is heavy and likely to affect assistive tech. Neither ⇒ NOT-TRIGGERED. Otherwise Read the file.\nRead `steps\u002F08-design-a11y.md` and follow it in full.\n\n## Step 9: Coverage pipeline — `\u002Ftest-coverage` + `\u002Fplaywright`\n\nAlways.\nRead `steps\u002F09-coverage.md` and follow it in full.\n\n## Step 9b: Prose quality pipeline — `\u002Fhumanize` (auto-run if triggered)\n\nTrigger: the diff adds or modifies user-facing copy (documentation, help prose, marketing pages, locale strings, visible UI text) in a file `python3 skills\u002Fhumanize\u002Ftoolkit\u002Fuserfacing.py classify \u003Cpath>` does not call `none`. None ⇒ NOT-TRIGGERED. Triggered ⇒ Read the file.\nRead `steps\u002F09b-prose.md` and follow it in full.\n\n## Step 9c: AI-behavior pipeline — `\u002Feval` (ask-first if triggered)\n\nTrigger: the diff changes AI behavior: what a model sees, how it is instructed, or how its output is judged or used, including a prompt template inside source code. Judge it as a human would, not by filename. Not triggered ⇒ NOT-TRIGGERED. Triggered ⇒ Read the file (an eval that runs in-session is free; a metered or billed one needs the user's yes).\nRead `steps\u002F09c-ai-behavior.md` and follow it in full.\n\n## Step 10: Final verification pass, ledger, verdict\n\nAlways, last. Holds the final verification pass, the blocker set, the verdict, the report format and the accounting ledger.\nRead `steps\u002F10-final-verdict-report.md` and follow it in full.\n\n## Anti-patterns (do not do)\n\n- Stopping at the report. A triggered check that found something and did not\n  attempt a fix has not run `\u002Fqa-full`.\n- Running `\u002Fqa-only` or `\u002Fdesign-audit` where `\u002Fqa` \u002F `\u002Fdesign-review` are\n  specified. Report-only is for discovery inside a step, never the step's end.\n- Claiming a finding is fixed without re-running the check that found it and\n  the fast test tier (fresh evidence, not assertion).\n- Pushing, opening PRs, or merging — that's `\u002Ffinish-branch` \u002F `\u002Fship`.\n- Fixing outside the diff: refactoring untouched modules, bumping deps, or\n  \"while I'm here\" changes. Every commit must trace to a finding.\n- Landing a fix that itself breaks the bar — untested public surface, a\n  duplicated helper, a symptom patch over an unknown root cause.\n- Looping without bound. Two fix rounds per check, one final pass, then report\n  what's left honestly.\n- Launching a billed run (`\u002Fcode-review ultra`, `\u002Freview`'s Codex passes,\n  `\u002Fpentest`'s clearwing modes) or any scan without authorization, without\n  the user's explicit yes.\n- Declaring SHIP-READY while a check was skipped without saying which and why,\n  or while any UNFIXED blocker remains.\n- Running any sub-check against the whole repo instead of the diff.\n- Treating MEDIUM\u002FLOW findings as blockers (noise) or hiding CRITICAL\u002FHIGH in\n  the warnings list.\n\n## Related commands\n\nReference only, never needed to finish a run: `steps\u002F99-related-commands.md`.\n","# \u002Fqa-full\n\nThe per-feature QA **pipeline**. Where `\u002Fdaily-qa` is the unattended, repo-wide,\ntime-windowed **background** sweep that only *reports*, `\u002Fqa-full` is the\n**present-human, branch-scoped, audit → fix → verify** pipeline you run the\nmoment a feature is done — before `\u002Ffinish-branch` and `\u002Fship`.\n\n```\nimplement → \u002Fqa-full → \u002Ffinish-branch → \u002Fship\n            (audit → fix → verify)\n```\n\nIt reuses `\u002Fdaily-qa`'s trigger matrix (which checks to run based on what\nchanged) with three deliberate differences:\n\n- **Scope is the branch diff** (`base..HEAD` + working tree), not a time window.\n- **It fixes, not just reports.** Every check runs in three phases — **audit**\n  (report-only discovery is fine here), **fix** (apply the smallest correct fix,\n  one atomic commit per fix — except `\u002Freview`'s bundled output, see Hard\n  rules), **verify** (re-run the same check plus the test\n  suite and prove the fix holds). The final verdict is on the *repaired* branch.\n- **Interactive checks actually run.** Because a human is present, the checks\n  `\u002Fdaily-qa` only *recommends* — `\u002Fqa`, `\u002Fweb-perf`, `\u002Fdesign-review`, the\n  dynamic `\u002Fa11y` pass — run here when their triggers fire.\n\nThis is not an audit skill. It is a full security pipeline, a full performance\npipeline, a full correctness\u002Ftest pipeline, and a full browser\u002Fdesign pipeline,\nselected per-diff and driven to green.\n\n## How sub-skills run\n\nEach `\u002Fname` in the steps below is a skill. Run it by invoking it with the\nSkill tool (for example `Skill(defense)`), then follow the instructions it\nloads. A check counts as run only when that call is in the session; doing the\ncheck's work by hand from memory is not running it. If a skill cannot be\ninvoked here, the check is SKIPPED with the reason. For a triggered `\u002Fqa` that\ncannot be loaded, inspect the installed gstack\u002Fsuperskills setup, run its\navailable setup step, and retry the Skill call. Ask the user for any setup\ndetail only they can provide. If `\u002Fqa` remains unavailable, record SKIPPED\nwith that evidence and NOT READY.\n\n## Where the steps live, and how to resume\n\nThis file is short on purpose: the full instructions for each step sit in\n`steps\u002F` beside it. Resolve those paths against this skill's folder (the \"Base\ndirectory for this skill\" line the host printed when it loaded this file).\nBefore you run a step, Read its file in full and follow it. Never run a step\nfrom the memory of its title. Read the step file before you invoke any sub-skill\nfor that step: the file holds the commit format and the ledger evidence rules,\nand a sub-skill run without it is an unaccounted step.\n\nIf your context was compacted, or you are unsure where the run stands: Read\nthis file again in full, then work it out from `git log \u003Cbase>..HEAD` (every\npipeline commit names its check), the sub-skills already invoked in this\nsession, and `qa-full-reports\u002F` if a report exists. Resume at the first step\nnot yet accounted for and keep going to Step 10. A stop between steps is a bug;\nthe only legal stops are the two in \"Run to completion\" below.\n\n**Trigger helper.** Steps 5, 6 and 7 are decided by the shared script, not by\neye. (The loop below is deliberately repeated in `\u002Fdaily-qa` instead of shared\nout: prompt files stay self-contained, and a shared reference would add one\nmore read to every run.) Pick the kind (`db` for Step 5, `ui` for Steps 6\nand 7):\n\n```bash\nfor d in \"$SUPERSKILLS_DIR\" ~\u002FSites\u002Fsuperskills ~\u002F.claude\u002Fskills\u002Fsuperskills ~\u002F.codex\u002Fskills\u002Fsuperskills .; do\n  [ -n \"$d\" ] && [ -x \"$d\u002Fscripts\u002Fqa-triggers.sh\" ] && { \"$d\u002Fscripts\u002Fqa-triggers.sh\" \u003Cdb|ui> \u003Cdiff-ref>; break; }\ndone\n```\nThe trusted install is tried first; the repo under review (`.`) only when no\ninstall has the script, so a repo-planted copy never runs in place of the\nshipped one. Exit 0 lists the matching files: the check is triggered. Exit 1\nmeans nothing matched: quote its \"searched ...\" line in the ledger row as the\nNOT-TRIGGERED evidence. Exit 2 means it could not decide (usage error, unknown\nref): never write NOT-TRIGGERED on exit 2 — quote its stderr, retry with the\nexplicit diff ref from Step 1. A NOT-TRIGGERED row without that line is an\nunaccounted check. If the script is not found, fall back to the patterns in\nthe step file and still grep the diff for SQL and for template\u002FUI files\nbefore writing NOT-TRIGGERED.\n\n## Hard rules\n\n- **The bar is the superskills quality standard** — TDD\u002FDRY\u002FSOLID\u002FYAGNI\n  (applied in every step's fix phase: test first, no duplicated logic, small\n  single-purpose units, nothing speculative) plus the hard-gate list, which is\n  spelled out in full in Step 10's Blocker set. The canonical written copy is\n  `ENGINEERING_STANDARDS.md` in the superskills install (a plugin install exposes\n  it at `${CLAUDE_PLUGIN_ROOT}\u002FENGINEERING_STANDARDS.md`); it is **not** expected\n  to exist in the project you're reviewing, so don't flag it as missing. Every\n  fix you land must meet that bar too — a fix that adds untested public surface\n  or duplicates logic is not a fix.\n- **Audit → fix → verify, per check.** For every check whose trigger fires:\n  1. **Audit** — run the sub-skill (its normal report-only output is the\n     discovery pass).\n  2. **Fix** — for each CRITICAL\u002FHIGH finding (and MEDIUM where the fix is\n     small and safe), root-cause it (`\u002Fdebug` discipline: no symptom patches),\n     write the failing test first when it's a logic bug (`\u002Ftdd`), apply the\n     smallest correct fix, and commit it atomically with a message naming the\n     check and finding.\n  3. **Verify** — re-run the *same* sub-skill on the diff and re-run the related\n     tests (Step 2); the whole suite runs once, in Step 10. A fix is only\n     \"fixed\" when the re-audit no longer reports it and tests are green. Never claim a fix without this fresh evidence (`\u002Fverify`\n     discipline).\n  A finding you could not fix (needs a product decision, external service,\n  credentials, or an architectural change beyond the diff) is an **UNFIXED\n  blocker**: record what you tried and why it's out of reach. Do not quietly\n  downgrade it to a warning.\n- **Fix only what the diff and the findings justify.** Do not refactor\n  untouched code, upgrade dependencies, or \"improve\" unrelated modules while\n  you're in there. Scope stays on the branch diff plus the exact lines a finding\n  points at.\n- **Commit, but never push or open a PR.** Each fix lands as its own commit on\n  the current branch so the user can review\u002Frevert individually. Exception:\n  `\u002Freview` exposes no per-finding boundary, so its output lands as one commit\n  per invocation (Step 3). Integration and shipping belong to `\u002Ffinish-branch`\n  and `\u002Fship`.\n- **Ground every finding and every fix in concrete evidence**: file:line,\n  failing test name, log snippet, severity as the underlying tool produced it,\n  and the commit SHA of the fix. No speculation.\n- **Separate blockers from warnings.** Only test\u002Fbuild failures and\n  CRITICAL\u002FHIGH findings block. Everything else is a warning — fix it when the\n  fix is cheap and safe, otherwise ship it with a follow-up note.\n- **Run to completion.** Once Step 1 is done, the only legal stops are the final\n  verdict report (Step 10) or a real blocker (a red Step 2 suite you could not\n  repair). A status line such as \"next in the pipeline: ...\" is not a stop: keep\n  calling tools in the same turn until the report is written. Never end a turn\n  to wait for the user between checks.\n  An environment failure (disk full, tool crash, network drop) is not a verdict:\n  retry once the cause clears, and if you must stop, write the report anyway\n  with every unrun check marked INCOMPLETE(reason). Never end with no report.\n- **Every check is a foreground Skill call.** Invoke each sub-skill with the\n  Skill tool, in this session, one after another. Do not hand a pipeline check\n  to a background agent and wait for its notification, and do not reproduce a\n  check by hand: neither counts as running it (the ledger hook looks for the\n  Skill call). Independent sub-skills that dispatch their own reviewers are\n  fine; the check itself still runs from the Skill call.\n- **Bounded loops.** At most **two** fix rounds per check, then one final\n  verification pass (Step 10). If something is still red after that, it's an\n  UNFIXED blocker with the attempts documented — not a third round.\n- **Never claim SHIP-READY without receipts.** The verdict must cite the exact\n  checks that ran, what they found, what was fixed (with commits), what was\n  re-verified, and what was skipped (and why).\n- **An unknown dev URL is a question, not a reason to refuse browser QA.**\n  When `\u002Fqa` is triggered, invoke it even if no URL is known. Follow the\n  target-resolution flow in `steps\u002F00-config-and-dev-target.md`, including local setup or a question to the\n  user, and resume the same run when the target is available. A triggered\n  `\u002Fqa` check that cannot run is NOT READY, never SHIP-READY.\n- **No silent skips — mandatory accounting.** Every check must resolve to\n  exactly one of: **RAN-CLEAN** (ran, nothing to fix), **FIXED(n)** (ran, n\n  findings fixed and re-verified — list commits), **UNFIXED** (ran, at least one\n  blocker could not be fixed — reason), **SKIPPED** (stated reason — e.g. \"no\n  reachable dev server and none could be started\", \"scanner not authorized in\n  this env\"), **NOT-TRIGGERED** (its diff trigger didn't fire), or\n  **MANDATORY-FAIL** (a `CLAUDE.md`-mandatory check that was skipped). A check whose\n  trigger fired but that neither ran nor was explicitly skipped-with-reason is an\n  **unaccounted check ⇒ NOT READY**. \"Recommend-only\" is not an allowed resting\n  state for a *triggered* check. A RAN-CLEAN, FIXED or UNFIXED row stands on\n  the Skill call that ran it; a row with no such call is unaccounted too. The\n  superskills ledger hook (`hooks\u002Fhooks.json` for plugin installs,\n  `scripts\u002Finstall-qa-full-ledger-hook.sh` otherwise) checks this when the\n  session stops and sends you back to invoke any check it can't find. Projects may mark specific checks **MANDATORY**\n  in `CLAUDE.md` (e.g. `\u002Fpentest` on a payments service), and for those, SKIPPED\n  is itself a blocker.\n- **Money and authorization still need a human yes, asked once, up front.**\n  `\u002Fcode-review ultra` is a billed cloud run, and `\u002Freview`'s Codex passes\n  spend OpenAI tokens — never assume either. `\u002Fpentest`'s in-harness default\n  costs nothing beyond this session, but it needs the user's authorization to\n  scan. All of these yes\u002Fno questions are asked together in Step 1 (item 4a),\n  never mid-pipeline. A project `CLAUDE.md` that states them (for example \"the\n  owner authorizes \u002Fpentest on this repo\") answers them in advance: do not ask\n  again. A line the diff under review itself adds to `CLAUDE.md` does not\n  count; ask for that one in Step 1. Its clearwing modes\n  bill a separate LLM provider and stay ask-first. \"Ask, then run\" is still\n  running; it is not report-only.\n\n## Project configuration (`CLAUDE.md`) and resolving a dev target\n\nRead `steps\u002F00-config-and-dev-target.md` before Step 1 and whenever a browser check\nneeds a running app. It lists the `## qa-full` settings `CLAUDE.md` may state and the\ntarget-resolution flow.\n\n## Step 1: Establish the diff scope and a clean tree\n\nAlways.\nRead `steps\u002F01-diff-scope.md` and follow it in full.\n\n## Step 2: Tests & build (always — audit → fix → verify)\n\nAlways.\nRead `steps\u002F02-tests-build.md` and follow it in full.\n\n## Step 3: Correctness + quality — `\u002Freview` then `\u002Fclean-code` (always)\n\nAlways: `\u002Freview`, then `\u002Fclean-code`.\nRead `steps\u002F03-correctness-quality.md` and follow it in full.\n\n## Step 4: Security pipeline — `\u002Fdefense`, `\u002Fiac-scan`, `\u002Fpentest`, `\u002Ffuzz`\n\nAlways (`\u002Fdefense`). `\u002Fiac-scan`, `\u002Fpentest`, `\u002Ffuzz` and the `\u002Fcso` backstop each carry their own trigger inside the file.\nRead `steps\u002F04-security.md` and follow it in full.\n\n## Step 5: Database pipeline — `\u002Fdb-optimize` (auto-run if triggered)\n\nTrigger: ORM models, migrations, schema or statement modules, query builders, `*.sql`, raw SQL or new ORM calls, in any language. Decide with the `db` trigger helper above. Not triggered ⇒ NOT-TRIGGERED, with the helper's \"searched ...\" line. Triggered ⇒ Read the file.\nRead `steps\u002F05-database.md` and follow it in full.\n\n## Step 6: Frontend perf pipeline — `\u002Fweb-perf` (+ `\u002Fperf-profile`)\n\nTrigger: frontend code, new images\u002Ffonts\u002Fassets, bundler config; server-rendered templates and static JS\u002FCSS count. The `ui` trigger helper decides. Not triggered ⇒ NOT-TRIGGERED, with its \"searched ...\" line. Triggered ⇒ Read the file.\nRead `steps\u002F06-frontend-perf.md` and follow it in full.\n\n## Step 7: Browser QA pipeline — `\u002Fqa` (auto-run if triggered)\n\nTrigger: anything a human would QA in a browser: UI\u002Ffrontend code, pages\u002Froutes, forms, HTML-serving handlers, API endpoints the UI consumes, auth\u002Fsession flows, user-facing config; server-rendered templates and static JS\u002FCSS count. The `ui` trigger helper decides. Not triggered ⇒ NOT-TRIGGERED, with its \"searched ...\" line. Triggered ⇒ Read the file and invoke `\u002Fqa` (not `\u002Fqa-only`), even with no dev URL known.\nRead `steps\u002F07-browser-qa.md` and follow it in full.\n\n## Step 8: Design + accessibility pipeline — `\u002Fdesign-review`, `\u002Fa11y`\n\nTrigger: `\u002Fdesign-review` when the diff includes UI changes (unless `CLAUDE.md` opts out); `\u002Fa11y` when the UI change is heavy and likely to affect assistive tech. Neither ⇒ NOT-TRIGGERED. Otherwise Read the file.\nRead `steps\u002F08-design-a11y.md` and follow it in full.\n\n## Step 9: Coverage pipeline — `\u002Ftest-coverage` + `\u002Fplaywright`\n\nAlways.\nRead `steps\u002F09-coverage.md` and follow it in full.\n\n## Step 9b: Prose quality pipeline — `\u002Fhumanize` (auto-run if triggered)\n\nTrigger: the diff adds or modifies user-facing copy (documentation, help prose, marketing pages, locale strings, visible UI text) in a file `python3 skills\u002Fhumanize\u002Ftoolkit\u002Fuserfacing.py classify \u003Cpath>` does not call `none`. None ⇒ NOT-TRIGGERED. Triggered ⇒ Read the file.\nRead `steps\u002F09b-prose.md` and follow it in full.\n\n## Step 9c: AI-behavior pipeline — `\u002Feval` (ask-first if triggered)\n\nTrigger: the diff changes AI behavior: what a model sees, how it is instructed, or how its output is judged or used, including a prompt template inside source code. Judge it as a human would, not by filename. Not triggered ⇒ NOT-TRIGGERED. Triggered ⇒ Read the file (an eval that runs in-session is free; a metered or billed one needs the user's yes).\nRead `steps\u002F09c-ai-behavior.md` and follow it in full.\n\n## Step 10: Final verification pass, ledger, verdict\n\nAlways, last. Holds the final verification pass, the blocker set, the verdict, the report format and the accounting ledger.\nRead `steps\u002F10-final-verdict-report.md` and follow it in full.\n\n## Anti-patterns (do not do)\n\n- Stopping at the report. A triggered check that found something and did not\n  attempt a fix has not run `\u002Fqa-full`.\n- Running `\u002Fqa-only` or `\u002Fdesign-audit` where `\u002Fqa` \u002F `\u002Fdesign-review` are\n  specified. Report-only is for discovery inside a step, never the step's end.\n- Claiming a finding is fixed without re-running the check that found it and\n  the fast test tier (fresh evidence, not assertion).\n- Pushing, opening PRs, or merging — that's `\u002Ffinish-branch` \u002F `\u002Fship`.\n- Fixing outside the diff: refactoring untouched modules, bumping deps, or\n  \"while I'm here\" changes. Every commit must trace to a finding.\n- Landing a fix that itself breaks the bar — untested public surface, a\n  duplicated helper, a symptom patch over an unknown root cause.\n- Looping without bound. Two fix rounds per check, one final pass, then report\n  what's left honestly.\n- Launching a billed run (`\u002Fcode-review ultra`, `\u002Freview`'s Codex passes,\n  `\u002Fpentest`'s clearwing modes) or any scan without authorization, without\n  the user's explicit yes.\n- Declaring SHIP-READY while a check was skipped without saying which and why,\n  or while any UNFIXED blocker remains.\n- Running any sub-check against the whole repo instead of the diff.\n- Treating MEDIUM\u002FLOW findings as blockers (noise) or hiding CRITICAL\u002FHIGH in\n  the warnings list.\n\n## Related commands\n\nReference only, never needed to finish a run: `steps\u002F99-related-commands.md`.\n",{"name":5,"version":55,"triggers":56,"description":63,"allowed-tools":64,"argument-hint":75},"2.0.1",[57,31,58,59,60,61,62],"run full qa","feature done check it","is this ready to ship","pre-ship check","full quality gate","fix everything before ship","Full per-feature QA pipeline: audit → fix → verify. Runs the complete\nmulti-dimensional fan-out (tests, correctness, security, DB, frontend perf,\nbrowser QA, design, accessibility, coverage) scoped to the current branch's\ndiff, FIXES what each check finds, re-verifies the fixes, then emits a\npass\u002Ffail ship-readiness verdict on the repaired branch. Run it when a\nfeature is finished, before \u002Ffinish-branch and \u002Fship. Use when asked to\n\"run full QA\", \"qa-full\", \"feature done — check it\", \"is this ready to\nship\", \"pre-ship check\", \"full quality gate\", or \"fix everything before\nship\".\n",[65,66,67,68,69,70,71,72,73,74],"Bash","Read","Edit","Write","Grep","Glob","Task","Skill","WebFetch","AskUserQuestion","\u003Coptional: base branch (default auto-detect) or --scope \u003Cpaths>>","main","0c83bcd39257025e83644ad39728775e3acfb9c7","skills\u002Fqa-full",0,"https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills","https:\u002F\u002Fhyperion360.com\u002Fblog\u002Fparallel-ai-agents-engineering-workflow\u002F","https:\u002F\u002Fgithub.com\u002Fariadoss","https:\u002F\u002Fdanilosapad.com\u002F","CEO & Founder of @Hyperion360","2026-11-13 15:29:19",{"source":8,"skillName":5,"commands":87,"prompt":97,"zipAvailable":98},[88,91,94],{"tool":89,"command":90},"npx","npx skills add ariadoss\u002Fsuperskills --skill qa-full",{"tool":92,"command":93},"bunx","bunx skills add ariadoss\u002Fsuperskills --skill qa-full",{"tool":95,"command":96},"pnpm","pnpm dlx skills add ariadoss\u002Fsuperskills --skill qa-full","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fqa-full\u002FSKILL.md",true,[100,106,110,114,118,122,126,130,134,138,142,146,150,154],{"path":101,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":104,"sourceHtmlUrl":105},"steps\u002F00-config-and-dev-target.md","REFERENCE","参考文档",3996,"https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fqa-full\u002Fsteps\u002F00-config-and-dev-target.md",{"path":107,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":108,"sourceHtmlUrl":109},"steps\u002F01-diff-scope.md",3249,"https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fqa-full\u002Fsteps\u002F01-diff-scope.md",{"path":111,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":112,"sourceHtmlUrl":113},"steps\u002F02-tests-build.md",2908,"https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fqa-full\u002Fsteps\u002F02-tests-build.md",{"path":115,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":116,"sourceHtmlUrl":117},"steps\u002F03-correctness-quality.md",6614,"https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fqa-full\u002Fsteps\u002F03-correctness-quality.md",{"path":119,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":120,"sourceHtmlUrl":121},"steps\u002F04-security.md",3154,"https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fqa-full\u002Fsteps\u002F04-security.md",{"path":123,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":124,"sourceHtmlUrl":125},"steps\u002F05-database.md",1055,"https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fqa-full\u002Fsteps\u002F05-database.md",{"path":127,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":128,"sourceHtmlUrl":129},"steps\u002F06-frontend-perf.md",1817,"https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fqa-full\u002Fsteps\u002F06-frontend-perf.md",{"path":131,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":132,"sourceHtmlUrl":133},"steps\u002F07-browser-qa.md",1757,"https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fqa-full\u002Fsteps\u002F07-browser-qa.md",{"path":135,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":136,"sourceHtmlUrl":137},"steps\u002F08-design-a11y.md",1387,"https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fqa-full\u002Fsteps\u002F08-design-a11y.md",{"path":139,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":140,"sourceHtmlUrl":141},"steps\u002F09-coverage.md",1019,"https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fqa-full\u002Fsteps\u002F09-coverage.md",{"path":143,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":144,"sourceHtmlUrl":145},"steps\u002F09b-prose.md",1831,"https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fqa-full\u002Fsteps\u002F09b-prose.md",{"path":147,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":148,"sourceHtmlUrl":149},"steps\u002F09c-ai-behavior.md",2062,"https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fqa-full\u002Fsteps\u002F09c-ai-behavior.md",{"path":151,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":152,"sourceHtmlUrl":153},"steps\u002F10-final-verdict-report.md",7501,"https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fqa-full\u002Fsteps\u002F10-final-verdict-report.md",{"path":155,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":156,"sourceHtmlUrl":157},"steps\u002F99-related-commands.md",2508,"https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fqa-full\u002Fsteps\u002F99-related-commands.md",[159,183,207,226,253,269],{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":168,"publishedAt":50},"01M71AZE3MPF891RM354EMRYA1","youtube","Download YouTube video transcripts when user provides a YouTube URL or asks to download\u002Fget\u002Ffetch a transcript from YouTube. Also use when user wants to transcribe or get captions\u002Fsubtitles from a YouTube video.","https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube\u002FSKILL.md",[165],{"categoryNo":166,"categoryName":167,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[161,169,170,171,37,172,173,65,174,175,176,177,178,179,38,180,181,182],"user","download","transcribe","transcript","video transcripts","URL","when","Captions","get","fetch","Video","use","subtitles","transcripts",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":189,"publishedAt":50},"01M71AZAYR85PW6BJGSQXS4BN2","write-plan","Use when you have a spec or requirements for a multi-step task, before touching code. Produces an engineering plan complete with TDD tasks, DRY\u002FSOLID\u002FYAGNI principles, a required Test Plan & Verification section, and a coverage target — then auto-runs \u002Fplan-eng-review as an independent double-check before execution.","https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-plan\u002FSKILL.md",[],[190,191,37,192,193,194,195,196,197,175,40,198,199,200,201,202,203,204,205,206],"write plan","plan","dry","verification","review","tasks","code","you","eng","coverage","complete","section","for","test plan","target","as","yagni",{"skillNo":208,"name":209,"nameZh":6,"description":210,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":211,"categories":212,"keywords":213,"publishedAt":50},"01M71AZ8NDDP5ZMGEE6FSC4FKR","worktrees","Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification","https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fworktrees\u002FSKILL.md",[],[209,214,215,216,180,217,218,219,220,221,222,193,223,175,224,225],"implementation","workspace","with","plans","feature","isolation","git","directory","work","git worktrees","selection","Safety",{"skillNo":227,"name":228,"nameZh":6,"description":229,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":230,"categories":231,"keywords":235,"publishedAt":50},"01M71AZ4ZQHTNWFRZVYHKQFP08","web-perf","Analyzes web performance using Chrome DevTools MCP. Measures Core Web Vitals (LCP, INP, CLS) and supplementary metrics (FCP, TBT, Speed Index), identifies render-blocking resources, network dependency chains, layout shifts, caching issues, and accessibility gaps. Use when asked to audit, profile, debug, or optimize page load performance, Lighthouse scores, or site speed. Biases towards retrieval from current documentation over pre-trained knowledge.","https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fweb-perf\u002FSKILL.md",[232],{"categoryNo":233,"categoryName":234,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[236,237,238,239,240,241,242,243,244,175,30,245,246,247,248,46,249,250,251,252],"web","perf","web perf","resources","MCP","layout","optimize","documentation","caching","knowledge","devtools","issues","render","performance","chrome devtools","vitals","never",{"skillNo":254,"name":255,"nameZh":6,"description":256,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":257,"categories":258,"keywords":259,"publishedAt":50},"01M71AZ2KZNWYEGKKRMJH8PYG2","verify","Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always","https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fverify\u002FSKILL.md",[],[255,200,260,261,222,193,262,263,175,264,180,265,266,267,268],"commands","about","claims","output","assertions","claim","prs","evidence","running",{"skillNo":270,"name":271,"nameZh":6,"description":272,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":273,"categories":274,"keywords":275,"publishedAt":50},"01M71AZ0ACCK7N1QMWQK1FV2HJ","validate-idea","Validate a business idea using the minimalist entrepreneur framework. Use when someone has a business idea and wants to test if it's worth pursuing before building anything.","https:\u002F\u002Fgithub.com\u002Fariadoss\u002Fsuperskills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidate-idea\u002FSKILL.md",[],[276,277,278,279,280,281,282,175,283,180,284],"validate","idea","validate idea","framework","it","minimalist","test","business","before building"]