t-261002151630-8f2ce6: метаскилл meta-skill-factory (повторяющаяся работа 2+ раза → SKILL.md в репо) + первый скилл presale-landing, боевой прогон на задаче лэндоса (источники и Stripe-CTA проверены)

This commit is contained in:
Simbiot Harness 2026-10-02 15:18:47 +00:00
parent f140b76dc7
commit cac1ffaae0
3 changed files with 240 additions and 0 deletions

19
skills/README.md Normal file
View file

@ -0,0 +1,19 @@
# Simbiot Harness — skills/
Реестр скиллов репо (формат по образцу ui-skills: каталог + SKILL.md).
Как пользоваться: агенты при старте задачи смотрят сюда (или через rag_lookup
«skill <название>»), грузят SKILL.md нужного скилла и идут по шагам.
Как добавить скилл: см. `skills/meta-skill-factory/SKILL.md` — скиллы рождаются,
когда повторяющаяся работа поймана 2+ раз, и сразу проходят боевой прогон.
| Скилл | Назначение | Когда грузить |
|---|---|---|
| `meta-skill-factory` | Метаскилл: превращение повторяющейся работы в скилл репо (шаги, чеклисты, критерии качества) | Заметил, что делаю одну и ту же работу 2+ раз — прежде чем делать руками в третий |
| `presale-landing` | Производство пресейл/продуктовых лендингов: структура, честные мокапы, Stripe CTA, quality gates | Задача на лендинг/пресейл-страницу или её v2 |
## Сторонние наборы
- `/tmp/ui-skills` — внешний набор ui-skills (frontend-design, improve-ui,
improve-animations...); задача переноса в репо: t-261002151425-d5f131.

View file

@ -0,0 +1,133 @@
---
name: meta-skill-factory
description: Use whenever recurring work is noticed (the same kind of task 2+ times — product visuals, presale landing pages, UI audits, digests of a given type, etc.) and the next repetition would again be done BY HAND. Instead of a hand run: capture the work as a full repo skill (SKILL.md with steps, checklists, quality gates), register it, and apply it to one live task immediately. Converts one-off knowledge into a repeatable, reviewable asset.
metadata:
origin: idea by Alex (TG, 2026-10-02), task t-261002151630-8f2ce6
scope: simbiot-harness, works for any cooperative repo
---
# Meta-skill factory: recurring work → repo skill
A skill is written once so that any agent (including future ticks of this
harness with zero memory) does the work correctly the first time and
provably well. It turns "I'll do it again by hand" into "load SKILL.md —
follow the steps — check the criteria."
## Trigger rule (when to run this skill)
Notice the trigger during a task. A skill is worth creating when **all** of:
- [ ] This is the **2nd+ time** you are doing the same kind of work this sprint
- [ ] The work has a **checkable end result** (file, page, list, metric —
not "communicated with someone")
- [ ] The next time, someone fresh can get **within ~5% of the desired
quality** based on the paper alone (the paper carries the decisions,
not the hand skills)
- [ ] The work is stable — the format won't change tomorrow
In between: "recurring by eye" without a result → not yet. A one-off task →
don't invent a skill.
## Skill format (repo pattern, template copied from ui-skills)
One skill = a directory in `<repo>/skills/<kebab-case-name>/` with:
```
skills/<name>/
├── SKILL.md # required: frontmatter + body per the template
└── reference/ # optional: templates, checklists, examples
```
`SKILL.md` — structure (headmatter + 6 sections):
```markdown
---
name: <kebab-case-name>
description: <When to load, as an action verb. This is the "when to use" line —
write it first, and it should make sense without the body of the file.>
metadata:
origin: <source of the skill: task/idea, date>
scope: <which repo/products>
---
# <Name>
<1–2 lines: what it turns into and what outcome.>
## Trigger rule
[checklist — when the skill can/can't be used (see above for the sample length)]
## Steps
[numbered steps; each = action + specific commands/files, like improve-ui]
## Quality criteria
[checkbox list — what output is accepted. Vague words ("good", "beautiful")
are forbidden: each item must have a verification method — file, grep,
measurement, reviewer list]
## Common mistakes
[3–5 items: what agents usually get wrong in this work]
## Done when
[final checklist + in which task format to close (task id, artifact path)]
```
Requirements:
- The skill is **read-friendly in 2 minutes**: no history of how you got to it,
no internal jargon without explanation.
- Quality criteria are phrased as **proof** («there exists», «measured», «there
are no more than N of»), not as wishes.
- SKILL.md is self-sufficient: executor without context from the conversation.
- If the skill is bigger than ~200 lines — split it out: the main process in
SKILL.md, references/templates in `reference/`.
## Steps
1. **Catch the repetition.** During a task, notice: "I have already done this
2+ times". If all trigger rules check out — this is a skill candidate.
2. **Freeze the decisions.** List what was done in those iterations «by hand»:
sources (files/links), tools, pipeline steps, what was corrected and why.
3. **Write the skill.** Create the dir `skills/<name>/`, follow the section
template, keep it within ~2 minutes of reading. Copy checklists and specific
paths/commands into the steps, don't write «make it beautiful».
4. **Register.** Add an entry to `skills/README.md` (or the index file if there
is one): name + description. If there is no index — create it with the same file.
5. **Combat test run.** Take the nearest live task of that same kind and go
through the skill as if reading it for the first time:
- the executor agent (or you) opens only SKILL.md (without conversation memory);
- walk through the steps → get the result;
- fix everything that had to be «remembered from memory» — write it into the
skill right away.
6. **Done when** see the final checklist
## Quality criteria
- [ ] Directory `skills/<name>/SKILL.md` exists, frontmatter has `name` and `description`
- [ ] All 6 template sections: Trigger rule, Steps, Quality criteria, Common mistakes, Done when
- [ ] Quality criteria are verifiable (they name a verification method, not a mood)
- [ ] The skill mentions specific paths/templates/tools — not abstract words
- [ ] Entry in `skills/README.md` (or an existing one updated)
- [ ] Combat test run: applied to a live task; changes if something was missing — noted in the history
## Common mistakes
- Writing a skill «for show», in the form of a memo: no concrete steps/criteria
— future agent can't repeat it.
- Quality criteria without a verification method: «the design is good» — not a criterion.
- Registering without a combat test run: SKILL.md untested on a live task can
break on the first real one.
- Inflating SKILL.md with conversation history («Alex wanted it that way»),
instead of decisions: the executor doesn't need history, they need the how.
- Several skills from one repetition: first «catch» the repetition, don't invent
skills for one-off work.
## Done when
- [ ] Skill file in the repo (skills/<name>/SKILL.md), registered in the index
- [ ] Combat test run completed on a live task of that same kind
- [ ] Closed in the task format (task id + artifact path) in the tick summary
## Related skills
- `presale-landing` — production of presale/product landings (first skill from the factory).

View file

@ -0,0 +1,88 @@
---
name: presale-landing
description: Use when making or reworking a presale/product landing (Simbiot, coop products): structure, sections, honest product mockups, Stripe CTA. Ensures a selling page with a distinct non-AI-look and provable quality instead of a generic template.
metadata:
origin: t-261002151630-84bd7f (Лэндос Simbiot), first skill born via meta-skill-factory
scope: Simbiot presale/product pages; adapted per product
---
# Presale landing: from content to a selling page
## Trigger rule
- [ ] Task: make a landing / rework a presale / a v2 version of a page exists
- [ ] There is an offer (or it's given by the task setting)
- [ ] Payment provider link (Stripe or similar) is available, or it's known that
a placeholder link is temporarily put with a P0 remark
## Steps
### 1. Sources
Gather before the layout: base page (`docs/simbiot_presale_landing.html`), the current
site (simbiot.cil.by), pricing directive (`docs/PRICE-DIRECTIVE-SIMBIOT.md`), the sales
plan (`docs/SALES-PLAN-PRESALE-PAGE.md`), packaging (`docs/PACKAGE-SIMBIOT-PRESALE.md`),
live Telegram threads (sales/presale) — don't rewrite the texts from scratch if
they already exist.
### 2. Locked structure
Mandatory sections in this order (each — a specific promise to the visitor):
1. **Hero** — one specific offer (who it's for + result + form of delivery). H1 ≤ 10
words, under it 1 sentence + CTA button.
2. **«Что это»** — 2–3 blocks «problem → mechanism → outcome».
3. **«Что включено»** — a specific list (Stripe-equipping, AI inference, agents in
the product, hosting, etc. — taken from «Что включено», not «a suite of possibilities»).
4. **«Как это работает»** — 3 steps from the visitor's side.
5. **Visuals of the product** — honest mockups: real UI, real TG-dialog. No
«sleek abstract renders» — each mockup is labeled and recognizable.
6. **Social proof** — who did it, statuses, numbers (only confirmed items; nothing invented).
7. **Tariff plans** — 2–3 plans, the price and limits from the pricing directive,
a CTA per plan.
8. **Final CTA** — the same Stripe-link.
9. Footer: who makes it, contacts, legal minimum.
### 3. Visual language (per ui-skills frontend-design)
- One accent color per page, a calm scale of backgrounds, no «rainbow» gradients.
- Typography: a distinct heading font (not «default Inter in default weight»),
font sizes: 1 H1 / page, h2 2× smaller, body 1×.
- Layout grids: max-width ~1100px, alternating bands (light / dark / light) give
the page a rhythm; on mobile — a single column, no horizontal scroll.
- Motion: 1–2 animations with meaning (the appearance of blocks in the viewport,
a smooth hover on CTA), no decorative bounces. `prefers-reduced-motion` — mandatory.
- Not-AI-look: don't use a standard set of icons, no «emoji-steps», real numbers
instead of adjectives ("2494 у.е." not "недорогой").
### 4. Quality gates (mandatory checks before handing the result)
- [ ] CTA is clicked (the Stripe-link is alive — no 404; the opening checked).
- [ ] Places counter and other numbers are up-to-date (if a live billing — from
the API/billing, not hardcoded).
- [ ] No «lorem ipsum» or unfinished blocks.
- [ ] Lighthouse (or equivalent): Performance ≥ 70 / Accessibility ≥ 90.
- [ ] The layout doesn't break on 375px width and 1440px (screenshot or resize).
- [ ] Each section answers: "What do I, the visitor, do with this?" — if there's no
reply to a section, it gets removed or merged into another one.
- [ ] `prefers-reduced-motion` handled, animations not «forever».
## Common mistakes
- «Vague» hero (an offer without a number/verb) — the visitor leaves without scrolling.
- A fake count, hardcoded «10 мест» — kills trust (P1 t-...08ba09).
- AI-look: a standard set of icons, emoji-steps, gradients «to make it pretty».
- Sections without a promise («Our advantages» with 4 cards of platitudes) — merge or remove.
- Visuals «not from the product» — renders unrelated to the real UI.
## Done when
- [ ] Page lives on the URL/hosting (or in the repo under docs/site/).
- [ ] Quality gates are passed and recorded in the task report.
- [ ] The CTA leads to a living Stripe-link (or a P0-remark is left).
- [ ] A v2 version of the page is in the repo history (or the diff is in the commit).
## Related skills
- `meta-skill-factory` — how skills like this are born (don't produce single-use ones).
- `improve-ui` / `improve-animations` (ui-skills) — audits of the ready page.