m

Plugin m from marketplace Molcajete.ai in MolcajeteAI/plugin. Commands read from the repo's manifest — 1 month ago.

Skills (26)

• plan-authoring

  Owns the plan file format. One prose Markdown plan per /m:plan invocation, written as a single file at specs/plans/<timestamp>-<slug>.md. Decomposes a use case into ordered, vertical, working-software tasks (never implementation layers), each a checkbox the build consumes. Referenced by /m:plan to e

• headless-research

  Lightweight, silent research that runs before spec-writing. Checks for existing research (user-provided or cached), runs 2 parallel agents if needed, and saves a machine-oriented context brief to .molcajete/research/. No user interaction.

• research-methods

  Full research orchestration skill — detects tech stack, parses input type, launches 4 parallel agents (web docs, community, library discovery, local codebase), and synthesizes findings into a progressive research guide.

• change-review

  Shared machinery for the code-review commands (/m:review, /m:preflight, /m:walkthrough). Owns the Molcajete prerequisite gate, change-set resolution (branch / PR / two refs / working tree) with base-branch detection, the mapping from a diff to the spec tree (feature -> UC -> scenario -> integration

• setup

  Rules and templates for the /m:setup command. One-shot foundation setup from a single project description plus codebase detection. Generates PROJECT.md, TECH-STACK.md, ACTORS.md, GLOSSARY.md, MODULES.md, DOMAINS.md, FEATURES.md, and .molcajete/settings.json.

• asking-questions

  Rule governing how every user-facing question is presented — write a Markdown brief first, then ask with AskUserQuestion carrying only the decision. Covers what may never go inside the question field, field limits, the built-in escape hatches, when a brief is not required, when not to ask at all, an

• change-description

  The universal template for describing a change set to a human — the walk: a little prose for the reason, then one section per spec change carrying its spec delta, its surface changes (interface, data layer, events, configuration), and its flow. Owns the atoms, the layout and diagram rules, and the t

• code-documentation

  Conventions for generating README.md files as LLM-optimized navigation documents. Covers YAML frontmatter, file tables, subdirectory tables, Mermaid diagrams, and stack-specific variants (backend, frontend, config). Used by /m:doc and the documentation task in build plans.

• git-committing

  Standards for structuring git commits during automated task execution. Covers message format, project style detection, atomic commit principles, scope assessment, and commit splitting. Read by build agents before committing work.

• git-conflict-resolution

  Reference material for resolving git merge and rebase conflicts. Covers the ours/theirs inversion under rebase, resolution strategies by file type, context gathering, and rules for correct resolution.

• github-issues

  How Molcajete opens a GitHub issue for work it found but does not do here. Owns the label vocabulary (AI-finding plus one kind label), the label creation that must run first, the batched offer question, the issue body shape, and the rule that every issue carries the Molcajete prompt that fixes it. L

• id-generation

  Rule enforcing canonical ID generation and permanent immutability for all entity identifiers (FEAT, UC, SC, FR, NFR, US, ADR). All IDs must be generated via the shared script — never compute base-62 manually. Once written, an ID never changes: never renumber, never reassign, never regenerate.

• output-economy

  How much Molcajete says, on every surface it writes to — spec files, plans, review documents, on-screen reports, question briefs, and command output. Sets the content test, the three moves for an over-long unit, per-surface budgets counted in sentences and sections, and the cases where completeness

• principles

  Engineering principles that bind any code Molcajete plans, builds, or reviews — integration tests as the trust contract, hexagonal default, dependency injection, 80% coverage floor, universal software craft (small functions, clear boundaries, no god files, refactor to reuse), technology-agnostic. Lo

• resolution-gate

  Rule that forbids an unresolved item in any document Molcajete generates — analyze first, then ask, then write. Defines the banned-marker vocabulary the spec guard hook enforces, the difference between a hole and a decided default, the fixed-category analysis sweep, the relevance filter and the ques

• specs-first

  The read order every entry point runs before it changes anything — the feature index, then the use cases, then the architecture document, then the requirements, then the code, with a web search at any point. Owns the frontmatter-first scan, the two entry modes (by ID, by description), the configurat

• status-rollup

  Status as first-class state on use cases and features. Defines the three-value enum (pending | dirty | implemented), per-level semantics, the Feature roll-up rule over its UCs, and which command writes which level. Task-level state lives in the plan's checkboxes; UC and Feature status live on the ar

• testing

  Technology-agnostic rules for the test-first build loop. Implementer, Validator, and Reviewer role contracts, outer-edge mocking, reading specs/TECH-STACK.md, Runner Inference, coverage gate scoped to a new file in full and to the changed lines of an existing file, legacy coverage reported and never

• uc-log

  Per-UC change log mechanics. Defines the CHANGELOG.md sidecar file path, TODO/DONE section layout, entry line format, the append-only invariant that forbids any command from removing or rewriting an existing entry, and entry-status transitions (pending → dirty → implemented). Referenced by /m:spec,

• writing-style

  How every sentence Molcajete writes reads — Simplified Technical English per ASD-STE100: active voice, one meaning per word, simple tenses, short sentences, no phrasal verbs. Holds the four accuracy rules that outrank every length cap, how to explain a new concept, how to show a computed value and a

• architecture

  Schema, section definitions, and population rules for ARCHITECTURE.md — the feature-level artifact that maps specs to code. Referenced by feature-authoring (scaffold creation) and reverse-engineering (code-driven population).

• feature-authoring

  Rules and templates for creating and updating feature documents. Defines EARS syntax patterns, Fit Criteria, Non-Goals positioning, FEAT-XXXX ID assignment, FEATURES.md row management, and the creation interview pattern. Used by /m:spec.

• reverse-engineering

  Rules and methodology for extracting specs from existing codebases. Defines research patterns, ARCHITECTURE.md population from code analysis, scope discovery, extraction patterns mapping code constructs to spec elements, and subagent dispatch for spec extraction.

• spec-lookup

  Shared machinery for the spec-query commands (/m:desc, /m:ids, /m:prompt). Owns the read-only prerequisite gate, the ID taxonomy that maps each prefix to its definition site, resolve-by-ID with its miss and partial branches, resolve-by- keyword with glossary expansion and two-tier ranking, and conte

• spec-revision

  Shared machinery for the revising spec commands (/m:fix, /m:change). Owns the skill load list, the prerequisite gate, loading the referenced specs, resolving a UC-XXXX to its module-instances with the multi-module fan-out, the spec-edit application rules, changelog and status writing, plan productio

• usecase-authoring

  Rules and templates for creating and updating use case files. Defines UC file structure with flat inline scenario blocks, mandatory Side Effects field with non-side-effects, YAML frontmatter schema, UC-XXXX ID assignment, USE-CASES.md row management, and the creation interview pattern.

Hooks (2)

• PreToolUse

  node

• PreToolUse

  node

Similar plugins