← Browse

@forceinjection/small-skill

A

Small skill with basic content for token testing

skillclaude

Install

agr install @forceinjection/small-skill --target claude

Writes 2 files into .claude/skills/, pinned to git-50cfda0b.

  • .claude/skills/small-skill/SKILL.md
  • .claude/skills/small-skill/metadata.json

Document


name: small-skill description: Small skill with basic content for token testing license: MIT

Small Skill: Code Formatting Guidelines

This skill describes a compact but realistic set of code formatting guidelines. It is used in tests that measure token counts for skill metadata versus full content. The text is intentionally longer than the template skill so that the savings from progressive disclosure are obvious when only the lightweight metadata is injected into the system prompt.

Goals of Consistent Formatting

  • Make code bases readable by any team member.
  • Reduce cognitive load when switching between files.
  • Minimize unnecessary diffs during code review.
  • Allow automated tools such as black and ruff to do most of the work.

When formatting is predictable, reviewers can focus on the substance of a change instead of spending time commenting on indentation, line length, or import ordering. A good rule of thumb is that humans should spend their attention on naming, structure, and correctness, while automated tools enforce the small mechanical rules.

Editor Integration

Most developers experience formatting rules through their editor or IDE. To keep friction low:

  1. Enable "format on save" for the primary language server.
  2. Configure the same line length in both the formatter and linter.
  3. Make sure the editor uses UTF‑8 and Unix line endings by default.
  4. Share editor configuration files (such as .editorconfig) in the repository.

The important part is that everyone on the team runs the same tools with the same configuration. If a project uses black, developers should not disable it locally or override its defaults in surprising ways.

Handling Legacy Code

In real projects there is almost always some legacy code that does not match the current formatting rules. A practical approach is:

  • Avoid reformatting the entire repository in a single massive commit.
  • Instead, reformat files as they are touched for real changes.
  • For large refactors, coordinate with the team so that merges remain manageable.

This incremental strategy allows teams to converge toward a consistent style without breaking every open feature branch. The tests in this repository treat this document as a "small" skill that still contains enough natural language to produce a meaningful token count.

Trustgrade A

  • passBody integrity

    Whether the stored document is plausibly the kind of file the artifact declares, rather than something fetched by mistake.

  • passType matchnot applicable to this artifact type

    Whether the artifact is really the kind of thing its metadata claims it is.

  • passFreshness

    How long since the source repository was last pushed to.

  • passPrompt injection

    Scans the artifact's own text for instructions aimed at your agent rather than at you.

  • passLicense

    Whether the source repository declares an SPDX license permissive enough to redistribute.

How the grade is calculated

Each check contributes 0 points when it passes, 1 when it warns, and 2 when it fails. The total maps to a letter:

  • Aevery check passed
  • Bone warning
  • Ctwo warnings
  • Dprompt injection or body integrity failed, or three warnings
  • Fone of those failed, and something else is wrong

These are automated hygiene checks, not a security audit, and not a dependency or vulnerability scan. A grade of A means nothing was flagged — not that the artifact is safe.

Versions

  • git-50cfda0b5c262026-07-31