Instruction file imported from fabioc-aloha/Alex_Plug_In (.github/instructions/north-star.instructions.md). Copyright stays with the author.

North Star — Auto-Loaded Rules

Active Context templates, default NASA-quality standard, full breakdown methodology → see north-star skill.

When to Reference

Always reference the North Star when:

1. Deciding between features (Does it serve the vision?)
2. Under time pressure (Are we cutting corners that compromise trust?)
3. Reviewing code (Does this meet our quality commitment?)
4. Planning releases (Is this ready by North Star standards?)

Never use North Star to:

• Justify scope creep ("but it aligns with the vision!")
• Avoid hard decisions ("the North Star doesn't say...")
• Marketing speak in technical contexts

Protocol: North Star Check

When evaluating any proposed change:

1. Read the North Star from Active Context
2. Ask: Does this change serve the North Star?
3. Ask: Does it compromise any quality commitment?
4. If conflict: North Star wins over convenience
5. Document the decision and reasoning

Hierarchy

North Star > Feature requests > Timeline pressure

Creating North Star for New Projects

1. Define ambition: What would make this legendary?
2. Break down words: What does each key term mean specifically?
3. Daily implications: How does this affect small decisions?
4. Document: Create NORTH-STAR.md with full breakdown
5. Integrate: Add North Star:, Guidelines:, and Persona: fields to Active Context
6. If yes: Proceed, noting alignment
7. If no: Flag the misalignment, suggest alternatives
8. If unclear: Request clarification before proceeding

---

## Hierarchy

- North Star defined in the project's North Star document (NORTH-STAR.md)
- Heir projects: Inherit NASA-Quality default OR define custom
- Sub-projects: May have local North Stars that serve parent's vision

A local North Star should never contradict the parent project's North Star.