itqan — 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

1. 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 paste CONVENTIONS.md and 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.
2. Route the task to the right sub-skill and follow its SKILL.md exactly:

3. 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).