hams-ollo

@hams-ollo source repo

22 skills
0 followers
7 hours ago last updated

▌
Reconcile Worktrees · hams-ollo
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 spine: new-task authors, fix-batch dispatches to isolated agents, reconcile-worktrees consolidates the verified results, and doc-sync follows it. Also use it proactively after a fix-batch run once every spawned agent has been individually verified, as the natural next step.

0
installs
▌
Spec Plan Readiness · hams-ollo
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`, which judges well-formedness.

0
installs
▌
Systematic Debugging · hams-ollo
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 purpose. The record it returns carries the facts a task file's bar demands and cannot otherwise obtain, so `new-task` writes a premise somebody checked. Trigger on "why is this failing", "find the root cause", "this test is flaky", "debug this", "the CI job broke and nobody knows why", or any defect that arrives without a cause. Distinct from `test-author`, which pins the observable this names, and from `fix-batch`, which dispatches the fix this refuses to write.

0
installs
▌
Doc Sync · hams-ollo
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 current-state document requires explicit per-finding approval and leaves an audit trail, and a contract document is never edited because a disagreement there means the code is wrong. Distinct from doc-author (writes documents that do not exist), doc-revise (edits a document you have already decided to change, and which this composes for editing discipline), and spec-conformance (audits code against a spec). It finds what drifted; it does not silently fix it.

0
installs
▌
New Task · hams-ollo
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 the existing backlog. Use when the user says "write a task for X", "add this to the backlog", "spec out this bug", "turn this into task files", "break this feature into tasks", or hands over an idea they want made executable. Requires an existing .tasks/ system (run init-worktracking first if absent). Feeds fix-batch: one task file per worktree-isolated agent.

0
installs
▌
Fix Batch · hams-ollo
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 than just discussed. It is the parallel-execution step of the kit spine: new-task authors the task files, fix-batch dispatches them, verifier-agent proves them, reconcile-worktrees lands them. Do not use it for a single fix (just do it directly) or for changes that are inherently sequential or interdependent (one agent's output feeds the next's input), since worktree isolation assumes the items do not need to see each other's work in progress.

0
installs
▌
Doc Author · hams-ollo
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 non-technical users", "scaffold the repo docs", "set up the docs folder", "write a deployment guide", "create a CLAUDE.md for this repo", "we need a design doc for X", or any request to produce a new .md document describing the codebase or project. When the document already exists and the user wants it updated, revised, or its links fixed, use doc-revise instead. When the user does not know which document is wrong, use doc-sync instead.

0
installs
▌
Doc Revise · hams-ollo
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 across the docs is still valid", "revise the README with this new content", "move completed items to the changelog", "the docs are out of date after these changes", "add contextual emojis to the headings", or any request to edit, refresh, or reconcile existing .md files. When the document does not exist yet and needs to be created from scratch, use doc-author instead. When the user does not know which document is wrong, use doc-sync instead.

0
installs
▌
Pr Describe · hams-ollo
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 when the user says "describe this PR", "write the PR body", "draft a pull request", "summarize my branch for a PR", "changelog entry for this branch", or is about to open a PR and wants the description and changelog written for them. Drafts only, safe with or without gh installed.

0
installs
▌
Spec Author · hams-ollo
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. Distinct from new-task (which decomposes an approved spec into tasks) and spec-quality (the review lens this composes).

0
installs
▌
Test Author · hams-ollo
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 reports coverage gaps instead of writing low-value passing tests. Distinct from test-quality (the lens it composes, which judges test design), spec-conformance (audits code against a spec), and fix-batch (runs tests). It writes tests; it never edits production code.

0
installs
▌
House Review · hams-ollo
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 finding that does not resolve, and writes findings ordered blocker to nit with file:line, the quote, a stable signature, why it matters, and a concrete fix. Use when the user says "review this", "review my changes", "code review", "review this PR/branch/diff", "what's wrong with this change", or wants a second pair of eyes before merging. Report-only: it never changes code.

0
installs
▌
Review Depth · hams-ollo
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 review", "how carefully should I review this", "is this worth a full review", or ask for a review of a whole branch. An explicit depth from the user always wins and detection only fills the gap. It selects effort, it does not review: the rubric, the severities, and the report-only posture stay in house-review and the review-quality lens.

0
installs
▌
Spec Quality · hams-ollo
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.

0
installs
▌
Test Quality · hams-ollo
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.

0
installs
▌
Agent Handoff · 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 this for handoff to another agent", "write a brief the next session can follow", "spin up an agent to do X, write the instructions first", or when the user is about to switch models or context windows and wants the work captured for a clean run. When the handoff target is a person (partner, client, teammate) rather than an agent, use human-handoff instead.

0
installs
▌
Human Handoff · hams-ollo
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 about where we are", "summary for the client", "onboard the new dev", "prep for the meeting with the other engineering team", "what should I tell a stakeholder about the open questions", "put together a handoff doc for whoever picks this up", or any request to explain project status to a person rather than an agent. If the handoff target is a fresh agent session or a spawned subagent that will execute work, use agent-handoff instead.

0
installs
▌
Verifier Agent · hams-ollo
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 is unapproved or no command is declared, so a verification that could not run is never recorded as a pass. Distinct from spec-conformance (the report-only lens it composes), test-author (which writes tests), house-review (which judges quality), and fix-batch (which dispatches the work). It verifies and reports; it never edits what it verifies.

0
installs
▌
Spec Conformance · hams-ollo
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 drift), and it is independent of test pass/fail.

0
installs
▌
Agent Observatory · hams-ollo
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 exposes nothing it declines with the reason stated rather than finding another route. Trigger on "what sessions do I have running", "which of my agents is still working", "find the session that did X", "rename that session", "tell the other session about this", "what did that wave cost", or any question that spans more than one session. Distinct from the observatory's own page, which reports and offers no action at all.

0
installs
▌
Init Worktracking · hams-ollo bundle
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-run, and detects a pre-existing tracker before writing. Use when the user wants to set up work-item tracking, a backlog, a todo/changelog system, or task files that parallel subagents can pick up, or says things like "add work tracking here", "set up the task system", or "scaffold the backlog". Feeds the new-task and fix-batch skills: one task file per worktree-isolated agent.

0
installs
▌
Project Bootstrap · hams-ollo bundle
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 directory they want turned into a real project. This is the front door of Zen Agent Skills: it calls init-worktracking so the repo comes up already tracked.

0
installs

22 published skills