On this page
Agent skills
What a skill is, how to install one, and what each skill in the set does.
A skill is a reusable instruction (SKILL.md) that teaches an agent to work
with the product correctly: respect the hierarchy, keep the ticket as memory,
move statuses honestly. The agent receives it over MCP and follows it literally,
so the text is written for an agent rather than a person: it reads as a
regulation, not as a guide.
How to install
Skills are distributed two ways. Over MCP — through list_skills and
get_skill: an agent with server access fetches them itself, nothing to
download. Or as an archive from the "Skills" page in the app, if the agent works
from a local skills directory.
The set
The pages below are generated from the skill sources at build time rather than written separately: a copy would drift from what the agent actually receives over MCP. Skills are written in English — exactly as the agent gets them.
| Skill | Purpose |
|---|---|
| bootstrap-spec | Use when a Flownix project's spec is empty or stale and the repository already has code and docs — triggers on "bootstrap the spec", "the project has no spec", "synthesize the spec from the repo", "собери спеку", "опиши проект по репозиторию", or right after flownix-init connects to an existing codebase. Inventories manifests, docs, contracts and CI, synthesizes a sourced base spec, applies it as the project spec plus doc nodes bound to system components. Read flownix-basics first. |
| execute-task | Use when doing the actual work for a node tracked in Flownix — task, plan, feature or epic. Triggers on "execute AF-TASK-12", "work on this ticket", "take this task", "implement the plan", "возьми задачу", "выполни тикет", "сделай AF-TASK-12", or any request naming a node slug to be implemented. Drives status through in_progress → testing, logs [progress]/[decision] comments, keeps the component binding correct, and handles the strict spec-mode close gate. Read flownix-basics first. |
| flownix-basics | Read FIRST before any Flownix / AI-Flow work over MCP, and before any other flownix-* skill. Use when the request mentions Flownix, AI-Flow, a node slug (AF-TASK-12, ACME-FEAT-3), a ticket/задачу/тикет/эпик/фичу in the tracker, the .flownix config, system components, doc deltas or spec mode, or when any create_node / get_node / update_node_status / rag_query / list_components tool is about to be called. Covers the node hierarchy, status lifecycle, the .flownix file, the "ticket is your memory" discipline, mandatory component binding, semantic search (rag_), the harness subsystem (harness./work./council.) and the full MCP tool reference. |
| flownix-harness-moderator | Use when you hold the judge or moderator role in a running Flownix harness council and must turn the deliberation into a decision. Triggers on "you are the judge in run …", "synthesize the council's verdict", "issue the judgement", "ты судья в совете", "вынеси решение", or on being handed a run_id with role_key judge. Collects proposals, critiques and responses from the claimed work item and issues council.submit_judgement with selected proposals and a rationale. |
| flownix-harness-participant | Use when you have been assigned a role in a running Flownix harness — council, review board or debate — and must do your turn. Triggers on "you are the architect in run …", "participate in the council", "claim your work item", "ты участник совета", "возьми свою роль в прогоне", or on being handed a run_id plus a role_key. Drives the full participant lifecycle over work.* and council.*: discover work, claim it, submit a proposal with claims and evidence, cross-review peers, respond to critiques, vote, complete. |
| flownix-init | Use when there is no project context — no .flownix file, an unknown project, or a fresh repository — and before any other flownix-* skill can run. Triggers on "connect to Flownix", "set up the project", "which project is this", "подключи проект", "настрой Flownix", "создай проект", or when a Flownix tool fails because project_id is unknown. Discovers or creates the org and project, writes the .flownix config, then offers onboarding: strict spec mode, spec bootstrap, component map, harness. |
| flownix-rag-search | Use when you need to find something in a Flownix project by meaning rather than by slug or hierarchy — "has this been done before?", "what did we decide about X?", "find the ticket about …", "найди задачу про …", "что мы решили по …", "было ли это уже" — and before creating any node or guessing at prior work. Covers the read-only rag_query / rag_context / rag_status tools, when to prefer them over get_tree/list_nodes, filtering by kind and component, and how the automatic index sync behaves. Read flownix-basics first. |
| flownix-review | Use when a code review has to be run and recorded in Flownix — triggers on the /review command, "review the code", "review this branch", "create a review", "add a review iteration", "сделай ревью", "проверь код", "проревьюй ветку", optionally scoped to a node slug. Reviews the branch diff, creates a review or appends an iteration for the same branch, links it to the node and its system components. Read flownix-basics first. |
| flownix-write-spec | Use whenever you are about to record or change described behaviour in a Flownix project — writing a feature's spec, updating a doc node, or preparing the delta a task needs to close. Triggers on "write the spec", "update the spec", "propose a delta", "напиши спеку", "обнови спеку", "предложи дельту", and on any refusal mentioning propose_doc_delta, proposal_not_approved or spec format issues. Owns the OpenSpec format, validate_spec, propose_doc_delta and the human approval gate. Read flownix-basics first. |
| harness-blueprint | Use when a project needs a new multi-agent harness — a council, review board or debate — and no existing one fits. Triggers on "build a council", "set up a review board", "we need agents to deliberate on X", "собери совет", "нужен консилиум агентов", "сделай харнесс". Runs a short interview, derives the stack and architecture from the project spec and repo, then builds, validates and publishes the harness version via harness.* tools. Read flownix-basics first. |
| map-components | Use when a Flownix project has no system components yet, or has them and the accumulated work is still unlinked — triggers on "map the components", "what does this system consist of", "link the tasks to services", "what stack do we use", "what tasks touched the database", "разложи по компонентам", "опиши систему", "привяжи задачи к компонентам", "какие задачи по базе", "по какому стеку", or when list_components comes back empty while planning or executing. Inventories the repository AND its stack and infrastructure, creates one component per real part of the system with repo_path, then proposes links for existing nodes, docs and reviews in batches — never linking silently. Read flownix-basics first. |
| plan-feature | Use when a new feature, epic or body of work has to be planned and tracked in Flownix — triggers on "plan a feature", "decompose this", "break this into tasks", "создай план", "распланируй фичу", "разбей на задачи", "заведи эпик", or any request to turn an idea into tickets. Decomposes the request into the epic→feature→plan→task tree via create_node, writes the feature's spec doc, binds every node and doc to system components, and adds tags and dependencies. Read flownix-basics first. |
| review-work | Use when work in Flownix is finished and has to be verified before it closes — a node sits in testing, or the request is "review this task", "check the work", "close the ticket", "проверь задачу", "прими работу", "закрой тикет". Verifies the node against its acceptance criteria, records per-criterion findings as a [review] comment, routes it to done or back to regression, then writes the feature doc, binds it to components and cascades the parent statuses. Read flownix-basics first. |
| spec-first-change | Use when the project has spec_first on and a change has to be worked out before any task exists — triggers on "plan a feature", "decompose this", "разбей на задачи", "заведи фичу" in a spec-first project, on the refusal spec_first_not_approved, and whenever get_project_policy reports spec_first true. Owns the whole procedure from opening a change to cutting tasks from the accepted document: draft delta, iteration with the human, submit, stop, then decomposition. Read flownix-basics and flownix-write-spec first. |
| sync-skills | Use when local Claude Code skill files under ~/.claude/skills/ may lag the Flownix backend — triggers on "sync the skills", "update my skills", "pull the latest skills", "обнови скиллы", "синхронизируй скиллы", or when a skill references a tool or rule that does not match what the server serves. Compares MD5 hashes to detect changes without downloading content, pulls only the skills that differ, and deletes skills the backend has retired. |
| update-knowledge | Use when what a Flownix node says no longer matches reality, or a decision, trade-off or outcome must be recorded so future agents find it — triggers on "update the spec", "record this decision", "the ticket is out of date", "обнови спеку", "зафиксируй решение", "запиши итог". Brings node content in line with the implementation (via doc deltas under strict spec mode), captures the why as [decision]/[done] comments, and propagates to the other nodes carrying the same stale knowledge. Read flownix-basics first. |
A typical work cycle
- Describe the product intent (free text or a Markdown specification).
- Over MCP the agent decomposes the idea into epics, features, plans and tasks.
- Tasks are executed one at a time; every step is recorded in a comment, status and progress stay honest.
- A review checks the result against the acceptance criteria and assembles documentation with cross-references.
- Finished tasks are grouped into releases — the graph, docs and progress update themselves.