Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

dte-tooling-scan

Sterne0

Forks0

Aktualisiert28. Juni 2026 um 00:42

Mine session history and recent work to recommend which tools, skills, plugins, or agents to adopt next — and flag overlap with what is already installed. Composes ce-sessions (prior-session synthesis), MemPalace history/knowledge-graph, the overlap logic from the skill-vet design, and light web research for candidates. Use when the user asks "what tools should we add", "scan our history for gaps", "what are we missing", "what would help based on what we do", or "tooling review". Optional loop over time windows or topics. Produces a recommendations doc; it does not install anything. Not for reviewing code or a PR (use dte-deep-reviewer), app architecture (use dte-arc-review), or auditing the dte-* skills themselves (use dte-skill-audit).

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

davidteren

davidteren/dte-skills

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

Sonstige ComputerberufeInformatik- und Mathematikberufe·SOC 15-1299

SKILL.md

readonly

name

dte-tooling-scan

description

dte-tooling-scan — history → "what to adopt next" doc

Read ../../references/conventions.md first. Output is a recommendations doc; never installs anything (installation is a separate, user-confirmed step).

Input

Optional: a time window ("last 2 weeks"), a topic ("testing", "review"), or nothing (recent history).
Optional loop over several windows/topics.

Procedure

Synthesize what we actually do. Run /ce-sessions over recent sessions + query MemPalace (mempalace_search, kg_query, kg_timeline) for recurring friction, repeated manual steps, and past "I wish we had X" moments. If MemPalace/sessions are unavailable, say so and use the repo's STATUS.md / git history instead.
Inventory what we own. List installed plugins/skills/agents (claude plugin list + the skill catalogue). This is the "already have" baseline.
Find the gaps. Cross the friction themes (step 1) against the inventory (step 2). A real gap is a recurring need with no owned tool that covers it. Use light web/Augment research only to name candidate tools for a confirmed gap — not to window-shop.
Apply the overlap rule (from skill-vet). For each candidate, state what it overlaps / replaces among owned tools. Reject or downgrade anything that mostly duplicates what we have (the majestic bloat lesson). Weight by our conventions + actual usage, not theoretical coverage.
Write docs/reviews/tooling-scan-<date>.md: ranked recommendations, each with — the friction it solves, the candidate, what it overlaps/replaces, effort (install vs build), and a clear adopt / bookmark / skip call. Plus a short "gaps with no good candidate yet" list.

Done when

The doc gives a short, ranked, overlap-aware adoption shortlist grounded in what we actually do — not a catalogue dump. Each item is install-or-build with a one-line justification.

Mehr aus diesem Repository

gleiches Repository

dte-pwa

davidteren/dte-skills

Make a Rails app installable and offline-capable — web app manifest, service worker, install prompt, offline/cache states, and (optionally) push — built on Rails 8's native PWA support, not a hand-rolled service worker. Composes Rails 8 native PWA (app/views/pwa/manifest.json.erb + service-worker.js + the routes), the ui.sh family + frontend-design for install/offline UI, ie-experience-reviewer for the offline UX, and a Chrome DevTools Application-panel installability check. Use when the user says "make this a PWA", "make it installable", "add a web app manifest / service worker", "work offline", "add to home screen", or "installable web app". Loops over a list of apps/surfaces. Not for general front-end work (use dte-ux) or native mobile (Hotwire Native is a different toolkit).

2026-06-280

dte-arc-review

davidteren/dte-skills

Architectural review of a Rails app, a subsystem, or a vertical slice, producing a written findings doc. Composes Augment context retrieval, layered-rails analyzers, intent-engineering audit, majestic Rails reviewers, and a ponytail over-engineering pass into one severity-ranked report. Use when the user asks to "review the architecture", "do an arc review", "assess the structure/design", "find architectural issues / god objects / fat models / layering problems", or to review a slice/subsystem. Loops over a list of slices when given several. Not for line-by-line PR/diff review (use dte-deep-reviewer) or for planning fixes (use dte-arc-plan).

2026-06-280

dte-test-auditor

davidteren/dte-skills

Audit a test suite for real value, not just presence — coverage gaps AND test quality (weak assertions, over-mocking, implementation-coupled/brittle tests, missing edge/error/integration paths), plus mutation testing where available to prove tests actually fail when code breaks. Composes SimpleCov, rails-testing (Minitest), the ce-code-review testing persona, and mutant. Use when the user says "audit the tests", "are these tests any good", "check test coverage/quality", "do the tests actually test anything", or after a feature lands. Loops over a list of files/modules. Not for writing new tests (use minitest-coder / rails-testing) — this judges existing ones.

2026-06-280

dte-arc-plan

davidteren/dte-skills

Turn architectural findings, a spec, a bug report, or an "improve area X" request into concrete, validated implementation plan(s) — always built with compound-engineering's ce-plan and validated with intent-engineering's ie-validate-plan. For a massive task it decomposes the work into many small, independently-shippable plans (loop), each ce-planned and validated, and emits a plan index that dte-arc-work then completes. Use when the user says "plan the fixes", "make a plan(s) from these findings", "plan this bug/refactor/feature", "break this big thing into plans", or hands over a dte-arc-review doc. Not for executing plans (use dte-arc-work) or producing findings (use dte-arc-review).

2026-06-280

dte-arc-work

davidteren/dte-skills

The full cycle for a task, bug, area, or a whole plan index — review, plan, do the work, then verify — with quality gates and progress reporting throughout. Composes dte-arc-review (or a light scan), dte-arc-plan, ce-work, ce-simplify-code/ponytail, and dte-deep-reviewer + dte-test-auditor to verify. Loops over a list of tasks/bugs OR over a dte-arc-plan INDEX worklist to complete many plans (one branch + gate + report each). Use when the user says "fix this", "do the work", "implement this plan", "work through these plans/tasks", or "handle this end to end". Stops for review after each item by default; --ship to auto commit/PR. --quick for a small bug, --deep for a real change. Not for a pure root-cause bug hunt (use dte-debug), a full-stack feature with UI (use dte-feature), an upgrade/data migration (use dte-migrate), or setting up an autonomous batch loop (use dte-loop).

2026-06-280

dte-feature

davidteren/dte-skills

Full-stack new feature spanning front-end AND back-end — plan, implement, and verify across architecture/back-end AND UI/UX/front-end, making sure BOTH are solid. Composes dte-arc-plan (validated plan), dte-arc-work (gated build), dte-ux + the ui.sh family for the front-end, and dte-deep-reviewer + ie-experience-reviewer to verify both layers. Use when the user says "build this feature", "ship this idea end to end", "add <feature> with a UI", or describes something that needs both a model/controller/job AND a screen. Loops over a list of features. Not for a back-end-only change (use dte-arc-work), pure UI (use dte-ux), or just defining the what (use dte-spec).

2026-06-280

name

dte-tooling-scan

description

dte-tooling-scan — history → "what to adopt next" doc

Read ../../references/conventions.md first. Output is a recommendations doc; never installs anything (installation is a separate, user-confirmed step).

Input

Optional: a time window ("last 2 weeks"), a topic ("testing", "review"), or nothing (recent history).
Optional loop over several windows/topics.

Procedure

Synthesize what we actually do. Run /ce-sessions over recent sessions + query MemPalace (mempalace_search, kg_query, kg_timeline) for recurring friction, repeated manual steps, and past "I wish we had X" moments. If MemPalace/sessions are unavailable, say so and use the repo's STATUS.md / git history instead.
Inventory what we own. List installed plugins/skills/agents (claude plugin list + the skill catalogue). This is the "already have" baseline.
Find the gaps. Cross the friction themes (step 1) against the inventory (step 2). A real gap is a recurring need with no owned tool that covers it. Use light web/Augment research only to name candidate tools for a confirmed gap — not to window-shop.
Apply the overlap rule (from skill-vet). For each candidate, state what it overlaps / replaces among owned tools. Reject or downgrade anything that mostly duplicates what we have (the majestic bloat lesson). Weight by our conventions + actual usage, not theoretical coverage.
Write docs/reviews/tooling-scan-<date>.md: ranked recommendations, each with — the friction it solves, the candidate, what it overlaps/replaces, effort (install vs build), and a clear adopt / bookmark / skip call. Plus a short "gaps with no good candidate yet" list.

Done when

The doc gives a short, ranked, overlap-aware adoption shortlist grounded in what we actually do — not a catalogue dump. Each item is install-or-build with a one-line justification.