modeled-information-format
OrganizationMIF-first documentation skill suite for Claude Code: one skill per document genre (Diataxis, ADR, RFC/PEP, runbook, PRD, Kiro, arc42/C4, changelog) over a MIF Level 1-to-3 floor.
Categories
Indexed Skills (44)
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-expert audience that demands traceable evidence and explicit method. Anti-trigger; for an informal trade-off narrative use google-design-doc, for a practitioner decision report built around a mandatory comparison table use engineering.
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 capturing a consequential, hard-to-reverse technical choice and needs it documented with rationale. Anti-trigger; for a how-to use diataxis-how-to, for requirements use prd or feature-spec, not an ADR.
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 as durable declarative knowledge. Use when the user needs a system/software architecture description, an arc42 doc, a software architecture document (SAD), or to record how a system is structured and why. Anti-trigger; for a single decision use an ADR (structured-madr/Nygard), and for task steps use a runbook/how-to.
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 of a larger document written for a first-time reader use exec-summary, for a released-version history use changelog.
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 in SBA/SCORE convention and Lean Canvas problem-solution framing. Use when the deliverable is a comprehensive plan for business development, financing, market planning, market research synthesis, or strategic planning that must stand alone for a lender, investor, or partner. Anti-trigger; for a single feature's build scope use prd, for a fieldwork-sampled market study use market-research-report, for a pure technical trade-off evaluation use engineering.
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 software architecture at varying zoom levels for mixed technical/non-technical audiences. Anti-trigger; for a point-in-time decision record use adr, for a sequence/data-flow or deployment-only view use the matching diagram genre instead.
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 humans will read. Anti-trigger; not for forward-looking roadmaps, marketing release announcements, or a raw dump of git commit log lines.
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 reproduce the clinical-study-report structure of a regulatory submission. Anti-trigger; for a scientific journal article write academic, for a financial/legal disclosure filing use regulatory-disclosure, not this genre — and this genre never asserts clinical validity or regulatory acceptance, only structure.
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 market on two evaluation axes and places each into one quadrant. Anti-trigger; for a narrative survey of a market's size, segments, and trends with no forced vendor placement use market-research-report, not this genre.
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 paper for an ACM or IEEE venue. Anti-trigger; for the APA/IMRaD empirical-paper structure with author-date citations use academic, for a practitioner decision report with a mandatory trade-offs table (no CCS/evaluation matter) use engineering.
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-trigger; for accomplishing a known task use diataxis-how-to, for a beginner learning by doing use diataxis-tutorial, for fact lookup use diataxis-reference.
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 use diataxis-tutorial, for looking up facts use diataxis-reference.
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 use diataxis-tutorial, for accomplishing a known task use diataxis-how-to.
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") rather than a single genre artifact.
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 technical decision or evaluation for the engineers who will build or operate the result. Anti-trigger; for a single immutable decision with no mandatory comparison table use adr, for a pre-build alignment narrative built around prose trade-offs rather than a required table use google-design-doc, for product requirements use prd or feature-spec.
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 report. Anti-trigger; for the full study those decision-makers are summarizing use market-research-report or security-pentest (or prd for product requirements), not this genre.
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 use arc42-arch-doc, for a decision record use adr, for a multi-feature product doc use prd.
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 decision on record. Anti-trigger; for a single immutable decision use adr, for product requirements use feature-spec, for an operational procedure use sre-runbook.
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 close reading, not an empirical study. Anti-trigger; for the same notes-bibliography convention with parenthetical author-date citations instead of footnotes use humanities-mla, for an empirical IMRaD paper with Method and Results use academic.
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 empirical IMRaD paper. Anti-trigger; for an empirical Method/Results report use academic, for the Chicago note-bibliography convention use humanities-chicago.
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 law resolves on the facts. Anti-trigger; for a single immutable engineering/technical decision use adr, for a regulated-industry compliance finding rather than a predictive legal question use compliance-audit.
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 must see the sampling basis, the fieldwork, and traceable evidence before they trust it. Anti-trigger; for tracking a trajectory over time use trend-analysis, for ranking vendors on two axes use competitive-quadrant, not this genre.
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 docs ("which doc covers X?", "what should this link to?"). Anti-trigger; for proving conformance use mif-validate — similarity is a suggestion signal, never a gate.
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-asserted. Use after authoring a MIF document in a session with capture enabled, to make its provenance witnessed rather than asserted; use verify to detect drift between a document's provenance block and what the ledger actually observed; use status when you just enabled capture or updated this plugin and want to confirm hooks are actually wired before trusting anything gets stamped. Anti-trigger; for writing the rest of the frontmatter use mif-frontmatter (asserted provenance from drafting context), and for schema/level/round-trip conformance use mif-validate.
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) embedded as PDF metadata — the standard Info dictionary, real Dublin Core properties, a fully typed mif-namespaced RDF/XML tree per field, and a retained raw-JSON copy as the machine-checkable losslessness guarantee. Input is JSON-LD only; a Markdown source is converted first with the existing mif-convert/mif-validate tooling. Use when a MIF document needs a portable, richly-formatted, metadata-bearing PDF rendering.
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 with control-mapping crosswalks. Use when the deliverable is standing standards or guidance issued under NIST's mandate. Anti-trigger; for a one-time client engagement report that applies a standard use security-pentest or compliance-audit, not this genre.
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 This, Reference Implementation, Rejected Ideas, and Open Issues. Use when the user is proposing or drafting a Python language/stdlib/process change in PEP form. Anti-trigger; for a project's own architecture decision use an ADR skill, and for end-user task instructions use a how-to.
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 language/library/platform change needs written design consensus BEFORE implementation. Anti-trigger; for a decision already made and being recorded use an ADR (structured-madr), and for a bug or small change use a plain issue.
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, post-exploitation, and a mandatory severity-ranked findings table scored against a current CVSS rubric). Use when the deliverable is an authorized penetration-test engagement report that must brief executives and equip remediation engineers from the same evidence base. Anti-trigger; for a controls-vs-framework compliance mapping use nist-sp or compliance-audit, for an operational incident-response procedure use playbook or sre-runbook.
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, replica lag). Anti-trigger; for strategic, multi-incident response design write a playbook, and for a learning lesson use diataxis-tutorial.
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 to its location. Use when the deliverable must reproduce the GRI sustainability-reporting structure. Reproduces the GRI structure only, never GRI assurance. Anti-trigger; for a SOC-2-shaped internal controls review use compliance-audit, for a Reg-S-K/Form-10-K annual disclosure use regulatory-disclosure — neither carries the GRI topic-standard frame or the content index this genre requires.
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 embedded via an img tag, since GitHub strips inline svg markup from rendered markdown. Use when a genre skill's chart need exceeds Mermaid's documented limits.
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 process legible and reproducible end to end. Anti-trigger; for a general scholarly write-up with no mandatory flow diagram or registered protocol use academic.
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 projects it forward under uncertainty. Anti-trigger; for a fieldwork-and-sampling study of a market at a point in time use market-research-report, for ranking vendors on two axes use competitive-quadrant, not this genre.
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, for diagrams alone use c4-model-diagram.
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-trigger; for accomplishing a known task use diataxis-how-to, for facts use diataxis-reference.
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.
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-tasks.
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-tasks.
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-requirements, for the design use kiro-design.
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 output form.
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 PRD.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.