How Tacomancy projects are run, made installable.

The seven

Each one exists because a spec says what it does.

Each line below is the one its SKILL.md describes the skill with — what it does, then when it fires.

guidance-tiers Frozen and living documentation

Establish frozen and living documentation tiers in a repository — a never-edited reference directory, living docs (a vocabulary file, an architecture document, ADRs), a precedence rule in the guidance file, and a check script run in CI that fails when the rules are broken. Use when a project starts from a design document (a brief, a spec, a contract) that agents must treat as authoritative while the project's current understanding diverges from it on purpose.

pin-prototypes Brief-driven design, pinned exports

Draft and run the prompt set that takes a project's brief through an HTML-exporting design tool the human drives. Use when a project has a brief and is about to prompt a design tool for its surfaces, when a design session has degraded and needs splitting, or when a surface is about to be implemented from a pinned prototype — or has none.

adr-shape ADRs that name what they close

Write and review architecture decision records in one shape — a lead paragraph naming what the ADR closes, numbered decisions with their reasoning inline, a verdict on every considered option, consequences that separate better from worse and list what was deliberately left open, a status that is a condition when it needs to be, and corrections as dated updates. Ships the template, the shape as a checklist, and a lint for the mechanical parts. Use when an ADR is to be written from a resolved discussion, when a grill-me or grill-with-docs round closes with a decision to record, when an existing ADR is reviewed against the shape, when an accepted one is corrected or superseded, and whenever the question is whether a detail belongs in the ADR or the architecture document. Not for writing the architecture document itself, for ranking a list by reversibility alone (reversibility-rank), or for scaffolding an ADR directory (guidance-tiers).

reversibility-rank What would be hard to change

Close a round of recommendations with a ranked note of which ones would be hard to reverse — the sticky items first, each with one line on why and a two-line deep-dive, the trivial ones in a single line. Use when a round of recommendations or decisions is being closed — after grill-me or grill-with-docs, on an ADR's numbered decisions — on any such list the user pastes, and whenever they ask which of these would be hard to change, what's sticky here, or about reversibility.

hidden-verify A desktop app checked without a window

Run, screenshot, or verify a change in a desktop application without a window ever appearing — the project skill for launching the application, which run looks for first. An environment contract the shell reads at start makes a run render the window unseen, capture a PNG after a delay, quit, and keep every piece of non-project state in a scratch directory. Use when asked to run the application or confirm a change works in it, when a change needs proof for a PR, or when the application lacks the hook and is about to be verified beside a person.

land-ticket Merge, close, name the next frontier

Land a reviewed PR — gate on the check run for its current head, merge in the history's style, close the ticket and its parent on the last child, act on the guidance file's post-merge triggers, and report the frontier this merge unblocked. User-invoked only; an agent never lands a PR on its own.

bluesky-feature-pipeline Idea to landed tickets, eight stages

Carry a blue-sky feature from an idea to landed tickets through eight session-bounded stages — operating picture, brief, prototype, reconcile, beats, spec, ticket, land — each owned by one kind of session whose authority ends at a checkable point, with the state between stages held in the issue tracker. Chains guidance-tiers, reversibility-rank, pin-prototypes, and land-ticket from this set and a grill skill, to-spec, to-tickets, implement, tdd, and code-review from the vendored set, each named as a pointer with a fallback when it is absent, so a partial install still runs — whole or in parts. Its enforcement layer, three PR checks (ticket link, test touch, post-merge trigger), a label mover, and an install script, is what gates PRs in tacomancy/skills itself.

How the repository is kept

The rules it holds itself to.

• A spec before a skill. A skill exists because a GitHub issue labelled spec says what it does. Nothing is written without one.
• A check that fails on unknown input stays a failure. No warn-and-continue mode, no default value that lets the unknown through.
• Vendored skills are never edited. Extension goes through the new skill's own trigger, or one line in the adopting repository's guidance file.
• Tests ship separately. tests/ mirrors skills/, so an install carries no test code. Every script a skill ships is tested as its user would run it: exit code, output, files — never from inside.
• Nothing project-specific in the body. A Vitrine path or token appears only as an example labelled as one; the contract is stated generically first. Each SKILL.md ends with one Origin line naming the pattern it came from, so drift is visible later.

Where it stands

Shipped, and run on its own pipeline.

Seven specs are written and every one has landed; nothing is in tickets. The install line above works for all seven. The repository now runs on bluesky-feature-pipeline itself: its checks gate every PR there, and a PR that changes what this page should say is blocked until it links the issue that will change it.

The specs · the README · the repository.