forge-ship

Name: forge-ship
Author: mgratzer

14installs5forks

How to install forge-ship?

mgratzer/forge/forge-ship

$npx -y skills add mgratzer/forge --skill forge-ship

Installs into the current project.

Summary

End-to-end implementation and self-review in a single invocation. Implements from an Issue, plan file, or free-text description, then runs a lean fresh-context review. Use when the user wants to implement and review without manual handoff between skills.

Files · 1

View on GitHub

SKILL.md

1	# Ship
2
3	Implement end to end — code it, review it, ship it. Implementation runs in the current session; tiny low-risk diffs review inline, otherwise review uses one fresh-context reviewer by default and deepens only when risk justifies it.
4
5	## Input
6
7	Same as `forge-implement`: Issue number/URL, plan file path, or free-text. Optional: `-- <additional context>`.
8
9	Unattended mode: `--unattended` skips plan approval and auto-triages findings by severity.
10
11	## Process
12
13	### Step 1: Implement
14
15	#### 1a. Understand
16
17	Determine input type (Issue number/URL, plan file, or free-text). For Issues, fetch via the project's Issue tracker (see [issue-operations](../_shared/issue-operations.md)). Parse requirements and acceptance criteria. Flag if underspecified.
18
19	#### 1b. Plan
20
21	For complex work, write 3–7 research questions and delegate to a sub-agent with the [forge-scout](../forge-implement/roles/forge-scout.md) role for unbiased codebase research. Prefer a cheap fast model for scout work.
22
23	From the research, create a plan: durable decisions, vertical phases (see [vertical-slicing](../_shared/vertical-slicing.md)), files to change, scope boundaries.
24
25	Present the plan via AskUserQuestion. In unattended mode: skip approval and proceed.
26
27	#### 1c. Branch
28
29	```bash
30	git fetch origin
31	git checkout $(git symbolic-ref refs/remotes/origin/HEAD \| sed 's@^refs/remotes/origin/@@')
32	git pull
33	git checkout -b <type>/<issue-number>-<brief-description>
34	```
35
36	When working from a plan file or free-text (no issue number), use `<type>/<brief-description>`.
37
38	#### 1d. Execute
39
40	Read AGENTS.md. Run pre-flight checks before the first phase (see [phase-execution](../forge-implement/references/phase-execution.md)). Implement in vertical phases — each phase spans all affected layers, includes tests, and ends with a commit. Run lint/types/tests at each phase gate.
41
42	After changing a pattern, grep for the old pattern across the appropriate scope and update all instances (see [pattern-audit](../forge-implement/references/pattern-audit.md)).
43
44	#### 1e. Update docs
45
46	Update `docs/*.md` and `AGENTS.md` if behavior or conventions changed.
47
48	#### 1f. Quality gate
49
50	- [ ] Lint — no violations
51	- [ ] Format — no violations
52	- [ ] Type check — no errors
53	- [ ] All tests pass
54	- [ ] Test coverage ≥ 90% for new/modified code
55
56	#### 1g. Push and create PR
57
58	Push branch, create PR with conventional commit title. Lead the summary with why the change was needed — pull the motivation from the linked issue's problem statement; if no issue is linked, derive it from the branch's commit history. Then briefly describe the approach taken. Include: changes list, test plan, quality checklist. Close the issue when one exists. Add a `> [!WARNING]` block for manual deployment steps.
59
60	Do not produce the implementation summary yet — the review will inform the final report.
61
62	### Step 2: Review (delegate)
63
64	Follow the [review-delegation](../_shared/review-delegation.md) process: collect the diff from the implementation, prefer one inline review pass for tiny low-risk diffs, otherwise use one fresh-context review pass by default, add a second pass only when risk justifies it, and aggregate findings. Fresh context eliminates self-review bias when delegated review is used — reviewers have no memory of implementation decisions.
65
66	### Step 3: Triage Findings
67
68	Use the aggregated findings from the review delegation.
69
70	In attended mode (default): present each finding to the user with a recommendation.
71
72	Bias hard toward fix now:
73	- Fix now — default for in-scope findings and small-to-moderate changes that still fit this PR → apply fix, commit
74	- Defer — only for larger changes that materially expand PR scope or are truly out of scope → create an Issue in the project's Issue tracker
75
76	In unattended mode: auto-triage using severity plus scope from the [review rubric](../_shared/review-rubric.md):
77
78	- P0–P2, if in scope and reasonably sized → fix now, commit
79	- P1–P2, if truly out of scope or materially larger than the current PR → defer, create an Issue in the project's Issue tracker
80	- P3 → ignore
81
82	For both modes, deferred items become Issues — see [issue-operations](../_shared/issue-operations.md) for provider-specific mechanics.
83
84	### Step 4: Summary
85
86	Report implementation and review results together.
87
88	## Output Format
89
90	```text
91	## Ship Summary
92
93	PR: #<number> — <title>
94	Branch: <branch-name>
95
96	### Implementation
97	- <N> commits, <M> files changed
98	- Tests: <added/modified/none>
99	- Docs: <updated/none>
100
101	### Review Findings
102	- Fixed in PR: <list or "none">
103	- Deferred: #<issue> — <title> (or "none")
104
105	### Quality Gates
106	- Lint: ✓/✗
107	- Types: ✓/✗
108	- Tests: ✓/✗
109	```

People who liked this also viewed

6 picks

Type

forge-ship

14installs5forks

View on GitHub

How to install forge-ship?

mgratzer/forge/forge-ship

$npx -y skills add mgratzer/forge --skill forge-ship

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Ship
2
3	Implement end to end — code it, review it, ship it. Implementation runs in the current session; tiny low-risk diffs review inline, otherwise review uses one fresh-context reviewer by default and deepens only when risk justifies it.
4
5	## Input
6
7	Same as `forge-implement`: Issue number/URL, plan file path, or free-text. Optional: `-- <additional context>`.
8
9	Unattended mode: `--unattended` skips plan approval and auto-triages findings by severity.
10
11	## Process
12
13	### Step 1: Implement
14
15	#### 1a. Understand
16
17	Determine input type (Issue number/URL, plan file, or free-text). For Issues, fetch via the project's Issue tracker (see [issue-operations](../_shared/issue-operations.md)). Parse requirements and acceptance criteria. Flag if underspecified.
18
19	#### 1b. Plan
20
21	For complex work, write 3–7 research questions and delegate to a sub-agent with the [forge-scout](../forge-implement/roles/forge-scout.md) role for unbiased codebase research. Prefer a cheap fast model for scout work.
22
23	From the research, create a plan: durable decisions, vertical phases (see [vertical-slicing](../_shared/vertical-slicing.md)), files to change, scope boundaries.
24
25	Present the plan via AskUserQuestion. In unattended mode: skip approval and proceed.
26
27	#### 1c. Branch
28
29	```bash
30	git fetch origin
31	git checkout $(git symbolic-ref refs/remotes/origin/HEAD \| sed 's@^refs/remotes/origin/@@')
32	git pull
33	git checkout -b <type>/<issue-number>-<brief-description>
34	```
35
36	When working from a plan file or free-text (no issue number), use `<type>/<brief-description>`.
37
38	#### 1d. Execute
39
40	Read AGENTS.md. Run pre-flight checks before the first phase (see [phase-execution](../forge-implement/references/phase-execution.md)). Implement in vertical phases — each phase spans all affected layers, includes tests, and ends with a commit. Run lint/types/tests at each phase gate.
41
42	After changing a pattern, grep for the old pattern across the appropriate scope and update all instances (see [pattern-audit](../forge-implement/references/pattern-audit.md)).
43
44	#### 1e. Update docs
45
46	Update `docs/*.md` and `AGENTS.md` if behavior or conventions changed.
47
48	#### 1f. Quality gate
49
50	- [ ] Lint — no violations
51	- [ ] Format — no violations
52	- [ ] Type check — no errors
53	- [ ] All tests pass
54	- [ ] Test coverage ≥ 90% for new/modified code
55
56	#### 1g. Push and create PR
57
58	Push branch, create PR with conventional commit title. Lead the summary with why the change was needed — pull the motivation from the linked issue's problem statement; if no issue is linked, derive it from the branch's commit history. Then briefly describe the approach taken. Include: changes list, test plan, quality checklist. Close the issue when one exists. Add a `> [!WARNING]` block for manual deployment steps.
59
60	Do not produce the implementation summary yet — the review will inform the final report.
61
62	### Step 2: Review (delegate)
63
64	Follow the [review-delegation](../_shared/review-delegation.md) process: collect the diff from the implementation, prefer one inline review pass for tiny low-risk diffs, otherwise use one fresh-context review pass by default, add a second pass only when risk justifies it, and aggregate findings. Fresh context eliminates self-review bias when delegated review is used — reviewers have no memory of implementation decisions.
65
66	### Step 3: Triage Findings
67
68	Use the aggregated findings from the review delegation.
69
70	In attended mode (default): present each finding to the user with a recommendation.
71
72	Bias hard toward fix now:
73	- Fix now — default for in-scope findings and small-to-moderate changes that still fit this PR → apply fix, commit
74	- Defer — only for larger changes that materially expand PR scope or are truly out of scope → create an Issue in the project's Issue tracker
75
76	In unattended mode: auto-triage using severity plus scope from the [review rubric](../_shared/review-rubric.md):
77
78	- P0–P2, if in scope and reasonably sized → fix now, commit
79	- P1–P2, if truly out of scope or materially larger than the current PR → defer, create an Issue in the project's Issue tracker
80	- P3 → ignore
81
82	For both modes, deferred items become Issues — see [issue-operations](../_shared/issue-operations.md) for provider-specific mechanics.
83
84	### Step 4: Summary
85
86	Report implementation and review results together.
87
88	## Output Format
89
90	```text
91	## Ship Summary
92
93	PR: #<number> — <title>
94	Branch: <branch-name>
95
96	### Implementation
97	- <N> commits, <M> files changed
98	- Tests: <added/modified/none>
99	- Docs: <updated/none>
100
101	### Review Findings
102	- Fixed in PR: <list or "none">
103	- Deferred: #<issue> — <title> (or "none")
104
105	### Quality Gates
106	- Lint: ✓/✗
107	- Types: ✓/✗
108	- Tests: ✓/✗
109	```

People who liked this also viewed

6 picks

Type