Engineering discipline
my agents skills
npx -y skills add imnotdev25/skills --skill engineering-disciplineAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Enforces a strict engineering-discipline workflow for any coding project — docs-first, modular code (100-LOC file ceiling), strict types, fail-loud errors, semantic logging, behavior-tests, dependency tracking, dated changelogs, and infra separation. Use this skill whenever the user types `/init-project` (bootstrap a new project) or `/existing-project` (onboard / audit a current repo), and also whenever the user asks to start a new codebase, scaffold a repo, set engineering standards, audit project structure, build a dependency map, write a FILE_TREE.md or DEPENDENCY.md, or work on a project under these rules. Trigger even when the slash commands aren't used verbatim — phrases like "start a new project", "set up a repo properly", "make this codebase clean", or "I want to add a feature to my project" should pull this skill in. The skill always interviews the user before producing code or docs; never assume tech stack, never skip the docs-before-code step.
SKILL.md
4.7 KB, as published. Nobody here has run it
Engineering Discipline
A workflow skill that enforces docs-first, modular, type-strict engineering on every project the user touches.
The skill exposes two entry commands:
/init-project— bootstrap a brand-new project with the full discipline scaffold (docs, infra, changelog, file-tree, dependency graph)./existing-project— onboard a current repo: read the file tree, build a dependency map, then start applying the discipline going forward.
If the user invokes either command, route immediately to the matching workflow file. If the user describes a project task without using a slash command but the intent matches (e.g. "let's start a Python service", "I want to add auth to my app, follow my rules"), confirm with one line which mode they want and proceed.
Hard rules (apply in every turn after the skill triggers)
These are non-negotiable. Read references/principles.md for the full reasoning behind each one.
- Check docs before implementing. Read
Docs/first. IfDocs/doesn't exist yet, that's the first thing to create. - Update docs before adding features. Doc edit lands in the same change as the code, never after.
- Append to
changelog/<YYYY-MM-DD>.mdfor every change. Format inreferences/doc-conventions.md. - Never assume — ask. Tech stack, scope, naming, deployment target. Ask via
ask_user_input_v0when options are available. - No file exceeds 100 LOC. Split before you hit the ceiling. Function-per-concern, file-per-cohesive-unit.
- Every function has typed input/output and a docstring. Strict casts. Document edge cases.
- Fail loud. No silent excepts, no swallowed errors, no
if err != nil { /* ignore */ }. - Make impossible states impossible. Use sum types / enums / discriminated unions instead of flag soup.
- Immutable by default. Mutation only where measurably necessary.
- Logging is semantic and designed first. Decide log events + fields before writing the logic that emits them.
- Tests cover behavior, not implementation. Refactor must not break passing tests.
- Feature flags > branching logic for anything that might toggle.
- Commits are meaningful, prefixed:
feat:,fix:,refactor:,docs:,test:,chore:,perf:,ci:,revert:. Commit message documents why, not what. - Infra lives in
infra/with its ownREADME.mdandDocs/mapped 1:1 to that README. Docs/FILE_TREE.mdandDocs/DEPENDENCY.mdexist and are kept current. Seeassets/for templates.- Open for extension, closed for modification. New behavior via new modules or strategies, not by editing stable interfaces.
- Aim for linear time and space. Reach for the right data structure before reaching for a loop.
- Optimize for change, not for today's requirements.
Routing
| User input | Read next |
|---|---|
/init-project or "start a new project" | references/init-project-workflow.md |
/existing-project or "onboard this repo" | references/existing-project-workflow.md |
| Mid-project work (adding feature, fixing bug) | references/principles.md — apply rules above; also enforce changelog + doc updates in the same turn |
| User asks about the discipline itself | references/principles.md |
Need to generate FILE_TREE.md, DEPENDENCY.md, or a changelog entry | references/doc-conventions.md + matching template in assets/ |
Style of interaction
The user prefers terse, directive communication and expects autonomous execution once intent is clear. Ask questions when something is genuinely ambiguous — and prefer ask_user_input_v0 with concrete options over prose questions. Don't ask back-to-back rounds when one tightly-scoped batch will do. When you do execute, generate code, not summaries.