auto-format-doc
Auto Format
Coding agents should not format files by hand. Instead, after creating or modifying a file, run the appropriate external formatter. This keeps formatting consistent across the project and avoids drift between human-written and agent-written files.
Currently supported: Markdown (.md) via Prettier.
When to run
After every Write or Edit operation that produces or modifies a .md file,
run the format command on that file. This includes:
- Creating a new Markdown file
- Editing an existing Markdown file
- Renaming or moving a Markdown file (format the new path)
Do not attempt to format Markdown content yourself (e.g., adjusting line length, reflowing paragraphs, fixing list indentation). The formatter handles all of that. Focus on content; let the tool handle style.
Platform detection
The command runner depends on the operating system. Detect the platform once at the start of your session and reuse the result:
if [[ "$(uname)" == "Linux" ]]; then
JUST_CMD="ajust"
else
JUST_CMD="sjust"
fi
Formatting commands
Markdown (.md)
Try the Just recipe first. If it fails for any reason (command not found,
recipe missing, permission error), fall back to the npx equivalent:
Preferred (Just recipe):
$JUST_CMD format-md <path> [<path> ...]
Fallback (direct npx):
npx --yes prettier@3 --write <path> [<path> ...]
The fallback runs the exact same command the Just recipe uses under the hood,
so the result is identical. The key thing is that the agent always tries the
Just recipe first -- it may carry project-specific Prettier configuration or
version pins -- and only resorts to npx when that fails.
- Pass the specific file path(s) you just wrote or edited.
- You can pass multiple paths in a single call if you modified several files.
- Do not run the command without a path argument -- that would format every Markdown file in the project, which is slow and noisy.
Example -- single file:
$JUST_CMD format-md docs/setup.md
Example -- multiple files in one task:
$JUST_CMD format-md README.md docs/setup.md CHANGELOG.md
Checking without writing
To verify whether files are correctly formatted without modifying them, use the check variant. Same try-then-fallback pattern:
Preferred:
$JUST_CMD format-md-check <path> [<path> ...]
Fallback:
npx --yes prettier@3 --check <path> [<path> ...]
This exits with a non-zero status if any file is not formatted. It is useful when the user asks you to verify formatting, in CI pipelines, or before committing to confirm everything is clean. It never writes to disk.
Error handling
If both the Just recipe and the npx fallback fail (e.g., Node.js is not
installed at all), warn the user and continue. Formatting is cosmetic -- a
failure should not block the task.
Example warning:
Markdown formatting failed (neither
$JUST_CMD format-mdnornpx prettiersucceeded). The file content is correct but may not match the project's formatting conventions. You can run the formatter manually later.
Rules summary
- After writing or editing any
.mdfile, format it: try$JUST_CMD format-md <path>first, fall back tonpx --yes prettier@3 --write <path>if it fails. - Always pass explicit file paths -- never run without arguments.
- Never format Markdown by hand -- delegate to the command.
- Always try the Just recipe first; only fall back to
npxwhen it fails. - If both methods fail, warn the user and move on.
More from sparkfabrik/sf-awesome-copilot
drupal-cache-debugging
Drupal cache debugging techniques and troubleshooting workflows. Use when asked about X-Drupal-Cache headers interpretation, finding max-age 0 sources, WebProfiler usage, cache hit/miss analysis, stale content debugging, or performance profiling cache-related issues.
21drupal-cache-contexts
Drupal cache contexts implementation guide. Use when asked about request-based cache variations, user.roles vs user context, URL contexts, language contexts, custom cache contexts, or cache context hierarchy. Helps prevent cache explosion from overly broad contexts.
21drupal-cache-tags
Drupal cache tags implementation guide. Use when asked about cache tag naming conventions, entity tags, list tags, custom tags, tag invalidation strategies, or debugging tag-based cache invalidation issues. Covers node:ID, config:name, entity_list patterns.
18drupal-lazy-builders
Drupal lazy builders and placeholder implementation. Use when asked about #lazy_builder render array property, TrustedCallbackInterface, auto-placeholdering, BigPipe integration, personalized content caching, or how to make user-specific content cacheable.
18drupal-cache-maxage
Drupal cache max-age configuration and behavior. Use when asked about time-based cache expiration, Cache::PERMANENT, max-age 0 issues, why Page Cache ignores max-age, or when content appears stale despite time expiration. Critical for understanding caching layer differences.
17drupal-dynamic-cache
Dynamic Page Cache and BigPipe module behavior in Drupal. Use when asked about authenticated user caching, auto-placeholdering, lazy builders, BigPipe streaming, X-Drupal-Dynamic-Cache header, or why content shows UNCACHEABLE status. Covers interaction between caching layers.
16