iopsystems

@iopsystems source repo

28 skills
0 followers
3 hours ago last updated

▌
Discuss · iopsystems
Capture a conversation or working session as a **discussion** (multiple attendees) or **session note** (solo author, often with an agent) in the knowledge-iop vault, AND surface what existing artifacts the conversation implicates. Discussions are the vault's napkin — freely editable and deletable — but their real value is triaging what they imply. Use this whenever the user says things like "let's write this down", "record the meeting", "capture this session", "note the decision points", "what did we discuss", or when a conversation has clearly concluded a loop that should be logged. This skill also surfaces follow-up actions: does this discussion invalidate an existing brief? does it warrant a new inquiry? does it frame a problem that isn't in the vault yet?

0 installs
▌
Open Arc · iopsystems
Open a new **arc** — a narrative unit of change in the knowledge-iop vault that spans weeks to quarters. Arcs have a beginning, middle, and end. Use this when the user says things like "let's start an arc for X", "open the Y arc", "we're kicking off a project on Z", "this deserves its own arc". Arcs group briefs, inquiries, and decisions under a shared charter — the situation, the tension, the direction of resolution. If the effort is permanent (not going to close), use `define-scope` instead. If it's a one-off, maybe it just needs a brief.

0 installs
▌
Close Arc · iopsystems
Close an open **arc** — mark its narrative complete (`closed`) or explicitly set aside (`abandoned`), and audit that its closing conditions were actually met. Use this when the user says things like "close the X arc", "we're done with this arc", "abandon arc Y", "wrap up the arc". An arc cannot be `closed` while any of its inquiries are still `open` — this skill invokes `vault_check_transition` to enforce that and surfaces the blockers concretely. Arcs that trail off without explicit closure are the vault's biggest smell; spending two minutes on this skill is how that's avoided.

0 installs
▌
Synthesize · iopsystems
Write the **synthesis** that closes an inquiry — read every submitted exploration, reconcile them against the framing, and produce the inquiry's resolved take. Use this when the user says things like "the barrier has released", "let's synthesize the inquiry", "we have all the explorations now", "resolve inquiry X". This skill assumes the barrier condition is met and all intended explorations have been submitted; it will refuse to synthesize a `status: open` inquiry. Synthesis is the only artifact that reads *across* explorations — everything before it is isolated.

0 installs
▌
Catchup · iopsystems
Summarize recent development activity in the current repo so the user can catch up on what others have changed in the last hours/days/weeks. Picks the window automatically — since the user's last commit, or else the larger of the last 5 commits vs the last 7 days — and produces a grouped, prioritized summary (themes, risky changes, files touched, who did what). Trigger when the user says things like "what did I miss", "catch me up", "what's new on this branch", "what changed since I was out", or after returning from time off.

0 installs
▌
Define Scope · iopsystems
Define a new **scope** — a stable reference frame (service, domain, surface, cross-cutting concern) that the vault cares about for years rather than the duration of a narrative arc. Use this when the user says things like "we need a scope for X", "add a scope", "register the billing service", "document this as a domain we care about". Scopes are flat (no hierarchy), they don't have arcs' narrative lifecycle, and they retire rather than close. Don't create a scope lightly — scope proliferation is a smell. If it's a short-lived effort, use `open-arc` instead.

0 installs
▌
Open Inquiry · iopsystems
Open a bounded parallel **inquiry** — the knowledge-iop vault's barrier-mode coordination primitive for cases where multiple people should explore a question independently before anyone synthesizes. Use this when the user says things like "let's explore alternatives", "I want N people to try this independently", "we need parallel drafts", "let's not converge too early", or when a problem has multiple credible approaches and premature convergence would foreclose options. An inquiry is a *directory*: framing up front, isolated exploration files, synthesis after the barrier releases. If the question has one clearly best answer already, use `propose-design` instead — inquiries are for genuine ambiguity.

0 installs
▌
Plan Feature · iopsystems
Scope, frame, and design a feature end-to-end — especially one that spans more than one repo. Runs a multi-turn Q&A covering problem, user value, constraints, surface area, key decisions, and cross-repo coordination, then fans the output out into the right places: paired problem/design briefs in the knowledge-iop vault (always), an optional design doc in the feature repo (`docs/design/<slug>.md`), and draft per-repo tracking issues. Use this when the user says things like "plan a feature", "scope this work", "I need a design for X", "let's kick off Y", "we need an RFC for this", or any time work needs both centralized knowledge capture and repo-local grounding. If the user only wants to capture a problem with no solution in mind, use `frame-problem` directly instead.

0 installs
▌
Vault Search · iopsystems
Query the knowledge-iop vault as a habit before drafting anything. Before you write a new problem-brief, design-brief, inquiry, decision, discussion, scope, or arc, first check whether a relevant artifact already exists so you can supersede, relate to, or frame from it — rather than orphan your work. Use this whenever the user says things like "what do we know about X", "is there already a brief on Y", "show me the design for Z", "find related artifacts", "what's the status of...", or before any phase skill (frame-problem, propose-design, record-decision, ...). The underlying programmatic tools are vault_search, vault_edges, and vault_check_transition — this skill teaches when to reach for each.

0 installs
▌
Frame Problem · iopsystems
Draft a **problem brief** — the "what actually is the problem" half of the paired briefs convention in knowledge-iop. A problem brief is written before any solution is proposed. Use this whenever the user says things like "we need a problem brief", "let's frame the problem", "what are we even solving", "capture the constraints", "I want to document a problem we can't solve yet", or any time they're about to design something but the problem hasn't been stated in one place. A problem brief can be orphan-of-solution — it's valuable even without a design. After framing a problem, the natural next step is `propose-design` (which `frames:` this brief).

0 installs
▌
Propose Design · iopsystems
Draft a **design brief** — the "how do we solve it" half of the paired briefs convention in knowledge-iop. Every design brief must declare `frames:` pointing at a problem brief (or `frames: none` with a reason, discouraged). Use this whenever the user says things like "I need a design brief", "let's design a solution for X", "propose a design", "draft the design half", "how should we approach this". If no matching problem-brief exists in the vault, this skill will direct you to `frame-problem` first — solutions without framing are the anti-pattern the vault is built to prevent.

0 installs
▌
Reconcile Vault · iopsystems
Reconcile the knowledge-iop vault. Two modes, same skill. **Interactive** — invoked after a phase skill commits an artifact; scoped to the touched artifact and its immediate graph neighborhood; applies and commits clean transitions by default. **Dream** — invoked by a Claude Max scheduled task; runs across the whole vault; writes a session-note with Part A (graph hygiene — deterministic) and Part B (strategic reflection — judgment), applies the transitions that pass the same clean-run test interactive mode uses, and merges both in one pull request by default. Use whenever the user says things like "reconcile the vault", "what needs attention", "dream over the vault", "check for blocked transitions", "what's the state of the project", "run reconciliation". Route blockers, warnings, ambiguity, and failed validation to human review. Interactive mode opens a pull request only when the user asks for one or a finding needs human review; dream mode always opens one, because it writes unattended. The vault has no for

0 installs
▌
Record Decision · iopsystems
Record a **decision** — the "because" that cites one or more design briefs (each of which frames a problem brief). Three-hop traceability: why do we do this? → this design → because of this problem. Use this when the user says things like "record the decision", "capture what we decided", "let's log this decision", "add a decision", or after a design brief has been accepted and the user wants to capture the downstream commitment. Decisions are written by humans (with agent help); briefs are written by agents. Keep that boundary firm. A decision cannot be `accepted` while any of its `derived_from` design briefs is not accepted — this skill invokes `vault_check_transition` to enforce that before writing.

0 installs
▌
Review Guide · iopsystems bundle
Draft the pull-request body as a guide for the human reviewing it: where to look more closely, what was tested and what was not, which calls were rather than deduction, and what will only show up in production. Use when asked to "draft the PR body", "write the PR description", "make this reviewable", "write a review guide", or whenever opening or updating a pull request. It runs on every change; what it publishes is proportional to the change, and a change with nothing to direct attention to earns one sentence rather than a guide. Beta — its ranking and publish rules are asserted rather than measured, so record friction and confirmation through `engineering-journal`. Symptoms that this skill applies: a description that retells the diff, a reviewer who reads files in whatever order the diff listed them, "all tests pass" with no statement of what the tests do not cover, a change whose risky decisions are invisible because they look like ordinary code, or an author who resolved an ambiguous requirement silently

0 installs
▌
Document Feature · iopsystems bundle
Use when creating or materially revising a project's README, code documentation, CLI help, diagrams, onboarding, or other feature documentation for users or developers.

0 installs
▌
Recommend Skills · iopsystems bundle
Use when a user asks which active skills from this MCP skill catalog or embedded agent-skill templates to use, seed, or adopt for a project; or when checking whether a project-local instance already covers that catalog need.

0 installs
▌
Submit Exploration · iopsystems
Author a single **exploration** within an open inquiry — one explorer's independent take on the question, drafted in isolation from other explorers. Use this when the user says things like "I want to contribute to inquiry X", "let me write my take on this", "add my exploration", "submit my draft". An exploration is intentionally drafted without seeing others' work — that's the barrier-mode coordination pattern. Submission freezes the content; synthesis comes later via the `synthesize` skill once the inquiry's barrier condition is met.

0 installs
▌
Sweep Comments · iopsystems bundle
Hold code comments and docstrings to a strict quality bar. Use whenever writing or editing comments — adding a comment to new code, being asked to "document this", "add comments", or "make this reviewer-ready" — and as a dedicated staleness sweep before opening or updating a pull request. Symptoms that this skill applies: comments that restate the adjacent code, the same design explanation sprinkled across several sites, docstring boilerplate on small internal helpers, derivation walkthroughs, war-story narration, comments describing behavior a design pivot has since deleted, commented-out code kept "just in case", ticketless TODOs, banner comments, docstrings written only to silence a linter, an invariant reduced to a pointer at the very site where a wrong edit would silently break it, or a comment asserting what the code does, has, or lacks that nobody checked against the code.

0 installs
▌
Dataflow Diagram · iopsystems bundle
Use when drawing or materially revising a dataflow or pipeline diagram for a program that already exists in code — a DAG, a processing chain, a stream topology, a service graph. Triggers include "diagram the pipeline", "show the dataflow", "chart the DAG", "visualize how the data moves", or a design doc or PR needing a picture of a running system. Symptoms include a hand-maintained diagram that no longer matches the code, a legend that disagrees with the chart, a glyph reused for two kinds of thing, a diagram that silently omits a node nobody classified, or a picture that is a screenshot rather than a source file.

0 installs
▌
Review Exchange · iopsystems bundle
Exchange threaded review notes with another local agent through a repo-local git bridge. Use when asked to "review this branch", "get a second opinion", "check the review feedback", "reply to the review", "what did Codex say", or whenever two independent agents are reviewing each other's work on the same repository. Installs itself into a repository that does not have the bridge yet, and upgrades one whose format has drifted. Symptoms that this skill applies: a review that arrives as chat text and is lost on the next compaction, a finding you disagree with and have nowhere to dispute, a reviewer repeating a finding that was already answered, or a repository where the other agent's notes have no agreed home.

0 installs
▌
Technical Prose · iopsystems bundle
State the word-level bar for technical prose: no hedged modality, no vocabulary that carries no fact, one name per thing. Use when asked to "de-slop this", "tighten this wording", "make this plainer", "cut the AI voice", or when another skill defers here for word choice. Symptoms that this skill applies: requirements softened to "should", possibility written as "may" or "could", intensifiers standing in for measurements ("robust", "blazingly fast", "seamlessly"), throat-clearing openers ("it is worth noting that"), a behavior described as "gracefully handled" rather than stated, the same thing called three names across one document, or an action buried in a nominalization ("perform compression of" for "compress"), a sentence chaining three clauses with "and", "but", "so", or a dash, a referent that resolves only for someone who was in the room ("this arc", "the fix"), or a metaphor standing where the fact should be. Also use for a cold read: "would this make sense to someone with no context?" Naming the reade

0 installs
▌
Seed Skill Template · iopsystems bundle
Use when a user has approved a catalog skill template to seed, customize, or upgrade, or explicitly asks to perform one of those actions for a project-local installed instance.

0 installs
▌
Dataflow Diagram 2 · iopsystems bundle
Draw a dataflow or pipeline diagram for a program that already exists in code — a DAG, a processing chain, a stream topology, a service graph. Use when asked to "diagram the pipeline", "show the dataflow", "chart the DAG", "visualize how the data moves", "make a graph of the program", or when a design doc or PR needs a picture of a running system. Symptoms that this skill applies: a hand-maintained diagram that no longer matches the code, a chart whose legend disagrees with the chart, a glyph reused for two different kinds of thing, a diagram that silently omits a node nobody classified, a legend placed by eye that overlaps an edge, or a picture that is a screenshot rather than a source file.

0 installs
▌
Engineering Journal · iopsystems bundle
Use when starting, continuing, handing off, reconciling, or closing a non-trivial engineering or research effort in a repository with durable project records.

0 installs
▌
Architecture Diagram · iopsystems bundle
Use when creating or materially revising system architecture diagrams — a build-time structure chart (units, layers, product composition) or runtime charts (thread model, life-of-a-request flow). Triggers include "architecture diagram", "threading diagram", "dataflow chart", "life of a request", "diagram the system". Symptoms include a hand-maintained diagram drifting from the code, a chart that cannot say whether a thread or queue still exists, or structure and runtime claims tangled in one unreadable picture.

0 installs
▌
Engineering Journal 2 · iopsystems bundle
Use when starting, continuing, handing off, or closing a non-trivial engineering or research effort in a shared repository; when preserving a measured negative result; when reconciling journal status, index, or backlog drift; or when identifying journal material that may inform future problem or design briefs.

0 installs
▌
Architecture Diagram 2 · iopsystems bundle
Use when creating or materially revising system architecture diagrams — a build-time structure chart (units, layers, product composition) or runtime charts (thread model, life-of-a-request flow). Triggers include "architecture diagram", "threading diagram", "dataflow chart", "life of a request", "diagram the system". Symptoms include a hand-maintained diagram drifting from the code, a chart that cannot say whether a thread or queue still exists, or structure and runtime claims tangled in one unreadable picture.

0 installs
▌
Format Layout Diagram · iopsystems bundle
Draw the layout of a memory or wire format that already exists in code — a byte anatomy of one encoded instance, the per-variant conventions of a shared encoding, or the linkage between blocks. Use when asked to "diagram the format", "show the byte layout", "draw the header", "picture the on-disk structure", "explain the encoding", or when a format reference, design record, or pull request needs a figure of a structure a reader cannot hold in their head. Beta — the conventions come from one format in one repository, so record friction and confirmation through `engineering-journal`. Symptoms that this skill applies: a byte grid drawn by hand from a specification, a figure whose offsets no longer match the encoder, a byte grid routed through a graph layout engine, a figure that cannot say whether it shows what ships or what is planned, or a figure that looks right in a browser and breaks in the rasterizer that publishes it.

0 installs

28 published skills