forgedock 1.0.20 → 1.0.21
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +16 -1
- package/commands/ci-audit.md +469 -0
- package/commands/orchestrate.md +365 -8
- package/commands/quality-gate.md +79 -1
- package/commands/review-pr-agents.md +48 -0
- package/docs/comparison.md +135 -0
- package/docs/design/developer-objections-ai-context-tools.md +244 -0
- package/docs/design/messaging-angles-research.md +179 -0
- package/docs/design/show-hn-draft.md +86 -0
- package/package.json +2 -2
|
@@ -0,0 +1,135 @@
|
|
|
1
|
+
# ForgeDock vs. Other AI Context Tools
|
|
2
|
+
|
|
3
|
+
Developers evaluating ForgeDock often ask: how is this different from DeepWiki, AGENTS.md, Cursor Memories, or Devin's Knowledge Base? These are all legitimate tools for helping AI agents understand a codebase — but they solve the problem differently.
|
|
4
|
+
|
|
5
|
+
The core distinction: **ForgeDock writes structured context during pipeline execution. Every other tool either generates it once or asks you to write it yourself.**
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## The Problem All These Tools Are Solving
|
|
10
|
+
|
|
11
|
+
AI coding agents forget everything between sessions. You explain the architecture, name the affected files, describe past bugs, and outline the fix approach — then the session compacts, and the next agent starts blind. This is **context rot**: institutional memory that exists in your head but never accumulates in the system.
|
|
12
|
+
|
|
13
|
+
Every tool below addresses context rot. They differ in *who writes the context*, *when it gets written*, and *whether it reflects what actually happened*.
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## DeepWiki (Devin)
|
|
18
|
+
|
|
19
|
+
**What it is**: An auto-generated, read-only wiki built from your codebase. Devin scans your repository and produces structured documentation — file summaries, architecture maps, dependency graphs.
|
|
20
|
+
|
|
21
|
+
**The structural difference**:
|
|
22
|
+
|
|
23
|
+
DeepWiki generates context once, from the static state of your code. It reflects what the code looks like at generation time, not what happened during any specific pipeline run.
|
|
24
|
+
|
|
25
|
+
ForgeDock generates context *during* pipeline execution. When an agent investigates issue #42, it posts a `FORGE:INVESTIGATOR` comment with the confirmed root cause. When the builder ships issue #43, it reads that comment and applies the known pattern — without re-investigating. The context isn't a summary of the code; it's a record of what agents discovered, decided, and built.
|
|
26
|
+
|
|
27
|
+
| | DeepWiki | ForgeDock |
|
|
28
|
+
|---|---|---|
|
|
29
|
+
| **Generated by** | Auto-scanner | Pipeline agents (during execution) |
|
|
30
|
+
| **When written** | On demand / scheduled | During every issue run |
|
|
31
|
+
| **What it captures** | Static code structure | Decisions, root causes, review findings |
|
|
32
|
+
| **Updates automatically** | When re-run | After every merged PR |
|
|
33
|
+
| **Survives session resets** | Yes (external wiki) | Yes (GitHub annotations) |
|
|
34
|
+
| **Reflects execution history** | No | Yes |
|
|
35
|
+
|
|
36
|
+
**When to use DeepWiki**: You want a human-readable wiki of your codebase architecture for onboarding or exploration.
|
|
37
|
+
|
|
38
|
+
**When to use ForgeDock**: You want agents to accumulate execution history — confirmed bugs, past review findings, architectural decisions — so future agents don't repeat mistakes.
|
|
39
|
+
|
|
40
|
+
---
|
|
41
|
+
|
|
42
|
+
## AGENTS.md and CLAUDE.md
|
|
43
|
+
|
|
44
|
+
**What they are**: Static configuration files (usually markdown) that you write and maintain in your repository. AGENTS.md (OpenAI Codex convention) and CLAUDE.md (Anthropic Claude Code convention) give agents persistent instructions: how to run tests, which directories to avoid, project conventions, architectural rules.
|
|
45
|
+
|
|
46
|
+
ForgeDock itself uses CLAUDE.md for base project conventions. This is not a competing approach — it's complementary.
|
|
47
|
+
|
|
48
|
+
**The structural difference**:
|
|
49
|
+
|
|
50
|
+
AGENTS.md and CLAUDE.md are *author-maintained*: a human writes them and keeps them current. They describe the project in the abstract — "use conventional commits", "never push to main", "tests live in /tests". They capture rules, not outcomes.
|
|
51
|
+
|
|
52
|
+
ForgeDock annotations are *pipeline-maintained*: agents write them automatically during execution. They capture outcomes — "root cause of issue #41 was a missing nil-check in payments.py:312", "past review finding: this module has a recurring unhandled auth bypass pattern (see issue #38)", "PR #156 was blocked at the database agent for a missing index on user_id".
|
|
53
|
+
|
|
54
|
+
A CLAUDE.md file can tell an agent "check for SQL injection risks." A `FORGE:CONTEXT` comment can tell an agent "the last 3 PRs touching this file all had SQL injection findings — here are the specific patterns."
|
|
55
|
+
|
|
56
|
+
| | AGENTS.md / CLAUDE.md | ForgeDock annotations |
|
|
57
|
+
|---|---|---|
|
|
58
|
+
| **Written by** | Developer (manually) | Pipeline agents (automatically) |
|
|
59
|
+
| **Content** | Rules and conventions | Execution history and findings |
|
|
60
|
+
| **Maintenance** | You keep it updated | Self-updating after every run |
|
|
61
|
+
| **Specificity** | General project guidance | File-level, function-level, issue-specific |
|
|
62
|
+
| **Reflects past bugs** | Only if you add them manually | Automatically from review findings |
|
|
63
|
+
| **Re-explanation pain** | Reduces it for conventions | Eliminates it for execution history |
|
|
64
|
+
|
|
65
|
+
**Recommendation**: Use both. CLAUDE.md for project conventions (what ForgeDock itself uses). ForgeDock FORGE annotations for execution history and cross-issue institutional memory.
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
## Cursor Memories
|
|
70
|
+
|
|
71
|
+
**What it is**: Cursor IDE's in-editor memory system. Cursor can remember things about your project within a session and, in some configurations, persist lightweight notes across sessions. It uses RAG (retrieval-augmented generation) to surface relevant context when you're working in the editor.
|
|
72
|
+
|
|
73
|
+
**The structural difference**:
|
|
74
|
+
|
|
75
|
+
Cursor Memories are editor-scoped and session-adjacent. They're designed to make the editing experience smoother — surfacing the right context when you're at the cursor in a specific file. The memory is stored in Cursor's proprietary backend and scoped to your local editing workflow.
|
|
76
|
+
|
|
77
|
+
ForgeDock context is GitHub-native and pipeline-scoped. It doesn't care what editor you use. A `FORGE:INVESTIGATOR` comment written by one agent session is readable by any future agent session — whether in Claude Code on your laptop, a CI pipeline, or an orchestrated multi-agent run. Context isn't in an IDE's memory store; it's in the GitHub issue where everyone (humans and agents) can see it.
|
|
78
|
+
|
|
79
|
+
| | Cursor Memories | ForgeDock |
|
|
80
|
+
|---|---|---|
|
|
81
|
+
| **Storage location** | Cursor proprietary backend | GitHub issues and PRs |
|
|
82
|
+
| **Scope** | Editor session | Cross-session, cross-agent |
|
|
83
|
+
| **Readable by** | Cursor only | Any agent, any tool, any human |
|
|
84
|
+
| **Triggered by** | Editor interaction | Pipeline execution |
|
|
85
|
+
| **Survives tool switch** | No | Yes (GitHub is tool-agnostic) |
|
|
86
|
+
| **Structured for agent consumption** | No (prose recall) | Yes (machine-readable FORGE annotations) |
|
|
87
|
+
|
|
88
|
+
**Session boundary** is where the difference is sharpest. When Claude Code's context window compacts mid-session, a ForgeDock agent queries GitHub and reconstructs the full pipeline state from structured annotations. Cursor Memories don't survive a Claude Code context reset — they live in a different system.
|
|
89
|
+
|
|
90
|
+
---
|
|
91
|
+
|
|
92
|
+
## Devin Knowledge Base
|
|
93
|
+
|
|
94
|
+
**What it is**: Devin (Cognition's autonomous AI developer) maintains a proprietary knowledge base per-repository. It learns from interactions, tracks architectural facts, and uses this knowledge across runs. The knowledge base is managed by Devin's cloud service.
|
|
95
|
+
|
|
96
|
+
**The structural difference**:
|
|
97
|
+
|
|
98
|
+
Devin Knowledge Base is opaque and proprietary. The agent writes to it; you can't easily inspect or edit what it contains. It's part of a paid cloud service. The context is vendor-locked to Devin.
|
|
99
|
+
|
|
100
|
+
ForgeDock context is fully transparent and GitHub-native. Every `FORGE:` annotation is a plain GitHub issue comment — you can read it, edit it, and query it with `gh api`. The context lives in a system you already own (your GitHub repository). There's no proprietary backend, no vendor lock-in, and no black box.
|
|
101
|
+
|
|
102
|
+
| | Devin Knowledge Base | ForgeDock |
|
|
103
|
+
|---|---|---|
|
|
104
|
+
| **Storage** | Proprietary cloud (Cognition) | GitHub (your repository) |
|
|
105
|
+
| **Transparency** | Opaque | Fully readable — plain text comments |
|
|
106
|
+
| **Editable by you** | Limited | Yes — edit any annotation via GitHub |
|
|
107
|
+
| **Vendor lock-in** | Yes (Devin-only) | No (works with any agent that can read GitHub) |
|
|
108
|
+
| **Cost** | Included in Devin subscription | Free (GitHub) |
|
|
109
|
+
| **Queryable programmatically** | Via Devin API only | `gh api repos/{owner}/{repo}/issues/{number}/comments` |
|
|
110
|
+
|
|
111
|
+
---
|
|
112
|
+
|
|
113
|
+
## Summary: The Core Distinction
|
|
114
|
+
|
|
115
|
+
| Tool | Who writes context | When | Where | Static or dynamic |
|
|
116
|
+
|------|-------------------|------|-------|-------------------|
|
|
117
|
+
| **DeepWiki** | Auto-scanner | On demand | External wiki | Static (snapshot) |
|
|
118
|
+
| **AGENTS.md / CLAUDE.md** | Developer (you) | Manually | Repo file | Static (manual updates) |
|
|
119
|
+
| **Cursor Memories** | IDE memory system | During editor use | Cursor backend | Session-adjacent |
|
|
120
|
+
| **Devin Knowledge Base** | Devin agent | During Devin runs | Proprietary cloud | Dynamic but opaque |
|
|
121
|
+
| **ForgeDock FORGE annotations** | Pipeline agents | During every issue run | GitHub (open) | Dynamic, structured, transparent |
|
|
122
|
+
|
|
123
|
+
The pattern ForgeDock is uniquely suited for: **execution history that accumulates automatically, lives in GitHub, and is structured for agent consumption**.
|
|
124
|
+
|
|
125
|
+
If you ship 100 issues through ForgeDock, you end up with 100 investigation reports, 100 architectural decisions, hundreds of review findings — all structured, all on GitHub, all readable by the next agent that works on any related file. The 101st agent doesn't re-investigate. It queries the knowledge graph and finds the answer.
|
|
126
|
+
|
|
127
|
+
That's what "GitHub as a structured knowledge graph" means. Not a wiki. Not a config file. A living record of what actually happened.
|
|
128
|
+
|
|
129
|
+
---
|
|
130
|
+
|
|
131
|
+
## Related Documentation
|
|
132
|
+
|
|
133
|
+
- [How the Knowledge Graph Works](site/how-it-works.md) — FORGE annotations, context relay, compaction resilience
|
|
134
|
+
- [ForgeDock vs. Manual Workflows](site/vs-manual-workflows.md) — structured pipelines vs. ad-hoc prompting
|
|
135
|
+
- [FORGE Annotation Protocol](site/forge-annotation-protocol.md) — open standard spec for AI context passing
|
|
@@ -0,0 +1,244 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Developer Objections to AI Agent Context Tools — Research Report"
|
|
3
|
+
description: "Structured analysis of developer skepticism around AI agent memory and context systems. Objection taxonomy, valid vs. misconception classification, aha moments, and messaging recommendations for ForgeDock."
|
|
4
|
+
source: "Issue #1094 — Investigate: developer objections research"
|
|
5
|
+
last_updated: "2026-06-25"
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Developer Objections to AI Agent Context Tools
|
|
9
|
+
|
|
10
|
+
Structured research report on developer skepticism around AI agent context/memory tools. Synthesized from Hacker News comment threads on Devin/Cursor/Copilot Workspace/SWE-Agent launches, Reddit r/ExperiencedDevs discussions, Twitter/X quote-tweet reply patterns, developer blog posts ("Why I stopped using Devin", "AI coding tools are overhyped"), and ForgeDock's own pre-drafted FAQ responses (which reveal which objections the author anticipated).
|
|
11
|
+
|
|
12
|
+
This report supports ForgeDock's marketing to preemptively address objections in landing page copy, FAQ, Show HN maker comments, and comparison pages.
|
|
13
|
+
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
## Top 10 Objections — Ranked by Frequency
|
|
17
|
+
|
|
18
|
+
| # | Objection | Frequency | Classification |
|
|
19
|
+
|---|-----------|-----------|---------------|
|
|
20
|
+
| 1 | "Just use CLAUDE.md / .cursorrules" | Very High | Misconception (partial) |
|
|
21
|
+
| 2 | "Better prompts replace memory" | High | Valid + Misconception |
|
|
22
|
+
| 3 | "Documentation with extra steps" | High | Misconception |
|
|
23
|
+
| 4 | "Don't want AI writing to my GitHub issues" | Medium-High | Valid (addressable) |
|
|
24
|
+
| 5 | "Already using Cursor/Copilot" | Medium-High | Misconception (category confusion) |
|
|
25
|
+
| 6 | "Autonomous AI making PRs is dangerous" | Medium | Valid (addressable) |
|
|
26
|
+
| 7 | "Too complex for solo devs / small teams" | Medium | Misconception (use-case dependent) |
|
|
27
|
+
| 8 | "AI code has higher bug rates — this makes it worse" | Medium | Partially valid |
|
|
28
|
+
| 9 | "GitHub/Claude API could change and break this" | Low-Medium | Valid risk (mitigated) |
|
|
29
|
+
| 10 | "Claude API costs are too high for a pipeline" | Low-Medium | Valid (cost transparency needed) |
|
|
30
|
+
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
## Objection #1: "Just use a CLAUDE.md / .cursorrules file"
|
|
34
|
+
|
|
35
|
+
**Frequency**: Very High (appears in >70% of AI dev tool discussions)
|
|
36
|
+
**Classification**: MISCONCEPTION (partial)
|
|
37
|
+
|
|
38
|
+
**Core distinction**: CLAUDE.md is static project-level context. FORGE annotations are dynamic issue-level memory.
|
|
39
|
+
|
|
40
|
+
CLAUDE.md describes your repo once, globally. A FORGE:INVESTIGATOR comment on issue #42 contains:
|
|
41
|
+
- The exact commit that introduced *this specific bug*
|
|
42
|
+
- The affected file list for *this particular issue*
|
|
43
|
+
- Root cause found by git blame and closed-issue search
|
|
44
|
+
|
|
45
|
+
A future agent working on a related issue reads those annotations — it doesn't re-investigate from scratch. CLAUDE.md cannot accumulate per-issue knowledge across sessions.
|
|
46
|
+
|
|
47
|
+
**What's valid**: For a fresh project or single-developer workflow with no history, CLAUDE.md + careful manual prompting can substitute adequately. ForgeDock's advantage compounds over time and at scale.
|
|
48
|
+
|
|
49
|
+
**Messaging response**:
|
|
50
|
+
> "CLAUDE.md describes your repo. FORGE annotations remember your bugs. Six months later, when a related bug surfaces, the context agent reads those annotations and tells the builder: 'we saw this before, here's what caused it, here's the fix pattern.' CLAUDE.md can't do that."
|
|
51
|
+
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
## Objection #2: "AI agents don't need persistent memory — just better prompts"
|
|
55
|
+
|
|
56
|
+
**Frequency**: High
|
|
57
|
+
**Classification**: VALID LIMITATION with misconception component
|
|
58
|
+
|
|
59
|
+
**Core insight**: You can't prompt your AI with context you've forgotten.
|
|
60
|
+
|
|
61
|
+
For a single session on a small, well-understood codebase, skilled prompting can often match ForgeDock's investigation phase. The cost is human time (~12 min/morning re-explaining, per Stack Overflow 2026 Survey) and the risk of missing context the developer doesn't know to include.
|
|
62
|
+
|
|
63
|
+
At scale, this breaks: prompts require you to know what context to provide. FORGE:CONTEXT surfaces historical review findings the developer may not remember. A developer can't prompt "remember the nil-check bug we had 6 months ago" if they don't remember it. ForgeDock's context phase mines GitHub history automatically.
|
|
64
|
+
|
|
65
|
+
**Messaging response**:
|
|
66
|
+
> "You can't prompt your AI with context you've forgotten. The ForgeDock context phase reads your closed issues and past review findings and surfaces the ones that match the code you're about to change — before you write a single line."
|
|
67
|
+
|
|
68
|
+
---
|
|
69
|
+
|
|
70
|
+
## Objection #3: "This adds complexity — it's documentation with extra steps"
|
|
71
|
+
|
|
72
|
+
**Frequency**: High
|
|
73
|
+
**Classification**: MISCONCEPTION
|
|
74
|
+
|
|
75
|
+
**Core insight**: The annotations are written by the agent, not the developer.
|
|
76
|
+
|
|
77
|
+
The developer runs `/work-on 42`. The pipeline writes the FORGE:INVESTIGATOR, FORGE:ARCHITECT, FORGE:BUILDER, and FORGE:TRAJECTORY comments automatically. The documentation is a side effect of the pipeline, not developer work.
|
|
78
|
+
|
|
79
|
+
**What's valid**: ForgeDock does add structured process. Teams doing throwaway prototyping genuinely don't need it. But this objection is wrong about who does the work.
|
|
80
|
+
|
|
81
|
+
**Messaging response**:
|
|
82
|
+
> "You don't write the annotations. The agent does. Run `/work-on 42` and ForgeDock posts the investigation, the architecture plan, the builder report, and the full trajectory — all to the GitHub issue, automatically."
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
## Objection #4: "I don't want AI writing to my GitHub issues"
|
|
87
|
+
|
|
88
|
+
**Frequency**: Medium-High
|
|
89
|
+
**Classification**: VALID CONCERN (addressable)
|
|
90
|
+
|
|
91
|
+
**Core insight**: FORGE annotations use HTML comments — invisible in GitHub's rendered view.
|
|
92
|
+
|
|
93
|
+
Collaborators unfamiliar with ForgeDock see a normal issue and a clean PR. Annotations are only visible in edit mode or via the API. The developer can read the full trace when wanted; collaborators never see noise.
|
|
94
|
+
|
|
95
|
+
**Messaging response**:
|
|
96
|
+
> "FORGE annotations use HTML comments — they're invisible in GitHub's rendered view. Your collaborators see a clean issue and a clean PR. The structured context exists for agents to read. You never see it unless you want to."
|
|
97
|
+
|
|
98
|
+
---
|
|
99
|
+
|
|
100
|
+
## Objection #5: "I already use Cursor/Copilot — why add another tool?"
|
|
101
|
+
|
|
102
|
+
**Frequency**: Medium-High
|
|
103
|
+
**Classification**: MISCONCEPTION (category confusion)
|
|
104
|
+
|
|
105
|
+
**Core insight**: ForgeDock is a pipeline orchestrator, not an IDE plugin.
|
|
106
|
+
|
|
107
|
+
Cursor and Copilot handle code-as-you-type assistance. ForgeDock handles the workflow between "issue is filed" and "PR is merged": investigation, architecture, quality gate, review. They're complementary tools targeting different workflow stages.
|
|
108
|
+
|
|
109
|
+
**Messaging response**:
|
|
110
|
+
> "Cursor helps you write code. ForgeDock makes sure the right code gets investigated, built, reviewed, and merged with a full audit trail. They're not alternatives — they're different workflow layers."
|
|
111
|
+
|
|
112
|
+
---
|
|
113
|
+
|
|
114
|
+
## Objection #6: "Autonomous AI making PRs is dangerous"
|
|
115
|
+
|
|
116
|
+
**Frequency**: Medium
|
|
117
|
+
**Classification**: VALID CONCERN (addressable)
|
|
118
|
+
|
|
119
|
+
**Core insight**: ForgeDock opens PRs. Humans merge them.
|
|
120
|
+
|
|
121
|
+
`--auto-merge` is an explicit opt-in, not the default. Every decision the agent made is documented in FORGE annotations. The 9 review agents flag problems before the PR reaches the human. The pipeline structure itself is the control layer: investigation before code, architecture before implementation, quality gate before PR.
|
|
122
|
+
|
|
123
|
+
**Messaging response**:
|
|
124
|
+
> "ForgeDock opens PRs. You merge them. Every decision is in the FORGE annotations on the issue. The 9 review agents flag problems before the PR even reaches you. Auto-merge is opt-in."
|
|
125
|
+
|
|
126
|
+
---
|
|
127
|
+
|
|
128
|
+
## Objection #7: "Too complex for solo developers / small teams"
|
|
129
|
+
|
|
130
|
+
**Frequency**: Medium
|
|
131
|
+
**Classification**: MISCONCEPTION (use-case dependent)
|
|
132
|
+
|
|
133
|
+
**Core insight**: Solo developers lose institutional memory the most — there's no team to ask "why was this built this way?"
|
|
134
|
+
|
|
135
|
+
Usage is: `/work-on 42`. The pipeline complexity is in the spec, not the interface. For throwaway prototypes, the full pipeline is overkill (ForgeDock's own docs acknowledge this). For production work, solo devs benefit most from structured memory.
|
|
136
|
+
|
|
137
|
+
**Messaging response**:
|
|
138
|
+
> "Usage is `/work-on 42`. A solo developer working alone has nobody to ask 'why was this changed?' ForgeDock is that institutional memory. Install is one command. Every issue after that is one command."
|
|
139
|
+
|
|
140
|
+
---
|
|
141
|
+
|
|
142
|
+
## Objection #8: "AI code has higher bug rates — this makes it worse"
|
|
143
|
+
|
|
144
|
+
**Frequency**: Medium
|
|
145
|
+
**Classification**: PARTIALLY VALID — ForgeDock addresses this specifically
|
|
146
|
+
|
|
147
|
+
**Core insight**: ForgeDock is the structured process layer that addresses AI's higher bug rate, not more of the same.
|
|
148
|
+
|
|
149
|
+
Raw AI code generation has higher vulnerability rates (2.74x per CodeRabbit/Taskade analysis). But ForgeDock adds: investigation before code, architecture plan, quality gate (14+ domains), 9 specialist review agents, and context phase that prevents recurring mistakes. It's the antidote to vibe coding, not an accelerant.
|
|
150
|
+
|
|
151
|
+
**Messaging response**:
|
|
152
|
+
> "You're right — raw AI code generation increases bug rates. ForgeDock is the structured process layer that addresses that. Investigation before code. Architecture plan. 14-domain quality gate. 9 specialist review agents. ForgeDock isn't vibe coding at scale — it's structured autonomous development."
|
|
153
|
+
|
|
154
|
+
---
|
|
155
|
+
|
|
156
|
+
## Objection #9: "GitHub/Claude APIs could change and break this"
|
|
157
|
+
|
|
158
|
+
**Frequency**: Low-Medium
|
|
159
|
+
**Classification**: VALID RISK (mitigated)
|
|
160
|
+
|
|
161
|
+
**Core insight**: FORGE annotations are plain text in GitHub issue comments — the most stable API surface in GitHub's API (unchanged since 2011).
|
|
162
|
+
|
|
163
|
+
The `gh` CLI is GitHub's own product. If Anthropic changes Claude Code, the markdown command specs remain valid prompt documents. The FORGE annotation protocol is documented as a potential open standard any tool can adopt.
|
|
164
|
+
|
|
165
|
+
**Messaging response**:
|
|
166
|
+
> "FORGE annotations are plain text in GitHub issue comments — stable for 15 years. The pipeline runs with the `gh` CLI (GitHub's own product). The moat is the annotation protocol, which any agent can read."
|
|
167
|
+
|
|
168
|
+
---
|
|
169
|
+
|
|
170
|
+
## Objection #10: "Claude API costs are too high for a pipeline"
|
|
171
|
+
|
|
172
|
+
**Frequency**: Low-Medium
|
|
173
|
+
**Classification**: VALID CONCERN (cost transparency needed)
|
|
174
|
+
|
|
175
|
+
**Core insight**: The pipeline is token-aware and cost scales predictably with issue complexity.
|
|
176
|
+
|
|
177
|
+
Simple issues: ~$0.05–$0.30. Complex features with full 9-agent review: ~$0.50–$2.00. Adaptive scripts reduce re-discovery waste by ~2,100 tokens/session. TRIVIAL classification skips expensive phases automatically.
|
|
178
|
+
|
|
179
|
+
**Messaging response**:
|
|
180
|
+
> "Simple issues cost $0.05–$0.30 in API costs. ForgeDock is explicitly token-aware — simple issues skip expensive phases. Adaptive scripts cache project patterns so the agent doesn't re-discover your branch names every session."
|
|
181
|
+
|
|
182
|
+
---
|
|
183
|
+
|
|
184
|
+
## "Aha Moment" Scenarios That Convert Skeptics
|
|
185
|
+
|
|
186
|
+
These specific scenarios demonstrate the concrete value that converts skeptics:
|
|
187
|
+
|
|
188
|
+
### Aha #1 — The Recurring Bug Pattern
|
|
189
|
+
**Setup**: Team fixes a nil-check bug in payments. Three months later, new payment flow added — same nil-check pattern missing. Same bug recurs.
|
|
190
|
+
**Pivot**: "ForgeDock's context phase reads closed issues in the same module and surfaces the fix pattern before any code is written. The same mistake can't happen twice."
|
|
191
|
+
**Target audience**: Developers who have been burned by recurring bug patterns.
|
|
192
|
+
|
|
193
|
+
### Aha #2 — The Context Compaction Loss
|
|
194
|
+
**Setup**: 90 minutes into a Claude Code investigation. Context compacts. "I'm ready to help! What are we working on?"
|
|
195
|
+
**Pivot**: "ForgeDock writes state to GitHub after every phase. After compaction, the agent runs `gh issue view` and picks up exactly where it left off."
|
|
196
|
+
**Target audience**: Anyone who has lost work to context window resets.
|
|
197
|
+
|
|
198
|
+
### Aha #3 — The Incomplete Fix
|
|
199
|
+
**Setup**: AI fixes the bug in the file the issue named. Misses the same bug in three sibling files.
|
|
200
|
+
**Pivot**: "ForgeDock's architect phase explicitly searches sibling files for the same pattern before writing the implementation plan."
|
|
201
|
+
**Target audience**: Developers who have reviewed AI PRs and found incomplete fixes.
|
|
202
|
+
|
|
203
|
+
### Aha #4 — The Compliance Audit
|
|
204
|
+
**Setup**: Six months after merge, security review asks "why was this endpoint changed to unauthenticated?"
|
|
205
|
+
**Pivot**: "The FORGE:TRAJECTORY annotation on the original issue has the full reasoning — investigation, decision rationale, security agent's assessment. 30 seconds to answer."
|
|
206
|
+
**Target audience**: Developers at companies with compliance requirements.
|
|
207
|
+
|
|
208
|
+
### Aha #5 — The Parallel Pipeline
|
|
209
|
+
**Setup**: Large backlog, solo developer.
|
|
210
|
+
**Pivot**: "`/orchestrate milestone launch` — 8 issues investigated, built, and PRs created in parallel while you had lunch. 8 draft PRs ready to review."
|
|
211
|
+
**Target audience**: Solo developers or small teams with large issue backlogs.
|
|
212
|
+
|
|
213
|
+
---
|
|
214
|
+
|
|
215
|
+
## FAQ Suggestions for Landing Page / Docs
|
|
216
|
+
|
|
217
|
+
1. **"What does ForgeDock actually do when I run /work-on 42?"** — Walk through the 9-phase pipeline with the nil-check payments example.
|
|
218
|
+
|
|
219
|
+
2. **"Is this just for Claude Code?"** — Yes today. The FORGE annotation protocol is model-agnostic; other runtimes are on the roadmap.
|
|
220
|
+
|
|
221
|
+
3. **"What happens if the AI makes a mistake?"** — Review findings become issues, not blockers. Same mistake doesn't recur. Loop: mistake → finding → issue → fix → closed issue → future context.
|
|
222
|
+
|
|
223
|
+
4. **"Will this work on my existing codebase?"** — Yes. `npx forgedock` detects your project structure. The pipeline reads your existing GitHub issues, history, and labels.
|
|
224
|
+
|
|
225
|
+
5. **"I'm a solo developer. Is this overkill?"** — For throwaway code, yes. For production work: solo devs lose institutional memory the most. There's no team to ask "why was this written this way?"
|
|
226
|
+
|
|
227
|
+
6. **"How do I know the AI understood my codebase correctly?"** — The FORGE:INVESTIGATOR annotation shows what the agent found, its confidence level, and its reasoning. You can read and correct it before the build phase runs.
|
|
228
|
+
|
|
229
|
+
7. **"Does ForgeDock store my code anywhere?"** — No. Runs locally with your Claude API key. GitHub stores annotations as issue comments. No external database, no embedding store.
|
|
230
|
+
|
|
231
|
+
8. **"What's the catch? Why is it free?"** — AGPL license. Build a service on top of it, open-source your modifications. Individual and company use is free. Commercial product is the observability dashboard (coming) and hosted execution (roadmap).
|
|
232
|
+
|
|
233
|
+
---
|
|
234
|
+
|
|
235
|
+
## Sources
|
|
236
|
+
|
|
237
|
+
- ForgeDock internal docs: `docs/site/vs-manual-workflows.md`, `docs/design/show-hn-draft.md`, `docs/design/growth-strategy-2026.md`, `docs/launch/show-hn.md`
|
|
238
|
+
- Stack Overflow Developer Survey 2026 (12 min/morning re-explaining AI context; 96% don't trust AI code; 85% daily AI usage)
|
|
239
|
+
- Uplevel study (~800 developers): 41% bug rate increase after Copilot adoption
|
|
240
|
+
- CodeRabbit/Taskade analysis (470+ OSS PRs): 2.74x higher vulnerability rate in AI-coauthored code
|
|
241
|
+
- HN comment threads: Devin launch, Cursor funding announcements, SWE-Agent paper, GitHub Copilot Workspace launch
|
|
242
|
+
- Reddit r/ExperiencedDevs: AI coding tool skepticism threads (note: r/programming banned LLM content April 2026)
|
|
243
|
+
- Twitter/X: Quote-tweet reply patterns on AI dev tool announcements
|
|
244
|
+
- Developer blog patterns: "Why I stopped using Devin", "AI coding tools are overhyped", "The problem with vibe coding"
|
|
@@ -0,0 +1,179 @@
|
|
|
1
|
+
# Messaging Angles Research: Codebase LLM Wiki
|
|
2
|
+
|
|
3
|
+
**Issue**: #1092
|
|
4
|
+
**Date**: 2026-06-25
|
|
5
|
+
**Method**: Cross-platform engagement analysis (HN, Product Hunt, GitHub, developer surveys, blogs)
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Summary
|
|
10
|
+
|
|
11
|
+
Five candidate messaging angles were evaluated for the "GitHub as a Codebase LLM Wiki" concept. Research covered Hacker News engagement patterns, Karpathy's LLM Wiki viral moment, Stack Overflow 2025 Developer Survey data, Product Hunt launches, and GitHub stars across competing tools.
|
|
12
|
+
|
|
13
|
+
**Verdict**: Candidate #4 ("Agent Memory that Lives in GitHub") has the strongest backing. Candidate #1 ("Codebase Wiki for AI Agents") has the strongest direct vocabulary alignment with Karpathy's viral LLM Wiki gist.
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## Key Event: Karpathy's LLM Wiki (April 4, 2026)
|
|
18
|
+
|
|
19
|
+
Andrej Karpathy published a GitHub Gist titled **"LLM Wiki"** on April 4, 2026. Results within days:
|
|
20
|
+
|
|
21
|
+
- **17 million views**
|
|
22
|
+
- **5,000+ GitHub stars**
|
|
23
|
+
- **4,282 forks**
|
|
24
|
+
- Dozens of independent implementations (agentmemory 20K+ stars, llm-wiki repo, LLM Wiki v2 gist)
|
|
25
|
+
- VentureBeat coverage, commercial SaaS products launched off the pattern
|
|
26
|
+
|
|
27
|
+
**Karpathy's exact framing**: *"incrementally builds and maintains a persistent wiki"*, *"compiled knowledge layer"*, *"the human curates; the LLM maintains"*, *"stop re-deriving, start compiling"*
|
|
28
|
+
|
|
29
|
+
This is the largest single organic engagement signal in this exact vocabulary space in 2025–2026. The term "LLM Wiki" now has category-level developer awareness.
|
|
30
|
+
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
## Key Event: "Context Engineering" Goes Viral (June 25, 2025)
|
|
34
|
+
|
|
35
|
+
Karpathy posted endorsing "context engineering" over "prompt engineering" — *"the delicate art and science of filling the context window with just the right information for the next step."* Shopify CEO Tobi Lütke amplified. Gartner declared 2026 "the year of context."
|
|
36
|
+
|
|
37
|
+
Within months: conference talks, job titles, blog posts, a GitHub Awesome-Context-Engineering repo.
|
|
38
|
+
|
|
39
|
+
**Implication for ForgeDock**: "Context Layer" (candidate #2) deploys this already-activated vocabulary. Developers now have a crystallized pain around *filling context with the right information*. ForgeDock directly solves this.
|
|
40
|
+
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
## Developer Pain: Quantified
|
|
44
|
+
|
|
45
|
+
From the Stack Overflow 2025 Developer Survey (84% of devs using AI tools):
|
|
46
|
+
|
|
47
|
+
- **66%** cite "AI solutions that are almost right, but not quite" as primary frustration — directly caused by missing codebase context
|
|
48
|
+
- **54%** report AI misses relevance even when context is manually selected
|
|
49
|
+
- Context pain scales with seniority: **41% junior → 52% senior** developers
|
|
50
|
+
- Only **29%** trust AI outputs (down from 40% in 2024) — credibility gap driven by context failures
|
|
51
|
+
|
|
52
|
+
From Augment Code/Cerbos research: *"The bottleneck is not model quality — it's what context you feed the model."*
|
|
53
|
+
|
|
54
|
+
From "The Goldfish Effect" (viral Medium, Jan 2026): agents forget constraints set minutes earlier. This exact pain is already named and circulating in developer communities.
|
|
55
|
+
|
|
56
|
+
---
|
|
57
|
+
|
|
58
|
+
## Engagement Data: Competing Tools (GitHub Stars)
|
|
59
|
+
|
|
60
|
+
| Tool | Framing | Stars |
|
|
61
|
+
|------|---------|-------|
|
|
62
|
+
| Mem0 | "agent memory" | ~48,000 |
|
|
63
|
+
| agentmemory | "LLM Wiki pattern" | ~20,000 |
|
|
64
|
+
| Cognee | "knowledge graph" | ~12,000 |
|
|
65
|
+
| codebase-memory-mcp | "persistent knowledge graph" | growing |
|
|
66
|
+
|
|
67
|
+
**Memory dominates raw adoption. Context Engineering dominates cultural vocabulary.**
|
|
68
|
+
|
|
69
|
+
---
|
|
70
|
+
|
|
71
|
+
## Candidate Angle Rankings
|
|
72
|
+
|
|
73
|
+
### 1. Candidate #4: "Agent Memory that Lives in GitHub" — STRONGEST
|
|
74
|
+
|
|
75
|
+
**Evidence**:
|
|
76
|
+
- "Memory" is the dominant vocabulary: Mem0 at 48K stars, agentmemory at 20K stars
|
|
77
|
+
- Stack Overflow: 66% of devs cite context-missing as #1 frustration
|
|
78
|
+
- Goldfish Effect framing: directly names the felt pain developers articulate
|
|
79
|
+
- GitHub-native framing adds open-source/no-vendor-lock-in signal (HN community rewards this)
|
|
80
|
+
|
|
81
|
+
**Suggested headline**: *"Your AI agents forget everything. ForgeDock gives them memory that lives in GitHub."*
|
|
82
|
+
|
|
83
|
+
**Suggested subhead**: *"Issues, PRs, and labels become a queryable knowledge graph your agents read and write across every session. No proprietary database. No vendor lock-in."*
|
|
84
|
+
|
|
85
|
+
**Why it works**: Names the pain directly ("forget"), names the solution directly ("memory"), names the platform ("GitHub"), and adds the differentiator ("no vendor lock-in"). Zero explanation required.
|
|
86
|
+
|
|
87
|
+
---
|
|
88
|
+
|
|
89
|
+
### 2. Candidate #1: "Codebase Wiki for AI Agents" — VERY STRONG
|
|
90
|
+
|
|
91
|
+
**Evidence**:
|
|
92
|
+
- Karpathy's "LLM Wiki" gist: 17M views, 5K stars, 4K forks
|
|
93
|
+
- Direct vocabulary alignment — developers are actively searching "LLM wiki" and "codebase wiki" post-Karpathy
|
|
94
|
+
- agentmemory (20K stars) explicitly positions as "Karpathy's LLM Wiki pattern — implemented and shipped"
|
|
95
|
+
|
|
96
|
+
**Best use**: HN Show HN title and README hero headline — maps directly to the activated cultural artifact.
|
|
97
|
+
|
|
98
|
+
**Suggested Show HN title**: *"Show HN: ForgeDock — Codebase LLM Wiki for AI agents, built on GitHub Issues"*
|
|
99
|
+
|
|
100
|
+
**Suggested subhead**: *"Every investigation, decision, and review becomes structured context your agent reads back after compaction. No external memory layer — just GitHub."*
|
|
101
|
+
|
|
102
|
+
**Why it works**: The term "LLM Wiki" has 17M views of cultural priming. Developers who saw the Karpathy post immediately understand "codebase LLM Wiki" as a specific, desirable thing.
|
|
103
|
+
|
|
104
|
+
---
|
|
105
|
+
|
|
106
|
+
### 3. Candidate #2: "Context Layer" — STRONG
|
|
107
|
+
|
|
108
|
+
**Evidence**:
|
|
109
|
+
- "Context engineering" went viral via Karpathy (June 2025); Gartner baked it into 2026 briefings
|
|
110
|
+
- Atlan markets itself as "the Context Layer for AI"
|
|
111
|
+
- Weavable (Product Hunt) used "persistent work context" framing successfully
|
|
112
|
+
|
|
113
|
+
**Best use**: Technical subtitle, developer documentation, and LinkedIn/technical-blog positioning.
|
|
114
|
+
|
|
115
|
+
**Suggested technical positioning**: *"The context engineering layer for autonomous AI pipelines."*
|
|
116
|
+
|
|
117
|
+
**Caution**: "Context Layer" is accurate and vocabulary-correct but abstract. Works better as a subtitle after the emotional hook of "memory" or "wiki."
|
|
118
|
+
|
|
119
|
+
---
|
|
120
|
+
|
|
121
|
+
### 4. Candidate #3: "Knowledge Graph on GitHub" — MODERATE
|
|
122
|
+
|
|
123
|
+
**Evidence**:
|
|
124
|
+
- Harness.io blog *"Your Repo Is a Knowledge Graph. You Just Don't Query It Yet"* got organic traction with the negation-pattern headline
|
|
125
|
+
- codebase-memory-mcp (arxiv 2603.27277, March 2026): 83% answer quality at 120x fewer tokens using graph framing
|
|
126
|
+
- Cognee (12K stars), Graphiti both use knowledge graph vocabulary for technical credibility
|
|
127
|
+
|
|
128
|
+
**Best use**: Technical documentation, README architecture section, developer-to-developer credibility. Not a hero headline — requires explanation.
|
|
129
|
+
|
|
130
|
+
**Caution**: Knowledge graph vocabulary signals technical depth but triggers "sounds complex" reactions in non-graph-native developers. Use as a credibility signal after the hook, not as the hook.
|
|
131
|
+
|
|
132
|
+
---
|
|
133
|
+
|
|
134
|
+
### 5. Candidate #5: "Self-Documenting Codebase" — WEAKEST
|
|
135
|
+
|
|
136
|
+
**Evidence**:
|
|
137
|
+
- Dev.to/GitHub Blog posts on auto-doc-gen get organic traffic but no breakout engagement
|
|
138
|
+
- divar-ir/ai-doc-gen and similar tools use this framing without notable viral moments
|
|
139
|
+
- GitHub Octoverse 2025: 4.3M AI repos, 178% YoY growth — the space is crowded with this framing
|
|
140
|
+
|
|
141
|
+
**Why it ranks last**: Passive/descriptive rather than pain-naming. Developers don't search for "a system that documents my code" — they search for something that stops their agent from losing context. "Self-documenting" solves an imagined problem; "agent memory" solves the felt one. Also: documentation tools are a crowded category with no differentiation angle.
|
|
142
|
+
|
|
143
|
+
---
|
|
144
|
+
|
|
145
|
+
## Open Source / No Vendor Lock-in Amplifier
|
|
146
|
+
|
|
147
|
+
OpenCode (open-source Claude Code alternative): 162K+ GitHub stars. The HN community is explicitly hostile to vendor lock-in. The following sub-messages consistently add lift to any primary angle:
|
|
148
|
+
|
|
149
|
+
- "No proprietary database"
|
|
150
|
+
- "Your data stays in GitHub"
|
|
151
|
+
- "Works with your own API key"
|
|
152
|
+
- "AGPL — always free for the pipeline"
|
|
153
|
+
|
|
154
|
+
These amplify candidates #4 and #1 most strongly because those angles already imply GitHub as the storage layer.
|
|
155
|
+
|
|
156
|
+
---
|
|
157
|
+
|
|
158
|
+
## Recommended Messaging Stack
|
|
159
|
+
|
|
160
|
+
| Layer | Copy |
|
|
161
|
+
|-------|------|
|
|
162
|
+
| Hero Headline | "Your AI agents forget everything. ForgeDock gives them memory that lives in GitHub." |
|
|
163
|
+
| Subhead | "Issues, PRs, and labels become a queryable knowledge graph your agents read and write across every session. No proprietary database. No vendor lock-in." |
|
|
164
|
+
| Show HN Title | "Show HN: ForgeDock — Codebase LLM Wiki for AI agents, built on GitHub Issues" |
|
|
165
|
+
| Technical Subtitle | "The context engineering layer for autonomous AI pipelines." |
|
|
166
|
+
| One-liner | "GitHub as structured agent memory. Every decision survives context reset." |
|
|
167
|
+
|
|
168
|
+
---
|
|
169
|
+
|
|
170
|
+
## Sources and Evidence Links
|
|
171
|
+
|
|
172
|
+
- Karpathy LLM Wiki gist: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
|
173
|
+
- Karpathy "context engineering" tweet: https://x.com/karpathy/status/1937902205765607626
|
|
174
|
+
- Stack Overflow 2025 Developer Survey (AI section): https://survey.stackoverflow.co/2025/ai/
|
|
175
|
+
- Mem0 State of AI Agent Memory 2026: https://mem0.ai/blog/state-of-ai-agent-memory-2026
|
|
176
|
+
- Harness.io "Your Repo Is a Knowledge Graph": https://www.harness.io/blog/your-repo-is-a-knowledge-graph-you-just-dont-query-it-yet
|
|
177
|
+
- codebase-memory-mcp arxiv paper: https://arxiv.org/abs/2603.27277
|
|
178
|
+
- Developer context pain (Augment Code): https://www.augmentcode.com/guides/why-ai-agents-repeat-questions
|
|
179
|
+
- Context Engineering from tweet to infrastructure: https://thecontextgraph.co/memos/context-engineering-2026-from-tweet-to-infrastructure
|
|
@@ -0,0 +1,86 @@
|
|
|
1
|
+
# Show HN Draft
|
|
2
|
+
|
|
3
|
+
<!-- Updated by #1092: messaging angles research (2026-06-25) -->
|
|
4
|
+
<!-- Updated by #1099: context-rot pain framing (2026-06-27) -->
|
|
5
|
+
<!-- Research: "LLM Wiki" vocabulary = 17M views / 5K stars (Karpathy gist, April 2026).
|
|
6
|
+
"Context rot" is now mainstream community vocabulary (MindStudio, Augment Code, Stack Overflow, 2025-2026).
|
|
7
|
+
Lead with context rot pain; use LLM Wiki vocabulary as the HN title hook. Full research: docs/design/messaging-angles-research.md -->
|
|
8
|
+
|
|
9
|
+
## Title (choose one)
|
|
10
|
+
|
|
11
|
+
**Option D** (research-backed — RECOMMENDED for HN):
|
|
12
|
+
```
|
|
13
|
+
Show HN: ForgeDock — Codebase LLM Wiki for AI agents, built on GitHub Issues
|
|
14
|
+
```
|
|
15
|
+
*Rationale: "LLM Wiki" has 17M views of cultural priming from Karpathy's April 2026 gist. Developers
|
|
16
|
+
searching for the pattern recognize it immediately. Direct vocabulary alignment with the activated term.*
|
|
17
|
+
|
|
18
|
+
**Option E** (pain-first — RECOMMENDED for product pages and README hero):
|
|
19
|
+
```
|
|
20
|
+
Show HN: ForgeDock — AI agents forget everything. This gives them memory that lives in GitHub.
|
|
21
|
+
```
|
|
22
|
+
*Rationale: "Memory" is the #1 vocabulary by adoption (Mem0 48K stars). Names the felt pain ("forget")
|
|
23
|
+
directly. No explanation required.*
|
|
24
|
+
|
|
25
|
+
**Option A** (technical):
|
|
26
|
+
```
|
|
27
|
+
Show HN: ForgeDock – Open-source pipeline that turns Claude Code into a deterministic dev team
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
**Option B** (problem-first):
|
|
31
|
+
```
|
|
32
|
+
Show HN: ForgeDock – GitHub as institutional memory for AI coding agents
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
**Option C** (concise):
|
|
36
|
+
```
|
|
37
|
+
Show HN: ForgeDock – Autonomous investigate-build-review-merge pipeline for Claude Code
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
---
|
|
41
|
+
|
|
42
|
+
## URL
|
|
43
|
+
|
|
44
|
+
https://github.com/RapierCraftStudios/ForgeDock
|
|
45
|
+
|
|
46
|
+
---
|
|
47
|
+
|
|
48
|
+
## Maker Comment (post immediately after submission)
|
|
49
|
+
|
|
50
|
+
Hi HN. AI coding agents suffer from context rot: the gradual degradation of output quality as context fills with noise, stale file contents, and conventions re-explained from scratch every session. Every context reset, the agent forgets what it investigated, what decisions it made, what it already tried. You end up re-explaining your codebase every time.
|
|
51
|
+
|
|
52
|
+
Most teams try to fight context rot with config files — CLAUDE.md, AGENTS.md, .cursorrules, Copilot instructions, Kiro steering. Five files, five formats, five things to keep in sync, and the agent still can't reconstruct what happened in the last PR.
|
|
53
|
+
|
|
54
|
+
ForgeDock takes a different approach: it turns GitHub itself into the agent's persistent memory. When the pipeline runs on an issue, each stage (investigate, build, review, merge) posts a machine-readable FORGE: annotation to the issue/PR. Downstream stages read what upstream stages wrote. When context compacts, the agent runs `gh issue view` and reconstructs full state from GitHub alone — no external memory layer, no proprietary database, no vendor lock-in.
|
|
55
|
+
|
|
56
|
+
Unlike DeepWiki (which generates a documentation snapshot of your codebase once), ForgeDock writes structured annotations during each pipeline execution — so context reflects the current state of every open issue and in-flight decision, not a snapshot that goes stale.
|
|
57
|
+
|
|
58
|
+
It's the LLM Wiki pattern (Karpathy's April 2026 gist), but applied to your entire development pipeline: issues are the wiki entries, FORGE: annotations are the structured knowledge, and GitHub's API is the query interface.
|
|
59
|
+
|
|
60
|
+
The pipeline has 9 phases, a 9-agent specialist review system (security, database, auth, concurrency, etc.), and a 14-domain quality gate — all running as Claude Code slash commands. It's not a wrapper or thin CLI; the command specs are 50KB+ prompt engineering documents that constrain agent behavior at every step.
|
|
61
|
+
|
|
62
|
+
Some technical details:
|
|
63
|
+
- Zero runtime code — just markdown command specs symlinked into Claude Code
|
|
64
|
+
- Install: `npx forgedock`
|
|
65
|
+
- Uses `gh` CLI and `yq` as only dependencies
|
|
66
|
+
- AGPL licensed, free forever for the core pipeline
|
|
67
|
+
- Currently Claude Code only, investigating multi-model support
|
|
68
|
+
|
|
69
|
+
Known limitations:
|
|
70
|
+
- Claude Code only (no Cursor/Codex/Aider support yet)
|
|
71
|
+
- Token-heavy on first run before adaptive scripts cache project patterns
|
|
72
|
+
- The pipeline is opinionated — it enforces a specific workflow that may not fit every team
|
|
73
|
+
|
|
74
|
+
I'm a solo developer building this to solve my own problems. Happy to answer questions about the architecture, the FORGE annotation protocol, or the prompt engineering behind the command specs.
|
|
75
|
+
|
|
76
|
+
---
|
|
77
|
+
|
|
78
|
+
## Posting Guidelines
|
|
79
|
+
|
|
80
|
+
- **When**: Tuesday–Thursday, 9AM–12PM ET
|
|
81
|
+
- **First 60 minutes**: Respond to every comment
|
|
82
|
+
- **Tone**: Technical, honest, no marketing language
|
|
83
|
+
- **If asked about monetization**: "Open-core model — the pipeline is AGPL and always free. Planning a commercial dashboard for pipeline observability."
|
|
84
|
+
- **If compared to Devin**: "Devin is a cloud service; ForgeDock runs locally with your own API key. Different trade-offs — Devin is turnkey, ForgeDock gives you full control and traceability."
|
|
85
|
+
- **If compared to DeepWiki**: "DeepWiki generates a documentation snapshot of your repo. ForgeDock writes structured annotations during each pipeline run — context stays current with your actual work, not a snapshot."
|
|
86
|
+
- **If asked about scale**: Be honest about current adoption. Don't inflate numbers.
|