Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

ship

Étoiles2

Forks0

Mis à jour14 juin 2026 à 15:57

Use when verified work is ready to land — turns it into a clean branch, commits, and a pull request whose body is drawn from the Spine (criteria, decisions, evidence). Refuses to ship work that hasn't passed verify. Reads the Spine; writes the shipped status back to it.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

AndrewTtofi

AndrewTtofi/spine

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	ship
description	Use when verified work is ready to land — turns it into a clean branch, commits, and a pull request whose body is drawn from the Spine (criteria, decisions, evidence). Refuses to ship work that hasn't passed verify. Reads the Spine; writes the shipped status back to it.

ship — land verified work

Shipping is a claim to the rest of the team: this is done, here's the proof, here's why. This skill assembles that claim from the Spine instead of from memory.

Steps

Read the Spine. Load journal.md (acceptance criteria + the latest verification result), conventions.md (test/build commands and any VCS or PR conventions), context.md (shared language), and decisions/ (ADRs to cite).
Gate on verify. Confirm every acceptance criterion is met with evidence in journal.md. If anything is unverified or failing, stop and run verify first — do not ship unproven work.
Prepare the branch. If you're on the default branch, create a feature branch first. Make sure the working tree is clean and the diff is only what this work intends to ship.
Commit hygiene. Group changes into clear, conventional commits with messages that explain why, following any pattern in conventions.md.
Bump the version if the change ships. If the diff touches the installable plugin surface — anything under skills/, or the plugin/marketplace manifests — bump the version so existing installs actually upgrade (an unchanged version makes /plugin upgrade a silent no-op). For this repo that means the same new version in all three places: root package.json, .claude-plugin/plugin.json, and the .claude-plugin/marketplace.json plugins[] entry. Use minor for a new skill or capability, patch for a fix to an existing skill; refresh the marketplace entry's description/keywords if the surface changed. CI's release-check enforces this on the PR, and the validator enforces that the three versions match — do it here so the gate is green. (Pure tooling-only changes — scripts/, .github/, .spine/, docs — need no bump.)
Compose the PR body from the Spine. Summary of what changed and why; the acceptance criteria as a ticked checklist; links to the ADRs that justify the approach; and the verification evidence (the real command output, not a claim). Name things using the Spine's shared language.
Push and open the PR against the base branch. Run the test/build commands from conventions.md one last time if CI won't.
Record in the Spine. Update journal.md: mark the work shipped, link the PR, and set Next step (await review / merge). Leave the merge to the user unless they ask you to land it.

Spine I/O

Reads: journal.md (criteria + verification result), conventions.md (commands, VCS/PR conventions), context.md (language), decisions/ (ADRs to cite).
Writes: journal.md (shipped status, PR link, next step).

Notes

Never ship work that verify hasn't passed — the PR body's evidence comes from a real run, not an assertion.
The PR body is a Spine read-out: criteria, decisions, evidence. If those are thin, the earlier phases were skipped — go back, don't paper over it.
Branch off the default branch; never commit straight to it.

Plus depuis ce dépôt

même dépôt

raise-debrief

AndrewTtofi/spine

Use right after a VC meeting to turn raw memory into a structured debrief — a signal read (interest vs. hesitation vs. pushback), the open diligence queue with draft answers, a send-ready follow-up email, and a clear recommended next step. Run within 24 hours; the follow-up email degrades fast. Use when asked to "debrief the meeting", "how did the pitch go", "write the follow-up email", or "what do I do after the meeting with <fund>".

2026-06-142

raise-report

AndrewTtofi/spine

Use to see the whole raise at a glance and to produce an investor-ready dossier — scans the .spine/raise/ namespace, builds a pipeline status tracker (every fund's scores, stage, and next action), and assembles a consolidated dossier suitable for sharing with an investor or advisor. Use when asked to "show the pipeline", "raise status", "track the funds", "what's stale", or "generate the investor report".

2026-06-142

raise-term

AndrewTtofi/spine

Use to analyse a VC term sheet — benchmarks every clause against current market norms, flags founder-unfriendly terms, scores founder-friendliness out of 100, and produces a ranked negotiation priority list with suggested pushback language. Informational only, not legal advice. Use when asked to "analyse this term sheet", "review the term sheet", "is this term sheet fair", or "what should I negotiate".

2026-06-142

raise-outreach

AndrewTtofi/spine

Use to turn a fund dossier into ready-to-send outreach — a cold email, a warm-intro request your contact can forward, and a LinkedIn DM, each built on the fund's own thesis language, plus a fund-specific one-pager. Refuses to draft for a no-go fund. Drafts only — it never sends. Use when asked to "draft outreach for <fund>", "write the intro email", "cold email this VC", or "make a one-pager for <fund>".

2026-06-142

raise-pitch

AndrewTtofi/spine

Use to prepare for pitching — full-spectrum prep in one skill. With no fund, it runs the stress-test: ten lethal questions a hostile VC would ask (know what to defend) and ten strongest signals a champion would champion (know what to lead with). With a fund, it builds a timed meeting plan with segment scripts, preemptive answers to that fund's diligence questions, and red-flag rebuttals. Use when asked to "prep me to pitch", "stress-test my pitch", "destroy my startup", "what are my strongest signals", or "prep for the meeting with <fund>".

2026-06-142

raise-funds

AndrewTtofi/spine

Use to research the VC landscape and build a ranked pipeline of funds to target — produces 15–20 funds in three tiers (pursue now, warm up first, monitor) with a fit rationale and a contact angle for each. Run before vetting and matching individual funds. Use when asked to "build a target list", "which VCs should we approach", "find funds for us", or "research the VC landscape".

2026-06-142

name	ship
description	Use when verified work is ready to land — turns it into a clean branch, commits, and a pull request whose body is drawn from the Spine (criteria, decisions, evidence). Refuses to ship work that hasn't passed verify. Reads the Spine; writes the shipped status back to it.

ship — land verified work

Shipping is a claim to the rest of the team: this is done, here's the proof, here's why. This skill assembles that claim from the Spine instead of from memory.

Steps

Read the Spine. Load journal.md (acceptance criteria + the latest verification result), conventions.md (test/build commands and any VCS or PR conventions), context.md (shared language), and decisions/ (ADRs to cite).
Gate on verify. Confirm every acceptance criterion is met with evidence in journal.md. If anything is unverified or failing, stop and run verify first — do not ship unproven work.
Prepare the branch. If you're on the default branch, create a feature branch first. Make sure the working tree is clean and the diff is only what this work intends to ship.
Commit hygiene. Group changes into clear, conventional commits with messages that explain why, following any pattern in conventions.md.
Bump the version if the change ships. If the diff touches the installable plugin surface — anything under skills/, or the plugin/marketplace manifests — bump the version so existing installs actually upgrade (an unchanged version makes /plugin upgrade a silent no-op). For this repo that means the same new version in all three places: root package.json, .claude-plugin/plugin.json, and the .claude-plugin/marketplace.json plugins[] entry. Use minor for a new skill or capability, patch for a fix to an existing skill; refresh the marketplace entry's description/keywords if the surface changed. CI's release-check enforces this on the PR, and the validator enforces that the three versions match — do it here so the gate is green. (Pure tooling-only changes — scripts/, .github/, .spine/, docs — need no bump.)
Compose the PR body from the Spine. Summary of what changed and why; the acceptance criteria as a ticked checklist; links to the ADRs that justify the approach; and the verification evidence (the real command output, not a claim). Name things using the Spine's shared language.
Push and open the PR against the base branch. Run the test/build commands from conventions.md one last time if CI won't.
Record in the Spine. Update journal.md: mark the work shipped, link the PR, and set Next step (await review / merge). Leave the merge to the user unless they ask you to land it.

Spine I/O

Reads: journal.md (criteria + verification result), conventions.md (commands, VCS/PR conventions), context.md (language), decisions/ (ADRs to cite).
Writes: journal.md (shipped status, PR link, next step).

Notes

Never ship work that verify hasn't passed — the PR body's evidence comes from a real run, not an assertion.
The PR body is a Spine read-out: criteria, decisions, evidence. If those are thin, the earlier phases were skipped — go back, don't paper over it.
Branch off the default branch; never commit straight to it.