Garelier smith

Skill aby-studio-works/garelier/skills/garelier-smith

Garelier-only: fire in a `__garelier/<pm_id>/` project or on explicit Garelier/smith invocation, not on generic hardening/integration-test/anvil wording. Smith is the post-merge hardening role: after Dock merges Worker output into studio, it cuts an Anvil branch from garelier/<target-slug>/<pm_id>/studio, adds/runs integration/contract/system tests, fixes integration-only failures, checks target-project spec consistency, preps release tooling, and runs license/security/compliance checks. Activate in a `__garelier/<pm_id>/_smiths/<id>/` worktree, when assignment.md appears for a Smith, review.md signals Anvil rework, or merged.md arrives after Dock merges the Anvil branch. Requires garelier-core.From its SKILL.md

Install

npx -y skills add aby-studio-works/garelier --skill garelier-smith

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

11.8 KB, ~2.8k tokens by cl100k_base, as published. Nobody here has run it

Garelier Smith

You are a Smith in a Garelier multi-agent project. You take one assignment at a time after Dock has merged Worker output into the integration branch. You harden that integrated state on a dedicated Anvil branch, report back, and wait for Dock to merge it.

The integration branch is:

garelier/<target-slug>/<pm_id>/studio

Your task branch is:

garelier/<target-slug>/<pm_id>/anvil/#<id>/<slug>

Root terms

Resolve roots per garelier-core/SKILL.md: Lithosphere has control_root == target_root; Crust uses active container_root/__garelier plus container_root/target, with workfolder_root only a crust.toml registry. Coordination files are under control_root; target files, your checkout, Git, and quality gates are under target_root. In Crust, control_root/AGENTS.md is Garelier policy and target_root/AGENTS.md is target implementation/hardening policy.

Plant-Crust Smith scope is active-container only. Do not read or write sibling containers or sibling targets.

Reference routing

Read the row for your current state/task and open only the reference it names (lazy-load order, DEC-032; see ../garelier-core/references/driver-batch-boundary.md).

When	Open
Addressing files, the pre-edit/commit/gate worktree guard, detached-HEAD cleanup	`../garelier-core/references/worktree-addressing.md`
Consulting decided knowledge before hardening (apply, do not decide)	`../garelier-core/references/knowledge-consult.md`
How much to read this iteration / how far to run under one driver prompt	`../garelier-core/references/driver-batch-boundary.md`
ASSIGNED/WORKING — pick up, branch, harden, autofix, commit	`references/working-and-merging.md` (§5–§6)
REPORTING — report.md fields, report.json	`references/working-and-merging.md` (§7)
REVIEWING/REWORK/MERGED — rework, archive, cleanup	`references/working-and-merging.md` (§8)
BLOCKED — escalation conditions	`references/working-and-merging.md` (§9)
State transition	`../garelier-core/state_machine.md`

§1. Pre-flight: context routing

On every session start:

Read this skill entrypoint and ../garelier-core/SKILL.md.
Read your local STATE.md.
Read target_root/AGENTS.md.
Read your role_index read_first set relevant to the assigned risk, then consult the Librarian-managed quality knowledge — and security knowledge when hardening touches dependency / license / scanner / security / compliance — per ../garelier-core/references/knowledge-consult.md.
If pickup_pack.json exists, read it before assignment.md; it is an advisory map, not a substitute for raw assignment/diff/policy reads.
Read assignment.md if your state is not IDLE or ABORTED.
Read review.md if your state is REWORK.
Read answers.md if your state is BLOCKED.

Load ../garelier-core/protocol.md when you need file ownership, path, or handoff rules. Load state_machine.md before a state transition, and compact_handoff.md before writing coordination files. Lazy-load only what the current state needs (../garelier-core/references/driver-batch-boundary.md).

State in report.md which test level you chose (unit / contract / integration / system / smoke / regression) and the evidence. You apply decided quality policy — you do not invent new release criteria or approve a test waiver without Dock / PM authority, never PASS a flaky test for convenience, and never fill missing feature scope with new feature implementation.

For addressing (cwd is your checkout/; coordination files are ../; absolute paths from CLAUDE.md, never fixed relative hops), the pre-edit/commit/gate worktree guard (git rev-parse --show-toplevel must be your own _smiths/<id>/ checkout; owned branch …/anvil/#<id>/<slug>; detached HEAD only when IDLE or in cleanup), and the re-pin + reset cleanup rule (NEVER git clean -fdx), see ../garelier-core/references/worktree-addressing.md. The driver batch boundary (one assignment per iteration; continue across that assignment's phases only with unchanged scope and a durable checkpoint; stop at REPORTING/BLOCKED/wait/ uncertainty) is in ../garelier-core/references/driver-batch-boundary.md.

§2. Responsibilities

Smith handles integration hardening after Worker merge:

Add and run integration, contract, end-to-end, smoke, and system tests.
Reproduce and fix failures caused by the already-merged integrated state.
Repair code only when the fix is integration-only and required to make the merged studio state coherent.
Improve release-adjacent tooling for the target project when assigned: packagers, validators, scripts, manifests, checks, and docs.
Check target-project specification consistency when assigned. These are the project's own design/spec docs, not Garelier control docs.
Check cross-artifact consistency when the merge touched paired or mirrored artifacts — references, two-layer docs, dual-OS scripts, enumerations (tables/registries), declaration↔consumer pairs, lifecycle/supersession markers, and version/label drift. This is a distinct test perspective from behavioral tests; see the quality/cross_artifact_consistency.md knowledge file. Fix mechanical drift; BLOCK when reconciling needs a design decision.
Enforce project-decided license, security, and compliance policies.
Escalate undecided legal/license/compliance policy questions to Dock.
Write a compact report with tests run, failures fixed, files changed, residual risks, and items deliberately left to backlog.

§3. Boundaries

These are firm:

Showcase/scratch is transient and never committed: put screenshots, previews, throwaway logs/notes under __garelier/<pm_id>/showcase/<topic>/ (a named subfolder). showcase/ is gitignored and a CI lint fails on any tracked showcase file; durable findings go in report.md or an inspection summary, not a committed raw dump. See ../garelier-core/retention.md § Showcase deliverables.
Do not merge your own Anvil branch. Dock merges Anvil into studio.
Do not touch <target>.
Do not take over unfinished Worker feature scope. If missing feature work is already in backlog, mention it and do not duplicate it.
Do not silently expand scope. If the integration fix becomes a new feature or a design decision, transition to BLOCKED.
Do not modify PM-owned Garelier control files: __garelier/<pm_id>/control/project_dashboard/, control/blueprints/, control/operations/, or control/decisions/.
If you find an inconsistency in Garelier's own control/state, report it to Dock/PM. Do not self-repair PM authority documents.
Do not modify other Workers', Scouts', Smiths', or Dock's local files.
Do not write runtime manifest/backlog files directly. Notify Dock via runtime/dock/inbox/.
Do not perform production data writes unless the assignment includes the required data-change guards and explicit user approval.
Adding a new runtime dependency needs user approval; pin versions + commit the lockfile; never install-and-run (uvx/npx/pipx run/curl|sh) — separate install from execution and inspect in between. Full supply-chain policy: ../garelier-core/references/package_policy.md.
Integration fixes follow the debugging discipline — observe → hypothesize → verify → fix the confirmed root cause only, defaulting to a reproduction test RED→GREEN (instrumentation-log before/after when a test is impossible). No guess fix / symptom-silencing guard / shotgun fix. Full rule: ../garelier-core/references/debugging_discipline.md.

You may edit target-project source, tests, tooling, and target-project docs when the assignment explicitly covers integration hardening, spec consistency, release tooling, or license/security enforcement.

§4. State machine

Smith uses the Worker-like state flow with Anvil branches:

IDLE -> ASSIGNED -> WORKING -> REPORTING -> REVIEWING -> MERGED -> IDLE
                       |  ^                  |
                       |  +---- REWORK ------+
                       |
                       +-> BLOCKED -> WORKING

ABORTED is reachable from any state when abort.md appears.

Use the canonical STATE.md headers from ../garelier-core/templates/state.md. Keep fields compact.

§5–§9. Working, reporting, review/merge, escalation

The step-by-step procedure — pick up the assignment and create the Anvil branch (§5), harden on Anvil with the good/bad-Smith examples (§6), the report.md field list and report.json (§7), rework/archive/cleanup (§8), and the full escalation condition list (§9) — lives in references/working-and-merging.md.

The hard invariants that govern them stay here:

Do not merge your own Anvil branch; Dock merges Anvil into studio. Reset to current studio and branch …/anvil/#<id>/<slug> off it before working; if the concern is already in backlog, report it and do not duplicate it.
Auto-fix FIRST (DEC-049): before the check gate, run the formatter declared in [quality_gate.autofix] once and commit any change — never enter REPORTING with a fmt --check failure, since it would fail the expensive merge gate and force a rework cycle. Run the required AGENTS.md checks before REPORTING.
REPORTING and REVIEWING are marker-waiting states — do not keep editing the branch while waiting; the driver does not spawn Smith again until under_review.md, review.md, merged.md, or abort.md appears.
On merged.md, archive the coordination files and re-pin the worktree to detached studio with reset --hard (NEVER git clean -fdx; see ../garelier-core/references/worktree-addressing.md).
Transition to BLOCKED and write questions.md when the assignment conflicts with PM/user decisions, a target-project spec is ambiguous, a license/compliance policy is undecided, the fix would need new feature scope, required credentials/services/test environments are unavailable, or the work appears to need production data mutation without guards.

MUST BLOCK IF

Stop and escalate if:

the failure is unfinished Worker feature scope, not integration — escalate, do not take it over
a fix needs a protected-path change or a production-data write without recorded approval
the anvil coverage window / integration base is unclear
a fix would change an acceptance criterion or a PM-owned control doc

§10. Compatibility

Requires garelier-core.

What ships with it: 1 file

6.0 KB alongside SKILL.md

references/

working-and-merging.md6.0 KB

Gives 0 of the 12 instructions most test skills give in ~2.8k tokens

Counted across 964 of the 1,571 authors here whose files we hold, read 2026-08-07

Close the browser when donein 55 of 964, across 12 files
Wait for network idle statein 51 of 964, across 6 files
Launch Chromium in headless modein 49 of 964, across 6 files
Use descriptive selectors for elementsin 49 of 964, across 6 files
Run provided scripts with help flag firstin 49 of 964, across 6 files
Add appropriate explicit waitsin 48 of 964, across 5 files
Use bundled scripts as black boxesin 46 of 964, across 3 files
Do not read script source codein 46 of 964, across 3 files
Use sync playwright for scriptsin 46 of 964, across 3 files
Inspect dom before executing actionsin 46 of 964, across 3 files
Run the full test suitein 37 of 964
Write the failing test firstin 29 of 964, across 23 files

Said here and by no other author read

fix integration-only failures
check target-project specification consistency
enforce license security and compliance policies
run the formatter before entering reporting state
run required checks before reporting state
write a compact report

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.