All authors
Claude Skills by seropaski
github.com/seropaski10 skills0 installs0 views
- Lets DecisionsService skill, loaded by lets-plan, lets-research, lets-implement, and lets-review; not invoked by the user. Decision levels, the question ladder, the RFC and ADR lifecycle, and epoch-based document naming.Votes: 0GitHub stars: 15
- Lets Doc StandardsService skill, loaded by every lets skill; not invoked by the user. The closed documentation tree with an _index.md table of contents in each folder, the docs root the tree lives under (docs by default, recorded in AGENTS.md), which document answers which question, the rule that glossary and convention changes need the human's approval, linking rules, the trust rule for repository content, and the discovery protocol.Votes: 0GitHub stars: 15
- Lets ImplementExecute a READY plan milestone by milestone through subagents, where an implementer writes, a validator checks, and a reviewer audits. Progress, deviations, and blockers go back into plan.md, so any session can resume from the repository. Use after lets-plan reports READY, or to resume a plan in progress.Votes: 0GitHub stars: 15
- Lets InitSet up a repository for the spec-driven workflow. Analyzes the project (stack, structure, domain vocabulary), interviews the human about product goals, users, domain areas, and open gaps, then writes AGENTS.md, the README, and the docs tree (glossary, design, ADR, RFC, conventions, plans) from both. The tree's root is docs, or the folder named with --docs-dir when docs is taken; AGENTS.md records it. Run once per project, and again after major stack changes.Votes: 0GitHub stars: 15
- Lets OrchestrationService skill, loaded by lets-plan, lets-research, lets-implement, and lets-review; not invoked by the user. Subagent roles (explorer, implementer, validator, reviewer), self-contained dispatch prompts, how subagents ask questions, the validate and review cycle, rework limits, and what the orchestrator never does itself.Votes: 0GitHub stars: 15
- Lets PlanPlan a task before writing code. Turns the request into numbered requirements, checks them against the codebase, asks the human everything the request leaves open, and writes spec.md and plan.md under the docs root recorded in AGENTS.md. Use before any non-trivial change. When the deliverable is understanding or documentation rather than behavior, use lets-research instead.Votes: 0GitHub stars: 15
- Lets ResearchExplore a codebase and record what was learned in the project's docs tree, as current-state design docs, glossary entries, and conventions. Never changes code and writes no spec, plan, or decisions. Use when the deliverable is understanding or documentation ("how does X work", "what is the state of Y", "document this area") rather than a working feature.Votes: 0GitHub stars: 15
- Lets ReviewReview a change before it merges. First checks it against the task's spec, plan, and ADRs, then looks for real risks in the code (security holes, wrong behavior, unsafe data changes, slow paths, logic it duplicated or left behind). Reports first and changes nothing until the human chooses what to fix. Takes an optional scope (staged, unpushed, branch, a commit, or a PR) and by default reviews the uncommitted changes.Votes: 0GitHub stars: 15
- Lets ShipCommit the current changes and open a merge request, with a conventional message, a secrets check, a push, and an MR via GitLab push options or a PR via gh, chosen from the origin remote. Closes the task's plan once the MR exists. Use to finish a task or checkpoint work; say "commit only" to skip the push and the MR.Votes: 0GitHub stars: 15
- Lets Skill MatrixService skill, loaded by lets-plan, lets-research, and lets-implement; not invoked by the user. Maps the task's capability areas to the domain skills actually installed in the current environment. Names no concrete skills, because every engineer's machine has a different set.Votes: 0GitHub stars: 15