thasmorato-skills

Plugin thasmorato-skills from marketplace thasmorato in ThaSMorato/skills. Commands read from the repo's manifest — 22 days ago.

Skills (39)

• acceptance

  Check every acceptance criterion and every part of the owner''s request against the running software before the work is called done: each one verified in the browser (with a screenshot), by a named test only, or not verified with the reason, recorded in one index the pull request reads. Use after th

• architecture
• asking
• clean-code
• code-smells
• data-access
• diagnose
• doc-validate
• domain-model
• flow-report
• generate-stack-guide
• generate-test-guide
• guardrails
• handoff
• implement
• interview
• plan-validate
• pr
• prototype
• questionnaire
• retro
• security
• tdd
• teach
• testing
• ticket-design
• ticket-plan
• tickets-validate
• tidy
• trim
• ui-audit
• ui-design
• ui
• visuals
• wait-what
• walkthrough
• writing-beats
• writing-fragments
• writing-shape

Slash commands (48)

• /thasmorato-skills:acceptance

  Check every acceptance criterion and every part of the owner''s request in the running software (browser and screenshot, a named test, or not verified with the reason) after the last change, and record it for /pr.

• /thasmorato-skills:adr-generate

  Write a formal ADR (MADR) from a confirmed Potential ADR.

• /thasmorato-skills:adr-identify

  Sweep the design docs (HLD/FDD/boundaries) for architectural decisions that merit an ADR, proposing Potential ADRs.

• /thasmorato-skills:adr-link

  Maintain the ADR link graph (supersedes/amends inverses) and refresh the timeline index.

• /thasmorato-skills:analyze

  Analyze an existing codebase (brownfield), the structural profile and architecture report, then optional per-component deep dives.

• /thasmorato-skills:audit-deps

  Audit the project's dependencies for vulnerable, deprecated, unmaintained or license-risky libraries, using the ecosystem's own audit tools.

• /thasmorato-skills:boundaries

  Write the boundary contract from the component map and the FDDs (allowed dependency edges, policy vs detail, plug points), as a machine-checkable manifest.

• /thasmorato-skills:c4-generate

  Generate C4 diagrams (PlantUML); C1/C2 from the HLD, the system C3 from the component map, C3/C4 per feature from the FDD.

• /thasmorato-skills:components

  Build the system component map from the HLD, the named parts every FDD maps its feature onto (the system-level C3).

• /thasmorato-skills:decompose

  Cut the product into epics and features, ordered by risk, with cross-feature dependencies and requirement coverage.

• /thasmorato-skills:design

  Build and persist the node map for one ticket (deep modules behind small interfaces at clean seams) before planning or coding.

• /thasmorato-skills:diagnose

  Find the cause of a bug by evidence (reproduce, three hypotheses of different kinds, evidence for and against, one discriminating probe at a time) and pin it with tests before anything is fixed.

• /thasmorato-skills:doc-validate

  Validate a design document against the one it came from before the human gate (coverage both ways, contradictions, glossary drift, unanswered RNFs) with a clean/dirty verdict.

• /thasmorato-skills:fdd

  Write a Feature Design Doc for one feature, from the HLD (docs/hld.md).

• /thasmorato-skills:flow-report

  Gather what several projects learned about the plugin itself: their flow-tagged retro and session findings grouped by the stage they would change, and the flow measurements per plugin version, ranked into proposals for the next version.

• /thasmorato-skills:flow

  Drive the Doc-Dev flow; scan where the project stands, report what's waiting, and name the next stage for you to run.

• /thasmorato-skills:generate-stack-guide

  Generate a per-technology engineering guide skill (conventions, idioms, gotchas and security idioms for one language or framework), as a lazy-loaded router.

• /thasmorato-skills:generate-test-guide

  Analyze a project's stack and generate a project-specific testing-guide skill (what to test, at which layer, and how, per artifact type, including acceptance-test flows).

• /thasmorato-skills:guardrails

  Install the checks a repository is missing, using the commands it already has: pre-commit hook, CI job, a Claude Code hook that blocks destructive git, and optionally a dependency linter for docs/boundaries.md. Each one is proven to fire.

• /thasmorato-skills:guidelines

  Generate the project's engineering guidelines router, an index of stack guides, documents, conventions and real commands (≤150 lines, lazy-loaded).

• /thasmorato-skills:handoff

  Write what only this conversation knows (decisions said in chat, preferences, what is in flight, what failed, the next step) into a handoff file for a fresh session, pointing at the flow's artifacts for everything else.

• /thasmorato-skills:hld

  Write the High-Level Design from the PRD (docs/prd.md).

• /thasmorato-skills:implement

  Execute a validated plan one SI at a time, test-first (red → green → refactor), run the SI's tests, then STOP before the next SI.

• /thasmorato-skills:interview

  Open the Doc-Dev flow with the requirements interview, producing the brief, glossary, and ADRs.

• /thasmorato-skills:mermaid-generate

  Generate Mermaid diagrams from an FDD into a single Markdown file.

• /thasmorato-skills:plan-validate

  Validate an implementation plan before coding (gaps, ambiguity, dependency cycles, untestable criteria) and emit a clean/dirty verdict that gates /implement.

• /thasmorato-skills:plan

  Break one ticket into a validated implementation plan, vertical SIs with tests, dependencies, and acceptance criteria.

• /thasmorato-skills:pr

  Write a ticket''s pull request body from what the work left on disk: a summary drawn as the smallest view, before-and-after evidence, and the merge danger (one-way or two-way door, blast radius).

• /thasmorato-skills:prd

  Write the PRD from the requirements brief (docs/requirements-brief.md).

• /thasmorato-skills:prototype

  Answer one design question with throwaway code (a clickable HTML demo of a state model, or switchable UI variants on the real page), record the answer where the design was waiting for it, and keep the code off the working branch.

• /thasmorato-skills:questionnaire

  Write the questions the owner cannot answer alone into a questionnaire for the person who can, or fold a filled questionnaire's answers back into the documents waiting on them.

• /thasmorato-skills:reconcile

  Re-measure the dependency graph and reconcile it with the component map and boundary contract (drift since the last measurement, the commits behind it, the amendments each owning stage should make, and at most three latent-component proposals backed by measured evidence).

• /thasmorato-skills:research

  Investigate a technical question against primary sources, producing a cited report that feeds the HLD/FDD.

• /thasmorato-skills:retro

  Look back over a finished epic, feature or cycle from what it left on disk (plans, validations, progress notes, reviews) and record what it taught about the process and the product.

• /thasmorato-skills:review

  Review the diff since a fixed point across narrow lenses in parallel (quality, tests, security, spec, standards, architecture, data, docs, and UI when the diff touches it), then synthesize, and verify every finding against the code before you decide.

• /thasmorato-skills:session-analyze

  Read a whole working session (every compaction segment) and report where the owner had to correct, reject or repeat something and what in the environment got in the way, each tagged as a problem of the flow or of this project, with the repeats across segments first.

• /thasmorato-skills:teach

  Teach a topic over several sessions in a teaching workspace (mission, trusted sources, learning records, glossary), through short HTML lessons with practice, each pitched just past what you already know.

• /thasmorato-skills:tickets-validate

  Validate a feature's ticket set before the human gate (coverage, invention, tickets too big or too small, several tickets on one seam, blocking cycles, dispersion), with a clean/dirty verdict.

• /thasmorato-skills:tickets

  Break an FDD into tracer-bullet tickets with blocking edges, then publish them (local files or a real tracker).

• /thasmorato-skills:tidy

  Make working code simple, Beck's four rules of Simple Design in order (expression, then duplication, then size), as structural changes with the tests untouched and green. After /review on a ticket's diff, or on any path that has tests covering it.

• /thasmorato-skills:trim

  After /implement and before /review, make a ticket's change smaller without changing behavior (revert incidental hunks, reuse what the repo already has, drop files and layers the change did not need, pull a spread-out behavior into fewer files). Proposed with evidence, applied only where you choose,

• /thasmorato-skills:ui-audit

  Evaluate an existing screen in the running software and list its problems with evidence and severity: an isolated design critique, a technical pass and a worst-case data run. Reports; never edits.

• /thasmorato-skills:ui-design

  Design a new screen or redesign an existing one before it is built: the brief in rounds, three directions as HTML with captures, the chosen one through every state and width with an isolated critic, then the screen spec in docs/ui/.

• /thasmorato-skills:wait-what

  The last answer did not land; re-pitch it with a little context, in simplified technical English and the glossary's words, shorter than before.

• /thasmorato-skills:walkthrough

  Teach the owner the change the AI built before it merges: an HTML lesson over the ticket''s diff (what it does, where it lives, the path per acceptance criterion, what can go wrong) with a recall quiz, then re-explain what was missed.

• /thasmorato-skills:writing-beats

  Writing, exploit phase: turn raw material into a piece one beat at a time, never using a concept before it is grounded.

• /thasmorato-skills:writing-fragments

  Writing, explore phase: an interview that collects raw fragments into one file, with no structure yet.

• /thasmorato-skills:writing-shape

  Writing, exploit phase: shape raw material into an argued article, paragraph by paragraph, from a chosen opening.

Subagents (31)

• adr-analyzer

  Sweep the design docs (HLD/FDD/boundaries) for architectural decisions that merit an ADR and propose them as Potential ADRs for the user to confirm. Delegate after /hld or /fdd, or when the user runs /adr-identify. It identifies and justifies; it does NOT write formal ADRs.

• adr-generator

  Write a formal ADR (MADR) from a confirmed Potential ADR. Delegate when the user runs /adr-generate <potential> or confirms a Potential ADR to formalize.

• adr-linker

  Maintain the ADR link graph (supersedes/superseded-by/amends edges and a timeline index). Delegate when the user runs /adr-link, or after new ADRs are generated.

• architectural-analyzer

  Analyze an existing codebase's architecture, the structural profile (stack, components, import graph, conventions, test setup) plus a prose report on risks and debt. Analysis only. Delegate when the user runs /analyze or wants to understand an inherited/existing codebase (brownfield).

• boundary-architect

  Write the boundary contract after the FDDs (which dependency edges are allowed, what is policy and what is detail, where variation is deferred). Delegate when the user runs /boundaries. Produces the machine-checkable map the code stages consume.

• c4-generator

  Generate C4 diagrams (PlantUML) from the design docs (C1/C2 from the HLD, the system-wide C3 from the component map, and per-feature C3/C4 from the FDD). Delegate after /hld, /components or /fdd, or when the user runs /c4-generate.

• component-analyzer

  Deep-analyze ONE component of an existing codebase (internal structure, business rules, dependencies, patterns, tech debt). Analysis only. Delegate when the user runs /analyze <component>, or fan out one per component discovered by the architectural-analyzer.

• component-mapper

  Turn the HLD's "Main components" section into the system component map, the named parts of the system, one level below the containers, that every FDD then maps its feature onto. Delegate when the user runs /components, after /hld.

• decomposer

  Cut the product into epics and features, ordered by risk, with cross-feature dependencies, coverage in the omission direction, and stable ids. Delegate when the user runs /decompose, after /components.

• dependency-auditor

  Audit an existing project's dependencies (outdated/deprecated/vulnerable/unmaintained libraries and licenses). Analysis only, never upgrades. Delegate when the user runs /audit-deps.

• fdd-writer

  Write a Feature Design Doc for one feature from the HLD. Delegate after /hld has produced docs/hld.md, when the user runs /fdd <feature> or asks to spec a feature.

• guideline-generator

  Generate the project's engineering guidelines as a ROUTER (an index of stack guides, rules, documents and commands, with lazy loading). Delegate when the user runs /guidelines.

• hld-writer

  Write a High-Level Design from a PRD. Delegate after /prd has produced docs/prd.md, when the user runs /hld or asks for the high-level architecture.

• mermaid-generator

  Generate Mermaid diagrams from an FDD into a single Markdown file (flows, sequence, state, class/ER as the feature warrants). Delegate after /fdd, or when the user runs /mermaid-generate.

• pattern-scout

  Before a node map is drawn, find how this repository already does what a ticket needs (the analogous implementations, the conventions to mirror, and where new code gets wired in), each at file:line with the real code. Documents what exists; never critiques. Dispatched by /design. Returns tables; nev

• prd-writer

  Write a PRD from a requirements brief. Delegate after /interview has produced docs/requirements-brief.md, when the user runs /prd or asks to turn the brief into a PRD.

• reconciler

  Re-measure the dependency graph and reconcile it with the component map and boundary contract (what drifted since the last measurement, by whom, and which amendments the owning stages should make) and detect latent components by measured evidence. Delegate when the user runs /reconcile. Measures and

• researcher

  Investigate a technical question against primary sources and capture cited findings as a Markdown report that feeds the HLD/FDD. Delegate as a background/AFK agent when the user runs /research <question>, or when a decision needs reading legwork.

• review-architecture

  Review a change against the repo's structure (illegal dependency edges, new cycles, boundary erosion, detail leaking into policy). One of the /review fan-out. Needs the boundary contract and the import graph, not just the diff. Reports findings; never edits.

• review-data

  Review a diff for data-access and I/O weaknesses (N+1 queries, queries in loops, missing indexes, unbounded results, wide transactions, chatty remote calls, stale caches, over-fetching). One of the /review fan-out. Reports findings; never edits.

• review-docs

  Review a diff for documentation it made false (a README step, an env var, a CLI flag, a described behavior that the changed code no longer matches). One of the /review fan-out. Reports findings; never edits.

• review-quality

  Review a diff for code smells and clean-code violations (naming, functions, comments, errors, design, module depth). One of the /review fan-out. Reports findings; never edits.

• review-security

  Review a diff for security weaknesses at the CWE level (injection, access control, crypto, secrets, session handling, SSRF, uploads, rate limits, LLM risks). One of the /review fan-out. Reports findings; never edits.

• review-spec

  Review a diff against what it was supposed to do (the plan's SIs, the ticket's acceptance criteria, the FDD's contracts) for missing criteria and scope drift. One of the /review fan-out. Reports findings; never edits.

• review-standards

  Review a diff against the repo's own documented standards, the guidelines router, the stack guides, the ADRs and the glossary. One of the /review fan-out. Reports findings; never edits.

• review-tests

  Review a diff's tests as first-class code (coverage of the acceptance criteria, behavior through public interfaces, single-act, determinism, test DSL quality). One of the /review fan-out. Reports findings; never edits.

• review-ui

  Review a diff that touches user-interface code for defects a mouse-and-fast-network author does not see (keyboard access, focus, accessible names, contrast, missing loading/empty/error states, errors found too late, signals that contradict the risk of an action, layout shift, slow interactions). One

• review-verifier

  Check every finding of a synthesized /review against the repository before the owner decides what to fix; give each a verdict backed by cited code, and never drop one. Runs inside /review, after synthesis. Returns verdicts; never edits anything.

• session-segment-analyst

  Read one segment of an extracted session transcript and report where the owner had to correct, reject or repeat something, each finding anchored on an owner turn by uuid and timestamp, and tagged as a problem of the flow or of this project. One of the /session-analyze fan-out. Reports findings; neve

• source-reader

  Deep-read ONE source for a research question and return cited notes for the researcher to synthesize. Delegate from /research when the survey found several primary sources worth reading in parallel. It reads and extracts; it does NOT write the report.

• ui-critic

  Critique a screen's design from its captures and source, with no stake in it (usability heuristics scored 0 to 4, cognitive load, signals against risk, two or three personas walking the task, design specificity) and return findings with evidence plus the strengths. Used by /ui-audit for the design a

Similar plugins