mif-docs

Plugin mif-docs from marketplace mif-docs in modeled-information-format/mif-docs-plugin. Commands read from the repo's manifest — 12 days ago.

Skills (47)

• academic

  Write a formal academic research report — Abstract, Background, Method, Findings, Discussion, References — with a selectable citation style (author-date/APA or numbered/Vancouver-IMRaD) and optional APA Method sub-sections. Use when the deliverable is a scholarly write-up for a research or technical

• adr

  Write an Architectural Decision Record (ADR) in the Structured MADR format — one decision, its drivers, the options weighed with risk, the chosen outcome, the consequences accepted, and an audit trail — validated by the structured-madr Action in both smadr and MIF modes. Use when a team is making or

• ai-architecture-doc

  Write a composite AI-spec architecture document that embeds an arc42/C4-style structure plus testable non-functional requirements and an ADR-style decision log in one spec-channel artifact. Use for an architecture spec a coding agent can consume. Anti-trigger; for a pure narrative use arc42-arch-doc

• arc42-arch-doc

  Author an arc42 architecture document — the 12-section industry template (introduction & goals, constraints, context, solution strategy, building blocks, runtime, deployment, cross-cutting concepts, decisions, quality requirements, risks & tech debt, glossary) that captures a system's architecture a

• audit-docs

  Audit MIF documents under one or more paths for accuracy, taxonomy alignment, editorial consistency, and frontmatter/provenance/temporal/relationship/citation conformance. Deterministic script checks run first at zero Agent cost; cross-document checks are guaranteed (three bounded Agent calls); per-

• briefing

  Write a one-page briefing or standup update — Headline, What's New, Why It Matters, What's Next / Asks — for a recurring audience that already holds context and needs the delta fast. Use for a terse status or situational update, not a narrative summary. Anti-trigger; for a longer standalone summary

• business-plan

  Write a full investor- and lender-ready business plan — Executive Summary, Company Description, Products & Services, Market Analysis, Competitive Analysis, Marketing & Sales Strategy, Operations Plan, Management & Organization, Financial Plan & Projections, Funding Request, and Appendix — grounded i

• c4-model-diagram

  Author a C4 model architecture document — Simon Brown's four levels of abstraction (System Context, Container, Component, Code) rendered as notation-independent Mermaid C4 diagrams plus an element catalog of people, systems, containers, and components. Use when the user needs to map or communicate s

• changelog

  Write or update a CHANGELOG in the Keep a Changelog 1.x format — a human-curated, reverse-chronological record of notable changes per released version, grouped by Added/Changed/Deprecated/Removed/Fixed/Security and versioned with SemVer. Use when the user needs release notes or a version history hum

• clinical-submission

  Write a clinical study report on the ICH E3 skeleton — Synopsis, Ethics, Investigators/Structure, Objectives, Investigational Plan, Methods (efficacy & safety), Results, Discussion & Conclusions, Tables/Figures/Appendices — situated in the CTD five-module frame (M1-M5). Use when the deliverable must

• competitive-quadrant

  Write a two-axis competitive-quadrant report — Completeness of Vision x Ability to Execute, four quadrants (Leaders / Challengers / Visionaries / Niche Players), per-vendor Strengths/Cautions, and a required Mermaid quadrant figure. Use when the deliverable ranks vendors or offerings in a defined ma

• compliance-audit

  Draft/model a compliance audit report shaped like a SOC 2 Type II controls report — auditor's-report framing, management's assertion, system description, in-scope criteria/framework, a mandatory tests-of-controls/findings matrix with severity, control gaps, remediation plan, and management response.

• computing-paper

  Write an ACM/IEEE computing conference or journal paper — Abstract, Introduction, Related Work, Approach/System Design, Evaluation, Discussion, Conclusion & Future Work, and a numbered References list — with IEEE numbered bracket citations. Use when the deliverable is a computing/engineering systems

• diataxis-explanation

  Write a Diataxis explanation — an understanding-oriented discussion that illuminates the why behind a topic, its background, design rationale, trade-offs, history, and connections to other ideas. Use when the reader needs to grasp a concept or decision, not perform a task or look up a fact. Anti-tri

• diataxis-how-to

  Write a Diataxis how-to guide — a task-oriented recipe that walks a competent user through accomplishing one real, already-understood goal, start to finish. Use when the user knows what they want to do and needs the steps, not learning or background. Anti-trigger; for a beginner learning by doing us

• diataxis-reference

  Write a Diataxis reference — a dry, information-oriented, exhaustive description of ONE thing (a CLI command, config file, API endpoint, or schema) whose structure mirrors the thing itself. Use when the user needs lookup material they consult, not read through. Anti-trigger; for learning by doing us

• diataxis-tutorial

  Write a Diataxis tutorial — a learning-oriented, hands-on lesson that takes a beginner through a single concrete success by doing, not explaining. Use when the user needs onboarding/getting-started content where the goal is the learner's confidence, not task completion or reference lookup. Anti-trig

• doc-set-planner

  Plan and decompose a broad documentation subject into a coordinated SET of MIF documents, fan out to the genre member skills, and reconcile the cross-document MIF relationship graph. Use when a request spans multiple documents ("document the auth system", "produce the full spec set for feature X") r

• ears-acceptance-criteria

  Turn a requirement, decision driver, or finding into an EARS-notation acceptance criterion that a human and an agent grade identically. Use when authoring acceptance criteria for a PRD, feature spec, architecture doc, ADR decision driver, or Kiro requirements document.

• engineering

  Write an engineering decision / evaluation report — Problem/Context, Options Considered, a mandatory options-vs-criteria Trade-offs comparison table, Decision, Implementation Notes, and Consequences — with optional ANSI/NISO Z39.18 technical-report front/back matter. Use when a team must document a

• exec-summary

  Write a 1-2 page decision-oriented executive summary — BLUF, Key Findings, Recommendation, Risks & Caveats — composable as the leadership-summary section of a fuller market-research or pentest report. Use when the deliverable is a short brief for decision-makers who will act without reading a full r

• feature-spec

  Write a lightweight, AI-ready Feature Specification — a ~500-2000 token spec with Overview, EARS acceptance criteria, Design, and Edge Cases that an implementer or coding agent can act on directly. Use when a single feature needs a concise build-ready spec. Anti-trigger; for org-wide architecture us

• google-design-doc

  Write a Google-style engineering design doc — an informal, trade-off-focused narrative that frames a problem, proposes one design, and weighs the alternatives it rejected. Use when an engineer must align a team on a non-trivial technical approach before building and wants the rationale and the decis

• humanities-chicago

  Write an argumentative humanities essay in Chicago Notes-Bibliography style — Introduction with thesis, thematic argument sections (claim, evidence, interpretation), Conclusion, numbered footnotes/endnotes, and a full Bibliography. Use when the deliverable is a humanities argument advanced through c

• humanities-mla

  Write an argumentative humanities essay in MLA style — Introduction with an explicit thesis, body argument sections, a Conclusion, MLA author-page in-text citations (e.g. (Author 42)), and a Works Cited list. Use when the deliverable is a humanities argument built on interpretation rather than an em

• kiro-design

  Write the design.md of an AWS Kiro three-document spec set — the technical design that traces back to numbered requirements. Use as the second Kiro artifact, between requirements.md and tasks.md. Anti-trigger; for the requirements use kiro-requirements, for the implementation task list use kiro-task

• kiro-requirements

  Write the requirements.md of an AWS Kiro three-document spec set — numbered requirements, each a user story plus EARS acceptance criteria. Use as the first artifact of a Kiro spec, feeding design.md and tasks.md. Anti-trigger; for the technical design use kiro-design, for the task list use kiro-task

• kiro-tasks

  Write the tasks.md of an AWS Kiro three-document spec set — a numbered, checkbox implementation plan where each task is small, test-driven, and traces to the design/requirements it implements. Use as the third Kiro artifact that drives implementation. Anti-trigger; for requirements use kiro-requirem

• legal-memo

  Write a predictive legal memorandum — Question Presented, Brief Answer, Statement of Facts, an IRAC Discussion (Issue, Rule, Application, Conclusion per issue), and a Conclusion, with Bluebook practitioner citations. Use when the deliverable is an internal legal analysis predicting how a question of

• market-research-report

  Write a full ESOMAR/ISO 20252-style market research report — Background & Objectives, Methodology (with mandatory sampling and fieldwork disclosure), Findings, Conclusions & Recommendations, and a Technical Appendix. Use when the deliverable is a complete market study for clients or stakeholders who

• mif-corpus

  Semantically index and query a corpus of MIF documents — ingest docs into a local vector store, run free-text search, find similar documents for cross-linking, and report corpus statistics via the optional mif-rs tools (mif-mcp MCP server or mif-cli). Use when a request needs discovery over existing

• mif-frontmatter

  Author MIF (Modeled Information Format) Level 1-3 frontmatter for any document, climbing from the L1 floor to L2/L3 only when the drafting context supplies real detail. Use whenever a doc needs MIF-conformant YAML frontmatter that projects losslessly to the canonical JSON-LD.

• mif-provenance

  Stamp witnessed provenance into a MIF document's frontmatter from the hook-observed session ledger, verify an existing provenance block against it, or check whether capture is actually active for the current session — hook-observed facts only (agent, agentVersion, session activity URN), never model-

• mif-to-pdf

  Convert a MIF JSON-LD document to a typeset PDF with real markdown rendering (headings, bold, inline code, flat bullet lists, tables, clickable links, embedded raster/SVG figures) plus every MIF frontmatter field (id/type/created, namespace/modified/temporal, provenance/citations/relationships) embe

• mif-validate

  Deterministically prove a document is MIF-conformant — schema-check its JSON-LD against the canonical mif-spec.dev schema, enforce the L1/L2/L3 floor, and verify the markdown<->JSON-LD round-trip is lossless. Use as the gate after authoring or editing any MIF document, and to convert a doc to either

• nist-sp

  Write a NIST Special Publication (SP 800-series style) standards/guidance document — authority statement, purpose & scope, audience, abstract, keywords, numbered normative sections with shall/should/may force, a required definitions/glossary, numbered bracketed references, and lettered appendices wi

• playbook

  Write a strategic operational playbook that coordinates a CLASS of situations (e.g. a Sev1 outage) across roles, decision points, and phases. Use for higher-altitude incident/operations coordination. Anti-trigger; for fixing one specific alert step-by-step use sre-runbook (tactical), not a playbook.

• prd

  Write a Product Requirements Document that leads with the problem, defines success metrics and non-goals, and expresses functional requirements as testable EARS criteria. Use when scoping what to build and why before design. Anti-trigger; for the technical how use feature-spec or a design doc, not a

• python-pep

  Write a Python Enhancement Proposal (PEP) — a formal design document proposing a change to the Python language, standard library, or process, with the canonical RFC822 header preamble plus Abstract, Motivation, Rationale, Specification, Backwards Compatibility, Security Implications, How to Teach Th

• regulatory-disclosure

  Write an SEC-style annual disclosure report — Business, Risk Factors, Properties & Legal Proceedings, Selected Financial Data, MD&A, Financial Statements & Supplementary Data, and Controls & Procedures, in Regulation S-K / Form 10-K item order. Use when the deliverable must reproduce the disclosure

• rust-rfc

  Write a Rust-style RFC (request for comments / enhancement proposal) — a structured design proposal with Summary, Motivation, Guide-level explanation, Reference-level explanation, Drawbacks, Rationale and alternatives, Prior art, Unresolved questions, and Future possibilities. Use when a substantial

• security-pentest

  Write a dual-audience PTES/OWASP-style penetration-test report — an Executive Summary for leadership (background, posture, risk profile, general findings, recommendation summary, strategic roadmap) plus a Technical Report for engineers (information gathering, vulnerability assessment, exploitation,

• sre-runbook

  Write an SRE operational runbook — a tactical, step-by-step procedure an on-call responder follows to detect, diagnose, and remediate ONE specific alert or failure condition under pressure. Use when the user needs incident-response content for a named alert/symptom (latency SLO burn, queue backlog,

• sustainability-report

  Write a GRI-Standards sustainability/ESG report — GRI 1 Foundation, GRI 2 General Disclosures, GRI 3 Material Topics (the materiality determination), topic standards across the GRI 200 (economic) / 300 (environmental) / 400 (social) series, and a mandatory GRI content index mapping every disclosure

• svg-charts

  Generate a standalone, brand-colorable SVG chart file (bar, line, pie, or combo) for cases the suite's default Mermaid-in-markdown convention cannot cover — more than roughly five pie or bar segments, custom per-series colors, log scales, or multi-series combo charts — saved as a real file and embed

• systematic-review

  Write a PRISMA 2020 systematic review — structured abstract, reproducible search/eligibility methods, a mandatory Mermaid PRISMA flow diagram of records identified/screened/excluded/included, risk-of-bias assessment, and synthesis of results. Use when the deliverable must make the evidence-selection

• trend-analysis

  Write a trajectory report — Trajectory, Signals, Drivers & Inhibitors, Scenarios, and Implications & Watch-list, with a mandatory trajectory/scenario diagram and an optional STEEP/PESTLE environmental scan plus methodology appendix. Use when the deliverable tracks how something is changing and proje

MCP servers (1)

• mif-mcp

  runs: mif-mcp

Hooks (5)

• SessionStart

  node ${CLAUDE_PLUGIN_ROOT}/hooks/provenance-session-start.mjs

• SessionStart

  node ${CLAUDE_PLUGIN_ROOT}/hooks/taxonomy-session-start.mjs

• PostToolUse

  node ${CLAUDE_PLUGIN_ROOT}/hooks/mif-guard.mjs

• PostToolUse

  node ${CLAUDE_PLUGIN_ROOT}/hooks/provenance-post-tool-use.mjs

• SessionEnd

  node ${CLAUDE_PLUGIN_ROOT}/hooks/provenance-session-end.mjs

Similar plugins