@ericrisco/rsc 0.1.43 → 0.1.45

package/skills/author-skill/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: author-skill
-description: "Use when authoring a NEW skill or editing an existing one for the rsc catalog — writing or fixing a SKILL.md, crafting a trigger-rich third-person description that fires on the right prompts, deciding what goes in references/ vs the body, writing evals/cases.yaml + evals/README.md, or wiring a skill into the catalog (tags, recommends, manifest). Triggers: 'write a skill', 'author a skill', 'create a new skill', 'escribe una skill', 'haz una skill nueva', 'edit this skill', 'improve this skill', 'my skill never triggers', 'my skill always fires', 'fix the description', 'the frontmatter is invalid', 'write evals for this skill', 'add this skill to the catalog', 'audit this skill against the rubric', 'progressive disclosure', 'SKILL.md too long'. Knows the rsc conventions: hybrid layout, tags/recommends frontmatter, manifest.json, the npx @ericrisco/rsc CLI, the Knowledge map. NOT building runtime features (that is the SDD chain) and NOT general docs."
+description: "Use when authoring a NEW rsc skill or editing an existing one — scoping it to one job, writing the description that decides whether it ever loads, splitting the body into references/, writing its evals, auditing it against the rubric. NOT building a product feature (that is `specify`) and NOT designing an agent loop (that is `building-agents`)."
 tags: [skill, authoring, meta]
 recommends: []
 origin: risco
@@ -8,38 +8,13 @@ origin: risco
 
 # author-skill — write skills that trigger and teach
 
-This is the **meta skill**: it authors and edits the other skills in the rsc catalog. A skill is two things bolted together — a **description that fires at the right moment**, and a **body that makes the agent better once it fires**. Most skills fail on the first. This skill exists to get both right, to the bar the rsc catalog already holds.
+This is the **meta skill**: it authors and edits the other skills in the rsc catalog. A skill is two things bolted together — a **description that fires at the right moment**, and a **body that makes the agent better once it fires**. Most skills fail on the first. Treat them as two separate engineering problems with two separate quality bars.
 
-It lives in `rsc-core` next to `init` and `harness`, the same way those govern the workspace. Where the SDD chain (`specify` → `plan` → … → `ship`) builds *product*, `author-skill` builds *the tools that build product*. Use it whenever a skill is born or edited.
+Where the SDD chain (`specify` → `plan` → … → `ship`) builds *product*, `author-skill` builds *the tools that build product*. Use it whenever a skill is born or edited.
 
-## When to use / when NOT to use
+**Not this skill — delegate:** a product feature specced or planned → `../specify/SKILL.md`, `../plan/SKILL.md`. An autonomous agent or tool-calling loop → `../building-agents/SKILL.md`. Generic project docs or a wiki article → the `../harness/SKILL.md` 02-DOCS engine. Bootstrapping a workspace or profiling the user → `../init/SKILL.md`.
 
-Use when:
-
-- Writing a brand-new skill from a one-line intent ("I keep re-explaining how we do X — make it a skill").
-- Editing an existing skill: tightening the description, splitting the body into `references/`, adding a checklist or anti-patterns table.
-- A skill mis-triggers — never fires when it should, or fires on everything.
-- Writing or repairing `evals/cases.yaml` + `evals/README.md`.
-- Wiring a finished skill into the catalog — `tags`, `recommends`, and the manifest (the rsc plumbing).
-- Auditing a skill against the rubric below before it ships.
-
-Do NOT use when (delegate or decline):
-
-- The user wants to *build a product feature* with a written spec/plan — that is the SDD chain (`../specify/SKILL.md` → `../plan/SKILL.md` → …), not a skill.
-- The user wants to design an autonomous agent / tool-calling loop — that is `../building-agents/SKILL.md`.
-- The user wants generic project docs or a wiki article — that is the `../harness/SKILL.md` 02-DOCS engine.
-- Bootstrapping a workspace or profiling the user — that is `../init/SKILL.md`.
-
-## Read the user profile first (accompaniment dial)
-
-Before writing, read `02-DOCS/wiki/harness/user-profile.md` for the technical level and the accompaniment dial, and **adapt**:
-
-- **L0** — draft the whole skill, show it, move on. Minimal narration.
-- **L1** — one line of *why* per major choice (why this trigger, why split that reference).
-- **L2** — justify each structural decision as you make it.
-- **L3** — explain everything, ask before committing to a name/scope, walk the rubric out loud.
-
-When no profile exists, default to non-technical framing and ask the two gauging questions (technical level + dial) before going deep. Skill authoring is itself a technical act — many users will want L2/L3 here even if they run L0 elsewhere.
+Read `02-DOCS/wiki/harness/user-profile.md` and work at the accompaniment dial it records; `../init/SKILL.md` owns that dial and sets it. With no profile, default to non-technical framing and ask for the technical level and the dial before going deep — skill authoring is itself a technical act, so many users want more narration here than they do elsewhere.
 
 ## What a skill is (the anatomy)
 
@@ -55,33 +30,33 @@ skills/<id>/
     └── verify.sh
 ```
 
-The **frontmatter** decides *if* the skill loads. The **body** decides *how good* the agent is once it does. Treat them as two separate engineering problems with two separate quality bars.
+The **frontmatter** decides *if* the skill loads. The **body** decides *how good* the agent is once it does.
 
 ## The description — the single highest-leverage line
 
-The description is the only part of a skill the agent reads at *every* turn to decide whether to pull the skill in. A vague description is a skill that never fires; an over-broad one is a skill that hijacks unrelated turns. Get this right before anything else.
+The description sits in context on **every turn the skill is installed**, invoked or not. The body is only paid for when the skill fires; the description is paid for always. So length here is a cost, never a credit. A vague description is a skill that never fires; an over-broad one hijacks unrelated turns. Get this right before anything else.
 
 Rules, all enforced:
 
 1. **Third person, present tense.** "Use when authoring a new skill…" — never "I help you…" or "You should…". The agent is reading *about* the skill.
-2. **Trigger-rich.** Lead with a `Use when …` clause naming the *situations* and *symptoms*, then a `Triggers:` list of concrete phrasings — including non-obvious ones and at least one other language the user actually writes in (rsc users mix Spanish/Catalan). The router matches on these.
-3. **Draw the boundary.** End with what it is **NOT** and which sibling owns that instead. Negative space prevents hijacking as much as positive triggers cause firing.
-4. **≤ 1024 characters, valid single-line quoted YAML.** One physical line, wrapped in double quotes, internal quotes escaped or avoided. If it does not parse, the skill does not load.
+2. **Discriminative, not exhaustive.** Lead with a `Use when …` clause naming the *situation*, then only the capabilities that separate this skill from its neighbours. Do **not** append a `Triggers: '…', '…'` phrase list: the model matches on meaning, so a keyword bank in three languages buys nothing and is charged on every turn. The test is *discrimination, not coverage* — could a reader pick this skill over its nearest sibling from this line alone?
+3. **Draw the boundary.** End with a `NOT <x> (that is <sibling>)` clause, naming a sibling that actually exists under `skills/`. Negative space prevents hijacking as much as positive matching causes firing.
+4. **Aim ≤ 350 characters; 1024 is the schema-enforced hard limit.** One physical line, wrapped in double quotes, internal quotes escaped or avoided. If it does not parse, the skill does not load.
 5. **`origin: risco`** on its own line. This marks it as ours.
 
 ```yaml
-# Good — situation + symptoms + phrasings + boundary
-description: "Use when X happens or the user shows symptom Y — doing A, fixing B, choosing C. Triggers: 'phrase one', 'frase en español', 'a non-obvious one'. NOT Z (that is `sibling`)."
+# Good — situation, the few capabilities that discriminate, a real boundary
+description: "Use when X happens or the user shows symptom Y — doing A, fixing B, choosing C. NOT Z (that is `sibling`)."
 
-# Bad — first person, no triggers, no boundary, would never route well
+# Bad — first person, no situation, no boundary; competes with every sibling on every turn
 description: "I help you write great skills and make them work."
 ```
 
-The full description recipe, the character-budget tactics, and a worked before/after → `references/description-recipe.md`.
+The full recipe, the budget tactics, and a worked before/after → `references/description-recipe.md`.
 
 ## Progressive disclosure — the body is an index, not an encyclopedia
 
-The body is loaded in full whenever the skill fires, so every line competes for the agent's attention. Keep the body **~120–400 lines**: the method, the rules, the decision points, and *pointers* to depth. Push anything long, reference-like, or rarely-needed into `references/<topic>.md` and link to it inline ("full table → `references/foo.md`").
+The body is loaded in full whenever the skill fires, so every line competes for the agent's attention. Write **the smallest body that still routes correctly**: 400 lines is a ceiling, not a target, and there is no floor — a skill that does its job in 60 lines beats the same skill padded to 200. Push anything long, reference-like, or rarely-needed into `references/<topic>.md` and link it inline at the point of use ("full table → `references/foo.md`").
 
 Decide where a paragraph lives:
 
@@ -92,12 +67,12 @@ Decide where a paragraph lives:
 | It is short and load-bearing | It is reference detail that would bloat the body |
 | Cutting it would change behavior | It is an example that illustrates but does not instruct |
 
-If the body creeps past ~400 lines, that is the signal to extract a reference — not to keep scrolling. A skill the agent half-reads is worse than a short one it reads fully.
+Every file under `references/` must be linked from the body. An unlinked reference is never loaded, so it is dead weight in the package — link it or delete it.
 
 ## The hybrid structure — when each piece earns its place
 
 - **SKILL.md** — always. Frontmatter + focused body.
-- **references/** — only when the body genuinely needs offloaded depth. Do not create an empty `references/` to look complete; a 150-line single-file skill is fine.
+- **references/** — only when the body genuinely needs offloaded depth. Do not create an empty `references/` to look complete; a single-file skill is fine.
 - **evals/** — always. `cases.yaml` + `README.md`. A skill with no evals is unverifiable and does not ship.
 - **scripts/verify.sh** — only when the skill produces a *checkable artifact* (code, config, copy with a ban-list). **Process skills** — those judged on the safety rails they install in the agent's behavior, like the SDD-phase skills or this one — do **not** ship a `verify.sh`; their evals carry a capability scenario instead.
 
@@ -119,10 +94,10 @@ The full protocol lives once in the `orient` skill; the footer only references i
 Run in order. Each step gates the next.
 
 1. **Name & scope.** One skill, one job. Pick a short kebab-case `<id>` that is the job, not the domain. If you can not say the job in one sentence, the scope is wrong — split it. Check no sibling already owns this; if one half-owns it, decide *edit the sibling* vs *new skill* before writing.
-2. **Draft the description.** Per the recipe above. This first, because writing it forces the scope clear. → `references/description-recipe.md`.
+2. **Draft the description.** Per the rules above. This first, because writing it forces the scope clear. → `references/description-recipe.md`.
 3. **Outline the body.** Method, rules, decision points. Mark what becomes a reference.
-4. **Write the body** in the rsc voice (see below). Tag every code/example fence with a language. Add a copy-able checklist or decision table *only where the flow actually branches* — not as decoration. Add a short anti-patterns table.
-5. **Extract references** for anything long or branch-specific.
+4. **Write the body** in the rsc voice (see below). Tag every code/example fence with a language. Add a checklist or decision table *only where the flow actually branches* — not as decoration. Add a short anti-patterns table.
+5. **Extract references** for anything long or branch-specific, and link each one inline.
 6. **Write the evals** — `cases.yaml` then `README.md`. → `references/eval-authoring.md`.
 7. **Wire it into the rsc plumbing** (`tags`, `recommends`, `npm run manifest`, and indexing any artifact in `02-DOCS/wiki/index.md` — the Knowledge map; root `CLAUDE.md` keeps only a short pointer). → `references/rsc-conventions.md`.
 8. **Self-audit against the rubric** (below). Fix every miss or justify it.
@@ -132,7 +107,7 @@ Run in order. Each step gates the next.
 Match the catalog, do not invent a new register:
 
 - Direct, second-person-to-the-agent instruction ("Read the profile first", "Cut any section with no job").
-- Rules stated as non-negotiables with a one-line *why*, not a lecture.
+- A rule gets stated where it applies, with a one-line *why* that makes it obviously absolute — not a lecture, and not a shouted NON-NEGOTIABLE.
 - Concrete over abstract: a number, a path, a Bad→Good pair beats an adjective.
 - Original prose. Mine ideas from anywhere; the words are Eric's. Do **not** reproduce another ecosystem's signature artifacts or phrasing — no borrowed "1% chance" urgency blocks, no copied rationalization wording, no `*-reviewer-prompt.md` files, no verbatim flowcharts. The rsc identity is its own.
 - Cross-reference siblings by name or `../<sibling>/SKILL.md`, only ones that actually exist.
@@ -147,27 +122,27 @@ attends to the named token), and can do *worse* than saying nothing at all. Matc
 
 | The failure is… | Use this form | Why, and example |
 | --- | --- | --- |
-| **Discipline** — the agent knows the rule but skips it under pressure (time, sunk cost, "just this once") | **Prohibition + rationalization table** (`Anti-patterns → STOP`) | The agent already knows what's right; it needs the excuse pre-refuted at the moment of temptation. This is exactly what the `STOP` tables are for. "I'll skip the failing test to ship" → name the rationalization, kill it. |
+| **Discipline** — the agent knows the rule but skips it under pressure (time, sunk cost, "just this once") | **The rule stated at the step it governs, with its why** — plus one row in the anti-patterns table | A rule in an appendix is skimmed; a rule in context is followed. "Do not ship a failing test — a red test merged is a lie in the suite", written at the ship step. Do not build a separate rationalization bank restating rules already in the flow; it is paid for on every load and read as decoration. |
 | **Wrong-shaped output** — tone, verbosity, format, structure come out wrong | **Positive recipe / contract** (show the target shape) | A prohibition ("don't be verbose", "no marketing fluff") makes it *more* likely — the model fixates on the banned shape. Give the shape to hit instead: "Reply in ≤3 sentences, lead with the verdict." Demonstrate, don't forbid. |
 | **Omitted element** — the agent forgets a required piece | **Required structural slot** (a checklist item or a template field it must fill) | You can't prohibit an absence. Make the slot mandatory so its emptiness is visible — a `Done-of-done` checkbox, a template section, a result-envelope field. |
 | **Conditional behavior** — right action depends on the situation | **Predicate-keyed conditional** ("When X → do Y; otherwise Z") | A flat rule fires in the wrong context. Key the behavior to its trigger so the agent branches correctly instead of over- or under-applying. |
 
-So: keep the `Anti-patterns → STOP` tables — they're the correct tool for *discipline* failures,
-which is most of what the SDD-discipline skills guard. But when you catch yourself writing "don't
-make it X" about the *shape* of an output, stop and rewrite it as the shape to hit. Prohibition is
-a scalpel for one failure type, not the default for all of them.
+So: an anti-patterns table earns its place when it names concrete **failure modes** the flow above
+does not already state. A table that re-lists rules from the body is pure cost — delete it and move
+each rule to its step. And when you catch yourself writing "don't make it X" about the *shape* of an
+output, rewrite it as the shape to hit.
 
 ## The best-practice rubric (audit before shipping)
 
 A skill ships only when every box is checked or a miss is consciously justified.
 
 - [ ] **Frontmatter parses** as YAML; `name` matches the directory `<id>`; `origin: risco` present.
-- [ ] **Description ≤ 1024 chars**, third-person, `Use when…` lead, concrete `Triggers:` (incl. a non-obvious and a non-English phrasing), and a `NOT … (that is sibling)` boundary.
+- [ ] **Description** third-person, `Use when…` lead, an explicit `NOT … (that is sibling)` boundary naming a real sibling, ≤ 350 chars target / ≤ 1024 hard limit — judged on discrimination against the nearest sibling, not coverage.
 - [ ] **One job.** The body never drifts into a second skill's territory; it delegates instead.
-- [ ] **Body 120–400 lines**, focused; long/branch-specific material lives in `references/`.
-- [ ] **Progressive disclosure** real — references are pointed to inline, not orphaned.
+- [ ] **Body ≤ 400 lines** — a ceiling, not a target, with no floor. Long/branch-specific material lives in `references/`.
+- [ ] **Every `references/` file linked** inline from the body; none orphaned.
 - [ ] **Every fence language-tagged**; no placeholder/TODO prose; examples concrete.
-- [ ] **Checklist/decision table only where a flow branches**; an **anti-patterns table** present.
+- [ ] **Checklist/decision table only where a flow branches**; an **anti-patterns table** present, naming failure modes rather than restating rules.
 - [ ] **Accompaniment dial honored** — reads the profile, adapts verbosity.
 - [ ] **Artifacts under `02-DOCS/wiki/`** and indexed in `02-DOCS/wiki/index.md` (the Knowledge map; root `CLAUDE.md` keeps only a short pointer), if the skill produces any.
 - [ ] **Concrete tooling delegated** to the stack skills rather than reinvented.
@@ -199,28 +174,20 @@ only when **both** are green:
    A failing `lift` means the body adds nothing a bare agent didn't already do — fix the body,
    don't game the checklist.
 
-## Anti-patterns / rationalizations → STOP
+## Anti-patterns
 
-| Rationalization | Reality / fix |
+| Failure mode | Reality / fix |
 | --- | --- |
-| "I'll polish the description later, the body matters more" | The description is *why the body ever runs*. Write it first, to bar. |
-| "More triggers = fires more = better" | Over-broad descriptions hijack unrelated turns. Add the `NOT` boundary and prune. |
-| "One skill that does specify + plan + implement is convenient" | One skill, one job. A multi-job skill triggers fuzzily and teaches poorly. Split it. |
-| "The body is long because the topic is rich" | Past ~400 lines the agent skims. Extract references; keep the body an index. |
-| "I'll skip evals, I'll just test it by hand once" | Unverifiable = does not ship. Write `cases.yaml`, including near-misses with `route_to`. |
-| "It's basically superpowers' writing-skills, I'll mirror it" | Mine the idea, write it in the rsc voice. Copied artifacts/phrasing are a defect. |
-| "I'll add a `references/` folder so it looks thorough" | Empty references are noise. Add depth only where the body points to it. |
-| "verify.sh on every skill is more rigorous" | A process skill has no artifact to grep. Its rigor is the capability eval. |
-| "Linking `../foo/SKILL.md` is fine even if foo isn't in this repo" | A dead link is a defect. Reference only siblings that exist. |
+| Description written last, once the body is done | The description is *why the body ever runs*, and drafting it first forces the scope clear. Write it first, to bar. |
+| Description padded for coverage — more phrasings, more languages, more verbs | It is in context on every turn, invoked or not. Prune until it discriminates against the nearest sibling and stops. |
+| One skill covering specify + plan + implement | Multi-job skills trigger fuzzily and teach poorly. One skill, one job — split it. |
+| Body grown past ~400 lines "because the topic is rich" | The agent skims what it cannot hold. Extract a reference and link it inline. |
+| A `references/` folder added to look thorough, or a reference nothing links to | An unlinked reference is never loaded — dead weight in the package. Link it at point of use or delete it. |
+| Evals skipped: "I'll just test it by hand once" | Unverifiable = does not ship. Write `cases.yaml`, near-misses with `route_to` included. |
+| `verify.sh` added to a process skill for rigor | A process skill has no artifact to grep. Its rigor is the capability eval. |
+| `../foo/SKILL.md` linked to something not in this repo | A dead link is a defect. Verify the directory exists under `skills/`. |
+| Another catalog mirrored wholesale ("it's basically superpowers' writing-skills") | Mine the idea, write it in the rsc voice. Copied artifacts or phrasing are a defect. |
 
 ## Project grounding (02-DOCS + CLAUDE.md)
 
 When authoring produces a durable design note (a skill's scope decision, a description rationale worth keeping), persist it under `02-DOCS/wiki/sdd/` and index it in `02-DOCS/wiki/index.md` (the Knowledge map; root `CLAUDE.md` keeps only a short pointer), per the `../harness/SKILL.md` convention — never a stray file at the repo root. The skill's own `evals/` is the executable record of intent; the wiki note is the human-readable why.
-
-## See Also
-
-- `../harness/SKILL.md` — the 02-DOCS Knowledge-map convention these artifacts live in; the bar this catalog holds.
-- `../init/SKILL.md` — the front door that profiles the user and sets the dial this skill reads.
-- `../building-agents/SKILL.md` — for autonomous agents/tool-loops, a different craft than authoring a skill.
-- `../specify/SKILL.md` — when the user wants a *product feature* specced, not a skill authored.
-- References: `references/description-recipe.md`, `references/eval-authoring.md`, `references/rsc-conventions.md`.

package/skills/author-skill/evals/README.md

@@ -44,11 +44,11 @@ the skill — or these rubrics — needs work.
 
 What a WITH-skill answer should show that a baseline misses:
 
-- **Description first**, to the recipe: third-person `Use when…` lead, concrete `Triggers:`
-  (incl. a non-obvious and a non-English phrasing), a `NOT … (sibling)` boundary, valid
-  single-line quoted YAML ≤ 1024 chars, `origin: risco`.
-- **Progressive disclosure** — a focused 120–400 line body that points into `references/`, not
-  an encyclopedia and not an orphaned references folder.
+- **Description first**, to the recipe: third-person `Use when…` lead, only the capabilities that
+  discriminate it from its nearest sibling, a `NOT … (sibling)` boundary, valid single-line quoted
+  YAML aiming ≤ 350 chars (1024 hard limit), `origin: risco`.
+- **Progressive disclosure** — the smallest body that still routes (400 lines is a ceiling, not a
+  target) pointing into `references/`, not an encyclopedia and not an orphaned references folder.
 - **evals authored** to the minimums, with `route_to` siblings that actually exist.
 - **No `verify.sh` on a process skill** — rigor comes from the capability eval.
 - **rsc wiring** named: `tags` + `recommends` frontmatter, `npm run manifest` regenerated,

package/skills/author-skill/evals/cases.yaml

@@ -1,8 +1,8 @@
 skill: author-skill
 
 # Cases for the rsc-core "author-skill" meta skill.
-# author-skill authors or edits a SKILL.md to the rsc catalog bar: a trigger-rich
-# third-person description (<=1024, valid YAML, origin: risco), a focused body with
+# author-skill authors or edits a SKILL.md to the rsc catalog bar: a discriminating
+# third-person description (~350 chars, valid YAML, origin: risco), a focused body with
 # progressive disclosure into references/, the best-practice rubric, and an
 # evals/cases.yaml + README for the NEW skill, plus the rsc plumbing (tags,
 # recommends, manifest.json, Knowledge map). It is NOT for building a
@@ -20,7 +20,7 @@ should_trigger:
     why: "Non-obvious symptom phrasing (no mention of 'skill authoring') pointing straight at the description craft — diagnosing/repairing a description that fails to route is exactly this skill's highest-leverage area."
 
   - prompt: "This SKILL.md is 600 lines and feels bloated. Help me restructure it."
-    why: "Edit/refactor of an existing skill toward progressive disclosure — author-skill's body-vs-references decision table and the 120-400 line target are the direct fix."
+    why: "Edit/refactor of an existing skill toward progressive disclosure — author-skill's body-vs-references decision table and the 400-line ceiling are the direct fix."
 
   - prompt: "Write the evals/cases.yaml for the skill I just drafted, with trigger and capability tests."
     why: "Eval authoring for a skill is squarely owned here (the should_trigger/should_not_trigger/route_to and capability rubric minimums) — a deliberately specific, non-obvious trigger."
@@ -57,8 +57,8 @@ capability:
     must_include:
       - "Reads 02-DOCS/wiki/harness/user-profile.md for the accompaniment dial (or asks the two gauging questions if absent) and adapts verbosity"
       - "Confirms scope is one job and checks no existing sibling already owns PR-description authoring before creating a new skill"
-      - "Drafts the description FIRST: third-person, 'Use when…' lead, concrete Triggers including a non-obvious symptom phrasing and a non-English one, a 'NOT … (that is `sibling`)' boundary, valid single-line quoted YAML <=1024 chars, with origin: risco"
-      - "Produces a focused body (~120-400 lines) with progressive disclosure — long/branch-specific detail pushed to references/ and pointed to inline, not an orphaned references/ folder"
+      - "Drafts the description FIRST: third-person, 'Use when…' lead, only the capabilities that discriminate it from its nearest sibling, a 'NOT … (that is `sibling`)' boundary, valid single-line quoted YAML aiming <=350 chars (1024 hard limit), with origin: risco"
+      - "Produces the smallest body that still routes (400 lines is a ceiling, not a target) with progressive disclosure — long/branch-specific detail pushed to references/ and pointed to inline, not an orphaned references/ folder"
       - "Language-tags every code/example fence and includes an anti-patterns table; adds a checklist/decision table only where a flow actually branches"
       - "Writes evals/cases.yaml meeting the minimums (>=5 should_trigger incl. non-obvious, >=4 should_not_trigger each with a real-sibling route_to, >=1 capability with a must_include rubric) plus an honest evals/README.md describing the two-axis run"
       - "Decides NO scripts/verify.sh because a PR-description skill is a process skill judged on its capability eval, OR includes verify.sh only if it emits a checkable artifact — and justifies the choice"
@@ -67,9 +67,9 @@ capability:
 
   - scenario: "A user pastes a skill whose description is 'I help you with deployments' and says 'it fires on everything and also misses real deploy questions — fix the triggering.' Show the description repair."
     must_include:
-      - "Diagnoses the two failure modes: first-person + no boundary causes hijacking; no concrete Triggers/situation causes misses"
+      - "Diagnoses the two failure modes: first-person + no boundary causes hijacking; no situation clause causes misses"
       - "Rewrites to third-person with a 'Use when…' situation lead and concrete verb phrases"
-      - "Adds a Triggers: list of real phrasings including a non-obvious symptom and a non-English one"
+      - "Keeps only the capabilities that discriminate deployment work from its nearest siblings, rather than padding a keyword list for coverage"
       - "Adds a 'NOT … (that is `sibling`)' boundary naming the real sibling(s) that own the excluded turns to stop hijacking"
-      - "Verifies the result is valid single-line quoted YAML and <=1024 chars (e.g. via the python YAML/length check) and keeps origin: risco"
+      - "Verifies the result is valid single-line quoted YAML, aims <=350 chars against the 1024 hard limit, and keeps origin: risco"
       - "Recommends updating evals/cases.yaml (especially should_not_trigger with route_to) and re-running the triggering eval, since description edits are wording-sensitive"

package/skills/author-skill/references/description-recipe.md

@@ -1,67 +1,66 @@
 # The description recipe
 
-The description is the only line the router reads on every turn to decide whether to load the skill. It is a *retrieval problem*, not a marketing problem. Write it to be matched, not admired.
+The description is the only line the router reads on every turn to decide whether to load the skill — and it sits in context on every turn the skill is installed, invoked or not. It is a *retrieval problem*, not a marketing problem. Write it to be matched, not admired, and keep it short: length here is a cost, never a credit.
 
 ## The shape
 
 ```text
 "Use when <SITUATION / SYMPTOM> — <verb phrase>, <verb phrase>, <verb phrase>.
- Triggers: '<phrase>', '<frase en español>', '<non-obvious phrase>', ….
- [Optional one clause naming what it KNOWS / owns.]
- NOT <out-of-scope thing> (that is `sibling`) and NOT <other> (that is `sibling`)."
+ NOT <out-of-scope thing> (that is `sibling`) [and NOT <other> (that is `sibling`)]."
 ```
 
-Four moves, in order:
+Three moves, in order:
 
-1. **Lead with the situation.** The first clause is a `Use when …` that names *when in the user's day* this fires — the moment, the symptom, the pain. The router matches situations better than nouns. "Use when a skill mis-triggers" beats "skill quality tool".
-2. **List concrete verb phrases.** Right after the lead, name the 3–6 things the skill actually does, as verbs ("writing a description", "splitting the body", "repairing cases.yaml"). These are dense match surface.
-3. **Add a `Triggers:` phrase list.** Real phrasings a user types — quoted. Include:
-   - at least one **non-obvious** phrasing (a symptom, not the skill's name): e.g. "my skill never triggers".
-   - at least one **non-English** phrasing (rsc users write Spanish/Catalan): e.g. "escribe una skill".
-   - the slash-command form if relevant.
-4. **Close with the boundary.** One or two `NOT … (that is `sibling`)` clauses. This is not optional decoration — negative space is what stops the skill from hijacking adjacent turns. Name the *real* sibling that owns the excluded job.
+1. **Lead with the situation.** The first clause is a `Use when …` that names *when in the user's day* this fires — the moment, the symptom, the pain. The model matches situations better than nouns. "Use when a skill mis-triggers" beats "skill quality tool".
+2. **Name only the discriminating capabilities.** Right after the lead, name the few things the skill does that its neighbours do not, as verbs ("writing a description", "splitting the body", "repairing cases.yaml"). Stop there. Do **not** append a `Triggers: '…', '…'` phrase list: the model matches on meaning, so a keyword bank — especially one repeated in three languages — buys no routing accuracy and is charged on every turn.
+3. **Close with the boundary.** One or two `NOT … (that is `sibling`)` clauses. This is not optional decoration — negative space is what stops the skill from hijacking adjacent turns. Name the *real* sibling that owns the excluded job, and verify it exists under `skills/`.
+
+## The test: discrimination, not coverage
+
+Do not ask "does this cover every way someone might phrase it?" — ask **"could a reader pick this skill over its nearest sibling from this line alone?"** Coverage is what tempts you to pad; discrimination is what actually routes. If two versions route the same, the shorter one is better.
 
 ## The hard constraints
 
-- **≤ 1024 characters.** Count them. Over budget = trim verb phrases and trigger duplicates first, never the boundary.
+- **Aim ≤ 350 characters; 1024 is the schema-enforced hard limit.** Over budget = trim verb phrases first, never the boundary.
 - **Valid single-line quoted YAML.** The description is one physical line wrapped in double quotes. No raw newlines inside the value. Avoid characters that break YAML in double quotes; if you need an apostrophe inside, it is fine (single quotes are literal inside double-quoted YAML). Never put an unescaped `"` inside.
 - **Third person, present tense.** The agent reads *about* the skill. "Use when…", "Triggers on…", "Knows…". Never "I", never "you should".
-- **State triggers and boundary — never the workflow.** The description says *when* to fire and *what it is not*. It must **not** summarize the procedure the body owns (the steps, the phase count, "does X then Y then Z"). This is not a style nit — it changes behavior. A description that pre-summarizes the steps becomes a *substitute* for reading the body: the agent acts on the summary and skips the real instructions. (Observed in the wild: a skill whose description said it runs *two* reviews made the agent run only *one*, because the summary was treated as the spec; deleting the workflow summary made the agent read the body and do both.) The verb phrases in move #2 name *capabilities* ("repairing cases.yaml"), not an ordered recipe ("first lint, then split, then validate"). If your description tells the reader how the skill works step by step, cut it down to triggers + boundary.
+- **State when it fires and where the boundary is — never the workflow.** The description says *when* to fire and *what it is not*. It must **not** summarize the procedure the body owns (the steps, the phase count, "does X then Y then Z"). This is not a style nit — it changes behavior. A description that pre-summarizes the steps becomes a *substitute* for reading the body: the agent acts on the summary and skips the real instructions. (Observed in the wild: a skill whose description said it runs *two* reviews made the agent run only *one*, because the summary was treated as the spec; deleting the workflow summary made the agent read the body and do both.) The verb phrases in move #2 name *capabilities* ("repairing cases.yaml"), not an ordered recipe ("first lint, then split, then validate"). If your description tells the reader how the skill works step by step, cut it back to situation + boundary.
 
-## Budget tactics when you blow 1024
+## Budget tactics when you are over
 
 In priority order, cut:
 
-1. Duplicate triggers that match the same situation ("write a skill" + "create a skill" — keep one).
-2. Verb phrases already implied by a trigger phrase.
-3. The optional "Knows…" clause.
+1. Verb phrases that name a capability the nearest sibling shares — they add no discrimination.
+2. Verb phrases already implied by the `Use when` lead.
+3. Any "Knows…" / "Understands…" clause.
 4. Shorten the boundary to one `NOT` clause naming the single most-confused sibling.
 
-Never cut: the `Use when` lead, at least 3 distinct triggers, one non-English trigger, one `NOT` boundary.
+Never cut: the `Use when` lead, or the last `NOT` boundary.
 
 ## Worked before → after
 
-**Before** (first person, no triggers, no boundary — 71 chars, would route badly):
+**Before** (first person, no situation, no boundary — 71 chars, would route badly):
 
 ```yaml
 description: "I help you write and improve skills so they work well."
 ```
 
-Problems: first person; no `Use when`; zero concrete phrasings for the router; no boundary, so it competes with `building-agents`, `specify`, and `init` on every "make a thing" turn.
+Problems: first person; no `Use when`; nothing that says *when* this fires; no boundary, so it competes with `building-agents`, `specify`, and `init` on every "make a thing" turn.
 
-**After** (third person, situation + verbs + phrasings + boundary, valid YAML, well under 1024):
+**After** (third person, situation + discriminating verbs + boundary, valid YAML, ~300 chars):
 
 ```yaml
-description: "Use when authoring a NEW skill or editing an existing one — writing a trigger-rich description, splitting a long body into references/, repairing evals/cases.yaml, or fixing a skill that never fires. Triggers: 'write a skill', 'escribe una skill', 'my skill never triggers', 'the description is too broad', 'audit this skill'. NOT building a product feature (that is `specify`) and NOT designing an agent loop (that is `building-agents`)."
+description: "Use when authoring a NEW skill or editing an existing one — writing the description that decides whether it loads, splitting a long body into references/, repairing evals/cases.yaml, or fixing a skill that never fires. NOT building a product feature (that is `specify`) and NOT designing an agent loop (that is `building-agents`)."
 ```
 
 ## Quick test
 
 Before committing a description, ask:
 
-- Could the router tell from this line alone *when* to fire it? (situation present)
-- Are there phrasings a real user would type, in their language? (triggers present)
-- Does it say what it is **not**, naming the sibling? (boundary present)
+- Could the reader tell from this line alone *when* to fire it? (situation present)
+- Could the reader pick it over its nearest sibling from this line alone? (discriminates)
+- Does it say what it is **not**, naming a sibling that exists? (boundary present)
+- Is anything in it there for coverage rather than discrimination? (cut it)
 - Does it describe *when/what-not*, and **never** the step-by-step procedure? (no workflow summary — if a reader could skip the body and act on the description alone, it leaks the workflow)
 - Does it parse as YAML and fit 1024? (run the check)
 

package/skills/author-skill/references/eval-authoring.md

@@ -59,7 +59,7 @@ For `author-skill`, the natural confusables are `specify`/`plan` (building a fea
 
 ## Writing good `capability` cases
 
-The `must_include` points are the differentiators — the specific things a *good* answer shows that a baseline answer misses. Make them **gradeable**: name the rule, the file path, the structural choice. "Writes a good skill" is not gradeable; "produces a third-person description ≤1024 with a `Use when` lead, a `NOT … (sibling)` boundary, and at least one non-English trigger" is.
+The `must_include` points are the differentiators — the specific things a *good* answer shows that a baseline answer misses. Make them **gradeable**: name the rule, the file path, the structural choice. "Writes a good skill" is not gradeable; "produces a third-person description under ~350 chars with a `Use when` lead and a `NOT … (sibling)` boundary naming a sibling that exists" is.
 
 For a process skill (no `verify.sh`), the capability scenario is the *primary* rigor — it is how you prove the safety rails actually change behavior. Make it count.
 

package/skills/author-skill/references/rsc-conventions.md

@@ -33,7 +33,7 @@ Every `SKILL.md` frontmatter MUST satisfy `schema/frontmatter.schema.json`:
 ```yaml
 ---
 name: my-skill                  # lowercase-kebab, matches the directory id
-description: Use when ...        # trigger-rich, third-person
+description: Use when ...        # third-person, situation + NOT boundary, ~350 chars
 tags: [keyword, keyword]         # what the consult advisor searches over (≥1)
 recommends: [sibling-skill]      # what the system offers to install next (real ids)
 profiles: [core, full]           # optional: named-profile membership

package/skills/automation-flows/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: automation-flows
-description: "Use when building or fixing a no-code automation on n8n, Make, or Zapier — wiring a trigger to multi-app steps with branching, data mapping, retries, and an error path, or choosing the platform by its billing model. Triggers: 'wire up a Zap / Make scenario / n8n workflow that does X when Y happens', 'new Stripe payment → Notion row → Slack message in n8n', 'my Zap keeps failing silently, add error handling and retries', 'should I use Make or Zapier for 50k runs a month', 'my automation bill exploded', 'give me the JSON to import into n8n', 'automatiza esto en Make sin código', 'munta un workflow a n8n amb gestió d'errors', 'por qué se me dispara el Zap dos veces'. NOT writing a typed API client in code with auth/pagination/backoff (that is api-connector-builder), NOT building the inbound endpoint that receives and verifies webhook events in your own app (that is webhooks), NOT scripting one vendor's SDK directly (that is stripe / notion-connector / google-workspace / whatsapp-telegram)."
+description: "Use when building or fixing a no-code automation on n8n, Make, or Zapier — trigger to multi-app steps with data mapping, dedup, retries and an error path — or picking the platform by billing unit (task vs credit vs execution). NOT a typed API client in code (that is api-connector-builder), NOT a webhook receiver in your own app (that is webhooks)."
 tags: [automation, n8n, make, zapier, no-code, workflows, error-handling, integrations]
 recommends: [automation-strategy, n8n, make, zapier, power-automate, webhooks, api-connector-builder, error-handling, stripe, notion-connector, google-workspace, whatsapp-telegram]
 profiles: []
@@ -9,16 +9,12 @@ origin: risco
 
 # Automation flows — glue many SaaS apps on a visual platform, with an error path that actually fires
 
-You are building a working automation on a hosted visual platform: a trigger, a chain of app actions with branching and explicit data mapping, and — non-negotiably — an error-handling and retry strategy. A flow that has no error path is not done. It is a silent failure waiting for the day the API hiccups and nobody notices the orders stopped syncing.
+You are building a working automation on a hosted visual platform: a trigger, a chain of app actions with branching and explicit data mapping, and an error-handling and retry strategy without which the flow is not done.
 
 Your job is two things at once: **platform judgement** (pick n8n vs Make vs Zapier by the constraints) and a **buildable artifact** (an importable n8n workflow JSON, or a precise numbered build sheet for Make/Zapier, which have no portable export).
 
 This skill stops the moment the right answer is real code. Writing a typed API client → `../api-connector-builder/SKILL.md`. Building the endpoint that *receives* a webhook in your own app → `../webhooks/SKILL.md`. Scripting one vendor directly → `../stripe/SKILL.md`, `../notion-connector/SKILL.md`, `../google-workspace/SKILL.md`, `../whatsapp-telegram/SKILL.md`.
 
-## The iron rule
-
-Every flow ships with an error path. Before you call a flow done, you must be able to point at: where a failed run goes, how many times it retries, and who gets told. No exceptions.
-
 ## 1. Pick the platform
 
 The single most expensive mistake is choosing on familiarity instead of cost model. The three platforms bill on fundamentally different units, and at volume that gap is 10×.
@@ -60,7 +56,7 @@ Good: Trigger = Airtable "new record" webhook              → fires the instant
 
 ## 3. Error handling — the spine
 
-This is what separates a toy from production. Full per-platform recipes (including the manual exponential-backoff loop) live in `references/error-handling.md`; here is the working core.
+Every flow ships with an error path, because a flow without one is a silent failure waiting for the day the API hiccups and nobody notices the orders stopped syncing. Before you call a flow done you must be able to point at three things: where a failed run goes, how many times it retries, and who gets told. Full per-platform recipes (including the manual exponential-backoff loop) live in `references/error-handling.md`, and the retry/backoff theory under them in `../error-handling/SKILL.md`; here is the working core.
 
 **n8n.** Build a dedicated **Error Workflow** that begins with the **Error Trigger** node — it runs only when a monitored workflow fails. Wire it to Slack/email/a log row, then set it as the main flow's `settings.errorWorkflow`. On risky nodes (anything hitting an external API) toggle **Retry On Fail** (Max Tries 3–5, set a Wait between tries) and, where a single failed item shouldn't kill the run, **Continue On Fail** (the node emits an error object instead of halting). n8n's built-in retry is **linear** — for true exponential backoff you build a wait/loop yourself (recipe in references).
 
@@ -108,7 +104,9 @@ Good: webhook → lookup event_id in store →
 
 **If n8n is chosen, produce an importable workflow JSON** the user can paste into *Import from File/Clipboard*. It must have a non-empty `nodes` array (including a trigger node), a `connections` object, and `settings.errorWorkflow` pointing at the Error Workflow. Reference credentials by the n8n **credential store**, never paste secrets inline. Full schema and a minimal trigger→action→error example: `references/n8n-workflow-json.md`.
 
-**If Make or Zapier is chosen, produce a numbered build sheet** — neither has a portable export you can hand over. One row per step: `# | app | action | field mapping (source → target) | error directive`. End with the trigger type and the dedup key. The capability eval covers these prose sheets; `verify.sh` covers the JSON.
+**If Make or Zapier is chosen, produce a numbered build sheet** — neither has a portable export you can hand over. One row per step: `# | app | action | field mapping (source → target) | error directive`. End with the trigger type and the dedup key.
+
+Run `scripts/verify.sh` on any JSON you emit: read-only, no network, no credentials — it parses the file and checks a non-empty `nodes` array, a `connections` object, and ≥1 trigger node (exits 0 on an empty target).
 
 ## Anti-patterns
 
@@ -122,11 +120,3 @@ Good: webhook → lookup event_id in store →
 | Secrets pasted inline in a node | Leaked in exports, unrotatable, shared everywhere | Use the platform credential store, reference by name |
 | One mega-flow doing everything | Unreadable, untestable, one failure nukes all | Split: trigger → sub-flow per concern |
 | Choosing platform by familiarity | Bill 10× higher than the right unit; "my automation bill exploded" | Pick by billing unit (task vs op vs execution) up front |
-
-## References & verification
-
-- `references/error-handling.md` — per-platform error deep dive, the manual exponential-backoff loop for n8n, and the three dedup patterns.
-- `references/n8n-workflow-json.md` — importable n8n JSON schema, minimal example, import steps, what `verify.sh` checks.
-- `scripts/verify.sh` — read-only; validates any `*.json` workflow you emit (parses, non-empty `nodes`, `connections` object, ≥1 trigger node). No network, no credentials. Exits 0 on an empty target.
-
-Cross-skills: webhook receiver → `../webhooks/SKILL.md`; typed API client in code → `../api-connector-builder/SKILL.md`; deeper retry/backoff theory → `../error-handling/SKILL.md`.

package/skills/automation-strategy/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: automation-strategy
-description: "Use when deciding whether a process is worth automating, choosing an automation platform, sizing ROI / build-vs-buy, designing an automation strategy, or diagnosing why a fleet of automations keeps breaking — the discipline layer that runs BEFORE anyone builds. Triggers: 'should we automate this?', 'is this worth automating', 'n8n vs Make vs Zapier vs Power Automate — which do we pick', 'custom script or no-code platform', \"what's the ROI on automating X\", 'design our automation strategy', 'our automations keep breaking', 'automating this cost more than it saved', '¿merece la pena automatizar esto?', 'qué plataforma de automatización elegimos'. NOT building the flow on a platform (design + importable artifact is automation-flows; driving a live platform API/MCP is the n8n / make / zapier / power-automate skills), NOT a typed API client with auth/pagination/backoff (api-connector-builder), NOT the inbound endpoint that receives webhook events in your app (webhooks)."
+description: "Use when deciding whether a process is worth automating, sizing ROI and build-vs-buy, choosing an automation platform, or diagnosing why a fleet of automations keeps breaking — the decision layer before anyone builds. NOT building the flow (that is `automation-flows`, or `n8n` / `make` / `zapier` / `power-automate` to drive a live platform)."
 tags: [automation, strategy, roi, build-vs-buy, platform-selection, orchestration, idempotency, n8n, make, zapier, power-automate]
 recommends: [automation-flows, n8n, make, zapier, power-automate]
 profiles: [core, full]
@@ -111,14 +111,6 @@ These are the guarantees every automation must meet regardless of platform. This
 | **No owner** | Orphaned automations rot; nobody notices the break or knows how it works | Name an owner + a one-page runbook per automation |
 | **Choosing platform by familiarity** | Bill 10× higher than the right billing unit; "our automation bill exploded" | Pick by billing unit for your run shape (§3) |
 
-## Related skills
-
-- `../automation-flows/SKILL.md` — **build layer**: designs the flow and emits the importable artifact once this skill has decided *whether* and *where*. Strategy decides; automation-flows designs.
-- `../n8n/SKILL.md`, `../make/SKILL.md`, `../zapier/SKILL.md`, `../power-automate/SKILL.md` — **operate layer**: drive that platform's live API/MCP to CRUD, activate, and run. Route here after §3.
-- `../api-connector-builder/SKILL.md` — when the answer is custom code, not a platform: typed client with auth/pagination/backoff.
-- `../webhooks/SKILL.md` — when you need to *receive* events in your own app (this skill treats webhooks as triggers, it doesn't build the receiver).
-- `../secure-coding/SKILL.md` — secrets/rotation engineering behind the orchestration policy in §4.
-
 ## Checklist
 
 - [ ] Ran the §1 gate: frequency × time-saved × error-rate × **stability** — and confirmed the process is standardized, not chaos being paved.

package/skills/aws-essentials/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: aws-essentials
-description: "Use when standing up the core AWS surface a small product needs — create a private S3 bucket for uploads, provision an encrypted RDS Postgres, choose ECS Fargate vs EC2 for a container, put CloudFront in front of S3, write or tighten an IAM policy, or harden a fresh account (root MFA, no long-lived keys). Triggers: 'set up an S3 bucket for user uploads', 'this role has AdministratorAccess, scope it down', 'spin up Multi-AZ Postgres on RDS', 'my bucket is public and I don't know why', 'this role can do everything', 'I can't encrypt RDS now', 'Fargate or EC2 for a low-traffic app', 'monta un bucket S3 privado', 'permisos mínims a IAM', 'posa CloudFront davant del bucket'. NOT the CI pipeline that ships your container (that is deployment), NOT app-code access-control review (that is secure-coding)."
+description: "Use when standing up the core AWS surface a small product needs: hardening a fresh account, a private S3 bucket, encrypted RDS Postgres, ECS Fargate vs EC2, CloudFront + OAC, or scoping an IAM policy to least privilege. NOT the CI pipeline that ships the container (that is `deployment`), NOT app-code access-control review (that is `secure-coding`)."
 tags: [aws, cloud, iam, s3, infrastructure]
 recommends: [deployment, secure-coding, dynamodb, postgresdb]
 origin: risco
@@ -17,19 +17,6 @@ god-mode app roles, long-lived keys, unencrypted databases). Pick the right tier
 account hardening → IAM (roles + scoped policies) → S3 (private) / RDS (encrypted) / ECS Fargate → CloudFront (OAC) → infra exists, wired, least-privilege
 ```
 
-## Operating posture — three rules
-
-- **Secure by default: keep the defaults AWS already hardened.** New S3 buckets are private
-  since April 2023 (Block Public Access on, ACLs disabled, SSE-S3 encryption). Do not undo them.
-- **Least privilege: scope every policy, never `"*"` on `"*"`.** A role that can do everything
-  is a breach waiting for one leaked credential. Start from a managed policy, then tighten.
-- **Roles, not keys.** Temporary credentials from a role beat a long-lived `AKIA…` access key
-  that lives forever in a `.env` and ends up on GitHub. Apps get task roles; CI gets OIDC.
-
-Boundary in one sentence: **this skill provisions and secures the AWS account and its core
-services; `../deployment/SKILL.md` puts your container on it; `../secure-coding/SKILL.md` audits
-the code inside it.**
-
 ## Service decision table
 
 | Need | Use | Use instead if |
@@ -61,7 +48,9 @@ Do this once, before anything else. Each line has a reason; skip none.
 
 Two principal types. **IAM users** = long-lived humans/keys; avoid them for workloads. **Roles**
 = an identity something *assumes* to get temporary credentials — this is what ECS tasks, Lambda,
-CI, and federated humans use. Default to roles.
+CI, and federated humans use. Default to roles: a temporary credential beats a long-lived `AKIA…`
+key that lives forever in a `.env`. (IAM governs who may call AWS APIs; access control *inside*
+your app code is `../secure-coding/SKILL.md`.)
 
 A policy is a JSON document. The four parts that matter:
 
@@ -181,7 +170,8 @@ Two more non-negotiables: the DB security group **references the app's security
 `0.0.0.0/0` (a DB open to the internet is a breach, not a convenience); credentials live in
 **Secrets Manager** with managed rotation (`--manage-master-user-password` above), never in task
 env vars. Use `--multi-az` for production HA. Full recipe (SG wiring, Secrets Manager rotation,
-connecting from ECS) → `references/rds-cloudfront-recipes.md`.
+connecting from ECS) → `references/rds-cloudfront-recipes.md`. Schema, indexes and query tuning
+once the instance exists → `../postgresdb/SKILL.md`.
 
 ## CloudFront + OAC — public web content, private bucket
 
@@ -214,10 +204,3 @@ Full CLI: create OAC → distribution → S3 bucket policy JSON → invalidation
 | Root user for daily ops | Highest blast radius, no per-action attribution | Root only for root-only tasks; admin via Identity Center |
 | No MFA on root | One phished password = total account loss | Passkey/security-key MFA on root and every human |
 | Confusing task role and execution role | App gets 403 at runtime, or ECS can't pull the image | Execution = pull image/logs; task = app's runtime perms |
-
-## Cross-links
-
-- `../deployment/SKILL.md` — Dockerfile, CI/CD, OIDC to ECR, the actual ship-the-container step.
-- `../secure-coding/SKILL.md` — app-code access control / OWASP (vs cloud IAM here).
-- `../postgresdb/SKILL.md` — schema, indexes, query tuning once the RDS instance exists.
-- For key-value / single-table serverless data instead of RDS, reach for the `dynamodb` skill.