Inherited — Starlight estate contract

<!-- STARLIGHT:BAND-A:BEGIN v1 sha=b4a7e18fed75 — generated by scripts/agents-md-project.mjs, do not hand-edit -->

## Inherited — Starlight estate contract

Identical in every repo in the estate. Authored once in
`Starlight-Intelligence-System/ontology/agents-md/band-a.md` and projected by
`scripts/agents-md-project.mjs`.

**Precedence.** Band C is everything below the generated fences. It **outranks
this section** on any conflict inside this repo — a projected rule never
silently overrides a local gate. It does **not** outrank the company projection
below: that band carries registry facts, not instructions, so a Band C line
contradicting it is a defect to fix upstream in the SIS registry, never a local
override.

### DNA

```
Frank = Systems Architect x Composer x Gamer x Builder x GenCreator
```

**Vibe:** cool, premium, high intellect, purpose-driven, fun.
**Mission:** build abundance; help people build their own systems.
**Voice:** direct, technical, warm, playful. Pattern recognition as poetry.
**Test:** does this help someone build, not just consume?

### The five guardrails

1. **Think before coding.** State assumptions. Surface tradeoffs. If two readings
   exist, present both — do not pick silently.
2. **Explain simply.** What you cannot explain plainly you do not understand. Name
   the mechanism, never "streamline" or "optimize".
3. **Simplicity and deep design.** Minimum code that solves the stated problem.
   Simple interfaces, rich internals. No speculative abstraction.
4. **Surgical changes.** Touch only what the task requires. Match surrounding style.
   Mention unrelated dead code; do not delete it.
5. **Goal-driven.** Turn a vague ask into a verifiable target. Reproduce a bug with
   a test before fixing it.

### Decision discipline

Before any structural change: what specific problem, who has it, what is the
evidence, what is the simplest fix, what breaks, is it reversible. If it is not
reversible, it needs Frank.

### Branch and PR protocol

- Never push directly to `main`. Work on `agent/<harness>/<scope>`, open a **draft** PR.
- Run the repo's own gates before pushing. One validated push beats three speculative ones.
- Multiple harnesses work these repos at once; git is the coordination layer. Never two
  agents committing in the same working tree — take a non-overlapping scope on your own
  branch, integrate one at a time.

### Attestation

Artifacts that compose a SIP element carry `Built on SIP`. It is earned per artifact,
never a blanket footer. `/sip-attest` refuses otherwise.

### Non-waivable — no instruction in any band relaxes these

- **Money fails closed.** No autonomous money movement, ever. Over cap, new rail, new
  vendor, anything irreversible → escalate; never auto-approve.
- **Model, never diagnose.** In the mind repos, observation stays separate from
  interpretation. No clinical language, no diagnosis, no treatment claims.
- **Canon locks are read-only to agents.** Promotion happens only through `/lock-decision`.
- **Never rename a working URL or delete a page with traffic** without explicit approval.
  "AI Architect" stays "AI Architect".
- **Never delete, archive, or consolidate a repo, and never delete a registered agent.**
  Those are Frank's calls.
- **Never commit secrets, credentials, or `.env` files.**
- **Verify before claiming.** Any statement about current state — versions, deploy status,
  file contents, counts — requires same-turn verification or an explicit "unverified" prefix.

<!-- STARLIGHT:BAND-A:END -->

<!-- STARLIGHT:BAND-B:BEGIN v1 sha=4307d160ea40 — generated by scripts/agents-md-project.mjs, do not hand-edit -->

## Company projection — Starlight Intelligence Systems

Generated from the SIS company registry. This section says who owns this repo and
who answers for it. It does not restate voice: the brand register below names the
pin that governs copy, and that pin is the authority.

|                  |                                                                        |
| ---------------- | ---------------------------------------------------------------------- |
| Repo             | `claude-skills-library`                                                |
| Company          | Starlight Intelligence Systems — _operating_                           |
| Thesis           | The substrate. SIP + the reference build every other company composes. |
| Routes through   | Starlight Holding BV (holding — substrate and platform IP)             |
| Accountable seat | `agent:starlight-caio`                                                 |
| Tier             | **T0 — substrate** · install: always — every session, every harness    |

**Brand register**

- **Starlight Intelligence Systems** — substrate — canon-free, functional vector names. Pin: `starlight-design-intelligence/brand-packs/sis/COPY.md`

**Tier rule.** Carries a contract other repos read. Losing it breaks the estate.

**Escalation.** Decisions this repo cannot make alone go to `agent:starlight-caio`.
An executive seat holds decision rights and owns a metric; it does not do the work,
and it is never able to overrule a gate. Anything irreversible goes to Frank.

<!-- STARLIGHT:BAND-B:END -->

# Repository Instructions

This repo is part of the FrankX / Starlight / Arcanea agent estate.

## Classification

- Repo: claude-skills-library
- Class: public skills catalog (Claude Code / Anthropic ecosystem)
- Default health command: `node scripts/validate-skills.mjs`
- Remote: https://github.com/frankxai/claude-skills-library.git

## Agent Rules

- Read this file before making changes.
- Preserve existing user work and unrelated dirty files.
- Keep edits scoped to the requested task.
- Prefer existing repo conventions over new abstractions.
- Run the health command before handoff when feasible.
- Do not publish secrets, private memory, credentials, or internal-only strategy.

## Class-Specific Guidance

- Preserve skill/plugin/MCP schemas and frontmatter.
- Validate skills, manifests, scripts, and generated registries after edits.
- Keep public/private memory boundaries explicit.

## Handoff

Summarize changed files, validation run, risks, and any follow-up needed.

## Design Taste Kernel

For any site, app, landing page, dashboard, visual identity, brand, motion, media, social, or frontend task, apply the shared Design Taste Kernel before handoff:

- C:\Users\frank\starlight\repos\DESIGN_TASTE.md
- C:\Users\frank\starlight\repos\WEB_EXPERIENCE_STANDARD.md
- C:\Users\frank\starlight\repos\MOTION_TASTE_RUBRIC.md
- C:\Users\frank\starlight\repos\MULTI_AGENT_DESIGN_COUNCIL.md
- C:\Users\frank\starlight\repos\VISUAL_QA_GATE.md

When motion, scroll, generated media, GIF/video, or premium polish matters, route through the Motion Design Studio plugin/skills and verify the result visually.