format-markdown

Estrellas10

Forks3

Actualizado21 de mayo de 2026 a las 18:39

Formats Markdown files consistently using project-native tooling first (repo scripts/config), then safe fallback formatters, and verifies the result with lint/check commands. Invoked when the user asks to format markdown, tidy docs, normalize README files, or fix markdown style drift.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Fuente

soulcodex

soulcodex/agentic

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Procesadores de texto y mecanógrafosOficina y apoyo administrativo·SOC 43-9022

Explorador de archivos

2 archivos

SKILL.md

readonly

name	format-markdown
description	Formats Markdown files consistently using project-native tooling first (repo scripts/config), then safe fallback formatters, and verifies the result with lint/check commands. Invoked when the user asks to format markdown, tidy docs, normalize README files, or fix markdown style drift.
version	1.0.0
tags	["documentation","markdown","formatting","linting"]
resources	["rules.md"]
vendor_support	{"claude":"native","opencode":"native","copilot":"prompt-inject","codex":"prompt-inject","gemini":"prompt-inject"}

Markdown Formatting Skill

Format Markdown files so they are structurally correct, readable, and consistent with the repository's formatting/lint rules.

Step 1 - Determine Scope

If the user provides files, format only those files.
Otherwise format changed Markdown files in the current branch/diff.
If no changed Markdown files exist, ask for explicit paths before proceeding.

Step 2 - Load Local Conventions

Read project formatting/lint config when present (for example .prettierrc*, .markdownlint*, lint scripts in package.json, justfile, Makefile).
Apply the repository's conventions over generic defaults.
Read rules.md and treat those rules as baseline behavior.

Step 3 - Apply Formatter (Preferred Order)

Run repository-native formatting command if one exists (for example just, make, or package script targeting markdown).
If none exists, use a standard Markdown formatter available in the repo toolchain (for example Prettier).
If Markdown linter auto-fix is configured, run it after formatting.

Do not introduce formatting tools that are not already part of the repository unless the user asks.

Step 4 - Validate

Run markdown checks/lint commands available in the repository.
If checks fail with auto-fixable findings, apply fixes and re-run checks.
Report any remaining non-auto-fixable violations with file paths.

Step 5 - Safety Rules

Preserve document meaning and code block content.
Do not rewrite prose for style unless the user asks.
Do not alter links/anchors in ways that break navigation.
Keep frontmatter valid and unchanged semantically.

Step 6 - Output

Report:

files formatted
command(s) used
verification command(s) and results
any remaining manual fixes required

Más de este repositorio

mismo repositorio

terraform-infrastructure

soulcodex/agentic

Structures, writes, and reviews Terraform infrastructure code. Covers module layout, remote state, workspace strategy, variable and secrets handling, CI plan/apply pipeline, naming conventions, and multi-region deployment patterns (provider aliases, per-region state, failover strategies), while delegating shared risk classification, version guards, and rollback contract to `terraform-risk-playbook`. Invoked when the user asks to write Terraform, set up infrastructure as code, or review IaC.

2026-06-2710

create-terraform-module

soulcodex/agentic

Creates or updates AWS-oriented Terraform module structure and implementation scaffolding. Focuses on file layout, variable/output contracts, provider and version constraints, tagging standards, safe composition patterns, and address-stability guardrails.

2026-06-2710

create-terraform-tests

soulcodex/agentic

Designs and implements Terraform module tests for AWS-targeted modules. Covers terraform-native tests, validation gates, fixture composition, and risk-focused assertions for regressions, address migration, and unsafe changes.

2026-06-2710

design-aws-terraform-iac

soulcodex/agentic

Designs AWS-targeted Terraform infrastructure plans before implementation. Focuses on service selection, module boundaries, state/backends, environment separation, security/compliance guardrails, acceptance criteria, and explicit risk/validation assumptions.

2026-06-2710

terraform-risk-playbook

soulcodex/agentic

Diagnoses Terraform/OpenTofu risk before generating changes. Defines the response contract, failure-mode routing, version/runtime guards, validation commands, and rollback expectations for modules, tests, CI, and state work.

2026-06-2710

use-aws-mini-stack-emulator

soulcodex/agentic

Uses lightweight AWS stack emulation for faster local Terraform iteration. Defines what can be safely validated locally, compatibility caveats, and the handoff boundary to real-AWS verification and reviewed plan/apply flows.

2026-06-2710

name	format-markdown
description	Formats Markdown files consistently using project-native tooling first (repo scripts/config), then safe fallback formatters, and verifies the result with lint/check commands. Invoked when the user asks to format markdown, tidy docs, normalize README files, or fix markdown style drift.
version	1.0.0
tags	["documentation","markdown","formatting","linting"]
resources	["rules.md"]
vendor_support	{"claude":"native","opencode":"native","copilot":"prompt-inject","codex":"prompt-inject","gemini":"prompt-inject"}

Markdown Formatting Skill

Format Markdown files so they are structurally correct, readable, and consistent with the repository's formatting/lint rules.

Step 1 - Determine Scope

If the user provides files, format only those files.
Otherwise format changed Markdown files in the current branch/diff.
If no changed Markdown files exist, ask for explicit paths before proceeding.

Step 2 - Load Local Conventions

Read project formatting/lint config when present (for example .prettierrc*, .markdownlint*, lint scripts in package.json, justfile, Makefile).
Apply the repository's conventions over generic defaults.
Read rules.md and treat those rules as baseline behavior.

Step 3 - Apply Formatter (Preferred Order)

Run repository-native formatting command if one exists (for example just, make, or package script targeting markdown).
If none exists, use a standard Markdown formatter available in the repo toolchain (for example Prettier).
If Markdown linter auto-fix is configured, run it after formatting.

Do not introduce formatting tools that are not already part of the repository unless the user asks.

Step 4 - Validate

Run markdown checks/lint commands available in the repository.
If checks fail with auto-fixable findings, apply fixes and re-run checks.
Report any remaining non-auto-fixable violations with file paths.

Step 5 - Safety Rules

Preserve document meaning and code block content.
Do not rewrite prose for style unless the user asks.
Do not alter links/anchors in ways that break navigation.
Keep frontmatter valid and unchanged semantically.

Step 6 - Output

Report:

files formatted
command(s) used
verification command(s) and results
any remaining manual fixes required