alignment-values-north-star
$
npx mdskill add lyndonkl/claude/alignment-values-north-starBuilds shared direction, values, and decision standards for teams.
- Creates actionable frameworks for new teams, scaling, or resolving misalignment.
- Depends on user intent regarding North Star, values, mission, or guardrails.
- Selects artifacts by layering aspirational direction with behavioral standards.
- Delivers structured documents containing clear frameworks and quick reference guides.
SKILL.md
.github/skills/alignment-values-north-starView on GitHub ↗
---
name: alignment-values-north-star
description: Creates actionable alignment frameworks that give teams a shared North Star (direction), values (guardrails), and decision tenets (behavioral standards). Enables autonomous decision-making while maintaining organizational coherence. Use when starting new teams, scaling organizations, defining culture, establishing product vision, resolving misalignment, creating strategic clarity, or when user mentions North Star, team values, mission, principles, guardrails, decision framework, or cultural alignment.
---
# Alignment: Values & North Star
## Table of Contents
- [Workflow](#workflow)
- [1. Understand Context](#1--understand-context)
- [2. Choose Framework](#2--choose-framework)
- [3. Develop Alignment Artifact](#3--develop-alignment-artifact)
- [4. Validate Quality](#4--validate-quality)
- [5. Deliver and Socialize](#5--deliver-and-socialize)
- [Common Patterns](#common-patterns)
- [Guardrails](#guardrails)
- [Quick Reference](#quick-reference)
The framework has three layers: North Star (aspirational direction), Values/Guardrails (core operating principles), and Decision Tenets/Behaviors (concrete, observable demonstrations of values).
**Quick Example:**
```markdown
# Engineering Team Alignment
## North Star
Build systems that developers love to use and operators trust to run.
## Values
- **Simplicity**: Choose boring technology that works over exciting technology that might
- **Reliability**: Every service has SLOs and we honor them
- **Empathy**: Design for the developer experience, not just system performance
## Decision Tenets
When choosing between options:
✓ Pick the solution with fewer moving parts
✓ Choose managed services over self-hosted when quality is comparable
✓ Optimize for debuggability over micro-optimizations
✓ Document decisions (ADRs) for future context
## Behaviors (What This Looks Like)
- Code reviews comment on operational complexity, not just correctness
- We say no to features that compromise reliability
- Postmortems focus on learning, not blame
- Documentation is part of "done"
```
## Workflow
Copy this checklist and track your progress:
```
Alignment Framework Progress:
- [ ] Step 1: Understand context
- [ ] Step 2: Choose framework
- [ ] Step 3: Develop alignment artifact
- [ ] Step 4: Validate quality
- [ ] Step 5: Deliver and socialize
```
**Step 1: Understand context**
Gather background: team/organization (size, stage, structure), current situation (new team, scaling, misalignment, crisis), trigger (why alignment needed NOW), stakeholders (who needs to align), hard decisions (where misalignment shows up), and existing artifacts (mission, values, culture statements). This ensures the framework addresses real needs.
**Step 2: Choose framework**
For new teams/startups (< 30 people, defining identity from scratch) → Use `resources/template.md`. For scaling organizations (existing values need refinement, multiple teams, need decision framework) → Study `resources/methodology.md`. To see examples → Review `resources/examples/` (engineering-team.md, product-vision.md, company-values.md).
**Step 3: Develop alignment artifact**
Create `alignment-values-north-star.md` with: compelling North Star (1-2 sentences, aspirational but specific), 3-5 core values (specific to this team, not generic), decision tenets ("When X vs Y, we..."), observable behaviors (concrete examples), anti-patterns (optional - what we DON'T do), and context (optional - why these values). See [Common Patterns](#common-patterns) for team-type specific guidance.
**Step 4: Validate quality**
Self-check using `resources/evaluators/rubric_alignment_values_north_star.json`. Verify: North Star is inspiring yet concrete, values are specific and distinctive, decision tenets guide real decisions, behaviors are observable/measurable, usable for decisions TODAY, trade-offs acknowledged, no contradictions, distinguishes this team from others. Minimum standard: Score ≥ 3.5 (aim for 4.5+ if organization-wide).
**Step 5: Deliver and socialize**
Present completed framework with rationale (why these values), examples of application in decisions, rollout/socialization approach (hiring, decision-making, onboarding, team meetings), and review cadence (typically annually). Ensure team can recall and apply key points.
## Common Patterns
**For technical teams:**
- Focus on technical trade-offs (simplicity vs performance, speed vs quality)
- Make architectural principles explicit
- Include operational considerations
- Address technical debt philosophy
**For product teams:**
- Center on user/customer value
- Address feature prioritization philosophy
- Include quality bar and launch criteria
- Make product-market fit assumptions explicit
**For company-wide values:**
- Keep values aspirational but grounded
- Include specific behaviors (not just values)
- Address how values interact (what wins when they conflict?)
- Make hiring/firing implications clear
**For crisis/change:**
- Acknowledge what's changing
- Re-center on core that remains
- Be explicit about new priorities
- Include timeline for transition
## Guardrails
**Do:**
- Make values specific and distinctive (not generic)
- Include concrete behaviors and examples
- Acknowledge trade-offs (what you're NOT optimizing for)
- Test values against real decisions
- Keep it concise (1-2 pages max)
- Make it memorable (people should be able to recall key points)
- Involve the team in creating it (not top-down)
**Don't:**
- Use corporate jargon or buzzwords
- Make it so generic it could apply to any company
- Create laundry list of every good quality
- Ignore tensions between values
- Make it purely aspirational (need concrete behaviors)
- Set it and forget it (values should evolve)
- Weaponize values to shut down dissent
## Quick Reference
- **Standard template**: `resources/template.md`
- **Scaling/complex cases**: `resources/methodology.md`
- **Examples**: `resources/examples/engineering-team.md`, `resources/examples/product-vision.md`, `resources/examples/company-values.md`
- **Quality rubric**: `resources/evaluators/rubric_alignment_values_north_star.json`
**Output naming**: `alignment-values-north-star.md` or `{team-name}-alignment.md`
More from lyndonkl/claude
- abstraction-concrete-examplesBuilds structured abstraction ladders that translate high-level principles into concrete, actionable examples across 3-5 levels. Bridges communication gaps, reveals hidden assumptions, and tests whether abstract ideas work in practice. Use when explaining concepts at different expertise levels, moving between abstract principles and concrete implementation, identifying edge cases by testing ideas against scenarios, designing layered documentation, decomposing complex problems into actionable steps, or bridging strategy-execution gaps.
- academic-letter-architectGuides the creation of evidence-based academic recommendation letters, reference letters, and award nominations that combine concrete examples, meaningful comparisons, and genuine enthusiasm. Use when writing recommendation letters for students, postdocs, or colleagues, or when user mentions recommendation letter, reference, nomination, letter of support, endorsement, or needs help with strong advocacy and comparative statements.
- adr-architectureDocuments significant architectural and technical decisions with full context, alternatives considered, trade-offs analyzed, and consequences understood. Creates a decision trail that helps teams understand why decisions were made. Use when choosing between technology options, making infrastructure decisions, establishing standards, migrating systems, or when user mentions ADR, architecture decision, technical decision record, or decision documentation.
- adverse-selection-priorProduces a Bayesian prior probability that an offered transaction is +EV for the recipient, given that the counterparty chose to propose it. Applies Akerlof market-for-lemons logic -- if they offered it, they believe it is +EV for them, so the prior that it is +EV for us is materially below 50%. Reusable across trade evaluation, waiver drops (another team dropping a player is also adverse selection), job-offer analysis, M&A, and any "someone offered me this" situation. Use when you receive an unsolicited trade/offer/proposal, analyzing incoming trade prior, evaluating why a counterparty proposed a deal, or when user mentions adverse selection, market for lemons, why did they offer this, incoming trade prior, they proposed it, Bayesian adjustment on received offer.
- analogy-weight-checkFor every analogy in a substacker draft, verifies it carries mechanical weight — the analogy does real work explaining the mechanism, not merely decorates it. Cross-references analogy-catalog.md for novelty (is this analogy reused from a prior post?) and domain fit (biology > organizational > sports preferred; physics/military disfavored). Use whenever an analogy appears in the draft. Trigger keywords: analogy weight, decorative, mechanical weight, reused analogy, catalog check, metaphor check.
- answer-uncomfortable-questionTakes one strategic question about substacker ("should we launch paid?", "is this section dead?", "are we writing for the wrong audience?") and produces the mandatory evidence + reasoning + downside triad plus a recommendation. Used 3 times per Growth Strategist review. Trigger keywords: uncomfortable question, strategic question, evidence reasoning downside, triad.
- attribute-performanceFor each substacker post that materially over- or under-performs the rolling baseline (|z| ≥ 1.0), produces a plain-English attribution paragraph with calibrated confidence (high / medium / low / unexplained). Considers subject-line effect, topic zeitgeist, external share, day-of-week, length effect, and audience-notes signals. Labels unexplained outliers explicitly rather than fabricating a story. Use after compute-baseline when outlier posts exist. Trigger keywords: attribution, why did this post work, outlier explanation, performance analysis.
- auction-first-price-shadingComputes the optimal shaded bid for a first-price sealed-bid auction given a true private value, an estimate of the number of competing bidders N, and a value-distribution assumption. Implements the `(N-1)/N` equilibrium shading rule for uniform private values, adjusts for log-normal or empirical value distributions, layers a risk-aversion adjustment, and caps output against the bidder's remaining budget. Domain-neutral auction theory reusable across fantasy sports (baseball FAAB, NBA/NHL waiver auctions), prediction-market limit sizing, sealed procurement bids, and any blind-bid context. Use when user mentions "first-price auction bid", "sealed bid shading", "(N-1)/N", "FAAB bid amount", "auction shading", "optimal bid first-price", "bid for sealed-bid", "blind bid sizing", or when downstream logic needs a principled shade factor rather than an ad-hoc heuristic.
- auction-winners-curse-haircutApplies a Bayesian haircut to a bid valuation for common-value auctions where winning is itself evidence the bidder over-estimated. Takes a raw valuation, a value-type classification (common_value / private_value / mixed), the number of informed bidders N, and a signal-dispersion estimate, and returns an adjusted valuation. Domain-neutral and reusable across fantasy FAAB, prediction markets, M&A bids, ad-auction budgets, and any generic bidding context. Use when user mentions "winner's curse", "common value auction", "valuation haircut", "adverse valuation", "Bayesian bid adjustment", or "over-paying in auction".
- audit-driftChecks every post currently assigned to a substacker section against that section's promise and flags posts that no longer fit. Distinguishes acceptable-stretch (minor) from borderline (surface for review) from genuine-drift (violates promise). Never reassigns automatically — only flags. Use on every Curator run where at least one section already exists. Trigger keywords: drift, drift audit, section fit, promise violation, post in wrong section.