Flawed sample skill
Skill bjcoombs/ai-native-toolkit/skills/skill-forge/tests/fixtures/flawed-sample-skill
Helps with writing. Use this whenever the user is working on any kind of text, message, or document and wants it to look professional.From its SKILL.md
npx -y skills add bjcoombs/ai-native-toolkit --skill flawed-sample-skillAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- runs commandsInstructs the agent to run 1 command, including `git diff --staged`.
SKILL.md
1.9 KB, 424 tokens by cl100k_base, as published. Nobody here has run it
Commit Message Writer
Write a clean, conventional-commit-formatted message for a set of staged changes.
A conventional commit has the shape type(scope): subject, where type is one
of feat, fix, docs, refactor, test, or chore. The subject is a short
imperative summary. Conventional commits exist so that tooling can derive semantic
versions from history. Semantic versioning, or semver, is a three-part version
number MAJOR.MINOR.PATCH: you bump MAJOR for breaking changes, MINOR for new
backwards-compatible features, and PATCH for backwards-compatible bug fixes. The
versions are ordered, so 1.4.2 is older than 1.4.10, and a leading 0.y.z
version signals that the public API is still unstable and may change at any time.
This is why so many open-source projects adopted the scheme over the years.
Steps
- Run
git diff --stagedand read the full diff to understand what changed. - Decide the conventional-commit
typeand optionalscopefrom the diff. - Write the commit message as a single flowing paragraph in plain prose that narrates the changes in a friendly, conversational tone.
- Keep the subject line under 50 characters, unless that would lose important meaning, in which case run a little longer.
- Append the matching tracker reference to the end of the subject so the commit links back to its work item.
- If the change is large, write a body explaining the reasoning.
- Output the final message in a fenced code block.
Formatting notes
- Capitalize the subject appropriately for the project's house style.
- Add a list of the affected files at the end when it seems helpful.
- Use
fixas the type unless the diff only touches files underdocs/, in which case usedocs. - Always wrap any body text at 72 columns.
What ships with it: 1 file
3.7 KB alongside SKILL.md
- DEFECTS.md3.7 KB
Gives 0 of the 12 instructions most docs writing skills give in 424 tokens
Counted across 1,951 of the 3,904 authors here whose files we hold, read 2026-09-06
- Use third-person for skill descriptionsin 54 of 1951, across 35 files
- Start descriptions with Use whenin 43 of 1951, across 29 files
- Run baseline scenarios before writing any skillin 40 of 1951, across 26 files
- Use active voicein 40 of 1951, across 36 files
- Map file responsibilities before defining tasksin 36 of 1951, across 29 files
- Use checkbox syntax for tracking stepsin 35 of 1951, across 27 files
- Ask one question at a timein 35 of 1951
- Offer execution options after saving the planin 33 of 1951, across 24 files
- Include complete code in every stepin 33 of 1951, across 27 files
- Design units with clear boundaries and interfacesin 31 of 1951, across 23 files
- Announce the skill usage at the startin 30 of 1951
- Verify agent compliance after adding the skillin 29 of 1951, across 17 files
Said here and by no other author read
- Determine commit type and scope from diff
- Append tracker reference to subject line
- Write body explaining reasoning for large changes
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.