Claude Skills by hams-ollo

Turns the current session's context into a self-contained, execution-ready brief that a fresh agent session or a spawned subagent can run without seeing this conversation. Use this whenever the user wants to move work to another agent or a new session and wants the instructions written down first. Trigger on phrases like: "draft me a prompt to trigger a new session", "craft a prompt I can paste into a new session", "prep this plan for the agents", "hand this off to a new session", "prepare th...

Use to answer questions about agent sessions across every project at once, and to act on one where the harness allows it. Reports which sessions exist, which are running, what each cost, which skills were used, and what failed, by reading the local observatory store rather than one transcript at a time. Where the harness exposes session management, it can also rename a session and hand a message to another one. It never starts, resumes, interrupts, or ends a session, and where the harness exp...

Writes new Markdown documentation for the repository it is used in, grounded in the actual code. Handles READMEs (technical or for non-technical readers), architecture docs with Mermaid diagrams, setup and deployment guides, contributing guides, design docs, and architecture decision records. Use this whenever the user wants to create documentation that does not exist yet. Trigger on phrases like: "create a README", "write an architecture doc with mermaid diagrams", "document this project for...

Updates and revises existing Markdown documentation in place, without flattening its voice or rewriting more than asked. Reconciles a doc with the current code or project state, fixes cross-document links and references after files or folders have moved, keeps a set of docs internally consistent. Use this whenever the user wants to change documentation that already exists. Trigger on phrases like: "update the docs to reflect this", "I moved these files, fix the links", "make sure the linking ...

Use when code has moved and the documentation may not have, or when a documentation set needs auditing for stale claims. Detects documentation drift by checking prose claims against repository facts, classifies every document as current-state (correctable), contract (report-only, human-owned) or ledger (skipped), and reports each finding with a stable id, the fact that grounds it, and a grounded or suspected confidence. Dry run is the default and detection never changes a file; updating a cur...

Delegate a batch of independent, already-scoped task files (bugs, chores, small features) to parallel isolated agents, each sandboxed in its own git worktree, with a mandatory independent verification pass before anything is treated as mergeable. Use this whenever asked to "fix these bugs", "work through the backlog", "spin up agents to fix X, Y, Z", or "parallelize these fixes", especially when there are 2 or more distinct, independently-fixable items and the user wants them actioned rather ...

Review a code change against an explicit house rubric and severities, and produce a structured, severity-ranked markdown review, without editing or committing anything. Determines the review range (the current branch against its merge-base with the default branch, with a working-tree fallback), applies the review-quality lens (correctness, security, error handling, tests, readability, performance, API design, docs), resolves every finding's quoted evidence against the real file and drops any ...

Packages the current state of a project into a handoff for a person: a business partner, a client, or a team member. Produces a document or a short message, in plain language, tuned to the reader, with internals and costs redacted when the reader is a client. Use this whenever the user wants to bring a person up to speed, ask a collaborator to decide something, prep for a meeting, or draft an update. Trigger on phrases like: "write an update for my partner", "draft a message to a teammate abo...

Scaffold a portable, agent-optimized spec-driven work-tracking system into the current repository: AGENTS.md (global rules + agent reading protocol), a .tasks/ directory of atomic task files, and (by tier) ROADMAP.md, CHANGELOG.md, a validate.py checker, and thin CLAUDE.md/Cursor/Copilot pointers. Choose a footprint tier (lite/standard/team) so small repos are not buried. Seeds AGENTS.md by inspecting the repo (package manager, test runner, CI, layout) instead of leaving blanks. Safe to re-ru...

Author one or more atomic, agent-ready task files for the .tasks/ work-tracking system, at a gold-standard bar. Turns a rough idea, a bug report, or a ROADMAP.md Feature into task files with honest touched_files, a real parent up-link, resolved depends_on, and a mechanically-verifiable acceptance command, then self-checks them with validate.py. Deliberately elicits and decomposes before writing, because a sharp task is worth 3-10x its authoring time downstream. Assigns collision-safe ids from...

Draft a pull request description and a matching changelog entry from a branch's diff, in the target repo's own changelog format, without touching GitHub. Determines the PR's commit range (the current branch against its merge-base with the default branch), surveys what changed, then produces a structured PR body plus a changelog line that references the work item when a .tasks/ system is present. Outputs text and surfaces the gh command to apply it; it never creates or edits a PR itself. Use w...

Bootstrap a new or bare repository with a sane, stack-matched baseline, then hand off to init-worktracking for work tracking. Detects the language and package manager, then lays down .gitignore, .editorconfig, a linter/formatter config, a LICENSE, and a README stub, without clobbering anything that already exists. Use when the user says "set up a new repo", "scaffold this project", "fire up my harness", "give me a starting point", "bootstrap this", or points at an empty or nearly-empty direct...

Safely consolidate one or more isolated git worktrees (for example left behind by parallel background agents, or from the fix-batch skill) into the main working tree, without committing or merging blindly. Use whenever asked to "reconcile the worktrees", "merge these agent branches", "bring the worktree changes back into main", "clean up the worktrees", or when multiple agent worktree directories exist and their changes need to land in the primary checkout. It is the landing step of the kit s...

Decide how much review a change has earned, before reviewing it. Selects quick, standard, or deep from stated signals (reviewable changed lines, directory spread, trust-boundary risk flags, blast radius, documentation-only scope), reports the signal table and the rule that fired, then runs house-review at the selected depth. Use when the user asks for a review and the change is either trivially small or big enough that one uniform effort setting is wrong, or when they say "quick look", "deep ...

Use when turning a raw idea, feature request, or bug into a persistent behavioral spec before any tasks or code. Drafts a scenario-based spec (problem, goals, non-goals, constraints, Given/When/Then scenarios with stable S-NNN ids, proposed surface, open questions), composes the spec-quality lens to self-check and revise until the verdict is ready, writes it under docs/spec/ with status draft, and stops. Marks the spec draft pending explicit human approval before new-task decomposes it. Disti...

Use when closing a spec-driven feature or issue, or auditing whether an implementation actually matches its spec. Given a spec path, emits a section-by-section conformance matrix mapping every scenario and proposed surface element to conformed (with file:line or test evidence), diverged (what, why, and both sides), or not-built, plus an audited/unreconciled coverage proof. This is the spec-vs-implementation audit, distinct from spec-quality (spec well-formedness) and doc-sync (doc-vs-code dri...

Use before implementation when a spec and its task decomposition must be checked for coding readiness. Applies a deterministic go/no-go gate for missing inputs, unresolved spec blockers, incomplete ordered task lists, spec-task contradictions, task-to-scenario traceability, scenario-to-test layer mapping, risk/rollback requirements, and first-safe-task selection; a blocked verdict authorizes no tests, code, or implementation delegation. Gates implementability, distinct from `spec-quality`, wh...

Use when drafting, reviewing, repairing, or validating scenario-based specs, product specs, implementation specs, Proposed Surface sections, Given/When/Then scenarios, Open Questions, or spec-quality checklists. A quality lens for spec well-formedness: keeps specs contract-level, observable, non-redundant, grounded in repo context, and free of implementation planning.

Use when a defect, test failure, flaky test, or unexpected behavior needs its cause established before anyone writes a task file or a fix. Reproduces the report first, localizes the failure to the boundary where behavior diverges, then tests one hypothesis at a time and returns a deterministic verdict, so a run that found nothing is never mistaken for one that did. It diagnoses and never repairs, and it never edits a tracked file, because instrumentation lives only in a copy it made for the p...

Use after an implementation to derive runnable tests from an approved spec's Given/When/Then scenarios and a task's acceptance criteria, one faithful test per scenario tagged with its S-NNN id. Stops rather than deriving tests from a spec whose status is not approved. Discovers and matches the repo's existing test framework, composes the test-quality lens to choose the lowest faithful layer and an exact-outcome oracle, supports characterization tests for legacy code with no coverage, and repo...

Use when creating, modifying, reviewing, or deciding whether to add tests, fixtures, mocks, integration tests, end-to-end tests, smoke tests, or test plans in any codebase or language, including regression tests for bug fixes. Chooses the test layer and oracle: guides agents to pick the right test layer, avoid low-value tests, and verify meaningful behavioral oracles. Distinct from house-review and review-quality, which judge code changes rather than test design.

Use before reconciling or landing an implementation to independently verify it against its approved spec and its task's acceptance criteria. Runs the declared verification commands and records each exact outcome, composes the spec-conformance lens so a contract divergence fails the run even when every command passes, maps each acceptance criterion to met or unmet with named evidence, and returns a deterministic pass, fail, or blocked verdict. Returns blocked rather than guessing when the spec...

`_has_skill()` in [`skill-reachability-reminder.py`](../../.agents/hooks/skill-reachability-reminder.py) returns true for **any** directory containing a `SKILL.md`. The contract asks a narrower question. The Proposed Surface row in [`cloud-executable.md`](../../docs/spec/cloud-executable.md) reads "at least one **kit skill** directory present at the repository's project-scope discovery directory, or at any user-scope discovery directory `install.py` targets", and `S-008`'s **Given** is "a clone

The observatory reports on sessions belonging to a running program, and the natural next wish is to act on one. `S-019` and `S-020` in [`docs/spec/agent-observatory.md`](../../docs/spec/agent-observatory.md) draw that boundary, and this task makes it a proven property rather than a stated intention.