All authors
Claude Skills by latere-ai
github.com/latere-ai16 skills0 installs3 views
- Commit And PushCommit the working tree as one commit per logical change, staging files explicitly, then push once. Use when work is finished and should reach the remote as reviewable units rather than a single mixed commit.Votes: 0GitHub stars: 2
- Tag And ReleaseCut a release by pushing a version tag, but only after proving CI is green on the exact commit being tagged, then watch the pipeline and confirm the new version is actually live before reporting success. Use when a repository releases by tag.Votes: 0GitHub stars: 2
- BreakdownSplit one spec into children — sub-design specs when questions are still open, or implementation-ready leaves when the plan is clear. Picks the mode from the spec's lifecycle state unless told otherwise. Writes new spec files and indexes them on the parent. Use when a spec is too large to build in one pass.Votes: 0GitHub stars: 2
- CreateWrite a new spec from scratch when none exists for the idea yet. Gathers context, explores the codebase, fills the frontmatter, and indexes it in specs/README.md. Use when the user says "create a spec", "write a spec", or "new spec". When a spec already exists but is out of date, use refine instead.Votes: 0GitHub stars: 2
- DispatchMark a validated spec ready to build and resolve its dependency wiring; where a task board with a transition API is present, create the linked task atomically. Also undispatches. Use when a design is settled and work should start — the spec must be validated and its dependencies complete.Votes: 0GitHub stars: 2
- DriftClassify how far what shipped diverged from what was specced, and record it on the spec: every item marked satisfied, diverged, not implemented, or superseded, unspecified work called out, and an Outcome section appended. Writes to the spec and may mark it stale. Use after an implementation lands and the spec should carry the verdict.Votes: 0GitHub stars: 2
- DriveRun the whole lifecycle for one spec, calling the other skills in order and advancing one legal transition at a time until it reaches a target state (default complete), stopping to ask at irreversible gates. Use when the user wants a spec taken from wherever it is to done rather than running each step by hand — and start here when unsure which single-spec skill applies.Votes: 0GitHub stars: 2
- HousekeepingRepair the numbering of a specs/ directory: give name-only specs a stable NNN id, retire terminal specs into .archive/ keeping their number, fix the cross-references the moves break, and optionally rebuild the index in number order. Moves files and commits. Operates on one directory at a time, so it works whether specs sit flat under specs/ or inside a track.Votes: 0GitHub stars: 2
- ImpactBlast radius of a change before it is made: which code and which other specs a proposed spec would touch, and which specs need updating as a consequence. Read-only. Use before implementing or breaking down, to size the work and surface hidden dependents.Votes: 0GitHub stars: 2
- ImplementBuild a spec: plan the work, implement each item with tests and docs, commit, then finalize. The only skill here that writes production code. Use when the user says "implement spec" or "build spec", or names a spec file to build.Votes: 0GitHub stars: 2
- RefineRewrite an existing spec so it matches what the codebase does now: drop shipped items, update partially-done ones, fix stale paths and names, remove obsolete scope. Takes optional feedback after the path to steer the rewrite. Use when a spec no longer describes reality; use create when there is no spec yet.Votes: 0GitHub stars: 2
- ReportSurvey the whole spec tree: what is complete, in progress, blocked, and actionable next. Reads the spec files, task files, and git history rather than any hand-maintained table. Read-only. Use for "where do things stand"; use validate to check the tree is structurally sound.Votes: 0GitHub stars: 2
- Review BreakdownAudit a breakdown before anyone builds it: dependency ordering, task sizing, coverage gaps, overlapping boundaries, missing tests. Read-only; returns PASS or NEEDS REVISION. Use immediately after breakdown.Votes: 0GitHub stars: 2
- Review ImplRead-only verdict on whether an implementation meets its spec: each acceptance criterion classified, unintended changes flagged, test coverage checked. Writes nothing; returns COMPLETE, INCOMPLETE, or NEEDS FIXES. Use to judge finished work; use drift to record that judgment on the spec, wrapup to close the spec out.Votes: 0GitHub stars: 2
- ValidateStructural lint over the spec tree — required frontmatter fields, valid status and effort values, track location, DAG acyclicity, dispatch consistency, orphans, status consistency. Read-only; reports problems and fixes nothing. Use to check the tree is well-formed; use report for what the specs say about progress.Votes: 0GitHub stars: 2
- WrapupClose out a finished spec: write the Outcome section, move the status through the testing gate to complete, update specs/README.md, and commit. Reconstructs from task notes or from git history. Writes and commits. Use when the work is genuinely done; use drift when the point is to record divergence rather than to finish.Votes: 0GitHub stars: 2