git-publish
Offers to commit and push the project, behind two explicit confirmations.
the file it writes
This skill writes no partial: it acts on the project through git. Its contract is below.
What it reads, writes and refuses
The skill's own contract, from SKILL.md, in the original wording.
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).
Source: SKILL.md § Contract, at nerviz e4cae27.
What the guard does with it
ops is the skill's class. ArchHook opens a phase when the skill is called and checks every write against the class's territory. The text on the right is the hook's own.
Class ops has an empty territory: this skill writes no file. Its whole effect is git over Bash, which the guard does not cover; two confirmations are what gate it.
Where it sits on the rail
Each card is a step of /new-feature; the arrow carries the partial one step hands to the next. Dashed steps run only when the use case needs them.
/new-feature orchestrator · opus/new-feature-implement orchestrator · sonnet