docs(agents): drop tracker CLI, brevity rule in artifact skills

AGENTS.md workflow now names actions, not tracker commands — tracker
CLI removed entirely so tooling can't be reintroduced into synced
skills. Brevity rule (shortest possible, caveman preferred, precision
must not suffer) added to writing-adrs, to-tickets, to-spec,
domain-modeling.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YFfpHjYmvPmAAGuiWYArw1

AGENTS.md

@@ -24,7 +24,7 @@ uvx disambiguate --from <ticket-file>
 or for GitHub issues:
 
 ```bash
-ghx issue view <number> --json body -q .body | uvx disambiguate --from -
+<tracker issue body> | uvx disambiguate --from -
 ```
 
 to resolve all referenced terms at once.
@@ -74,29 +74,18 @@ Live in `.agents/skills/`. Synced using `npx skills update -p -y` — don't edit
 
 ### Agentic Engineering Workflow
 
-Use `ghx` for all repository interaction. `gh` and `tea` are disabled — calling them tells you to use `ghx` instead.
-
-`ghx` exposes a curated subset of `gh`'s verbs (plus a few additions, e.g. `--code-comment`) and presents the **same `gh`-style interface against both GitHub and Forgejo**, so you never need to know which host the repo is on. It is **not** a full `gh` replacement: it has only the verbs listed below. If a command isn't in this list, `ghx` doesn't have it — don't fall back to `gh`/`tea`.
-
-#### Available `ghx` verbs
-
-- **issues:** `issue create`, `issue view` (`--comments`), `issue list`, `issue comment`, `issue edit`
-- **pull requests:** `pr create`, `pr view` (`--comments`), `pr list`, `pr comment`, `pr edit`, `pr review` (`--body`, repeatable `--code-comment path:line:text`), `pr checks`, `pr status`
-- **CI:** `run list`, `run view`
-
-Use `run list` / `run view` for workflow-run detail; use `pr checks` / `pr status` for a PR's check rollup.
+Interact with issues/PRs/CI via the tracker tooling available in your environment (per its own AGENTS.md/config). Workflow below names actions, not commands — no specific tracker CLI here (keeps repo tool-agnostic, prevents tooling leaking into synced skills).
 
 The modes below are the kinds of work the user will ask for. **Each runs in its own session — possibly a different model or agent** (Review especially). Follow the named skills at each step.
 
 #### Plan
 
 - Explore the codebase. Flag `DECISION:SCOPE` when resolving ambiguities. Use the `documenting-decisions` skill (refs: `pre-approval-gate.md`, `scope-interpretation.md`).
-- Write an issue → `ghx issue create`
-- Set issue metadata → `ghx issue edit` (labels/assignees/milestone)
+- Write an issue; set metadata (labels/assignees/milestone).
 
 #### Implement
 
-- Read the given issue and comments → `ghx issue view --comments`
+- Read the given issue and comments.
 - Do Test-Driven Development per the `tdd` skill.
 - Implement the minimal code to pass tests, then the remaining code per the ticket spec. Place `DECISION:` markers per the `documenting-decisions` skill (refs: `decision-markers.md`, `marker-examples.md`).
 - Commit discipline:
@@ -104,30 +93,27 @@ The modes below are the kinds of work the user will ask for. **Each runs in its
   - `prek` must pass on every commit (lint/format hooks only — prek never runs unit tests).
   - TDD red-step commits are expected and required (a commit whose new tests fail but whose lint/format passes). **CI evaluates at PR HEAD, not per-commit**, so a red-step commit does not constitute a CI failure — do not treat it as one.
   - Don't fix lint manually — run the formatter. Only touch code directly if the tools can't resolve it.
-- Push → `git push` *(plain git; git is not routed through `ghx`)*
-- Create the PR if not already present, and link it to the issue both ways → `ghx pr create` (start with `Closes #<number>` in description), then `ghx issue edit` if a back-reference is needed. **If a PR already exists for this branch, do not create or re-link it** — skip to CI.
+- Push → `git push`
+- Create the PR if not already present, and link it to the issue both ways (start with `Closes #<number>` in description; back-reference on the issue if needed). **If a PR already exists for this branch, do not create or re-link it** — skip to CI.
   PR body must include:
   - `Closes #<number>`.
   - Any obstacles that diverged from the initial plan, and — in the rare event spec deviation was unavoidable — what deviated and why.
   - All `DECISION:` markers present in the diff, rendered per the `documenting-decisions` skill format.
-- Check CI → `ghx run list` / `ghx run view` (or `ghx pr checks` once the PR exists).
+- Check CI (workflow runs; PR check rollup once the PR exists).
 - If CI fails, fix it by re-entering this **Implement** workflow.
 
 #### Review
 
-- Read the given issue and comments → `ghx issue view --comments`
+- Read the given issue and comments.
 - Review the PR and give Critical / Important feedback per the `requesting-code-review` skill.
-- Submit it as a single review → `ghx pr review`:
-  - PR-level summary feedback → `--body "..."`
-  - Feedback tied to specific lines → repeatable `--code-comment path:line:text`
-  - Put both in the same `ghx pr review` call; don't split a review across `pr review` and `pr comment`.
+- Submit as a single review: PR-level summary body + line-tied code comments together — don't split across a review and separate comments.
 
 #### Apply Review Comments
 
-- Read the given issue and comments → `ghx issue view --comments`
-- Read PR comments and code comments → `ghx pr view --comments`
-- If the review uncovers inconsistencies in the issue, **comment** on it freely → `ghx issue comment`
-- Only **edit** issue content when the user explicitly requests it → `ghx issue edit`. Editing is gated on explicit request because it can overwrite human-authored intent; commenting is always safe, editing is not.
+- Read the given issue and comments.
+- Read PR comments and code comments.
+- If the review uncovers inconsistencies in the issue, **comment** on it freely.
+- Only **edit** issue content when the user explicitly requests it. Editing is gated on explicit request because it can overwrite human-authored intent; commenting is always safe, editing is not.
 - Then re-enter the **Implement** workflow.
 
 ## Dependencies

derived/domain-modeling/SKILL.md

@@ -14,6 +14,8 @@ The domain model lives in two places:
 - **Glossary** — `docs/glossary/`, one markdown file per term, in the format `uvx disambiguate` expects (see below). Never a root `CONTEXT.md`.
 - **Decisions** — ADRs in `docs/adr/`, per the `writing-adrs` skill.
 
+Glossary entries, ADRs, docs: as short as possible, caveman mode preferred (`caveman` skill) — precision and understandability must not suffer.
+
 Create files lazily — only when you have something to write. If `docs/glossary/` doesn't exist, create it when the first term is resolved.
 
 ## During the session

derived/to-spec/SKILL.md

@@ -28,7 +28,7 @@ Spec is load-bearing. No grilling session (`docs/glossary/grilling-session.md`)
 
    Check seams with user.
 
-3. Write spec per template, apply litmus test to every section, publish per consumer repo's tracker conventions (AGENTS.md). Apply `ready-for-agent` label — no further triage.
+3. Write spec per template — as short as possible, caveman mode preferred (`caveman` skill), precision and understandability must not suffer. Apply litmus test to every section, publish per consumer repo's tracker conventions (AGENTS.md). Apply `ready-for-agent` label — no further triage.
 
 Spec template:
 

derived/to-tickets/SKILL.md

@@ -116,6 +116,8 @@ Every outcome-shaping decision, stated or referenced (ADR/glossary). Bugfix: spe
 - Reference per blocking ticket, or "None — can start immediately".
 ```
 
+Ticket prose: as short as possible, caveman mode preferred (`caveman` skill) — precision and understandability must not suffer.
+
 No file paths/code snippets — stale fast. Exception: prototype snippet encoding a decision more precisely than prose (state machine, reducer, schema, type shape) → inline, note prototype origin, trim to decision-rich parts.
 
 Work frontier one ticket at a time, clearing context between tickets.

original/writing-adrs/SKILL.md

@@ -24,6 +24,8 @@ Create the `docs/adr/` directory lazily — only when the first ADR is needed.
 
 That's it. An ADR can be a single paragraph. The value is in recording *that* a decision was made and *why* — not in filling out sections.
 
+As short as possible — caveman mode preferred (`caveman` skill). Hard limit: precision and understandability must not suffer.
+
 ## Optional sections
 
 Only include these when they add genuine value. Most ADRs won't need them.