augments
FeaturedA collection of rigorous, phase-isolated SDLC skills to tether autonomous agents to real-world engineering standards.
Install
Plugins install via a marketplace, in two steps.
This plugin isn't listed in a marketplace we've indexed. Install it directly from its GitHub repository — the README has the setup steps.
View on GitHubBundles
Everything this plugin ships — skills, agents, commands, hooks, and MCP servers it bundles.
Skills (28)
spec-it
Use when you have a goal or feature and need the detailed requirements before design — what it must do, how each is verified, and the assumptions and risks involved. Produces a requirements spec (SRS) under .augments/specs/. Grill unknowns with interview-me; this captures the WHAT, never the HOW.
caveman
Use when the user asks for brevity — "caveman mode", "be terse", "less tokens" — switch to ultra-compressed output that drops filler but keeps every technical fact, code block, and error message exact. Persists until the user says stop. Drops terseness only for security and destructive-action warnings.
dispatching-parallel-agents
Use when you have two or more genuinely independent pieces of work — separate failing tests, unrelated bugs, parallel research threads — that share no files, no state, and no ordering. Fan them out to concurrent agents, each with its own scope and deliverable, then reconcile. Skip when tasks depend on each other or share a file (sequence them with executing-plans), or when the work is quick enough inline.
interview-me
Use whenever a request, plan, or design is unclear or underspecified — in any phase, before you build on it. Grills you one question at a time, answering from the codebase first and asking only what it genuinely cannot determine, then writes a short alignment brief. Skip for trivial or already-precise requests.
prototyping
Use when a design or feasibility question is genuinely uncertain and cheaper to answer by building a throwaway than by arguing — a tricky bit of logic, a layout choice, a library's real behaviour. Answers ONE question, then is deleted. Skip when you already know the answer.
using-augments
Use when starting any task or conversation, or whenever you're unsure which skill fits — maps the available engineering skills by SDLC phase, points to the one that fits the moment, and gives the single mental model behind them all. The router for the toolbox; it does no work itself. Not for dispatched subagents executing a scoped task — they run the task, not re-orient.
using-git-worktrees
Use when work needs isolation from your current checkout — a multi-task plan, parallel agents, or a risky change you don't want touching the main working tree. Sets up a worktree (or your harness's native isolation) with its own branch, ports, and data, so commits never land on the wrong branch. Skip when isolation already exists or the change is a quick one-liner on the current branch.
writing-skills
Use when creating a new skill or editing an existing one in this library. Defines the lean format — thin SKILL.md, progressive disclosure, trigger-style descriptions, complexity gates — and how to prove a skill works. This is for AUTHORING skills, not using them.
zoom-out
Use when you're about to work in a region of the codebase you don't know well — before changing anything, go up a layer and map the relevant modules and their callers in the project's own vocabulary. Skip when you already understand the area.
finishing-a-branch
Use when a change's checks have been run and verified green and you're ready to wrap the branch — clean commits, a real PR description, and a clear merge/keep/discard decision. If "done" or "tested" is only asserted and not yet confirmed by running the check, verify first (verifying-completion) — don't wrap on an unverified claim. Gates on green before anything destructive; never force-pushes or discards without explicit say-so. Skip mid-development — this is the wrap-up.
architecture-decisions
Use when making a significant, hard-to-reverse technical decision — a datastore, sync vs async, a framework, a public contract, a security model — to record it as an ADR before building on it. Captures the options weighed, the choice, and why the alternatives were rejected. Skip for easily-reversible choices.
coding-standards
Use once per project, or when conventions drift, to set the coding standards agents and humans follow — the domain vocabulary, the patterns to use, and the things to never do. Produces the coding-standards section of the design document or a standing conventions file. Skip if the project already has clear, followed standards.
Show all 28 bundled skills Showing all 28 bundled skills
data-model
Use when designing the data a system stores and how it relates — entities, attributes, relationships, and the invariants that keep it correct. Produces the data-model section of the design document. Skip for a feature that adds no persistent state.
system-architecture
Use after the requirements are set, when a non-trivial system needs designing before it's built — components, boundaries, data flow, and the seams that keep it testable. Produces the architecture section of the design document. Skip for a small feature; its structure lives in the plan.
ui-ux
Use when designing a user-facing interface — the flows, layout, and experience — before building it. Produces the UI/UX section of the design document as concrete user flows with acceptance criteria. Skip for backend-only or non-interactive work.
writing-plans
Use when you have an alignment brief or a clear multi-step task and need an executable plan before implementing. Produces a per-task plan directory (00-index plus numbered task files) so each task loads independently instead of re-reading one large file on every context compaction. Skip for single-step or trivial work — just do it.
executing-plans
Use when you have a plan directory from writing-plans (a 00-index map plus per-task contract files) and need to execute it to done. Works one task at a time, gates each task on its Evaluator, and keeps the index as the live record. Skip for a single task — just do it.
test-driven-development
Use when implementing any feature or bugfix that has real logic or behavior — before writing implementation code, and whenever you feel the pull to skip writing a test first. Skip for throwaway spikes, pure config, or content with no logic.
debugging
Use when encountering any bug, test failure, or unexpected behavior — including a test that passes only intermittently (a flaky test is an unexplained bug to root-cause, not a green to trust) — before proposing or applying a fix, and whenever you feel the pull to guess-and-patch. Finds the root cause through a reproduction you can run. Skip only for a one-line error you can see and fully explain.
post-mortem
Use after a failure escaped to production or was caught late — a regression, outage, data corruption, or a defect found long after it shipped — to find why the process let it through and turn that into a structural fix. Also for an end-of-cycle retrospective on work that went badly. Skip for a bug you can simply fix — that is debugging; this asks why it escaped, not what the code did wrong.
refactor-architecture
Use when an existing codebase has architectural friction — changes touch many files, modules are shallow, seams leak — and you want to improve its structure. Reviews for module depth and locality, then proposes targeted refactors. Skip for new design (use system-architecture) or a quick local fix.
define-goals
Use at the start of a new project or initiative — before scoping or building — to pin down what success means. Extracts the core objective and measurable success criteria into the project brief. Skip for a single feature; use interview-me for feature requirements.
feasibility-check
Use before committing to a project or initiative — to decide whether the goal is achievable within the real constraints, and to surface the risks that could sink it. Produces a go / no-go / go-if verdict and points the riskiest unknowns at a prototype.
scope-it
Use after the goals are set and before design — to draw the boundary of a project or initiative — what is in, what is explicitly out, and the smallest cut that still meets the goal. Skip for a single feature; use interview-me.
receiving-code-review
Use when review feedback arrives — from a human or another agent — on code you wrote and you're about to respond. Forces verifying each finding against the code before acting, pushing back with evidence when a finding is wrong, and refusing performative agreement. The discipline that keeps review honest on the author's side.
requesting-code-review
Use when a non-trivial change reaches a done boundary — before claiming it complete, committing, merging, or opening a PR — not only when you already want fresh eyes. Green gates and passing tests don't substitute - they prove the checks pass, not that the change is right. Dispatches an independent reviewer scoped to the diff, checking convention-conformance and whether the change does what was asked. Skip for a trivial mechanical diff (rename, version bump, config one-liner) — self-review instead.
security-audits
Use when a change touches a trust boundary — authentication, authorization, attacker-controlled input, secrets, or data exposure — and you need to review it for security problems before it ships. Traces untrusted data from source to sink rather than eyeballing. Skip for a change with no security surface.
verifying-completion
Use before claiming work is complete, fixed, passing, or done — and before committing or opening a PR. Run the actual check and read its output before the claim, never "should work". Fires whenever you feel the pull to declare success without running anything.
Hooks (1)
Quality Score: 73/100
Details
- Author
- NjoyimPeguy
- Repository
- NjoyimPeguy/augments
- Created
- 2 weeks ago
- Last Updated
- today
- Language
- Shell
- License
- MIT