@r1z4x/tezgah 1.9.0 → 1.11.0

package/skills/harness/SKILL.md

@@ -1,17 +1,24 @@
 ---
 name: harness
 description: >
-  Pick and run the right multi-agent harness for a task in this tree, backed by the
-  codegraph index. Routes to the graph-map, graph-review, or graph-impact dynamic
-  workflows, or to a single general-purpose subagent briefed with the codegraph tools when a full harness is overkill.
-  Use when the user asks for depth, coverage, an audit, a full review, "every call
-  site", "what breaks if", "how does this work end to end", says ultracode, or when
-  a task is too wide for one context window. Not for a task whose deliverable is
-  evidence rather than code - use `research`.
+  Use when the ask needs depth: an audit, every call site, what breaks if;
+  detaylı incele, tüm çağrı noktaları; ultracode. Not for evidence - use
+  `research`.
 ---
 
 # harness
 
+## When to use
+
+Pick and run the right multi-agent harness for a task in this tree, backed by
+the codegraph index. Routes to the graph-map, graph-review, or graph-impact
+dynamic workflows, or to a single general-purpose subagent briefed with the
+codegraph tools when a full harness is overkill. Use when the user asks for
+depth, coverage, an audit, a full review, "every call site", "what breaks if",
+"how does this work end to end", says ultracode, or when a task is too wide for
+one context window. Not for a task whose deliverable is evidence rather than
+code - use `research`.
+
 This skill is the **multi-agent** sense of the word "harness": it picks and runs a
 multi-agent harness over the code graph for a task too wide for one context window.
 It is not tezgah's own layer around a host, and not the runtime a host itself is -
@@ -61,7 +68,7 @@ is reported as such, and an empty list beside it is not evidence of absence.
 and `unverified` (hit the cap, or every refuter failed - label them as such). Never promote a refuted or unverified finding.
 
 `graph-review` is one review round, not a loop: inside a plan it is round one or round two of the
-plan's single review (two rounds at most, `tezgah-task review` refuses a third), never one run per
+plan's single review (two rounds at most, `~/.config/tezgah/bin/tezgah-task review` refuses a third), never one run per
 task, and never re-run on a diff it already read.
 
 `graph-impact`'s `graph_blind_spots` are call sites the graph could not see - string dispatch, config,

package/skills/i-have-adhd/SKILL.md

@@ -1,16 +1,8 @@
 ---
 name: i-have-adhd
 description: >
-  Shapes output for a reader who acts on it: answer or next action on the first
-  line, numbered steps for multi-step work, the position restated in one line
-  while work is in flight, tangents suppressed, errors as location/cause/fix,
-  lists capped at five ranked items, estimates marked as estimates, and no
-  preamble, recap or closer. Use on any answer the reader has to act on - a fix,
-  a plan, a report, a status update. Also use when the user says "i-have-adhd",
-  "adhd mode", "shape the output", "lead with the action", or complains that the
-  answer buried the point. Not for code comments, commit messages, docs and
-  anything else that is not a reply to a person (the exec contract governs
-  those) - use `no-ai-slop` for that prose.
+  Use when the reply is something to act on: a fix, plan, report, status; adhd
+  mode; kısaca, adım adım, ne yapmam lazım. Not for docs - use `no-ai-slop`.
 license: MIT
 metadata:
   tags: "output style, actionability, reporting"
@@ -23,6 +15,19 @@ metadata:
 
 # i-have-adhd
 
+## When to use
+
+Shapes output for a reader who acts on it: answer or next action on the first
+line, numbered steps for multi-step work, the position restated in one line
+while work is in flight, tangents suppressed, errors as location/cause/fix,
+lists capped at five ranked items, estimates marked as estimates, and no
+preamble, recap or closer. Use on any answer the reader has to act on - a fix, a
+plan, a report, a status update. Also use when the user says "i-have-adhd",
+"adhd mode", "shape the output", "lead with the action", or complains that the
+answer buried the point. Not for code comments, commit messages, docs and
+anything else that is not a reply to a person (the exec contract governs those) -
+use `no-ai-slop` for that prose.
+
 The reader acts on the answer. Friction between "got it" and "did it" is where
 the work dies, and a buried answer is friction.
 
@@ -59,7 +64,13 @@ Bad: "Let's look at this. Your auth flow has a few moving pieces..."
 Good: "Run `npm install jsonwebtoken@9`, then edit `src/auth.ts:42`."
 
 If the answer is a decision, the decision is the first line, with the reasoning
-after it.
+after it. If the answer is steps, line 1 is step 1 itself - `1. <path or
+command>: <what to do>` - and nothing stands above the list. A diagnosis is
+context, not an action: the cause goes inside the step it explains.
+
+Bad: "Kök sorun: the dashboard has no loading state.", then the steps.
+Good: "1. `src/Dashboard.jsx:5`: add a loading state - the blank screen is why
+users leave."
 
 ### 2. Number multi-step work
 

package/skills/no-ai-slop/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: no-ai-slop
-description: Edit drafts into sharper, more human writing while preserving the writer's personal voice, or detect AI-slop patterns without rewriting. Use when the user wants a draft clearer, more direct, more opinionated, or less AI-sounding, or asks whether writing reads as AI. Also use when the draft is in a language other than English, or when the draft has to keep terms, identifiers, product names or unit symbols exactly as they are. Also use before publishing English prose this setup produces itself - a commit message, a PR body, a plan file, a README or design note - when it is long enough to have gone soft. Not for shaping a reply the reader has to act on - use `i-have-adhd`.
+description: >
+  Use when a draft reads AI-sounding; yapay zeka gibi, insani yaz; sharper,
+  human prose in any language. Not for a reply to act on - use `i-have-adhd`.
 ---
 
 <!-- Source: https://github.com/petergyang/no-ai-slop (MIT, Peter Yang).
@@ -13,6 +15,18 @@ description: Edit drafts into sharper, more human writing while preserving the w
 
 # No AI slop
 
+## When to use
+
+Edit drafts into sharper, more human writing while preserving the writer's
+personal voice, or detect AI-slop patterns without rewriting. Use when the user
+wants a draft clearer, more direct, more opinionated, or less AI-sounding, or
+asks whether writing reads as AI. Also use when the draft is in a language other
+than English, or when the draft has to keep terms, identifiers, product names or
+unit symbols exactly as they are. Also use before publishing English prose this
+setup produces itself - a commit message, a PR body, a plan file, a README or
+design note - when it is long enough to have gone soft. Not for shaping a reply
+the reader has to act on - use `i-have-adhd`.
+
 You are a sharp human editor. Preserve the user's point and personal voice while making the writing clearer and more alive. Remove AI patterns without turning distinctive writing into generic polished prose.
 
 ## In this setup

package/skills/plan-add/SKILL.md

@@ -1,18 +1,25 @@
 ---
 name: plan-add
 description: >
-  Creates a new plan file under <git root>/.tezgah/plans/open/ from free text, bootstraps
-  the .tezgah/plans/ layer (README + open/ + done/) if missing, refreshes the README status
-  table, and commits it as `plan: add NNN slug` in the private .tezgah repository. Use when a piece of work
-  spans sessions or waits on something and the user says "/tezgah:plan-add <text>",
-  "add a plan", "track this as a plan", or "make a plan for ...". Do NOT use for
-  small self-contained edits that fit in one session. Not for reading which plans
-  are open - use `plan-status`.
+  Use when work spans sessions: track this as a plan, add a plan,
+  /tezgah:plan-add; plan oluştur, birkaç oturum. Not for open plans - use
+  `plan-status`.
 argument-hint: "<one-line description of the work>"
 ---
 
 # plan-add
 
+## When to use
+
+Creates a new plan file under <git root>/.tezgah/plans/open/ from free text,
+bootstraps the .tezgah/plans/ layer (README + open/ + done/) if missing,
+refreshes the README status table, and commits it as `plan: add NNN slug` in the
+private .tezgah repository. Use when a piece of work spans sessions or waits on
+something and the user says "/tezgah:plan-add <text>", "add a plan", "track this
+as a plan", or "make a plan for ...". Do NOT use for small self-contained edits
+that fit in one session. Not for reading which plans are open - use
+`plan-status`.
+
 Input: `$ARGUMENTS` (free text describing the work). Run these steps in order.
 
 1. Resolve the root: `ROOT=$(git rev-parse --show-toplevel)`. If it fails, stop and
@@ -41,7 +48,7 @@ Input: `$ARGUMENTS` (free text describing the work). Run these steps in order.
    word `unverifiable` and why, since *when possible* is the loophole
    (`~/.config/tezgah/bin/tezgah-render-table --acceptance` reports the items that
    name no command). An item that names no command keeps the plan out of a
-   writing phase (`tezgah-task` refuses it, through the predicate `--strict`
+   writing phase (`~/.config/tezgah/bin/tezgah-task` refuses it, through the predicate `--strict`
    refuses on), so this is the plan's own check, not a report read later. State:
    `not started` plus the findings from
    step 4. Next: the first concrete action - when the plan holds two or more
@@ -49,14 +56,14 @@ Input: `$ARGUMENTS` (free text describing the work). Run these steps in order.
    worktree and a subset of `allowed_paths:`, spawned in one message. Dates: `date +%F`. `allowed_paths:`:
    the globs the work will write, from the files step 4 found (`apps/admin/**`,
    `packages/ui/src/**`), narrow enough that a write outside them is a surprise
-   - the plan names its own scope, and `tezgah-task start` without `--allow`
+   - the plan names its own scope, and `~/.config/tezgah/bin/tezgah-task start` without `--allow`
    holds the task to it. A plan that has to spike an assumption first (does the
    approach work at all?) writes the four `spike:` keys below: `implementation`
    is refused while `spike_recorded:` names no answer, so the answer is recorded
    before the build rather than after it. `after:`: the ids of the open plans
    this one cannot start before (`after: 012, 015`), only when step 4 found a
    real dependency - a plan with none can run beside the others, and
-   `tezgah-task status` names which ready plans share no `allowed_paths:` prefix.
+   `~/.config/tezgah/bin/tezgah-task status` names which ready plans share no `allowed_paths:` prefix.
 6. Rewrite the README status table: `~/.config/tezgah/bin/tezgah-render-table` (installed by `bin/tezgah-setup --install`; if it is missing, run that script)
    (one row per open plan, sorted by id; it prints the rows). A new plan has no PR
    state to enrich, so no `--pr-info` here; that enrichment belongs to plan-status.
@@ -69,7 +76,7 @@ Input: `$ARGUMENTS` (free text describing the work). Run these steps in order.
    no "Generated with" / "Made with", no robot emoji, no Claude/Anthropic/OpenAI/
    GPT/Codex/Gemini/Cursor/Copilot credit.
 8. Report the file path and the table row.
-9. Start it yourself with `tezgah-task` - the lifecycle is the session's, never
+9. Start it yourself with `~/.config/tezgah/bin/tezgah-task` - the lifecycle is the session's, never
    a command handed to the user:
    `~/.config/tezgah/bin/tezgah-task start NNN --phase discovery` writes `phase:`
    into this file and clears the phase from every other open plan. To run two
@@ -91,22 +98,22 @@ Input: `$ARGUMENTS` (free text describing the work). Run these steps in order.
    `checkpoint:` - the commit the work returns to - and uncommitted work has none
    to record. Make the checkpoint commit it prints, then run the phase move
    again and the sha is written. Move the phase yourself as the work reaches it
-   (`tezgah-task phase implementation`, then `verification`); when a write is
+   (`~/.config/tezgah/bin/tezgah-task phase implementation`, then `verification`); when a write is
    refused for its path and the plan's work genuinely reaches that file, widen
-   the scope with `tezgah-task allow <glob> ... --why "<reason>"`, which records the reason. Never retype the record:
+   the scope with `~/.config/tezgah/bin/tezgah-task allow <glob> ... --why "<reason>"`, which records the reason. Never retype the record:
    the gate refuses a write to it, because the CLI's checks would be skipped.
-   Tick an Acceptance box with `tezgah-task tick NNN <n>` (`--undo` unticks),
-   rewrite State or Next with `tezgah-task note NNN state|next "<text>"`,
-   record the spike's answer with `tezgah-task spike NNN "<answer>"`, which
+   Tick an Acceptance box with `~/.config/tezgah/bin/tezgah-task tick NNN <n>` (`--undo` unticks),
+   rewrite State or Next with `~/.config/tezgah/bin/tezgah-task note NNN state|next "<text>"`,
+   record the spike's answer with `~/.config/tezgah/bin/tezgah-task spike NNN "<answer>"`, which
    writes `spike_recorded:` on the plan, active or not, and annotate an item the
-   owner accepted as not met with `tezgah-task unmet NNN <n> "<reason, who
+   owner accepted as not met with `~/.config/tezgah/bin/tezgah-task unmet NNN <n> "<reason, who
    accepted it>"`, which writes `UNMET:` and is the form `close done` takes in
    place of a tick. These four work from the main checkout or from any of its
    worktrees.
-   After the merge, `tezgah-task close NNN done` deactivates the plan,
+   After the merge, `~/.config/tezgah/bin/tezgah-task close NNN done` deactivates the plan,
    moves it to done and removes every merged worktree. It refuses while an
    Acceptance box is open: tick it, or, only when the owner accepted the item
-   as not met, end it with `tezgah-task unmet NNN <n> "<reason, who accepted
+   as not met, end it with `~/.config/tezgah/bin/tezgah-task unmet NNN <n> "<reason, who accepted
    it>"`, which writes the `UNMET:` line and leaves the box open.
 
 10. If the work settles a decision that is hard to reverse, spans components, or
@@ -147,27 +154,27 @@ after:
 ```
 
 `allowed_paths:` is written here, at creation (step 5): the scope the task's
-writes have to stay inside, one glob per `- ` line. `tezgah-task` adds the rest:
+writes have to stay inside, one glob per `- ` line. `~/.config/tezgah/bin/tezgah-task` adds the rest:
 `phase:` - `discovery`, `implementation` or `verification`, on one open plan, or
 on one plan per worktree when their scopes share no prefix (step 9) - is the
 activation key the gate reads, set when the session starts
 the task itself (step 9); `allowed_from:` records where a scope the CLI replaced came from.
-`tezgah-task phase verification` lists what the plan owes before it is done: its
+`~/.config/tezgah/bin/tezgah-task phase verification` lists what the plan owes before it is done: its
 acceptance commands run unpiped, and a fresh reviewer (the host's
 `tezgah-reviewer` subagent) reading the diff, whose verdict
-`tezgah-task review NNN <reviewer> approve|changes` records as `review:`.
-`tezgah-task close NNN done` (plan-sync) refuses without an `approve`, and on an
+`~/.config/tezgah/bin/tezgah-task review NNN <reviewer> approve|changes` records as `review:`.
+`~/.config/tezgah/bin/tezgah-task close NNN done` (plan-sync) refuses without an `approve`, and on an
 unticked Acceptance item with no `UNMET: <reason>`; `discarded` needs neither.
 
 `after:` names the plans that must be done before this one starts - a `- NNN`
-block or `after: 012, 015`. `tezgah-task status` reads it: each open plan's
+block or `after: 012, 015`. `~/.config/tezgah/bin/tezgah-task status` reads it: each open plan's
 Acceptance boxes ticked (`acceptance 3/8 checked`), what it still waits on
 (`waits on 012 (open)`), and a `parallel:` line naming the ready plans whose
 `allowed_paths:` share no prefix, which can run at once in separate worktrees.
 An `after:` id no plan carries, or an open plan whose `status:` is not open or
 blocked, is a `FAIL` line there.
 
-`checkpoint:` is written by `tezgah-task` when the phase moves to
+`checkpoint:` is written by `~/.config/tezgah/bin/tezgah-task` when the phase moves to
 `implementation`: the sha of the commit the work returns to, or `pending` while
 the tree still holds work no commit names - and while it reads `pending` the gate
 refuses that phase's writes until the tree is committed, because one state to
@@ -177,7 +184,7 @@ return to is what a large refactor has instead of 200 per-file snapshots
 The four `spike:` keys are optional and go together, on a plan that must answer
 one question before it can be built: `spike:` is that question, `spike_box:` the
 time box (minutes, or one focused session), `spike_recorded:` where the answer
-is recorded (`tezgah-task spike NNN "<answer>"` writes it) - empty until it is,
+is recorded (`~/.config/tezgah/bin/tezgah-task spike NNN "<answer>"` writes it) - empty until it is,
 which is what refuses `implementation` - and
 `spike_throwaway:` whether the code is thrown away once it has answered. Nothing
 enforces the throwaway half, because `allowed_paths:` already does: a spike pins

package/skills/plan-status/SKILL.md

@@ -1,17 +1,23 @@
 ---
 name: plan-status
 description: >
-  Reads every open plan under <git root>/.tezgah/plans/open/, enriches rows with live PR
-  state from `gh`, rewrites the README status table, commits it as
-  `plan: update status` in the private .tezgah repository, and ends with a single recommendation for which plan to
-  work on next. Use when the user says "/tezgah:plan-status", "what plans are open",
-  "plan status", "where are we on the plans", or at the start of a session to pick
-  work. Read-only except the README table and filling an empty `pr:` field. Not
-  for closing finished plans - use `plan-sync`.
+  Use when asking what plans are open, plan status, what to work on next; açık
+  planlar, sıradaki iş, devam. Not for closing plans - use `plan-sync`.
 ---
 
 # plan-status
 
+## When to use
+
+Reads every open plan under <git root>/.tezgah/plans/open/, enriches rows with
+live PR state from `gh`, rewrites the README status table, commits it as `plan:
+update status` in the private .tezgah repository, and ends with a single
+recommendation for which plan to work on next. Use when the user says
+"/tezgah:plan-status", "what plans are open", "plan status", "where are we on
+the plans", or at the start of a session to pick work. Read-only except the
+README table and filling an empty `pr:` field. Not for closing finished plans -
+use `plan-sync`.
+
 1. Resolve the root: `ROOT=$(git rev-parse --show-toplevel)`. If it fails, stop and
    say plans need a git repo. If `$ROOT/.tezgah/plans/open` is missing, say so and stop.
 2. For each `.tezgah/plans/open/*.md`: read the frontmatter (id, title, status, branch, pr)

package/skills/plan-sync/SKILL.md

@@ -1,18 +1,24 @@
 ---
 name: plan-sync
 description: >
-  Closes out finished plans: fetches origin, checks each open plan's branch for a
-  merged or closed PR (or a branch merged into main), marks it done or discarded,
-  moves it to .tezgah/plans/done/ (a done plan only with an approving review),
-  rewrites the README status table, and commits one `plan: done NNN slug` (or
-  `plan: discard`) per moved plan in the private .tezgah repository. Use when the user says
-  "/tezgah:plan-sync", "sync plans", "close finished plans", or after PRs were merged.
-  Removes branches only via tezgah-task close; edits only .tezgah/plans. Not for
-  a status read of the open plans - use `plan-status`.
+  Use when PRs merged and it is time to sync plans and close finished plans;
+  biten planları kapat, planları eşitle. Not for a status read - use
+  `plan-status`.
 ---
 
 # plan-sync
 
+## When to use
+
+Closes out finished plans: fetches origin, checks each open plan's branch for a
+merged or closed PR (or a branch merged into main), marks it done or discarded,
+moves it to .tezgah/plans/done/ (a done plan only with an approving review),
+rewrites the README status table, and commits one `plan: done NNN slug` (or
+`plan: discard`) per moved plan in the private .tezgah repository. Use when the
+user says "/tezgah:plan-sync", "sync plans", "close finished plans", or after
+PRs were merged. Removes branches only via `~/.config/tezgah/bin/tezgah-task close`; edits only
+.tezgah/plans. Not for a status read of the open plans - use `plan-status`.
+
 1. Resolve the root: `ROOT=$(git rev-parse --show-toplevel)`. If it fails, stop and
    say plans need a git repo. If `$ROOT/.tezgah/plans/open` is missing, say so and stop.
 2. `git fetch --prune origin`.
@@ -40,7 +46,7 @@ description: >
    refuses `done` unless the
    plan records `review: <reviewer> approve` - fresh reviewers (the host's
    `tezgah-reviewer` subagent, one per dimension in one message for a large diff)
-   read `git diff <base>..HEAD` and `tezgah-task review NNN <reviewer> approve`
+   read `git diff <base>..HEAD` and `~/.config/tezgah/bin/tezgah-task review NNN <reviewer> approve`
    wrote the verdict. A refused plan stays open:
    report it with the refusal, never move it by hand, and never start a review
    round from here. One review per plan, over its whole diff in the verification
@@ -50,7 +56,7 @@ description: >
    tr: KARAR); after round two what is left is fixed by the session and closed
    with `--resolved`, or recorded fix-later only with DECISION (tr: KARAR),
    never a third round. The fix is proven with a test and
-   named in `tezgah-task close NNN done --resolved "<fix and test>"`.
+   named in `~/.config/tezgah/bin/tezgah-task close NNN done --resolved "<fix and test>"`.
 7. Rewrite the README status table: `~/.config/tezgah/bin/tezgah-render-table` (installed by `bin/tezgah-setup --install`; if it is missing, run that script)
    (one row per open plan, sorted by id; it prints the rows). No `--pr-info` here:
    the row's `pr` cell comes from the plan files, and review/check enrichment
@@ -69,9 +75,9 @@ description: >
    GPT/Codex/Gemini/Cursor/Copilot credit.
 9. Report four lists: moved plans (with done/discarded and the evidence line),
    plans `close` refused (with its reason), still-open plans - each with what
-   `tezgah-task status` says it waits on, so a plan whose `after:` names one just
+   `~/.config/tezgah/bin/tezgah-task status` says it waits on, so a plan whose `after:` names one just
    discarded (`waits on NNN (discarded)`) is named for the user to re-plan - and
-   gh failures. Never delete a branch or a worktree by hand (`tezgah-task close`
+   gh failures. Never delete a branch or a worktree by hand (`~/.config/tezgah/bin/tezgah-task close`
    removes the landed ones), never edit code outside `.tezgah/plans/`.
 
 ## Format

package/skills/pm-frameworks/SKILL.md

@@ -1,26 +1,35 @@
 ---
 name: pm-frameworks
 description: >
-  Two product-management methods vendored offline behind the `product-analysis`
-  skill: the intended-vs-implemented gap audit (a gap is a finding only when the
-  documented intent and the code that enforces it are both cited) and the
-  Opportunity Solution Tree (one outcome, opportunities as needs, solutions
-  compared, the cheapest experiment per assumption). Use when a product question
-  needs the method, not just the framework name: intended-vs-implemented audits,
-  opportunity solution trees, discovery mapping and assumption tests. Read the
-  one entry the task needs, never both by default.
+  Use when a PM ask needs a method: opportunity solution trees, PM gözüyle,
+  fırsat çözüm ağacı, intended-vs-implemented. Not for surveys - use
+  `product-analysis`.
 ---
 
 # pm-frameworks
 
+## When to use
+
+Two product-management methods vendored offline behind the `product-analysis`
+skill: the intended-vs-implemented gap audit (a gap is a finding only when the
+documented intent and the code that enforces it are both cited) and the
+Opportunity Solution Tree (one outcome, opportunities as needs, solutions
+compared, the cheapest experiment per assumption). Use when a product question
+needs the method, not just the framework name: intended-vs-implemented audits,
+opportunity solution trees, discovery mapping and assumption tests. Read the one
+entry the task needs, never both by default.
+
 Two methods, kept byte-for-byte from `https://github.com/phuryn/pm-skills` (MIT)
 at the revision recorded in `SOURCE`. They are here so an offline session can
 read the method rather than cite its name.
 
 | Read | When |
 |---|---|
-| `intended-vs-implemented/SKILL.md` | auditing what a system says it does against what the code does - permissions, trust boundaries, an "internal only" comment that nothing enforces. The PE axis of `product-analysis`. |
-| `opportunity-solution-tree/SKILL.md` | structuring discovery: one outcome, opportunities as customer needs, three or more solutions compared before a choice, the cheapest experiment per risky assumption. The PM axis of `product-analysis`. |
+| `intended-vs-implemented/ENTRY.md` | auditing what a system says it does against what the code does - permissions, trust boundaries, an "internal only" comment that nothing enforces. The PE axis of `product-analysis`. |
+| `opportunity-solution-tree/ENTRY.md` | structuring discovery: one outcome, opportunities as customer needs, three or more solutions compared before a choice, the cheapest experiment per risky assumption. The PM axis of `product-analysis`. |
+
+Each is upstream's `SKILL.md` renamed `ENTRY.md`, bytes unchanged, so a host that
+lists every `SKILL.md` below its skills directory does not list it.
 
 `product-analysis` is the tezgah skill that consumes both; this one is the text.
 Neither file is a rule: the contract's evidence classes, the `research`

package/skills/pm-frameworks/SOURCE

@@ -8,13 +8,14 @@ are byte-for-byte upstream, frontmatter included. Checkout for a re-vendor:
 ## What is vendored
 
 Two skills, one `SKILL.md` each, at the upstream path so a vendored file is
-findable again. The manifest is this table, and `tests/test_skills.py` holds it
-to the bytes.
+findable again, renamed `ENTRY.md` (bytes unchanged) so a host that lists every
+`SKILL.md` below its skills directory (codex, Cursor) does not list it. The
+manifest is this table, and `tests/test_skills.py` holds it to the bytes.
 
 | file | upstream path | sha256 | lines |
 |---|---|---|---|
-| `intended-vs-implemented/SKILL.md` | `pm-ai-shipping/skills/intended-vs-implemented/SKILL.md` | `6d917f0e59f78ea6b5d847f57b1c816baa2948cac56529939589cd73d2e4c9eb` | 42 |
-| `opportunity-solution-tree/SKILL.md` | `pm-product-discovery/skills/opportunity-solution-tree/SKILL.md` | `6b23e44a5ace86aa20d64cc130322265ace6a53a29831cc403b974098a379bcc` | 64 |
+| `intended-vs-implemented/ENTRY.md` | `pm-ai-shipping/skills/intended-vs-implemented/SKILL.md` | `6d917f0e59f78ea6b5d847f57b1c816baa2948cac56529939589cd73d2e4c9eb` | 42 |
+| `opportunity-solution-tree/ENTRY.md` | `pm-product-discovery/skills/opportunity-solution-tree/SKILL.md` | `6b23e44a5ace86aa20d64cc130322265ace6a53a29831cc403b974098a379bcc` | 64 |
 
 ## What is not, and why
 
@@ -26,7 +27,8 @@ else is one URL away and stays that way.
 
 ## The only modification
 
-None. Both files keep their upstream bytes, frontmatter and description included.
+None. Both files keep their upstream bytes, frontmatter and description included;
+only the file name changed, `SKILL.md` to `ENTRY.md`.
 `skills/pm-frameworks/SKILL.md` is tezgah's own entry point and is not part of the
 manifest, the same way `skills/ai-research/SKILL.md` is not.
 

package/skills/ponytail/SKILL.md

@@ -1,18 +1,8 @@
 ---
 name: ponytail
 description: >
-  Forces the laziest solution that actually works, simplest, shortest, most
-  minimal. Channels a senior dev who has seen everything: question whether the
-  task needs to exist at all (YAGNI), reach for the standard library before
-  custom code, native platform features before dependencies, one line before
-  fifty. Supports intensity levels: lite, full (default), ultra. Use on ANY
-  coding task: writing, adding, refactoring, fixing, reviewing, or designing
-  code, and choosing libraries or dependencies. Also use whenever the user
-  says "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal
-  solution", "yagni", "do less", or "shortest path", or complains about
-  over-engineering, bloat, boilerplate, or unnecessary dependencies. Do NOT
-  use for non-coding requests (general knowledge, prose, translation,
-  summaries, recipes). Not for prose that has gone soft - use `no-ai-slop`.
+  Use when coding - writing, fixing, refactoring, a dependency; minimum kod,
+  sade, yagni, simplest, lazy. Not for prose - use `no-ai-slop`.
 argument-hint: "[lite|full|ultra]"
 ---
 
@@ -20,6 +10,21 @@ argument-hint: "[lite|full|ultra]"
 
 # Ponytail
 
+## When to use
+
+Forces the laziest solution that actually works, simplest, shortest, most
+minimal. Channels a senior dev who has seen everything: question whether the
+task needs to exist at all (YAGNI), reach for the standard library before custom
+code, native platform features before dependencies, one line before fifty.
+Supports intensity levels: lite, full (default), ultra. Use on ANY coding task:
+writing, adding, refactoring, fixing, reviewing, or designing code, and choosing
+libraries or dependencies. Also use whenever the user says "ponytail", "be
+lazy", "lazy mode", "simplest solution", "minimal solution", "yagni", "do less",
+or "shortest path", or complains about over-engineering, bloat, boilerplate, or
+unnecessary dependencies. Do NOT use for non-coding requests (general knowledge,
+prose, translation, summaries, recipes). Not for prose that has gone soft - use
+`no-ai-slop`.
+
 You are a lazy senior developer. Lazy means efficient, not careless. You have
 seen every over-engineered codebase and been paged at 3am for one. The best
 code is the code never written.
@@ -28,7 +33,7 @@ code is the code never written.
 
 ACTIVE EVERY RESPONSE. No drift back to over-building. Still active if
 unsure. Off only: "stop ponytail" / "normal mode". Default: **full**.
-Switch: `/tezgah:ponytail lite|full|ultra` on Claude, or `tezgah-pony
+Switch: `/tezgah:ponytail lite|full|ultra` on Claude, or `~/.config/tezgah/bin/tezgah-pony
 lite|full|ultra` on any host (a bare call shows the level). The level is stored
 in `~/.config/tezgah/ponytail.level` and rides the per-turn reminder whenever it
 is not `full`, so an armed level is never a phrase the model has to remember.
@@ -119,6 +124,6 @@ test, YAGNI applies to tests too.
 
 ## Boundaries
 
-Ponytail governs what you build; the one thing it says about the reply's shape is the `Output` section above, and `i-have-adhd` governs how the reply reads otherwise (the exec contract owns the language). "stop ponytail" / "normal mode": revert. The level is a machine-wide setting that persists until it is changed - `tezgah-pony` is where it lives, and a level set once is in force in every later session.
+Ponytail governs what you build; the one thing it says about the reply's shape is the `Output` section above, and `i-have-adhd` governs how the reply reads otherwise (the exec contract owns the language). "stop ponytail" / "normal mode": revert. The level is a machine-wide setting that persists until it is changed - `~/.config/tezgah/bin/tezgah-pony` is where it lives, and a level set once is in force in every later session.
 
 The shortest path to done is the right path.

package/skills/product-analysis/SKILL.md

@@ -1,24 +1,28 @@
 ---
 name: product-analysis
 description: >
-  Runs a product analysis across five axes - value (HEART's Goals to Signals to
-  Metrics, opportunities before features), usability (Nielsen's heuristics with
-  their severity scale, the cognitive walkthrough, WCAG 2.2 AA, axe-core, and the
-  running app read through analyze-app down to component x state, tree and rendered
-  image both),
-  feasibility (a cited code path, documented intent against the code that enforces
-  it), competition (a teardown with a stated comparison basis, review mining), and
-  triage (keep, fix, cut or bet, with kill criteria) - where every finding names
-  one evidence class. Use when a task is to analyse or improve a product: product
-  analysis, UX audit, competitor teardown, which feature next, retention, churn,
-  funnel, pricing, a PRD or a roadmap and backlog review, or a
-  "should this feature exist" ask. Code discovery belongs to the code graph and ML
-  experiments to the research skill; this one owns the product question. Not for
-  one feature across its layers - use `feature-audit`.
+  Use when doing product analysis: ürün analizi, rakip, UX audit, competitor,
+  retention, which feature next. Not for one feature - use `feature-audit`.
 ---
 
 # product-analysis
 
+## When to use
+
+Runs a product analysis across five axes - value (HEART's Goals to Signals to
+Metrics, opportunities before features), usability (Nielsen's heuristics with
+their severity scale, the cognitive walkthrough, WCAG 2.2 AA, axe-core, and the
+running app read through analyze-app down to component x state, tree and
+rendered image both), feasibility (a cited code path, documented intent against
+the code that enforces it), competition (a teardown with a stated comparison
+basis, review mining), and triage (keep, fix, cut or bet, with kill criteria) -
+where every finding names one evidence class. Use when a task is to analyse or
+improve a product: product analysis, UX audit, competitor teardown, which
+feature next, retention, churn, funnel, pricing, a PRD or a roadmap and backlog
+review, or a "should this feature exist" ask. Code discovery belongs to the code
+graph and ML experiments to the research skill; this one owns the product
+question. Not for one feature across its layers - use `feature-audit`.
+
 A product question is answered from priors unless something forces it to be
 concrete. This skill is that forcing function: five axes, one evidence class per
 finding, and an artifact that outlives the session. It does not add machinery -
@@ -152,7 +156,7 @@ The state matrix is mandatory for every interactive component and every data vie
 A state that does not exist is a finding, and a missing empty, loading or error
 state is usually a bigger one than a state that merely looks wrong.
 
-The per-component read is `tezgah-triage --states FILE --component <ref>` over the
+The per-component read is `~/.config/tezgah/bin/tezgah-triage --states FILE --component <ref>` over the
 snapshot `analyze-app` took: one judgement per state over that component's lines.
 A static snapshot shows only the current state - never hover, and only the data
 state the route happens to be in - so `--states` answers what the tree shows now,
@@ -262,8 +266,8 @@ ones the product's stage justifies, and say which were skipped.
 
 ## The artifact
 
-Run it as a research line, not a monologue: `tezgah-research init <slug>
---question "..."` under the repository's `.tezgah/research/`, then `check` before
+Run it as a research line, not a monologue: `~/.config/tezgah/bin/tezgah-research init <slug>
+--ask "<the user's words>" [--question "..."]` under the repository's `.tezgah/research/`, then `check` before
 reporting. Declare the line's `deliverable` in `state.json` as `{"kind":
 "analysis", "path": "<where the analysis lands>", "ask": [<the ask's items>]}`, so
 `check` holds it to answering every ask item. An analysis answers its question
@@ -277,7 +281,7 @@ between goes under `decisions/` with at least three variants. On top of what
    solutions, they are recorded as `decisions/<id>/` (the research skill's
    "Variants"): at least three produced solutions plus the status quo as V0, the
    criterion set committed in `criteria.json` before any solution is scored, every
-   cell appended with `tezgah-research compare` (a judged cell with two raters), and
+   cell appended with `~/.config/tezgah/bin/tezgah-research compare` (a judged cell with two raters), and
    `decision.md` naming the chosen solution, what ruled out each other one and the
    `flip:`. Otherwise the analysis names the recommended one and why.
 4. Risks by class - value, usability, viability, feasibility - each with the

package/skills/product-flow/SKILL.md

@@ -1,18 +1,23 @@
 ---
 name: product-flow
 description: >
-  Carries a new product capability from evidence to a measured result: it walks
-  the nine steps of the flow in order - research, metrics, assumptions,
-  decision, instrumentation, forward spec, design, build, re-measure - and does
-  the first step whose artifact is missing with the skill that step names, so
-  each hand-off is a written artifact that names the one before it instead of a
-  memory. Use when a session must design a metric dashboard, a new metric or a
-  new feature from data or an ask, and carry it from research to re-measure. Not
-  for auditing an existing feature - use `feature-audit`.
+  Use when a new metric dashboard or feature is carried from data to re-measure;
+  yeni özellik, metrik, ölç. Not for an existing feature - use `feature-audit`.
 ---
 
 # product-flow
 
+## When to use
+
+Carries a new product capability from evidence to a measured result: it walks
+the nine steps of the flow in order - research, metrics, assumptions, decision,
+instrumentation, forward spec, design, build, re-measure - and does the first
+step whose artifact is missing with the skill that step names, so each hand-off
+is a written artifact that names the one before it instead of a memory. Use when
+a session must design a metric dashboard, a new metric or a new feature from
+data or an ask, and carry it from research to re-measure. Not for auditing an
+existing feature - use `feature-audit`.
+
 A new product capability - a dashboard over a data file, a metric, a feature
 someone asked for - drifts when its steps live in the session's head: the chart
 gets drawn before anyone says which goal it serves, and nobody comes back to see
@@ -57,7 +62,7 @@ spec in `spec.md`. Each step's artifact names the earlier artifact it rests on.
 7. **design** (`design-contract`). A component in `.tezgah/design-contract.md`
    that names the decision it serves.
 8. **build** (`design-contract`). Judged by the design check
-   (`tezgah-design check`) and the Stop UI rule, not by this flow.
+   (`~/.config/tezgah/bin/tezgah-design check`) and the Stop UI rule, not by this flow.
 9. **re-measure** (`analyze-app`). Once the decision's observe-after date has
    passed, measure the decision's metric again and write the result and what it
    means for the decision.