saleh-alhaddad/itqan-engineering
Установка
npx skills add saleh-alhaddad/itqan-engineeringСтавит скилл в текущий проект - CLI спросит, для каких агентов. С флагом -g - в домашнюю папку, для всех проектов.
Установи скилл «saleh-alhaddad/itqan-engineering» из репозитория https://github.com/saleh-alhaddad/itqan-engineering: найди в нём папку с SKILL.md и скопируй её целиком в .claude/skills/saleh-alhaddad-itqan-engineering (для Codex - в .agents/skills/saleh-alhaddad-itqan-engineering). Потом прочитай SKILL.md и коротко скажи, в каких задачах будешь его применять.
Вставьте в Claude Code или Codex, открытый в папке проекта.
В Библиотеке ВайбКода этот скилл открывает исходник: автоматической установки для его формата пока нет. Поставьте командой или промптом.
Скачать ВайбКод · Windows и macOS
Описание
The full software-engineering lifecycle as one suite — DISCOVER, DEFINE, PLAN, BUILD, VERIFY, REVIEW, SHIP — with approval gates before code, test-first builds, evidence before "done", and resumable multi-session work. Routes to 12 sub-skills covering any stack, plus feature discovery, security audit, UI/UX craft, and learning roadmaps.
SKILL.md
Исходник на GitHubitqan — engineering skills suite router
This repository is a suite of 12 skills sharing one backbone. When installed as a single
skill (e.g. via npx skills add), this file is your map; everything referenced below ships
inside this folder.
This suite is invoked explicitly — it never fires on its own. The user names it; nothing
here triggers from a matched description or keyword. engineer is the entry point for
lifecycle work and routes to the phases itself, but every sub-skill is also a valid door in
and bootstraps its own workspace (§1). If you are reading this file, you have been invoked:
route and proceed.
How to work
-
Read CONVENTIONS.md first — the shared rules every sub-skill depends on (§1 workspace · §2 phase ledger · §4 memory & judgment · §5 resume sweep · §6 role dial · §7 gates · §8 multi-agent · §12 commit policy · §14 grounding · §15–17 session/big-change/freshness · §18 closing output · §19 data-driven decisions · §20 filesystem access & integrity). If you cannot read it, stop. A denied read, a sandbox refusal, or a corporate policy on dot-directories (this suite often installs under
~/.agents/skills/or.cursor/) leaves you with this map and nothing else. Say which path was refused and what it blocks, then offer the two ways out: copy the suite to a readable path, or have the user pasteCONVENTIONS.mdand the sub-skill you need. Never improvise a phase from the table below and call it following the skill. A directory listing that returns zero files is a block until proven otherwise: try reading a file you know exists before concluding the folder is empty. -
Route the task to the right sub-skill and follow its
SKILL.mdexactly:
| The user wants… | Follow |
|---|---|
| Something built/implemented/shipped end-to-end, or to "continue" prior work | skills/engineer/SKILL.md — the orchestrator |
| Feature ideas / "what should we build next" | skills/discover/SKILL.md |
| A spec/PRD, or schema / data-model / API-contract design | skills/define/SKILL.md |
| An approved spec broken into an ordered task plan | skills/blueprint/SKILL.md |
| Code written for an already-defined task (test-first), incl. scoped fixes/optimizations | skills/construct/SKILL.md |
| Proof it works / a bug root-caused | skills/verify/SKILL.md |
| A senior-depth read-only code review | skills/inspect/SKILL.md |
| A security audit / threat model / hardening pass | skills/harden/SKILL.md |
| A safe release with rollback + GO/NO-GO | skills/release/SKILL.md |
| UI/UX design or a UI audit (web/mobile) | skills/design/SKILL.md |
| A learning roadmap, or onboarding onto this codebase | skills/learn/SKILL.md |
| A whole-app health analysis / feature audit by an expert panel | skills/assess/SKILL.md |
| To see or steer what the suite has learned about how they decide | skills/engineer/SKILL.md, its Judgment requests |
- Discipline packs (auto-selected by detected stack) live in references/disciplines/ — stack packs (backend, frontend, mobile, ai-ml, any-language), the shared ui-craft.md, and concern packs (database, security, devops).
Non-negotiables (from CONVENTIONS)
- Two user-approval gates before code (spec, plan) and GO/NO-GO before ship — recorded in the ledger; a resumed run re-proves them (§2, §5, §7).
- Evidence before claims: run it fresh and read the output before saying "done" (§5.1).
- Only the code says what exists: "done" cites the file and line, "not done" shows the searches that found nothing, and the decisions you locked bind the build (§5.2).
- It writes code the way your code already does it, names the files it followed, and asks when the code has two ways (§4.2); a better way is proposed with options, never slipped in (§4.3).
- Nothing is lost: every run journals its START, RESUME, each DECISION, and a STOP before
every reply into the task's
log.md, and writes only the files the workspace tree names (§1, §2.1). - It learns how you decide only from choices you made, applies that only as far as you allow, and never decides a gate, a commit, a push, a security waiver, or anything irreversible (§4.1).
- Never commit or push without the user's approval; commit messages never mention the AI (§12).
- Don't guess — verify (cited), ask, or label a suggestion (§14); check the web with today's date for time-sensitive facts (§17).