agentleFS
Sign inStart free
Yesterday-AIYesterday-AI/ytstack/skills/software-craftsmanship/SKILL.md

software-craftsmanship

Skill2 starsChanged 29 days agoMITView on GitHub

Reference for clean code, robust architecture and test discipline: structure, naming, boundaries, review criteria, no test slop. Use when writing or reviewing non-trivial code, when the user asks for a code review or a refactoring plan, or when a codebase shows accumulating debt. Not a procedure; its rules apply in context.

  • Commits and pushes

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 9 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Rule: Only write tests for Core Logic (State Management, Data Transformation, Protocols).

    line 33
  2. Distinctive:

    Why: Avoid bloated codebases, fragile tests, and maintenance nightmares.

    line 34
  3. Distinctive:

    Action: If you see a test that doesn't verify a critical path -> Delete/Refactor it.

    line 35
  4. Distinctive:

    Definition: Every interaction must yield a tangible artifact or decision.

    line 38
  5. Distinctive:

    Rule: Do not loop in discussion.

    line 39
  6. Very specific:

    Action: If stuck -> Execute forward-momentum skill logic.

    line 41
  7. Very specific:

    Rule: Write your own scripts (e.g., generate_proto.sh) for reproducibility.

    line 45
  8. Distinctive:

    Action: If a task is complex -> Script it.

    line 47
  9. Very specific:

    Rule 1 (Branches): Never push directly to main.

    line 51
  10. Distinctive:

    Rule: Use meaningful names, short functions, and clear separation of concerns.

    line 80
  11. Distinctive:

    When starting a new feature: Read these rules first.

    line 86
  12. Distinctive:

    During implementation: Check your work against these principles.

    line 87

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Software Craftsmanship Skill 🛠️✨

Clean Code. Robust Architecture. No Test Slop.

A foundational skill for high-quality software engineering. Use this skill when writing code, structuring projects, or conducting code reviews.

Usage

# Read the core principles
read skills/software-craftsmanship/SKILL.md

Rules of Engagement 🛡️

1. NO_TEST_SLOP 🚫🧪

  • Definition: Tests that verify only UI structure (snapshots), boilerplate, or mocked behavior without testing business logic.
  • Rule: Only write tests for Core Logic (State Management, Data Transformation, Protocols).
  • Why: Avoid bloated codebases, fragile tests, and maintenance nightmares.
  • Action: If you see a test that doesn't verify a critical path -> Delete/Refactor it.

2. FORWARD_MOMENTUM 🚀

  • Definition: Every interaction must yield a tangible artifact or decision.
  • Rule: Do not loop in discussion. Create a file, run a command, or make a decision.
  • Why: Action > Analysis Paralysis.
  • Action: If stuck -> Execute forward-momentum skill logic.

3. OWN_YOUR_TOOLS 🔧

  • Definition: Relying on magic or external services for critical build steps.
  • Rule: Write your own scripts (e.g., generate_proto.sh) for reproducibility.
  • Why: Robustness, independence, and clarity.
  • Action: If a task is complex -> Script it.

4. GIT_ETIQUETTE 🔀🐙

  • Definition: Professional collaboration via Git and GitHub.
  • Rule 1 (Branches): Never push directly to main. Use feat/<name> or fix/<name>.
  • Rule 2 (PR Structure): Explain the Why, What, and Outcome.
    • Context: Why is this necessary?
    • Changes: What implementation details matter?
    • Impact: What is the result?
    • A PR without this context is unacceptable.
  • Rule 3 (Review): Self-review your diff before requesting review. Don't waste the reviewer's time with typos or debug logs.
  • Rule 4 (PR Metadata): Always fill PR metadata fields where applicable.
    • --reviewer: Assign the responsible reviewer (default: lx-0 for Yesterday repos).
    • --assignee: Assign the author (@me) so ownership is clear.
    • --label: Tag with e.g. enhancement, bug, documentation, skill -- helps triage.
    • --milestone: Attach to a milestone if one exists for the target release/sprint.
    • --project: Link to the relevant GitHub Project board if configured.
    • A PR without reviewer assignment is invisible. Don't let work rot in the queue.
  • Why: Context > Code. A diff shows what changed; the PR description explains why. Metadata ensures the right people are notified and the work is properly tracked.
  • Action: git checkout -b feat/<name> → commit → gh pr create --body "..." --reviewer lx-0 --assignee @me --label enhancement.

5. CLEAN_CODE 🧹 -- CCD Wertesystem

Das Clean Code Developer (CCD) Wertesystem strukturiert Qualitätsprinzipien in 5 aufeinander aufbauende Grade (Rot → Orange → Gelb → Grün → Blau). Jeder Grad vertieft Prinzipien und Praktiken:

  • 🔴 Rot: DRY, KISS, IOSP, VCS, täglich reflektieren
  • 🟠 Orange: SRP, SoC, SLA, Integrationstests, Reviews
  • 🟡 Gelb: SOLID (ISP, DIP, LSP, OCP), Unit Tests, Mocks
  • 🟢 Grün: CI, Statische Analyse, IoC Container
  • 🔵 Blau: CD, TDD, iterative Entwicklung, Architektur

Vollständige Übersicht: references/ccd-principles.md

  • Definition: Code is for humans to read, machines to execute.
  • Rule: Use meaningful names, short functions, and clear separation of concerns.
  • Why: Maintainability.
  • Action: Refactor ruthlessly.

Instructions 📝

  1. When starting a new feature: Read these rules first.
  2. During implementation: Check your work against these principles.
  3. During review: Flag violations explicitly (e.g., "Violation: NO_TEST_SLOP detected in test/widget_test.dart").

Authored by ManniTheRaccoon. 🦝

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free