engineering-kit

Plugin engineering-kit from marketplace conceptadev in btwld/agent-plugins. Commands read from the repo's manifest — 11 days ago.

Skills (16)

• architecture

  Use when choosing, evaluating, or recording a consequential technical design decision from concrete requirements and constraints—for example a technology selection, component boundary, data ownership choice, architecture decision record, or developing a chosen API design into consumer examples and t

• ci-loop

  Use when watching pull request CI checks, diagnosing failing PR jobs, and iterating on minimal targeted fixes until all required PR checks are green using `gh pr checks` as the source of truth. Do not use for authoring a new pull request description (`pr-authoring`) or performing a static code revie

• clean-sheet-review

  Use when an existing plan, spec, API, architecture, or implementation should be reconsidered from its purpose and first principles: "from first principles", "take a step back", "if we built this today", "what should survive", or "rethink this without being bound by previous design decisions". Derive

• code-simplifier

  Use when the user explicitly invokes `$code-simplifier`, names the code-simplifier skill and asks to use it, or explicitly asks to deslop recently written or modified code. Do not infer it from a generic cleanup request or a non-trivial edit. Run a separate, behavior-preserving refinement and slop-r

• executing-plans

  Use when implementing or resuming an existing written implementation plan with multiple tasks, dependencies, or verification steps. Follow the plan through the authorized endpoint and keep unfinished work visible. Not for writing a new plan, choosing an unresolved design, reviewing a plan without im

• pr-authoring

  Use when the user asks to create, open, or update a GitHub pull request from an already-pushed branch, or to draft, rewrite, or improve a PR title and description. Inspect the base-to-head diff, commits, repository template, supplied issue context, actual validation, and relevant visual evidence; th

• pr-canvas

  Use when the user explicitly invokes `$pr-canvas` or asks to generate an interactive HTML pull request review walkthrough page in the browser with core vs mechanical file grouping, plain-English pseudocode annotations, and moved-code diff detection. Do not use for standard text-based code review (`w

• pr-comments

  Use when fetching, verifying against current `HEAD`, and skeptically triaging inline review threads and discussion comments from an active pull request into a prioritized action list. Do not use when performing a new code review from scratch (`wild-code-review`) or drafting a pull request descriptio

• pr-prep

  Use when preparing a pull request or branch before review by removing stray local artifacts, reorganizing noisy WIP commit history into logical dependency-ordered commits (while proving Git tree identity), and adding reviewer entry-point guidance without changing code behavior. Do not use for defect

• reference-implementation

  Use when creating, reviewing, refactoring, or auditing a reference-quality implementation — canonical code that others should copy, where correctness, traceability, and earned abstraction matter. Trigger on "reference implementation", "canonical version", "golden-path example", "the blessed implemen

• sbvr

  Use when the user mentions SBVR or wants to create, review, audit, validate, or update business vocabulary and business rules in structured natural language. Trigger on formalizing requirements into vocabulary and rules, writing business rules, reviewing SBVR specs, structured natural language, fact

• verify

  Use when proving or disproving a specific technical claim, bug fix, UI/API behavior change, or performance/memory improvement with fresh falsifiable baseline-versus-treatment runtime evidence and returning a `VERIFIED`, `NOT VERIFIED`, or `INCONCLUSIVE` verdict. Do not use for vague stylistic claims

• wild-code-review

  Use when reviewing or auditing a pull request, commit, diff, staged snapshot, working tree, pasted patch, files, or repository for defects, regressions, missing tests, suspicious or unnecessary code, hollow tests, stray non-production or planning artifacts, AI-generated code slop, structural maintai

• writing-for-agents

  Use when creating, editing, or refactoring documents an agent consumes, including skills (SKILL.md and reference files), AGENTS.md, CLAUDE.md, or agent reference docs. Do not use for human-facing documentation, user stories, or Linear/issue-tracker prose (use writing-for-humans).

• writing-for-humans

  Use when writing, editing, or reviewing human-facing technical and project prose—including documentation, specs, capability and user-story documents, Linear or issue-tracker descriptions, procedures, READMEs, and technical explanations—using Simplified Technical English (ASD-STE100) and single-sourc

• writing-plans

  Use when requirements or an approved specification describe a multi-step software change that should be converted into an executable written plan before implementation. Ground the plan in the actual repository, order work by dependency, and scale detail to risk and executor context. Not for one or t

Similar plugins