[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69BJ71F38DR2QASW4HZ8K2Q":3,"skill-same:01M69BJ71F38DR2QASW4HZ8K2Q":65},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":21,"linkOnly":22,"markdownContent":23,"markdownBody":24,"frontMatter":25,"refName":29,"commitSha":30,"skillDirectory":31,"forksCount":32,"repositoryHtmlUrl":33,"repositoryHomepageUrl":6,"ownerHtmlUrl":34,"ownerBlogUrl":35,"ownerDescription":36,"updatedAt":37,"install":38,"resources":50},"01M69BJ71F38DR2QASW4HZ8K2Q","goalify",null,"Compose and lint a \u002Fgoal stop-condition from the current conversation, catching known termination-failure patterns before showing it to the user. Use when the user wants to turn the current task into a \u002Fgoal loop, asks to \"goalify this\", wants a stop condition for autonomous work, says \"write a goal condition\", \"make this a \u002Fgoal\", \"turn this into a goal\", or asks for help wording a condition for \u002Fgoal.","microsoft\u002Famplifier-app-cli","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69BHYVWVEWQF0DY6W6TMESV",19,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Fgoalify\u002FSKILL.md",[],[5,19,20],"lint","help","2026-11-10 10:12:30",false,"---\nname: goalify\ndescription: >\n  Compose and lint a \u002Fgoal stop-condition from the current conversation,\n  catching known termination-failure patterns before showing it to the user.\n  Use when the user wants to turn the current task into a \u002Fgoal loop, asks to\n  \"goalify this\", wants a stop condition for autonomous work, says \"write a\n  goal condition\", \"make this a \u002Fgoal\", \"turn this into a goal\", or asks for\n  help wording a condition for \u002Fgoal.\nuser-invocable: true\nversion: 1.3.0\nlicense: MIT\n---\n\nRun this procedure yourself, in the current conversation. Do not delegate it\nto a sub-agent or forked session — Phase 1 reads the live transcript.\n\n$ARGUMENTS\n\nIf the user supplied focus text above, use it to scope Phase 1. If empty,\nextract from conversation alone — do not ask the user to restate what they\nalready said.\n\n---\n\n## Phase 1 — Extract\n\nFrom the conversation so far, determine:\n\n- **The target end state.** What does \"finished\" concretely look like? It\n  must be a state that can be checked, not an activity that can be performed\n  indefinitely. (\"a usable app\" is checkable; \"finish building the project\"\n  is not — there is no test for \"finished building\".)\n- **What is already done.** Re-read the transcript for completed sub-tasks,\n  passing tests, merged changes, or resolved questions. These become\n  candidates for the KNOWN section (Phase 2) or for narrowing scope\n  (SCOPE-OUTS).\n- **What is explicitly NOT required.** Anything the user has ruled out,\n  deferred, or said isn't needed. This is the raw material for SCOPE-OUTS.\n\nIf the end state genuinely cannot be determined from context (not merely\neffortful to determine), ask one direct question. Otherwise proceed —\nguessing and then showing your extraction for correction is faster than\nfront-loading a question the transcript already answers.\n\n## Phase 2 — Compose\n\nEmit a candidate condition using this structure. Every element is required\nunless marked optional.\n\n1. **One-sentence outcome** naming a checkable end state (not an activity).\n2. **Disjunctive exit**: the condition must be satisfiable by *either*\n   reaching the end state *or* conclusively demonstrating it cannot be\n   reached (naming the blocker). Never phrase a condition with only one exit.\n3. **Per-item negative terminal**, if the condition lists multiple items\n   (tasks, sites, phases, experiments). Each item must be able to resolve to\n   its own PASS \u002F FAIL \u002F BLOCKED-with-named-reason — a blocker on one item\n   converts *that item* to a residual; it must not block the whole goal.\n4. **SCOPE-OUTS section** — an explicit list of what is *not* required. Write\n   this by directly converting anything from Phase 1's \"not required\" list\n   into a plain negative statement (e.g. \"No production soak time required.\"\n   \u002F \"Uniformity across all N items is NOT the goal.\").\n5. **Reachable terminal verb**, whenever finishing depends on an external\n   system that can *refuse* — a work-tracker claim or resolution, a merge, a\n   deploy, a publish. Name the primary verb AND the verb to use when the\n   primary refuses. A terminal verb with no reachable fallback is a missing\n   disjunctive exit one layer down: the actor can reach the end state and\n   still be unable to record it, which reads to the evaluator as \"not done\"\n   forever. See L7 for the work-tracker case, which is mandatory.\n6. **KNOWN section (optional)** — facts already established, so the actor\n   doesn't re-derive them. Label it explicitly as a speed aid: it prevents\n   wasted turns, it does not by itself prevent stalls, so it never replaces\n   items 1–5.\n\n## Phase 3 — Lint\n\nCheck the full composed document against every rule below. Work through all\nBLOCKERS first; a document with any BLOCKER triggered is not ready to show.\nThen check WARNINGS, which are advisory and do not block presentation.\n\n**Read the whole document for each check.** Several of these rules are only\ndetectable by considering the document as one system — a single clause\nelsewhere can silently defeat a correct-looking rule everywhere else. Do not\nscan for keywords in isolation and stop at the first clean-looking match.\n\n### BLOCKERS — fix all before presenting\n\n- **L1 — Ordering\u002Fprovenance constraint on the transcript's own history.**\n  Any phrasing that requires evidence to precede, or be produced independent\n  of, events that already exist in the transcript (e.g. \"verify it yourself,\n  then state what you verified\", \"proof must precede the claim\", \"evidence\n  you produced yourself\" applied to something already reported by a\n  sub-agent or prior turn). This class of requirement is **unrepairable** —\n  no later turn can change what already happened earlier in the transcript,\n  so it cannot be fixed by adding more work. If the condition constrains\n  ordering, it must constrain only *future* actions, never re-litigate what\n  is already in the history.\n\n- **L2 — Universal quantifier over a set with possibly-exempt members.**\n  \"all N\", \"every X\", \"each of the Y\", \"uniform\u002Funiformity\", \"complete\n  parity\", applied to a set, is a blocker **unless** each item individually\n  carries a negative terminal (see Compose #3) or the condition names which\n  members are exempt and why. Without one of those, a single member that\n  cannot structurally produce the required evidence makes the whole\n  condition permanently unsatisfiable.\n\n- **L3 — Elapsed wall-clock requirement.** Anything that requires real time\n  to pass beyond the current session: \"production soak\", \"after N days of\n  use\", \"monitor over time\", \"verify in real-world use\". A single session\n  cannot advance wall-clock time; this can never be satisfied in-session.\n\n- **L4 — Human-in-the-loop or external-actor dependency mid-loop.**\n  \"stop and ask me if you need a decision\", \"once a reviewer merges this\",\n  \"wait for approval before continuing\". This directly conflicts with\n  unattended continuation — the loop will halt waiting on an event that a\n  condition-checking loop cannot itself produce.\n\n- **L5 — Open enumeration.** Scope phrased as an unbounded or unenumerated\n  set: \"all editing features of X\", \"complete parity with Y\", \"everything\n  needed to fully support Z\". An evaluator can always name one more item\n  under this phrasing, so it never terminates. Convert to a closed, named\n  list, or to a single representative artifact.\n\n- **L7 — Work-tracker terminal verb that can refuse.** Any condition whose\n  completion requires `work_resolve` or `work_release` is a blocker **unless\n  the condition also names `work_erratum` as the terminal verb for the case\n  where the item is already resolved, or held by another session.** Both\n  `work_resolve` and `work_release` refuse a session that does not hold the\n  item, and no amount of further work makes them succeed — so a condition\n  that ends only in those verbs has no reachable terminal state from the\n  moment a sibling session resolves the item. `work_erratum` is append-only,\n  requires no claim, and any actor may call it at any time, which is exactly\n  why it is the fallback.\n\n  **This applies to EVERY lane targeting a shared or many-lanes work item, not\n  only the lane that happens to discover the problem.** Write the fallback in;\n  do not leave each lane to rediscover it.\n\n  Required wording in the composed condition (adapt the names, keep the\n  structure and keep it as a plain instruction, per W4):\n\n  ```\n  TERMINAL VERBS. Record the outcome with\n  work_resolve(id=\u003Citem>, reason=\u003Cuser-readable summary>) when this session\n  holds the item. If work_claim refused, or the item is already resolved, or\n  another session holds it: record the outcome with\n  work_erratum(project=\u003Cproject>, item_id=\u003Citem>, text=\u003Csame summary>)\n  instead — append-only, no claim required — and treat that as the terminal\n  step, complete. Do NOT retry work_resolve or work_release in that state;\n  both refuse a session that never held the item.\n  ```\n\n- **L0 — Cross-clause consistency (meta-rule).** *An escape hatch is only as\n  strong as the strictest other clause in the same document.* After\n  confirming L1–L7 pass individually and a disjunctive exit exists, re-read\n  the document once more asking only: **is there any other sentence, anywhere\n  in the document, that is stricter than the stated exit and would override\n  it?** A document can have a textbook-perfect exit clause and still be\n  unsatisfiable because one unrelated sentence elsewhere re-imposes an L1–L7\n  style constraint the exit clause doesn't cover. Confirming an exit clause\n  exists is not sufficient — confirm nothing else in the document is\n  stricter than it.\n\n- **L7 — Infrastructure provisioned without teardown or handoff in DONE.**\n  This one is not about whether the condition can terminate, but about the\n  state it leaves behind when it does. If the goal stands up anything that\n  outlives the run — containers, VMs, background servers, external\n  environments — the condition must make *teardown-complete*, or an explicit\n  named handoff to an owner, part of DONE. A goal whose satisfied state leaves\n  resources running and unowned is abandoned, not finished. Does not fire for\n  goals that provision nothing.\n\n### WARNINGS — advisory, do not block presentation\n\n- **L6 — Missing disjunctive exit.** The document should state achievement\n  *or* a way to conclusively end in \"not achievable, here is why\" (see\n  Compose #2). Flag and fix its absence where practical, but do not block\n  presentation on it alone.\n- **W1** — Multiple items are listed but not all of them carry their own\n  negative terminal (some do, some don't).\n- **W2** — No clause asking the actor to show evidence inline in the\n  transcript as it's produced, rather than only asserting a result.\n- **W3** — Scope reads like more than one session's worth of work (multi-week\n  rollout language, coordination across many independent repos\u002Fteams,\n  phased production deployment).\n- **W4** — The condition contains a cautionary anecdote or narrative about a\n  failure mode (e.g. \"don't repeat what went wrong last time\", \"make sure\n  this doesn't stall like before\") rather than a plain instruction. Any such\n  narrative addressed to the actor is read by the evaluator too, and can\n  silently become a criterion the evaluator judges against instead of\n  guidance the actor merely follows. State requirements as plain criteria,\n  never as stories.\n\n  **This applies to the condition you are composing right now.** Write every\n  clause as a direct instruction to the actor, never as a story about a past\n  run. If you catch yourself writing \"so that we don't repeat X\", rewrite it\n  as the direct requirement it implies, with no reference to the incident.\n\n### If a BLOCKER cannot be cleared\n\nRewrite and re-check. Allow up to three rewrite passes. If a BLOCKER still\nfires after three passes, stop and surface the specific tension to the user\nby name (e.g. \"the user's own request requires enumerating an open-ended set\n— L5 fires no matter how I phrase it; how would you like to bound this?\").\nDo not present a condition that still fails a BLOCKER.\n\n---\n\n## Output format\n\nProduce output in this exact order:\n\n1. **Write the file.** Write the condition text to\n   `.amplifier\u002Fgoals\u002F\u003Cslug>.md` (create the directory if it does not exist),\n   where `\u003Cslug>` is a kebab-case slug (≤ 40 chars) of the one-sentence\n   outcome. Overwrite if the file already exists. State the path on its own\n   line, e.g. `Wrote: .amplifier\u002Fgoals\u002Fusable-checkout-flow.md`.\n2. **Render inline.** Immediately after, show the same condition inside a\n   fenced code block — terminal reflow will otherwise destroy its\n   multi-line structure.\n3. **Lint table.** Follow with the lint report as a table.\n4. **Next step, last.** End the entire response with the recommended next\n   step and nothing after it: offer (do not auto-run) `\u002Fgoal @\u003Cpath>` using\n   the path from step 1, framed as what to run once any edits to the file\n   are made and saved.\n\nWrote: `.amplifier\u002Fgoals\u002F\u003Cslug>.md`\n\n```\n\u003Cthe condition text>\n```\n\n| Rule | Result | Note |\n|------|--------|------|\n| L0 | no known pattern detected | ... |\n| L1 | no known pattern detected | ... |\n| L2 | no known pattern detected | ... |\n| L3 | no known pattern detected | ... |\n| L4 | no known pattern detected | ... |\n| L5 | no known pattern detected | ... |\n| L7 | no known pattern detected | ... |\n| L6, W1–W4 | (list only the ones that fired) | ... |\n\nA clean table means no *known* failure pattern was detected — not that the\ncondition is validated. Say so if the user reads it as a guarantee.\n\nEdit `.amplifier\u002Fgoals\u002F\u003Cslug>.md` directly for any changes. Then, as the\nlast line of the response: \"Once you're happy with the file, run `\u002Fgoal\n@.amplifier\u002Fgoals\u002F\u003Cslug>.md` to start the loop — want me to run it now, or\nwould you like to adjust anything first?\"\n","Run this procedure yourself, in the current conversation. Do not delegate it\nto a sub-agent or forked session — Phase 1 reads the live transcript.\n\n$ARGUMENTS\n\nIf the user supplied focus text above, use it to scope Phase 1. If empty,\nextract from conversation alone — do not ask the user to restate what they\nalready said.\n\n---\n\n## Phase 1 — Extract\n\nFrom the conversation so far, determine:\n\n- **The target end state.** What does \"finished\" concretely look like? It\n  must be a state that can be checked, not an activity that can be performed\n  indefinitely. (\"a usable app\" is checkable; \"finish building the project\"\n  is not — there is no test for \"finished building\".)\n- **What is already done.** Re-read the transcript for completed sub-tasks,\n  passing tests, merged changes, or resolved questions. These become\n  candidates for the KNOWN section (Phase 2) or for narrowing scope\n  (SCOPE-OUTS).\n- **What is explicitly NOT required.** Anything the user has ruled out,\n  deferred, or said isn't needed. This is the raw material for SCOPE-OUTS.\n\nIf the end state genuinely cannot be determined from context (not merely\neffortful to determine), ask one direct question. Otherwise proceed —\nguessing and then showing your extraction for correction is faster than\nfront-loading a question the transcript already answers.\n\n## Phase 2 — Compose\n\nEmit a candidate condition using this structure. Every element is required\nunless marked optional.\n\n1. **One-sentence outcome** naming a checkable end state (not an activity).\n2. **Disjunctive exit**: the condition must be satisfiable by *either*\n   reaching the end state *or* conclusively demonstrating it cannot be\n   reached (naming the blocker). Never phrase a condition with only one exit.\n3. **Per-item negative terminal**, if the condition lists multiple items\n   (tasks, sites, phases, experiments). Each item must be able to resolve to\n   its own PASS \u002F FAIL \u002F BLOCKED-with-named-reason — a blocker on one item\n   converts *that item* to a residual; it must not block the whole goal.\n4. **SCOPE-OUTS section** — an explicit list of what is *not* required. Write\n   this by directly converting anything from Phase 1's \"not required\" list\n   into a plain negative statement (e.g. \"No production soak time required.\"\n   \u002F \"Uniformity across all N items is NOT the goal.\").\n5. **Reachable terminal verb**, whenever finishing depends on an external\n   system that can *refuse* — a work-tracker claim or resolution, a merge, a\n   deploy, a publish. Name the primary verb AND the verb to use when the\n   primary refuses. A terminal verb with no reachable fallback is a missing\n   disjunctive exit one layer down: the actor can reach the end state and\n   still be unable to record it, which reads to the evaluator as \"not done\"\n   forever. See L7 for the work-tracker case, which is mandatory.\n6. **KNOWN section (optional)** — facts already established, so the actor\n   doesn't re-derive them. Label it explicitly as a speed aid: it prevents\n   wasted turns, it does not by itself prevent stalls, so it never replaces\n   items 1–5.\n\n## Phase 3 — Lint\n\nCheck the full composed document against every rule below. Work through all\nBLOCKERS first; a document with any BLOCKER triggered is not ready to show.\nThen check WARNINGS, which are advisory and do not block presentation.\n\n**Read the whole document for each check.** Several of these rules are only\ndetectable by considering the document as one system — a single clause\nelsewhere can silently defeat a correct-looking rule everywhere else. Do not\nscan for keywords in isolation and stop at the first clean-looking match.\n\n### BLOCKERS — fix all before presenting\n\n- **L1 — Ordering\u002Fprovenance constraint on the transcript's own history.**\n  Any phrasing that requires evidence to precede, or be produced independent\n  of, events that already exist in the transcript (e.g. \"verify it yourself,\n  then state what you verified\", \"proof must precede the claim\", \"evidence\n  you produced yourself\" applied to something already reported by a\n  sub-agent or prior turn). This class of requirement is **unrepairable** —\n  no later turn can change what already happened earlier in the transcript,\n  so it cannot be fixed by adding more work. If the condition constrains\n  ordering, it must constrain only *future* actions, never re-litigate what\n  is already in the history.\n\n- **L2 — Universal quantifier over a set with possibly-exempt members.**\n  \"all N\", \"every X\", \"each of the Y\", \"uniform\u002Funiformity\", \"complete\n  parity\", applied to a set, is a blocker **unless** each item individually\n  carries a negative terminal (see Compose #3) or the condition names which\n  members are exempt and why. Without one of those, a single member that\n  cannot structurally produce the required evidence makes the whole\n  condition permanently unsatisfiable.\n\n- **L3 — Elapsed wall-clock requirement.** Anything that requires real time\n  to pass beyond the current session: \"production soak\", \"after N days of\n  use\", \"monitor over time\", \"verify in real-world use\". A single session\n  cannot advance wall-clock time; this can never be satisfied in-session.\n\n- **L4 — Human-in-the-loop or external-actor dependency mid-loop.**\n  \"stop and ask me if you need a decision\", \"once a reviewer merges this\",\n  \"wait for approval before continuing\". This directly conflicts with\n  unattended continuation — the loop will halt waiting on an event that a\n  condition-checking loop cannot itself produce.\n\n- **L5 — Open enumeration.** Scope phrased as an unbounded or unenumerated\n  set: \"all editing features of X\", \"complete parity with Y\", \"everything\n  needed to fully support Z\". An evaluator can always name one more item\n  under this phrasing, so it never terminates. Convert to a closed, named\n  list, or to a single representative artifact.\n\n- **L7 — Work-tracker terminal verb that can refuse.** Any condition whose\n  completion requires `work_resolve` or `work_release` is a blocker **unless\n  the condition also names `work_erratum` as the terminal verb for the case\n  where the item is already resolved, or held by another session.** Both\n  `work_resolve` and `work_release` refuse a session that does not hold the\n  item, and no amount of further work makes them succeed — so a condition\n  that ends only in those verbs has no reachable terminal state from the\n  moment a sibling session resolves the item. `work_erratum` is append-only,\n  requires no claim, and any actor may call it at any time, which is exactly\n  why it is the fallback.\n\n  **This applies to EVERY lane targeting a shared or many-lanes work item, not\n  only the lane that happens to discover the problem.** Write the fallback in;\n  do not leave each lane to rediscover it.\n\n  Required wording in the composed condition (adapt the names, keep the\n  structure and keep it as a plain instruction, per W4):\n\n  ```\n  TERMINAL VERBS. Record the outcome with\n  work_resolve(id=\u003Citem>, reason=\u003Cuser-readable summary>) when this session\n  holds the item. If work_claim refused, or the item is already resolved, or\n  another session holds it: record the outcome with\n  work_erratum(project=\u003Cproject>, item_id=\u003Citem>, text=\u003Csame summary>)\n  instead — append-only, no claim required — and treat that as the terminal\n  step, complete. Do NOT retry work_resolve or work_release in that state;\n  both refuse a session that never held the item.\n  ```\n\n- **L0 — Cross-clause consistency (meta-rule).** *An escape hatch is only as\n  strong as the strictest other clause in the same document.* After\n  confirming L1–L7 pass individually and a disjunctive exit exists, re-read\n  the document once more asking only: **is there any other sentence, anywhere\n  in the document, that is stricter than the stated exit and would override\n  it?** A document can have a textbook-perfect exit clause and still be\n  unsatisfiable because one unrelated sentence elsewhere re-imposes an L1–L7\n  style constraint the exit clause doesn't cover. Confirming an exit clause\n  exists is not sufficient — confirm nothing else in the document is\n  stricter than it.\n\n- **L7 — Infrastructure provisioned without teardown or handoff in DONE.**\n  This one is not about whether the condition can terminate, but about the\n  state it leaves behind when it does. If the goal stands up anything that\n  outlives the run — containers, VMs, background servers, external\n  environments — the condition must make *teardown-complete*, or an explicit\n  named handoff to an owner, part of DONE. A goal whose satisfied state leaves\n  resources running and unowned is abandoned, not finished. Does not fire for\n  goals that provision nothing.\n\n### WARNINGS — advisory, do not block presentation\n\n- **L6 — Missing disjunctive exit.** The document should state achievement\n  *or* a way to conclusively end in \"not achievable, here is why\" (see\n  Compose #2). Flag and fix its absence where practical, but do not block\n  presentation on it alone.\n- **W1** — Multiple items are listed but not all of them carry their own\n  negative terminal (some do, some don't).\n- **W2** — No clause asking the actor to show evidence inline in the\n  transcript as it's produced, rather than only asserting a result.\n- **W3** — Scope reads like more than one session's worth of work (multi-week\n  rollout language, coordination across many independent repos\u002Fteams,\n  phased production deployment).\n- **W4** — The condition contains a cautionary anecdote or narrative about a\n  failure mode (e.g. \"don't repeat what went wrong last time\", \"make sure\n  this doesn't stall like before\") rather than a plain instruction. Any such\n  narrative addressed to the actor is read by the evaluator too, and can\n  silently become a criterion the evaluator judges against instead of\n  guidance the actor merely follows. State requirements as plain criteria,\n  never as stories.\n\n  **This applies to the condition you are composing right now.** Write every\n  clause as a direct instruction to the actor, never as a story about a past\n  run. If you catch yourself writing \"so that we don't repeat X\", rewrite it\n  as the direct requirement it implies, with no reference to the incident.\n\n### If a BLOCKER cannot be cleared\n\nRewrite and re-check. Allow up to three rewrite passes. If a BLOCKER still\nfires after three passes, stop and surface the specific tension to the user\nby name (e.g. \"the user's own request requires enumerating an open-ended set\n— L5 fires no matter how I phrase it; how would you like to bound this?\").\nDo not present a condition that still fails a BLOCKER.\n\n---\n\n## Output format\n\nProduce output in this exact order:\n\n1. **Write the file.** Write the condition text to\n   `.amplifier\u002Fgoals\u002F\u003Cslug>.md` (create the directory if it does not exist),\n   where `\u003Cslug>` is a kebab-case slug (≤ 40 chars) of the one-sentence\n   outcome. Overwrite if the file already exists. State the path on its own\n   line, e.g. `Wrote: .amplifier\u002Fgoals\u002Fusable-checkout-flow.md`.\n2. **Render inline.** Immediately after, show the same condition inside a\n   fenced code block — terminal reflow will otherwise destroy its\n   multi-line structure.\n3. **Lint table.** Follow with the lint report as a table.\n4. **Next step, last.** End the entire response with the recommended next\n   step and nothing after it: offer (do not auto-run) `\u002Fgoal @\u003Cpath>` using\n   the path from step 1, framed as what to run once any edits to the file\n   are made and saved.\n\nWrote: `.amplifier\u002Fgoals\u002F\u003Cslug>.md`\n\n```\n\u003Cthe condition text>\n```\n\n| Rule | Result | Note |\n|------|--------|------|\n| L0 | no known pattern detected | ... |\n| L1 | no known pattern detected | ... |\n| L2 | no known pattern detected | ... |\n| L3 | no known pattern detected | ... |\n| L4 | no known pattern detected | ... |\n| L5 | no known pattern detected | ... |\n| L7 | no known pattern detected | ... |\n| L6, W1–W4 | (list only the ones that fired) | ... |\n\nA clean table means no *known* failure pattern was detected — not that the\ncondition is validated. Say so if the user reads it as a guarantee.\n\nEdit `.amplifier\u002Fgoals\u002F\u003Cslug>.md` directly for any changes. Then, as the\nlast line of the response: \"Once you're happy with the file, run `\u002Fgoal\n@.amplifier\u002Fgoals\u002F\u003Cslug>.md` to start the loop — want me to run it now, or\nwould you like to adjust anything first?\"\n",{"name":5,"license":15,"version":26,"description":27,"user-invocable":28},"1.3.0","Compose and lint a \u002Fgoal stop-condition from the current conversation, catching known termination-failure patterns before showing it to the user. Use when the user wants to turn the current task into a \u002Fgoal loop, asks to \"goalify this\", wants a stop condition for autonomous work, says \"write a goal condition\", \"make this a \u002Fgoal\", \"turn this into a goal\", or asks for help wording a condition for \u002Fgoal.\n",true,"main","631c4bdbcf3dcd2da20456ad6ccef386e778c101","amplifier_app_cli\u002Fdata\u002Fskills\u002Fgoalify",28,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-12 01:45:24",{"source":8,"skillName":5,"commands":39,"prompt":49,"zipAvailable":28},[40,43,46],{"tool":41,"command":42},"npx","npx skills add microsoft\u002Famplifier-app-cli --skill goalify",{"tool":44,"command":45},"bunx","bunx skills add microsoft\u002Famplifier-app-cli --skill goalify",{"tool":47,"command":48},"pnpm","pnpm dlx skills add microsoft\u002Famplifier-app-cli --skill goalify","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Fgoalify\u002FSKILL.md",[51,57,61],{"path":52,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":55,"sourceHtmlUrl":56},"examples\u002Fknown-bad-L1-ordering.md","REFERENCE","参考文档",1169,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Fgoalify\u002Fexamples\u002Fknown-bad-L1-ordering.md",{"path":58,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":59,"sourceHtmlUrl":60},"examples\u002Fknown-bad-L2-quantifier.md",1491,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Fgoalify\u002Fexamples\u002Fknown-bad-L2-quantifier.md",{"path":62,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":63,"sourceHtmlUrl":64},"PROVENANCE.md",5209,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Fgoalify\u002FPROVENANCE.md",[66,81,91,99],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":21},"01M69BJ9BX3FSEPSFADNZFTZBA","ten-lane-highway","Become the Highway Manager: drive many parallel \u002Fgoal lanes continuously toward a defined outcome, refilling lanes on every manager cycle so none sit idle. Use when the user wants continuous parallel throughput toward an outcome: \"run the highway\", \"\u002Fhighway\", \"10-lane highway\", \"keep N lanes full\", \"keep re-feeding lanes as they drain\", \"drive this for me in parallel\", \"do them all and monitor\", \"keep the lanes full\", \"work the whole list in parallel until done\". NOT for a one-shot batch that launches once and drains together — use goal-batch. NOT for bounded edits that each end in their own PR — use mass-change. Requires git, tmux, the amplifier CLI on PATH, and the goalify and monitor skills.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Ften-lane-highway\u002FSKILL.md",[],[73,5,74,75,76,77,78,79,80],"ten lane highway","git","run","monitor","pr","change","tmux","cli",{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":21},"01M69BJ51WJSADYHSFYAGMNDK3","goal-batch","Batch independent work into isolated \u002Fgoal lanes. Triggers: \"run these in parallel\", \"goal-batch\", \"launch lanes for these\", \"work these N tasks simultaneously\", \"batch these as goals\". Show the plan; require explicit user approval before launch; verify results before landing. Not for bounded per-PR edits (mass-change) or continuous refill-on-drain work (ten-lane-highway).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Fgoal-batch\u002FSKILL.md",[],[88,77,75,89,78,90],"goal batch","tasks","launch",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":21},"01M69BJ3GMC0R27M16QKP33XYZ","doctor","Diagnose an Amplifier CLI environment through the CLI doctor agent. USE WHEN a user requests CLI runtime, settings or missing-capability inspection. DO NOT USE for project bugs or other hosts.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Fdoctor\u002FSKILL.md",[],[93,98,80],"diagnose",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":21},"01M69BJ1PV3RT2VTC0PVVXJMC1","amplifier-config","Explain, inspect, troubleshoot, and safely modify Amplifier CLI configuration — providers, settings scopes, bundles, routing, skills, and source overrides. Use when someone describes desired Amplifier CLI behavior and needs effective-value provenance, a safe change plan, implementation, or outcome-based verification.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-app-cli\u002Fblob\u002Fmain\u002Famplifier_app_cli\u002Fdata\u002Fskills\u002Famplifier-config\u002FSKILL.md",[],[106,107,80,108,78,109,110],"config","amplifier config","routing","troubleshoot","safe"]