forge-implement

Name: forge-implement
Author: mgratzer

16installs5forks

How to install forge-implement?

mgratzer/forge/forge-implement

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

Installs into the current project.

Summary

Implement a feature or fix from an Issue, plan file, or free-text description, following project standards. Use when the user wants to start working on an Issue, implement a feature, fix a bug, or build from a plan or roadmap.

Files · 1

View on GitHub

SKILL.md

1	# Implement
2
3	Implement a feature or fix following project standards.
4
5	## Input
6
7	Primary input: an Issue number/URL, a plan file path, or free-text description. Optional: `-- <additional context>` for execution guidance.
8
9	## Process
10
11	### Step 1: Understand the Work
12
13	Determine the input type and extract requirements. Detect the Issue tracker provider (see [CONTEXT.md](../../CONTEXT.md)).
14
15	- Issue — fetch using the project's Issue tracker (see [issue-operations](../_shared/issue-operations.md)). Parse title, requirements, acceptance criteria, labels, sub-issues, comments. Add labels if missing.
16	- Plan file — extract goals, requirements, constraints, acceptance criteria.
17	- Free-text — parse scope and constraints. Ask clarifying questions if underspecified.
18
19	Flag for user input if: vague criteria, `discovery` label, scope too large, or dependencies incomplete.
20
21	### Step 2: Plan Approach
22
23	Identify durable architectural decisions — data model, API contracts, and module boundaries that absorb change instead of exposing internals. Prefer interfaces that stay simpler than their implementations; avoid pass-through wrappers and shallow seams.
24
25	For complex work, delegate codebase research to a sub-agent for unbiased findings:
26
27	#### Research (delegate)
28
29	Write 3–7 factual questions about existing systems, patterns, and integration points. Delegate to a [forge-scout](roles/forge-scout.md) sub-agent that receives only the questions — not the issue. If no sub-agent support, read the role file and answer each question following its rules.
30
31	Inputs: Role: [forge-scout](roles/forge-scout.md), the research questions, codebase access.
32	Expected output: One factual answer per question, with file paths and code references.
33
34	If the runtime supports per-task model choice, prefer a cheap fast model for scout work — scouting is factual reconnaissance, not deep synthesis. Otherwise inherit the parent session model and keep the scout task narrow.
35
36	From the research, create a plan:
37	- Durable decisions
38	- Structure outline — vertical phases, each spanning all affected layers they need and ending with a verification step. Phase 1 proves the happy path end to end; later phases add one axis of complexity at a time.
39	- Files to create or modify
40	- Scope boundaries (what will NOT change)
41
42	Present the plan via AskUserQuestion. Get user confirmation before coding. In unattended mode: skip AskUserQuestion and proceed.
43
44	### Step 3: Create Feature Branch
45
46	```bash
47	git fetch origin
48	git checkout $(git symbolic-ref refs/remotes/origin/HEAD \| sed 's@^refs/remotes/origin/@@')
49	git pull
50	git checkout -b <type>/<issue-number>-<brief-description>
51	```
52
53	When working from a plan file or free-text (no issue number), use a descriptive slug: `<type>/<brief-description>`.
54
55	### Step 4: Implement
56
57	Read AGENTS.md first. Follow project conventions strictly.
58
59	Execute the work in vertical phases:
60	- Pre-flight before the first phase — validate only the checks that matter for this change: codegen, config placement, required env vars, external dependencies, and existing code patterns.
61	- Per phase — implement end to end across all needed layers, keep tests close to the behavior, and verify unfamiliar APIs before using them.
62	- Phase gate — before moving on, run relevant tests/checks, confirm no new lint/type failures, and commit one logical change.
63
64	### Step 5: Pattern Consistency Audit
65
66	If you changed a pattern (error handling, component structure, API convention), grep for every other file using the old pattern and update them too:
67
68	```bash
69	grep -rn "<pattern>" <search-root>/
70	```
71
72	Audit the pattern shape, not just a literal string. Choose the right search scope, re-grep after updating, and note any intentional exceptions in the PR.
73
74	### Step 6: Update Documentation
75
76	If behavior changed, update:
77	- `docs/*.md` — architecture, API, development guides
78	- `AGENTS.md` — if conventions or patterns changed
79	- Code comments — only where logic isn't self-evident
80
81	### Step 7: Final Quality Gate
82
83	Run all project quality checks (discover from AGENTS.md, project docs, or repository scripts):
84
85	- [ ] Lint — no violations
86	- [ ] Format — no violations
87	- [ ] Type check — no errors
88	- [ ] All tests pass
89	- [ ] Test coverage ≥ 90% for new/modified code — run the project's coverage tool. If coverage tooling is not configured, flag this to the user and offer to set it up.
90
91	Fix issues and commit fixes.
92
93	### Step 8: Push and Create PR
94
95	```bash
96	git push -u origin <branch-name>
97	```
98
99	Create PR with conventional commit title format. Lead the summary with why the change was needed — pull the motivation from the linked issue's problem statement; if no issu

People who liked this also viewed

6 picks

Type

forge-implement

16installs5forks

View on GitHub

How to install forge-implement?

mgratzer/forge/forge-implement

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Implement
2
3	Implement a feature or fix following project standards.
4
5	## Input
6
7	Primary input: an Issue number/URL, a plan file path, or free-text description. Optional: `-- <additional context>` for execution guidance.
8
9	## Process
10
11	### Step 1: Understand the Work
12
13	Determine the input type and extract requirements. Detect the Issue tracker provider (see [CONTEXT.md](../../CONTEXT.md)).
14
15	- Issue — fetch using the project's Issue tracker (see [issue-operations](../_shared/issue-operations.md)). Parse title, requirements, acceptance criteria, labels, sub-issues, comments. Add labels if missing.
16	- Plan file — extract goals, requirements, constraints, acceptance criteria.
17	- Free-text — parse scope and constraints. Ask clarifying questions if underspecified.
18
19	Flag for user input if: vague criteria, `discovery` label, scope too large, or dependencies incomplete.
20
21	### Step 2: Plan Approach
22
23	Identify durable architectural decisions — data model, API contracts, and module boundaries that absorb change instead of exposing internals. Prefer interfaces that stay simpler than their implementations; avoid pass-through wrappers and shallow seams.
24
25	For complex work, delegate codebase research to a sub-agent for unbiased findings:
26
27	#### Research (delegate)
28
29	Write 3–7 factual questions about existing systems, patterns, and integration points. Delegate to a [forge-scout](roles/forge-scout.md) sub-agent that receives only the questions — not the issue. If no sub-agent support, read the role file and answer each question following its rules.
30
31	Inputs: Role: [forge-scout](roles/forge-scout.md), the research questions, codebase access.
32	Expected output: One factual answer per question, with file paths and code references.
33
34	If the runtime supports per-task model choice, prefer a cheap fast model for scout work — scouting is factual reconnaissance, not deep synthesis. Otherwise inherit the parent session model and keep the scout task narrow.
35
36	From the research, create a plan:
37	- Durable decisions
38	- Structure outline — vertical phases, each spanning all affected layers they need and ending with a verification step. Phase 1 proves the happy path end to end; later phases add one axis of complexity at a time.
39	- Files to create or modify
40	- Scope boundaries (what will NOT change)
41
42	Present the plan via AskUserQuestion. Get user confirmation before coding. In unattended mode: skip AskUserQuestion and proceed.
43
44	### Step 3: Create Feature Branch
45
46	```bash
47	git fetch origin
48	git checkout $(git symbolic-ref refs/remotes/origin/HEAD \| sed 's@^refs/remotes/origin/@@')
49	git pull
50	git checkout -b <type>/<issue-number>-<brief-description>
51	```
52
53	When working from a plan file or free-text (no issue number), use a descriptive slug: `<type>/<brief-description>`.
54
55	### Step 4: Implement
56
57	Read AGENTS.md first. Follow project conventions strictly.
58
59	Execute the work in vertical phases:
60	- Pre-flight before the first phase — validate only the checks that matter for this change: codegen, config placement, required env vars, external dependencies, and existing code patterns.
61	- Per phase — implement end to end across all needed layers, keep tests close to the behavior, and verify unfamiliar APIs before using them.
62	- Phase gate — before moving on, run relevant tests/checks, confirm no new lint/type failures, and commit one logical change.
63
64	### Step 5: Pattern Consistency Audit
65
66	If you changed a pattern (error handling, component structure, API convention), grep for every other file using the old pattern and update them too:
67
68	```bash
69	grep -rn "<pattern>" <search-root>/
70	```
71
72	Audit the pattern shape, not just a literal string. Choose the right search scope, re-grep after updating, and note any intentional exceptions in the PR.
73
74	### Step 6: Update Documentation
75
76	If behavior changed, update:
77	- `docs/*.md` — architecture, API, development guides
78	- `AGENTS.md` — if conventions or patterns changed
79	- Code comments — only where logic isn't self-evident
80
81	### Step 7: Final Quality Gate
82
83	Run all project quality checks (discover from AGENTS.md, project docs, or repository scripts):
84
85	- [ ] Lint — no violations
86	- [ ] Format — no violations
87	- [ ] Type check — no errors
88	- [ ] All tests pass
89	- [ ] Test coverage ≥ 90% for new/modified code — run the project's coverage tool. If coverage tooling is not configured, flag this to the user and offer to set it up.
90
91	Fix issues and commit fixes.
92
93	### Step 8: Push and Create PR
94
95	```bash
96	git push -u origin <branch-name>
97	```
98
99	Create PR with conventional commit title format. Lead the summary with why the change was needed — pull the motivation from the linked issue's problem statement; if no issu

People who liked this also viewed

6 picks

Type