git-publish
Oferece commit e push do projeto, atrás de duas confirmações explícitas.
o arquivo que ela escreve
Esta skill não escreve parcial: ela age no projeto por meio do git. O contrato dela está abaixo.
O que lê, escreve e recusa
O contrato da própria skill, do SKILL.md, no texto original.
Class
ops — the territory is skill_classes.ops in @.claude/schemas/extensions.json, and it is empty: this skill writes no file. Its whole effect is git over Bash, which the guard deliberately does not cover — a commit is not a file write, and the two confirmations below are what gate it. allowed-tools pre-approves only the local git subcommands and gh auth status; the remote step is left to permissions.ask (decision 0076).
Input (optional, from the invoking context or the typed argument)
a short description of what was just done — e.g. "initial scaffold, blueprint hexagonal, maven, features: rest,jpa" or "UC-001-order: order management feature". Used to build the commit message. No input → generic message from what git status shows.
The typed argument
/new-feature and /new-feature-implement end by printing /git-publish <message>[ — paths: <p…>][ — pre-existing: <p…>]. The message is everything before the first literal — paths: or — pre-existing:; each marker, when present, opens one of the two inputs below. Paths are space-separated.
Input (optional): paths to stage
When the invoking context or the typed argument names paths — /new-feature prints them for an approved spec not implemented yet (docs/use-cases/UC-NNN-<slug>/, docs/use-cases/BACKLOG.md) — gate 1 lists and stages only those paths. Anything else dirty in the tree stays unstaged and is named in the report.
Input (optional): pre-existing changes
— pre-existing: <paths> is the list the feature flow's guardrail took at the start of its run (IGNORED counts as an entry). It is the PRE_EXISTING_WORK list of step 1, handed over instead of rediscovered: a /git-publish typed after /clear has none of that run's context, so what the guardrail saw is what the line carries. Without the marker, step 1 discovers it from git status --porcelain as before.
Input (optional): project directory
When the invoking context names project: <absolute path> — project-initializer does, because it runs in a session opened somewhere else — that directory is the project. Run every command of this procedure as (cd "<path>" && git …), gh repo create included, so --source=. is the project and git init never lands in the session's own repository. Without it, the project is the session's directory.
Reads
git status, git remote -v, gh auth status. Nothing in the project files.
Writes
.git/ of the current project, and — only after the second confirmation — a new GitHub repository via gh repo create, or a push to a remote the user names. Never writes project source files.
Integration
- Invoked by project-initializer (agent) right after a green build, via the Skill tool, with a scaffold summary as context. - Typed by the user at the end of each of the two feature flows, after /clear, from the line the flow printed: after /new-feature approves a spec, with the approved spec's paths as the only paths to stage; after /new-feature-implement succeeds, with the UC name/summary as the message. Neither flow invokes it. - Invocable directly by the user (/git-publish, or by asking in plain language).
Fonte: SKILL.md § Contract, no nerviz e4cae27.
O que o guard faz com ela
ops é a classe da skill. O ArchHook abre uma fase quando a skill é chamada e confere cada escrita contra o território da classe. O texto à direita é o do próprio hook.
A classe ops tem território vazio: esta skill não escreve arquivo. Todo o efeito dela é git via Bash, que o guard não cobre; as duas confirmações é que a controlam.
Onde ela fica no trilho
Cada cartão é um passo do /new-feature; a seta leva o parcial que um passo entrega ao seguinte. Passos tracejados só rodam quando o caso de uso precisa.
/new-feature orchestrator · opus/new-feature-implement orchestrator · sonnet