kanbot 0.0.0-stage → 0.2.0

package/templates/.agents/skills/accessibility/SKILL.md

@@ -0,0 +1,76 @@
+---
+
+name: accessibility
+description: "Practical WCAG 2.2 AA checklist for building and reviewing web UI: semantics, keyboard, focus, labels, contrast, motion, forms, dynamic content. Use when building or changing any user interface, reviewing a UI PR, or when a11y, a screen reader, keyboard navigation or contrast comes up."
+---
+
+# Accessibility (WCAG 2.2 AA)
+
+Build it in while writing the markup; retrofitting costs more. Native HTML elements get most of this right for free.
+
+## Structure and semantics
+
+- [ ] One `<h1>` per page; headings in order without skipped levels; headings describe the section.
+- [ ] Landmarks: `<header>`, `<nav>`, `<main>`, `<footer>`; one `<main>`.
+- [ ] Buttons are `<button>` (actions), links are `<a href>` (navigation). No clickable `<div>`/`<span>`.
+- [ ] Lists are `<ul>/<ol>`, tabular data is `<table>` with `<th scope>`.
+- [ ] `lang` set on `<html>`. Page `<title>` describes the page.
+- [ ] ARIA only when no native element fits; a wrong role is worse than none.
+
+## Keyboard and focus
+
+- [ ] Every interactive element is reachable and operable with Tab, Shift+Tab, Enter, Space, and arrow keys where the pattern expects them (menus, tabs, radios).
+- [ ] Focus order follows the visual order. No positive `tabindex`.
+- [ ] Focus is always visible, with at least 3:1 contrast against its background. Never `outline: none` without a replacement.
+- [ ] Focused elements are not hidden behind sticky headers or footers (2.4.11).
+- [ ] Dialogs: focus moves in on open, is trapped inside, Escape closes, focus returns to the trigger. Prefer `<dialog>`.
+- [ ] No keyboard traps. A "Skip to content" link when there is repeated navigation.
+
+## Names, labels and images
+
+- [ ] Every control has an accessible name: visible `<label for>`, or `aria-label` for icon-only buttons.
+- [ ] The accessible name contains the visible label text (2.5.3).
+- [ ] Informative images have `alt` describing their purpose; decorative ones have `alt=""`. Icon SVGs inside labelled buttons get `aria-hidden="true"`.
+- [ ] Link text makes sense out of context: "View invoice 1042", not "Click here".
+
+## Colour and contrast
+
+- [ ] Body text at least 4.5:1; large text (24px, or 18.7px bold) at least 3:1.
+- [ ] UI component boundaries and meaningful icons at least 3:1.
+- [ ] Colour is never the only signal: errors also have text or an icon; links in text are underlined or otherwise distinct.
+- [ ] Check both light and dark themes if the app has them.
+
+## Layout and input
+
+- [ ] Works at 320px wide without horizontal scrolling (except tables, maps, code), and at 200% zoom.
+- [ ] Text spacing can be increased without clipping; no fixed heights on text containers.
+- [ ] Target size at least 24x24 CSS px, or enough spacing around it (2.5.8). Aim for 44x44 on touch.
+- [ ] Drag-only interactions have a single-pointer alternative (2.5.7).
+- [ ] Nothing depends on hover alone; tooltips are reachable by keyboard and dismissable.
+
+## Forms
+
+- [ ] Labels are visible and persistent (placeholders are not labels).
+- [ ] Required fields are marked in text, not only with colour or `*` without explanation.
+- [ ] Errors identify the field and say how to fix it; linked via `aria-describedby`; focus or summary on submit.
+- [ ] Correct `type` and `autocomplete` (`email`, `name`, `one-time-code`, …).
+- [ ] Don't ask for information already given in the same flow (3.3.7); allow paste in password and code fields (3.3.8).
+
+## Dynamic content and motion
+
+- [ ] Status changes that don't move focus (saved, count updated, results loaded) are announced via `role="status"` / `aria-live="polite"`. Errors that need attention: `role="alert"`.
+- [ ] Loading states are announced, or the busy region has `aria-busy="true"`.
+- [ ] Respect `prefers-reduced-motion`: disable non-essential animation and parallax.
+- [ ] No content flashes more than 3 times per second. Auto-playing or moving content can be paused.
+- [ ] Session timeouts warn and allow extension.
+
+## How to check quickly
+
+1. Tab through the changed UI from the top without a mouse. Can you do the whole task? Can you always see where focus is?
+2. Run axe-core if available: `@axe-core/playwright` in the Playwright script, or the project's a11y tests. Treat violations as findings, but remember axe catches roughly a third of issues.
+3. Inspect accessible names in Playwright: `page.getByRole("button", { name: "Save" })` should find the control. If role-based locators cannot find it, neither can a screen reader user.
+4. Zoom to 200% and resize to 320px.
+
+## Severity when reviewing
+
+`blocker`: keyboard trap, primary action unreachable by keyboard or unlabelled. `major`: any other AA failure in the changed UI. `minor`: best-practice gaps beyond AA.

package/templates/.agents/skills/approach-designer/SKILL.md

@@ -0,0 +1,79 @@
+---
+
+name: approach-designer
+description: Produce N genuinely different solution approaches for one problem, each with how it works, tradeoffs, risk and effort, plus a comparison table. Use for issues labelled explore:N, when writing a plan's "## Approaches" section, or when asked for alternatives or options to compare.
+---
+
+# Approach designer
+
+With `explore:N`, each approach is built in parallel by its own implementer on its own branch, and a human picks one by comparing working PRs. That only pays off if the approaches are different enough that seeing them side by side teaches something.
+
+## Make them genuinely different
+
+Pick the axis where the decision matters most for this problem, then spread approaches across it. Useful axes:
+
+| Axis              | Example spread for "let users find old invoices"                            |
+| ----------------- | --------------------------------------------------------------------------- |
+| Interaction model | Search box · faceted filters · timeline browsing                            |
+| Where logic lives | Client-side filtering of loaded data · server query endpoint · search index |
+| Data model        | Denormalised read model · query on existing tables · materialised view      |
+| Build vs. reuse   | Custom component · existing design-system table · third-party library       |
+| Timing            | Synchronous · background job with notification · precomputed nightly        |
+| Scope of change   | Minimal tweak to the current screen · new dedicated screen                  |
+
+Two approaches are the same approach if they differ only in: naming, styling or colours, a library swap with the same model (two date-picker packages), parameter values, or the order of the same steps.
+
+Self-test: could a human describe the difference in one sentence that mentions user experience, architecture or cost? If not, replace one.
+
+Constraints shared by all approaches:
+- Every approach meets every acceptance criterion. If it cannot, it is not an option.
+- Every approach fits one small PR. A huge approach next to a small one is not a fair comparison; shrink it or drop it.
+- Every approach follows project conventions unless deviating is the point of the approach (then say so).
+
+## Format
+
+Write exactly N sections, numbered from 1 with no gaps, then a comparison table.
+
+```markdown
+## Approaches
+
+### Approach 1: <descriptive name>
+
+**Summary:** <one sentence a product owner understands.>
+
+**How it works:** <3-6 sentences: what the user experiences, then where the logic lives and what data changes.>
+
+**Implementation steps:**
+1. <step> Files: `…`
+2. …
+
+**Tradeoffs:**
+- Good: <concrete benefit>
+- Costs: <concrete downside: complexity, perf, UX limitation, lock-in>
+
+**Risk:** <the main thing that could go wrong, and how likely.>  
+**Effort:** S | M | L <relative to the other approaches, with a one-line reason.>
+
+### Approach 2: <descriptive name>
+
+…
+
+### Comparison
+
+|                  | Approach 1: <name> | Approach 2: <name> | …   |
+| ---------------- | ------------------ | ------------------ | --- |
+| User experience  |                    |                    |     |
+| Complexity added |                    |                    |     |
+| Performance      |                    |                    |     |
+| Reversibility    |                    |                    |     |
+| Effort           | S                  | M                  |     |
+| Best when        |                    |                    |     |
+```
+
+## Writing good approaches
+
+- Names describe the idea: "Inline editing", "Wizard", "Background import", not "Option A" or "Simple approach".
+- Be concrete about the user experience. Implementers build what you write; vague approaches converge into the same build.
+- Name real downsides. "Slightly more code" is not a tradeoff; "every list view needs a new loading state because data arrives after first render" is.
+- "Best when" says which circumstances would make each approach the right choice. This is what helps the human choose.
+- Do not declare a winner in the plan. A single sentence of recommendation after the table is fine if you have a clear reason.

package/templates/.agents/skills/code-review/SKILL.md

@@ -0,0 +1,83 @@
+---
+
+name: code-review
+description: Checklist, severity rubric and finding format for reviewing a code change. Use when reviewing a branch or PR diff for correctness, tests, security and maintainability, when deciding finding severity, or when judging whether a fixer resolved a finding.
+---
+
+# Code review
+
+Find the problems that would hurt users or the team after merge, and say each one so precisely that it can be fixed without a conversation. A short list of real issues beats a long list of preferences.
+
+## Read before judging
+
+- `git log <base>..HEAD` and `git diff <base>...HEAD --stat` to see the shape.
+- Read the plan's acceptance criteria and implementation steps; the diff should match them.
+- For each non-trivial hunk, open the whole function and its callers. Most real bugs sit at the edges of the diff.
+- Run tests, lint and typecheck. Do not assume CI will.
+
+## Checklist (in priority order)
+
+**Correctness**
+- Does it do what the plan says for every input, including empty, null, zero, very large, duplicate and unicode input?
+- Off-by-one, wrong comparison, inverted condition, missing `await`, unhandled promise, race between concurrent requests.
+- State updates: stale state, cache not invalidated, partial writes without a transaction.
+- Changed function signatures or behaviour: are all callers updated?
+
+**Tests**
+- Does each acceptance criterion have a test that would fail if the feature were removed?
+- Do tests assert outcomes, or only that mocks were called?
+- Unhappy paths covered? No skipped, weakened or deleted tests?
+
+**Security**
+- Input validated at trust boundaries; output encoded (no raw HTML from user input).
+- Queries parameterised; no string-built SQL, shell commands or paths from user input.
+- Authorisation on every new endpoint, action and data query (can user A read user B's data?).
+- No secrets, tokens or personal data in code, logs, fixtures, screenshots or error messages.
+- New dependencies: maintained, reasonably sized, licence compatible.
+
+**Data and operations**
+- Migrations safe on existing data and reversible, or the irreversibility is stated.
+- Backward compatibility of APIs, events and stored formats.
+- Errors surfaced to the user or logged with enough context; not swallowed.
+- Obvious performance traps: N+1 queries, unbounded lists, work inside render loops.
+
+**Maintainability**
+- Follows `project-conventions` and the patterns of neighbouring code.
+- Reuses existing utilities instead of duplicating them.
+- Names say what things are; no dead code, commented-out code or leftover debug output.
+- Complexity proportionate to the problem; no speculative abstractions.
+
+## Severity rubric
+
+| Severity  | Meaning                                                                                                                                         | Blocks merge |
+| --------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------ |
+| `blocker` | Wrong behaviour on a main path, data loss or corruption, security hole, failing tests/build, acceptance criterion untested and broken           | Yes          |
+| `major`   | Bug in an edge case users will hit, missing test for a criterion, broken error handling, convention violation that will spread, risky migration | Yes          |
+| `minor`   | Real but low-impact issue: unclear naming, small duplication, missing test for a rare edge case                                                 | No           |
+| `nit`     | Preference or polish. Use sparingly; at most 3 per review                                                                                       | No           |
+
+When unsure between two levels, pick the lower one and explain the risk.
+
+## Writing a finding
+
+Each finding has: location, what is wrong, why it matters, and a suggested fix.
+
+> `src/invoices/service.ts:84` — `total` is computed before discounts are applied, so invoices with a discount code show the undiscounted amount (criterion 3). Move the `applyDiscounts` call above the sum, and add a test with a 10% code.
+
+- One problem per finding. Merge repeats into one finding listing all locations.
+- Point at the line in the new version of the file.
+- Show a failure scenario ("a user with no projects gets a 500") rather than a principle ("this is not robust").
+- Suggest the fix, and code only if short.
+- Ask a question only when you genuinely could not determine the answer by reading; say what you checked.
+
+## Avoid
+
+- More than ~10 findings. If you have more, keep the most important and summarise the rest in one finding.
+- Nit storms: formatting, import order and style a linter or formatter covers.
+- Requesting scope beyond the plan. Suggest a follow-up issue as a `nit` at most.
+- Rewriting the author's working approach to your preferred one without a concrete defect.
+- Approving with an unresolved `blocker` or `major`.
+
+## Re-review rounds
+
+For each previous finding: fixed (drop it), not fixed (repeat with the same id and what is still wrong), or the fixer disagreed (accept the reasoning, or explain once more why it matters). Check that fixes did not introduce new problems.

package/templates/.agents/skills/frontend-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/templates/.agents/skills/frontend-design/SKILL.md

@@ -0,0 +1,76 @@
+---
+
+name: frontend-design
+description: Guidance for distinctive, intentional visual design when building new UI or reshaping an existing one. Helps with aesthetic direction, typography, and making choices that don't read as templated defaults.
+license: Complete terms in LICENSE.txt
+---
+
+# Frontend Design
+
+Approach this as the design lead at a design studio known for giving every client a distinct visual identity that is not mistaken for anyone else's. This client has already rejected proposals that felt cliché or templated, and is paying for a distinctive point of view: make deliberate, opinionated choices about palette, typography, and layout that are specific to this brief, and take aesthetic risk if justified.
+
+## Ground your designs in the subject matter
+
+If the brief does not identify what the product or subject matter is, identify it yourself before designing, and confirm with the client. You can come up with one concrete subject, the design's audience, and the design's primary job, as a proposal. If there's any information in your memory about the client's preferences or context about what they're building, use that as a hint. The subject's industry, subject matter, materials, and vernacular are where distinctive visual choices come from — a design for a toy for girls aged 8–11 will be very aesthetically different from a dashboard for financial analysts. Build with the brief's real content and subject matter throughout.
+
+## Design principles
+
+For web designs, the hero is the first thing viewers will see. Open with the most characteristic thing in the subject's world, in the form that is most appropriate: a headline, an image, an animation, a live demo, an interactive moment, or other treatments. Be deliberate with your choice: a big number with a small label, supporting stats, and a gradient accent is the default treatment, so only use it if that's truly the best option.
+
+Typography carries the personality of the page. You don't need a different typeface for display or headline text and body content: use one family or two, and if two, make them clearly distinct.
+
+Choose your typefaces deliberately, not the default families you would reach for on any other project, and set a clear type scale following the default guidance of The Elements of Typographic Style with intentional weights, widths, and spacing. When type is used as a headline or visual element, use the type treatment itself as an active part of the design, not a neutral delivery vehicle for the content.
+
+Default to line lengths of less than 80 characters. Serif typefaces can have slightly longer line lengths; give serif body text slightly more line-height than a sans-serif.
+
+Avoid these default typographic treatments; they are the commonest tells of a generated page:
+- Accenting just a single word or phrase in a headline, like putting one word in italic/bold or a different color.
+- Using all caps for labels.
+- Adding unnecessary typographic labels above content.
+
+Visual structure is information. Structural devices like outlines, borders, numbering, eyebrows, dividers, labels, etc., encode useful information about the content rather than decorate it. Many generic designs use numbered markers (01 / 02 / 03), but that's only appropriate if the content actually is a sequence — like a stepped process or a timeline. Before adding numbered markers, check the content really is a sequence.
+
+Use non-user-triggered motion sparingly and deliberately, only to draw attention. A single orchestrated moment — one page-load sequence or one reveal — lands better than scattered effects; fade-and-slide-up entrances on each section and hover transitions on every card are the generic default and read as AI-generated. Motion that answers a person's action (opening, expanding, confirming) is welcome when it shows what changed.
+
+Consider written content carefully. Often a design brief may not contain real content, and it's up to you to come up with copy and placeholder content. Copy can make a design feel as templated as the design itself. See the below section on writing for more guidance.
+
+## Process: plan, review against the brief, build, critique
+
+For calibration, AI-generated design right now clusters around some traits:
+1. a warm cream background (near #F4F1EA) with a high-contrast serif display and a terracotta or warm-clay accent (often near #D97757 — Anthropic's own Claude-interaction accent, so on a user's brief it reads as a tell);
+2. a near-black background with a single bright acid-green or vermilion accent;
+3. a broadsheet-style layout with hairline rules, zero border-radius, and dense newspaper-like columns;
+4. the SaaS-card kit: content chopped into identical rounded cards, one border-radius on everything regardless of hierarchy, the same soft grey shadow (rgba(0,0,0,.1)) under each, and gradient washes as decoration;
+5. template chrome that appears whatever the subject: a tracked-out ALL-CAPS eyebrow label above every heading; meta strings joined with middle dots ('A · B · C'); labels built as 'WORD — fragment' with a spaced em dash; tinted near-black (#0B0B0B, #111) standing in for black; a monospace face for small data labels; a '→' appended to link and button text.
+
+All traits are legitimate for some briefs, but they are defaults rather than choices, and they appear regardless of subject. Where the brief pins down a visual direction, follow it exactly — the brief's own words always win, including when it asks for one of these looks. Where it leaves an axis free, don't spend that freedom on one of these defaults. As with a hired human designer, there's often a careful balance between doing what you're good at and taking each project as a chance to experiment and learn.
+
+Work in two passes. First, brainstorm a short design plan based on the client's design brief: create a compact token system with color, type, layout, and principles.
+- Color: describe the core base palette as 4–6 named hex values.
+- Type: the typefaces and their roles.
+- Layout: a layout concept, using one-sentence prose descriptions and ASCII wireframes to ideate and compare. Include alignment guidance; should the content be left aligned, center aligned, justified?
+- Principles: the high-level guidance for what makes this page unique.
+
+Then review that plan against the brief before building: if any part of it reads like the generic default you would produce for any similar page (work through a similar prompt to see if you arrive somewhere similar) rather than a choice made for this specific brief — revise that part, say what you changed and why. Only after you've confirmed the relative uniqueness of your design plan should you start to write the code, following the revised plan.
+
+When writing the code, be careful of structuring your CSS selector specificities. It's easy to generate CSS classes that cancel each other out (especially with a type-based selector like .section and an element-based selector like .cta). This can happen often with padding/margin between sections.
+
+## Restraint and self-critique
+
+Spend your boldness in one place. Let one element be the memorable thing, keep everything around it quiet and disciplined, and cut any decoration that does not serve the brief. Build to a quality floor without announcing it: responsive down to mobile, visible keyboard focus, reduced motion respected, visually accessible, harmonious color palettes. Critique your own work as you build, taking screenshots to review if your environment supports it — a picture is worth 1000 tokens. Consider Chanel's advice: before leaving the house, take a look in the mirror and remove one accessory. Human creatives have memory and always try to do something new, so if you have a space to quickly jot down notes about what you've tried, it can help you in future passes.
+
+## More on writing in design
+
+Words appear in a design for one reason: to make it easier to understand and use. They are design content, not decoration. Bring the same intentionality and minimalism to copywriting that you would bring to spacing and color. Before writing anything, ask what the design needs to say, and how it can best be said to help the person navigate the experience.
+
+Write from the end user's perspective. Name things by what users will understand in simple language, not by how the system is built. A user manages notifications, not webhook config. Describe what something is or does in plain terms rather than selling it. Being specific and legible to new users is always better than being clever.
+
+Use active voice as default. A CTA says exactly what happens when it is used: "Save changes," not "Submit." An action keeps the same name through the whole flow, so the button that says "Publish" produces a toast that says "Published." The vocabulary of an interface is the signposting for someone navigating the product. Cohesion and consistency are how people learn their way around.
+
+Treat failure and emptiness as moments for direction, not mood. Explain what went wrong and how to fix it, in the interface's voice rather than a person's. Errors don't apologize, and they are never vague about what happened. An empty screen is an invitation to act.
+
+Keep the tone conversational: plain verbs, sentence case, no filler, with tone matched to the brand and the audience. Let each written element do exactly one job.
+
+---
+
+Source: vendored verbatim from [anthropics/skills](https://github.com/anthropics/skills/tree/main/skills/frontend-design) (Apache License 2.0, see LICENSE.txt).

package/templates/.agents/skills/issue-splitting/SKILL.md

@@ -0,0 +1,78 @@
+---
+
+name: issue-splitting
+description: Split large issues into small, vertical, independently shippable slices using INVEST and standard splitting patterns. Use when a plan feels too big for one PR, has more than ~7 acceptance criteria, touches many unrelated areas, when a human asks to split, or when deciding whether follow-up work becomes a sub-issue or an idea.
+---
+
+# Issue splitting
+
+The goal is the smallest change that delivers something a user can notice (or that measurably unblocks the next change), shipped in one reviewable PR. Small slices get reviewed properly, merge without conflicts, and give feedback early.
+
+## Is it too big?
+
+Split when any of these hold:
+
+- More than ~7 acceptance criteria, or criteria about clearly separate outcomes.
+- Expected diff over ~400 changed lines (excluding generated files and lockfiles).
+- More than one user role or more than one screen/flow is changed.
+- It contains "and" in the want: "I want to filter **and** export".
+- An implementation step hides a large unknown ("integrate with payment provider").
+- You cannot describe how a reviewer tests it in five steps.
+
+## INVEST check for each slice
+
+- **Independent**: can merge in any order relative to sibling slices, or the order is explicit.
+- **Negotiable**: describes the need, leaves room in how.
+- **Valuable**: a user or operator notices something, even if small.
+- **Estimable**: no unbounded unknowns; otherwise spike first.
+- **Small**: one PR, one concern.
+- **Testable**: has Given/When/Then criteria.
+
+## Slice vertically, not horizontally
+
+Wrong: "1. database tables, 2. API, 3. UI". None of these is usable alone.
+Right: "1. view a list of invoices (read-only, newest first), 2. filter by status, 3. mark an invoice as paid". Each goes through every layer it needs.
+
+## Splitting patterns
+
+Try these in order; pick the one that gives the thinnest valuable first slice.
+
+| Pattern              | Split by                                                                                                     | Example                                                                                     |
+| -------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- |
+| Workflow steps       | Steps in the user's flow; ship the simplest end-to-end path first                                            | Checkout: pay with saved card → add new card → apply discount code                          |
+| Business rules       | One rule per slice                                                                                           | Shipping: flat rate → free over 500 kr → regional surcharges                                |
+| Data variations      | Types or sources of data                                                                                     | Import: CSV → Excel → Google Sheets                                                         |
+| Happy / unhappy path | Success first, then error handling and edge cases (only if the first slice still fails safely)               | Upload: valid file → size limit → resumable upload                                          |
+| Interface variations | Simplest interface first                                                                                     | Keyboard shortcut → command palette entry → settings UI                                     |
+| Operations (CRUD)    | One operation per slice                                                                                      | Create tag → rename tag → delete tag                                                        |
+| Roles                | One user role at a time                                                                                      | Members can comment → guests can comment                                                    |
+| Performance later    | Make it work, then make it fast                                                                              | Synchronous report → background job with progress                                           |
+| Spike                | A time-boxed investigation that answers one question, output is a decision or prototype, not production code | "Can we use the bank's API for reconciliation? Spike: authenticate and fetch one statement" |
+
+Never split by layer, by "frontend/backend", or into "tests later".
+
+## Smallest shippable first slice
+
+Ask: what is the least we could ship that someone would use or that teaches us something? Usually: one role, one happy path, one data type, hard-coded defaults instead of settings, no bulk operations. Behind a feature flag is fine if the project has flags.
+
+## Sub-issue or idea?
+
+- **Sub-issue** (`subIssue: true`): a slice of this issue's need that someone should build next. Column `planning` if it is clear enough to plan now, `ideas` if it needs the human to prioritise first.
+- **Idea** (`subIssue: false`, column `ideas`): related but a different need, a nice-to-have you noticed, or tech debt discovered along the way.
+- **Neither**: things that are just part of doing this slice well. Keep them in the plan.
+
+When splitting, this issue keeps the first slice. Rewrite its plan to cover only that slice and list the other slices under `## Out of scope` with a note that they were proposed as new issues.
+
+## Body for each new slice
+
+```markdown
+As a <user>, I want <capability>, so that <outcome>.
+
+<Two to four sentences: the need, and how this slice relates to the parent issue.>
+
+### Draft acceptance criteria
+
+- [ ] Given …, when …, then …
+
+Split from #<parent> (slice 2 of 3).
+```

package/templates/.agents/skills/kanbot-admin/SKILL.md

@@ -0,0 +1,57 @@
+---
+
+name: kanbot-admin
+description: Maintain this repo's kanbot setup with a human. Use to add or edit kanbot agents, skills or project memory, change `.kanbot/config.yml`, run `kanbot upgrade` or merge `.kanbot-new` files. Not for board jobs.
+---
+
+# kanbot admin
+
+You are helping a human maintain kanbot, the board-driven agent team in this repo. Board agents (planner, implementers, reviewers, fixer) never use this skill.
+
+## Map
+
+| Path                       | What                                   | Edit?                           |
+| -------------------------- | -------------------------------------- | ------------------------------- |
+| `.kanbot/agents/<name>.md` | Agent definitions, the source of truth | Yes, then `kanbot sync`         |
+| `.agents/skills/<name>/`   | Skills shared by all agents            | Yes                             |
+| `.kanbot/config.yml`       | Daemon config; schema next to it       | Yes                             |
+| `.kanbot/manifest.json`    | Template hashes from the last upgrade  | Never by hand                   |
+| `.claude/`, `.codex/`      | Generated by `kanbot sync`             | Never; edit the source and sync |
+
+`kanbot <command> --help` lists every flag. Agent frontmatter fields and output schemas: read an existing agent in `.kanbot/agents/` and copy its shape.
+
+## Recipes
+
+Finish every recipe with `kanbot sync` when agents changed, then `kanbot doctor`, then show the human the diff. The human commits and pushes; worktrees are made from the pushed base branch, so agents see nothing until then.
+
+### Add or change an agent
+
+1. Copy the closest existing agent. `name` must match the filename.
+2. Column agents (`tier: column`) need an `output` schema; subagents (`tier: sub`) are reached through a column agent's `subagents`.
+3. A new implementer also needs an entry under `implementers` in config and a matching `type:<x>` label on GitHub. Tell the human to create the label.
+4. The body says _how_ to work. The daemon's prompt carries the task.
+
+### Add a skill
+
+1. Create `.agents/skills/<name>/SKILL.md` with `name` (matches the folder) and a `description` that says what it covers and when it applies.
+2. Add the name to `skills` in each agent that should load it.
+
+### Add a memory
+
+When the human says "remember that …" or corrects something agents keep getting wrong, add a fact per `project-memory`. Stack, commands and conventions go in `project-conventions` instead.
+
+### Upgrade kanbot
+
+1. Run `bunx kanbot@latest upgrade --dry-run` and summarise it for the human.
+2. Run `bunx kanbot@latest upgrade`.
+3. Merge every `.kanbot-new` file (below).
+
+### Merge `.kanbot-new` files
+
+For each `<file>.kanbot-new` next to `<file>`:
+
+1. Diff the two. Name each difference: the human's customisation, or kanbot's improvement.
+2. Write the merged result into `<file>`: keep every customisation, take every improvement. Where they collide, ask the human.
+3. Delete `<file>.kanbot-new`.
+
+Done when `kanbot doctor` reports no unmerged `.kanbot-new` files and the human has seen a per-file summary of what was kept and taken.