Security and privacy review for a scoped change. Use when a change touches authentication, authorization, secrets, sensitive data or destructive actions. Do not use for general code review or dependency upgrades without a security surface.
Evidence-based gate for creating a new skill or agent profile. Use when someone proposes a new skill, agent or reusable procedure. Do not use to change an existing skill (self-improvement).
UI, accessibility and interaction-quality review. Use when a change alters screens, components, visual tokens or keyboard and screen-reader behavior. Do not use for API or CLI interfaces (public interface review) or functional QA runs (QA).
Performance investigation with reproducible measurements. Use when latency, throughput, memory or load time must be measured or improved. Do not use for code cleanup without a measured performance goal.
Prevent mixed-responsibility modules and uncontrolled file growth. Use before adding behavior to a large or mixed-responsibility file, or when splitting one. Do not use for small, local edits to cohesive modules.
Clarify expected behavior, then implement test-first where applicable. Use when a feature or fix has unclear acceptance criteria or needs new tests. Do not use for documentation-only changes.
Select a bounded, behavior-preserving cleanup batch. Use when removing duplication, dead code or stale files without changing behavior. Do not use for feature work or large restructurings (REFACTORINGGUIDE.md).
Prepare scoped conventional commit, tag and release messages. Use when committing, tagging or writing release notes. Do not use for frontmatter or wiki tags.
Validate FCVW structure, schemas, ownership, plan states, reading routes, Markdown and wiki health, and clean-template boundaries. Use before structural closeout, after moving governed files, or when auditing the framework. Do not use to change a skill or policy's content.
Format portable Markdown and optional Obsidian-compatible links. Use when writing or repairing links, callouts or embeds in governed Markdown. Do not use to validate frontmatter schemas (governance-validator).
Coordinate explicitly authorized parallel work across non-overlapping scopes. Use only when the user authorizes several agents or parallel sessions. Do not use for sequential single-agent work.
Instantiate project-owned FCVW profiles from a clean baseline. Use when starting a new project from the framework (Phase 0 briefing and PROJECT.md). Do not use for an existing codebase (retroactive-instantiation) or for CSS frameworks named Bootstrap.
Prepare and validate an application or framework release. Use when changing a version, tag, changelog or release record, or publishing assets. Do not use merely to read release notes or check a releasestatus field.
Adopt FCVW in an existing project without overwriting history. Use when adding the framework to a codebase that already has code, history or documentation. Do not use for a new project (project-instantiation).
Improve an existing skill or agent from evidence while preserving its scope. Use when a skill fails, drifts from a canonical rule or needs a trigger change. Do not use to create a new skill (agent-factory).
Diagnose failures with evidence and hypotheses before fixing them. Use when a check fails, behavior is unexplained or a regression appears. Do not use for planned feature work without a failure.
Promote sourced reusable knowledge, merge duplicates, compact sessions and rotate memory. Use when adding, merging, reviewing or archiving wiki notes. Do not use for framework policy changes.
Map an application on first use, test its behavior through the running target and keep a sourced product wiki. Use when asked to map screens, commands or APIs, run functional QA, or update product-behavior notes after a change. Do not use for unit-test design (brainstorming-and-tdd) or performance measurement…
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: