Run any Skill in Manus with one click

mcaf-formatting

Stars20

Forks0

UpdatedFebruary 1, 2026 at 12:48

Format code and keep style consistent using the repository’s canonical formatting/lint commands from `AGENTS.md`. Use after implementing changes or when formatting drift causes noisy diffs; keep formatting changes intentional and verified with build/tests.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

Zendevve

Zendevve/opentweak

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	mcaf-formatting
description	Format code and keep style consistent using the repository’s canonical formatting/lint commands from `AGENTS.md`. Use after implementing changes or when formatting drift causes noisy diffs; keep formatting changes intentional and verified with build/tests.
compatibility	Requires the repository’s formatter/linter tools; uses commands from AGENTS.md.

MCAF: Formatting

Outputs

Formatted code changes (consistent with repo style)
Evidence: formatting command(s) run and any follow-up build/tests

Workflow

Use the canonical format command from AGENTS.md (do not invent commands).
Run the formatter on the smallest scope possible (if your tools allow it).
Review the diff:
- ensure changes are formatting-only
- if the formatter touched many files, separate the change or confirm it was explicitly requested
Verify (follow AGENTS.md for sequencing + required commands):
- for formatting-only changes: run the smallest meaningful verification the repo requires (build/tests/analyze as applicable)
- for formatting as part of a behaviour change: follow the repo’s normal order (don’t reorder the pipeline)
If format/linters are missing or flaky:
- fix AGENTS.md to point to a real, repeatable command
- only then rerun formatting
Report what was run and what changed.

Guardrails

Do not introduce unrelated refactors under the cover of formatting.
Keep formatting changes and behaviour changes reviewable.

More from this repository

same repository

mcaf-adr-writing

Zendevve/opentweak

Create or update an ADR (Architecture Decision Record) under `docs/ADR/` using `docs/templates/ADR-Template.md`: context, decision, alternatives, consequences, rollout, and verification. Use when changing architecture, boundaries, dependencies, data model, or cross-cutting patterns; ensure it is self-contained, has a Mermaid diagram, and defines testable invariants.

2026-02-0120

mcaf-architecture-overview

Zendevve/opentweak

Create or update `docs/Architecture/Overview.md` (architecture diagrams): maintain Mermaid diagrams for system/modules, interfaces/contracts, and key classes/types; document dependency rules; link to ADRs/features. Use when onboarding, refactoring, or adding modules/boundaries.

2026-02-0120

mcaf-feature-spec

Zendevve/opentweak

Create or update a feature spec under `docs/Features/` using `docs/templates/Feature-Template.md`: business rules, user flows, system behaviour, Mermaid diagram(s), verification plan, and Definition of Done. Use before implementing a non-trivial feature or when behaviour changes; keep the spec executable (test flows + traceability to tests).

2026-02-0120

mcaf-skill-curation

Zendevve/opentweak

Create, update, and validate repository skills under your agent’s skills directory (Codex: `.codex/skills/`, Claude: `.claude/skills/`) so they match the real codebase and `AGENTS.md` rules; tune YAML `description` triggers, apply feedback, and generate `<available_skills>` metadata blocks.

2026-02-0120

mcaf-testing

Zendevve/opentweak

Add or update automated tests for a change (bugfix, feature, refactor) using the repository’s testing rules in `AGENTS.md`. Use TDD where applicable; derive scenarios from docs/Features/* and ADR invariants; prefer stable integration/API/UI tests, run build before tests, and verify meaningful assertions for happy/negative/edge cases.

2026-02-0120

name	mcaf-formatting
description	Format code and keep style consistent using the repository’s canonical formatting/lint commands from `AGENTS.md`. Use after implementing changes or when formatting drift causes noisy diffs; keep formatting changes intentional and verified with build/tests.
compatibility	Requires the repository’s formatter/linter tools; uses commands from AGENTS.md.

MCAF: Formatting

Outputs

Formatted code changes (consistent with repo style)
Evidence: formatting command(s) run and any follow-up build/tests

Workflow

Use the canonical format command from AGENTS.md (do not invent commands).
Run the formatter on the smallest scope possible (if your tools allow it).
Review the diff:
- ensure changes are formatting-only
- if the formatter touched many files, separate the change or confirm it was explicitly requested
Verify (follow AGENTS.md for sequencing + required commands):
- for formatting-only changes: run the smallest meaningful verification the repo requires (build/tests/analyze as applicable)
- for formatting as part of a behaviour change: follow the repo’s normal order (don’t reorder the pipeline)
If format/linters are missing or flaky:
- fix AGENTS.md to point to a real, repeatable command
- only then rerun formatting
Report what was run and what changed.

Guardrails

Do not introduce unrelated refactors under the cover of formatting.
Keep formatting changes and behaviour changes reviewable.