@kennethsolomon/shipkit 1.0.0

package/skills/sk:accessibility/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: sk:accessibility
+description: WCAG 2.1 AA accessibility audit. Use after /sk:frontend-design or on existing frontend code to catch accessibility issues before implementation or before shipping. Reports findings — does NOT fix code.
+license: Complete terms in LICENSE.txt
+---
+
+## Purpose
+
+Audit the frontend design spec or existing UI code for WCAG 2.1 AA compliance. This is an audit skill — it identifies issues and produces a findings report. It does NOT fix code.
+
+Run this skill:
+- **After `/sk:frontend-design`** — validate the design spec before implementation starts
+- **Before `/sk:finish-feature`** — validate the implemented UI before merging
+- **On existing code** — audit any frontend code or component
+
+## Hard Rules
+
+- **DO NOT fix code.** Report only. The user decides what to fix.
+- **Every finding must cite a specific design spec section, file, or component.**
+- **Every finding must reference the WCAG criterion it violates** (e.g., WCAG 1.4.3).
+- **Skip if the task is backend-only** — ask "Is there any frontend component?" before proceeding.
+
+## Before You Start
+
+1. Determine scope: design spec (from `/sk:frontend-design` output) or existing code files?
+2. If auditing code: `git diff main..HEAD --name-only` to find changed frontend files.
+3. If `tasks/accessibility-findings.md` exists, read it — check if prior findings have been addressed.
+4. If `tasks/lessons.md` exists, read it — apply accessibility-related lessons as targeted checks.
+
+## Audit Checklist
+
+### 1. Color & Contrast (WCAG 1.4.3, 1.4.11)
+- Normal text (< 18px / < 14px bold): minimum **4.5:1** contrast ratio against background
+- Large text (≥ 18px or ≥ 14px bold): minimum **3:1** contrast ratio
+- UI components and graphical objects (borders, icons, chart elements): minimum **3:1**
+- Check all color palette combinations from the design spec
+- Verify disabled states are still distinguishable (not just greyed out with no other indicator)
+
+### 2. Keyboard Navigation (WCAG 2.1.1, 2.1.2, 2.4.3, 2.4.7)
+- All interactive elements reachable by Tab key
+- Logical tab order (follows visual reading order)
+- No keyboard traps (user can always navigate away)
+- Visible focus indicator on all interactive elements (not removed with `outline: none` without replacement)
+- Modal/dialog focus management: focus moves into modal on open, returns to trigger on close
+- Skip navigation link present for pages with repeated navigation
+
+### 3. ARIA & Semantics (WCAG 4.1.2, 1.3.1)
+- Semantic HTML first (`<button>`, `<nav>`, `<main>`, `<header>`) — ARIA only when HTML is insufficient
+- All interactive elements have accessible names (via label, aria-label, or aria-labelledby)
+- Icons-only buttons have `aria-label` or visually hidden text
+- Dynamic content updates announced via `aria-live` regions where appropriate
+- No invalid ARIA roles or attributes
+- Form inputs associated with labels (via `<label for>` or `aria-labelledby`)
+
+### 4. Images & Media (WCAG 1.1.1, 1.2.x)
+- Informative images have descriptive `alt` text
+- Decorative images have `alt=""` (empty alt, not missing)
+- Complex images (charts, diagrams) have long descriptions
+- Videos have captions; audio has transcripts
+
+### 5. Forms (WCAG 1.3.5, 3.3.1, 3.3.2)
+- All fields have visible labels (not just placeholder text — placeholders disappear on input)
+- Required fields indicated (not by color alone)
+- Error messages: specific, descriptive, associated with the field (`aria-describedby`)
+- Error messages do not disappear on blur
+- Autocomplete attributes on common fields (`name`, `email`, `tel`, etc.)
+
+### 6. Motion & Animation (WCAG 2.3.1, 2.3.3)
+- No content flashes more than 3 times per second
+- All non-essential animations respect `prefers-reduced-motion` media query
+- Auto-playing animations can be paused, stopped, or hidden
+
+### 7. Content & Structure (WCAG 1.3.1, 2.4.6, 2.4.2)
+- Single `<h1>` per page; heading hierarchy is logical (no skipped levels)
+- Page has a descriptive `<title>`
+- Link text is descriptive standalone ("Read the docs" not "Click here")
+- Tables have `<th>` headers with appropriate scope
+- Language declared (`<html lang="en">`)
+
+## Generate Report
+
+Write findings to `tasks/accessibility-findings.md`:
+
+```markdown
+# Accessibility Audit — YYYY-MM-DD
+
+**Scope:** [design spec | changed files on branch `<branch>`]
+**Standard:** WCAG 2.1 AA
+
+## Failures (must fix)
+
+- **[Component/File:Line]** Description
+  **Criterion:** WCAG X.X.X — [Name]
+  **Impact:** [Who is affected and how]
+  **Recommendation:** [How to fix]
+
+## Warnings (should fix)
+
+- **[Component/File:Line]** Description
+  **Criterion:** WCAG X.X.X — [Name]
+  **Recommendation:** [How to fix]
+
+## Manual Checks Required
+
+- [Things that require human/screen reader testing]
+
+## Passed Checks
+
+- [Categories that passed with no findings]
+
+## Summary
+
+| Level    | Count |
+|----------|-------|
+| Failures | N     |
+| Warnings | N     |
+| Manual   | N     |
+```
+
+**Never overwrite** `tasks/accessibility-findings.md` — append new audits with a date header.
+
+## When Done
+
+Tell the user:
+
+> "Accessibility audit complete. Findings saved to `tasks/accessibility-findings.md`.
+> - **Failures:** N | **Warnings:** N | **Manual checks:** N
+>
+> Address failures before implementation, then run `/sk:write-plan` to proceed."
+
+If there are no failures:
+> "No accessibility failures found. N warnings noted. Run `/sk:write-plan` to proceed."
+
+---
+
+## Model Routing
+
+Read `.shipkit/sk:config.json` from the project root if it exists.
+
+- If `model_overrides["sk:accessibility"]` is set, use that model — it takes precedence.
+- Otherwise use the `profile` field. Default: `balanced`.
+
+| Profile | Model |
+|---------|-------|
+| `full-sail` | sonnet |
+| `quality` | sonnet |
+| `balanced` | sonnet |
+| `budget` | haiku |
+
+> `opus` = inherit (uses the current session model). When spawning sub-agents via the Agent tool, pass `model: "<resolved-model>"`.

package/skills/sk:api-design/LICENSE.txt

@@ -0,0 +1,177 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS

package/skills/sk:api-design/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: sk:api-design
+description: Design REST or GraphQL API contracts before implementation. Use this skill when the user needs to design API endpoints, request/response shapes, authentication patterns, error codes, or data contracts. Produces an API specification — NOT code.
+license: Complete terms in LICENSE.txt
+---
+
+## CRITICAL: Design Phase Only — NO CODE
+
+**This skill is a design phase, not an implementation phase.**
+
+- **DO NOT** write, edit, or generate any code (no controllers, routes, models, migrations)
+- **DO NOT** use file editing tools (Edit, Write, Bash)
+- **DO produce** endpoint contracts, request/response shapes, error codes, auth flows, and data models
+- Implementation happens in `/sk:execute-plan` — not here
+
+This skill designs clear, consistent API contracts that `/sk:write-plan` and `/sk:execute-plan` can implement without ambiguity.
+
+## Before You Start
+
+1. If `tasks/findings.md` exists and has content, read it in full. Use the agreed approach and requirements as the design brief.
+2. If `tasks/lessons.md` exists, read it in full. Apply every active lesson as a constraint — particularly patterns flagged under **Bug** that relate to API structure, auth, or data validation.
+
+## API Context
+
+Establish these before designing:
+
+- **API type**: REST, GraphQL, or both?
+- **Consumers**: Who calls this API? (web app, mobile app, third-party, internal service)
+- **Auth method**: JWT, API key, OAuth2, session cookie, or none?
+- **Versioning strategy**: URL prefix (`/v1/`), header (`Accept-Version`), or none?
+- **Transport**: HTTPS only. No exceptions.
+
+If context is unclear from `tasks/findings.md`, ask the user before proceeding.
+
+## Design Thinking
+
+Before designing endpoints, model the domain:
+
+- **Resources**: What are the core entities? (e.g., User, Order, Product)
+- **Relationships**: How do resources relate? (ownership, nesting, references)
+- **Actions**: What operations exist? (CRUD + custom actions like `/publish`, `/archive`)
+- **Invariants**: What rules can never be violated? (e.g., a published post can't be deleted)
+
+**CRITICAL**: Design for the consumer, not the database. An API that mirrors the database schema 1:1 is usually wrong — design for what clients actually need.
+
+## API Design Guidelines
+
+### REST Endpoints
+- **Nouns, not verbs** in URLs: `/orders` not `/getOrders`
+- **Plural resources**: `/users`, `/posts`, `/comments`
+- **Nested only one level deep**: `/users/{id}/orders` ✓ — `/users/{id}/orders/{id}/items` ✗ (use `/order-items?orderId=`)
+- **HTTP methods map to actions**: GET (read), POST (create), PUT (full replace), PATCH (partial update), DELETE (remove)
+- **Custom actions**: use POST + verb suffix: `POST /orders/{id}/cancel`
+
+### Request Design
+- Use JSON request bodies for POST/PUT/PATCH
+- URL params for resource IDs
+- Query params for filtering, sorting, pagination
+- Headers for auth tokens and content negotiation
+
+### Response Design
+- Consistent envelope: `{ data, meta, errors }` or resource-direct — pick one and use it everywhere
+- Pagination: `{ data: [...], meta: { total, page, per_page, last_page } }`
+- Timestamps: ISO 8601 (`2026-03-15T22:00:00Z`)
+- IDs: strings (not integers) — avoids enumeration attacks
+
+### Status Codes
+- `200` OK (GET, PUT, PATCH success)
+- `201` Created (POST success)
+- `204` No Content (DELETE success)
+- `400` Bad Request (validation failure)
+- `401` Unauthenticated (missing/invalid token)
+- `403` Forbidden (authenticated but not authorized)
+- `404` Not Found
+- `409` Conflict (duplicate, state violation)
+- `422` Unprocessable Entity (business rule violation)
+- `429` Too Many Requests (rate limited)
+- `500` Internal Server Error
+
+### Error Format
+Standardize error responses:
+```json
+{
+  "errors": [
+    {
+      "code": "VALIDATION_FAILED",
+      "field": "email",
+      "message": "Email is already taken"
+    }
+  ]
+}
+```
+
+### Auth Design
+- JWT: short-lived access token (15min–1hr) + refresh token (7–30 days)
+- API keys: prefix with service identifier (`sk_live_`, `pk_test_`)
+- Never return tokens in URL params — headers or response body only
+- Document which endpoints require auth and what permissions
+
+### Rate Limiting
+- Define limits per endpoint tier (public, authenticated, admin)
+- Return `Retry-After` header on `429`
+
+## Output Format
+
+End every `/sk:api-design` session with a structured specification:
+
+```
+## API Design Specification
+
+### Overview
+[API purpose, consumers, base URL pattern, versioning approach]
+
+### Authentication
+[Auth method, token format, how to include in requests, refresh flow]
+
+### Resource Models
+[Core entities with their fields, types, and constraints]
+
+### Endpoints
+
+| Method | Path | Auth | Description |
+|--------|------|------|-------------|
+| GET    | /v1/resource | required | List resources |
+| ...    | ...  | ...  | ... |
+
+### Endpoint Details
+[For each endpoint: request params/body shape, success response shape, error cases]
+
+### Error Codes Reference
+[Application-specific error codes and when they occur]
+
+### Rate Limits
+[Per-tier limits, headers returned]
+
+### Versioning & Breaking Changes
+[What constitutes a breaking change, deprecation policy]
+```
+
+After presenting the specification, tell the user: **"Run `/sk:write-plan` to turn this into an implementation plan."**
+
+---
+
+## Model Routing
+
+Read `.shipkit/sk:config.json` from the project root if it exists.
+
+- If `model_overrides["sk:api-design"]` is set, use that model — it takes precedence.
+- Otherwise use the `profile` field. Default: `balanced`.
+
+| Profile | Model |
+|---------|-------|
+| `full-sail` | opus (inherit) |
+| `quality` | opus (inherit) |
+| `balanced` | sonnet |
+| `budget` | sonnet |
+
+> `opus` = inherit (uses the current session model). When spawning sub-agents via the Agent tool, pass `model: "<resolved-model>"`.

package/skills/sk:brainstorming/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: sk:brainstorming
+description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
+---
+
+# Brainstorming Ideas Into Designs
+
+## Overview
+
+Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
+
+Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
+
+<HARD-GATE>
+Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
+</HARD-GATE>
+
+## Anti-Pattern: "This Is Too Simple To Need A Design"
+
+Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
+
+## Checklist
+
+You MUST create a task for each of these items and complete them in order:
+
+1. **Explore project context** — read `tasks/findings.md` and `tasks/lessons.md` if they exist, then check files, docs, recent commits
+2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
+3. **Propose 2-3 approaches** — with trade-offs and your recommendation
+4. **Present design** — in sections scaled to their complexity, get user approval after each section
+5. **Write findings** — Save the agreed-upon direction to `tasks/findings.md`:
+   - Problem statement
+   - Key decisions made
+   - Chosen approach + rationale
+   - Open questions (if any remain)
+   (Optionally also write a full design doc to docs/plans/YYYY-MM-DD-<topic>-design.md)
+6. **Transition to implementation** — invoke writing-plans skill to create implementation plan
+
+## Process Flow
+
+```dot
+digraph brainstorming {
+    "Explore project context" [shape=box];
+    "Ask clarifying questions" [shape=box];
+    "Propose 2-3 approaches" [shape=box];
+    "Present design sections" [shape=box];
+    "User approves design?" [shape=diamond];
+    "Write design doc" [shape=box];
+    "Invoke writing-plans skill" [shape=doublecircle];
+
+    "Explore project context" -> "Ask clarifying questions";
+    "Ask clarifying questions" -> "Propose 2-3 approaches";
+    "Propose 2-3 approaches" -> "Present design sections";
+    "Present design sections" -> "User approves design?";
+    "User approves design?" -> "Present design sections" [label="no, revise"];
+    "User approves design?" -> "Write design doc" [label="yes"];
+    "Write design doc" -> "Invoke writing-plans skill";
+}
+```
+
+**The terminal state is invoking writing-plans.** Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.
+
+## The Process
+
+**Understanding the idea:**
+- If `tasks/findings.md` exists and has content, read it in full. Summarize the prior
+  decisions to the user and ask: extend, revise, or start fresh? Do not re-explore
+  what is already decided unless the user asks.
+- If `tasks/lessons.md` exists, read it in full. Apply every active lesson as a design
+  constraint throughout the brainstorm — particularly prevention rules when proposing approaches.
+- Check out the current project state first (files, docs, recent commits)
+- Ask questions one at a time to refine the idea
+- Prefer multiple choice questions when possible, but open-ended is fine too
+- Only one question per message - if a topic needs more exploration, break it into multiple questions
+- Focus on understanding: purpose, constraints, success criteria
+
+**Exploring approaches:**
+- Propose 2-3 different approaches with trade-offs
+- Present options conversationally with your recommendation and reasoning
+- Lead with your recommended option and explain why
+
+**Presenting the design:**
+- Once you believe you understand what you're building, present the design
+- Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
+- Ask after each section whether it looks right so far
+- Cover: architecture, components, data flow, error handling, testing
+- Be ready to go back and clarify if something doesn't make sense
+
+## After the Design
+
+**Documentation:**
+- Write the findings to `tasks/findings.md` (required — captures problem, decisions, approach, rationale)
+- Optionally: Create a full design doc at `docs/plans/YYYY-MM-DD-<topic>-design.md` for complex projects
+- Commit the findings and any design document to git
+
+**Implementation:**
+- Invoke the writing-plans skill to create a detailed implementation plan
+- Do NOT invoke any other skill. writing-plans is the next step.
+
+## Key Principles
+
+- **One question at a time** - Don't overwhelm with multiple questions
+- **Multiple choice preferred** - Easier to answer than open-ended when possible
+- **YAGNI ruthlessly** - Remove unnecessary features from all designs
+- **Explore alternatives** - Always propose 2-3 approaches before settling
+- **Incremental validation** - Present design, get approval before moving on
+- **Be flexible** - Go back and clarify when something doesn't make sense
+
+---
+
+## Model Routing
+
+Read `.shipkit/sk:config.json` from the project root if it exists.
+
+- If `model_overrides["sk:brainstorming"]` is set, use that model — it takes precedence.
+- Otherwise use the `profile` field. Default: `balanced`.
+
+| Profile | Model |
+|---------|-------|
+| `full-sail` | opus (inherit) |
+| `quality` | opus (inherit) |
+| `balanced` | sonnet |
+| `budget` | sonnet |
+
+> `opus` = inherit (uses the current session model). When spawning sub-agents via the Agent tool, pass `model: "<resolved-model>"`.