@syntesseraai/opencode-feature-factory 0.4.0 → 0.4.2
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/agents/building.md +29 -3
- package/agents/ff-acceptance.md +7 -0
- package/agents/ff-research.md +7 -0
- package/agents/ff-review.md +7 -0
- package/agents/ff-security.md +7 -0
- package/agents/ff-validate.md +7 -0
- package/agents/ff-well-architected.md +7 -0
- package/agents/planning.md +7 -0
- package/agents/reviewing.md +7 -0
- package/bin/ff-deploy.js +3 -1
- package/package.json +1 -1
- package/skills/ff-learning/SKILL.md +68 -0
package/agents/building.md
CHANGED
|
@@ -68,9 +68,27 @@ At the start of EVERY building task:
|
|
|
68
68
|
5. **Load the ff-delegation skill** and assess parallelization opportunities
|
|
69
69
|
6. **Load the ff-mini-plan skill** and create an execution plan
|
|
70
70
|
7. **Load the ff-todo-management skill** and create a todo list for tracking progress
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
71
|
+
8. **Load the ff-severity-classification skill** to assess risks of changes
|
|
72
|
+
9. **Document your context** - Use `ff-agents-update` tool to create `.feature-factory/agents/building-{UUID}.md`
|
|
73
|
+
10. **Check for existing plans** - Use `ff-plans-list` and `ff-plans-get` to find implementation plans
|
|
74
|
+
|
|
75
|
+
## Git Worktrees (Mandatory)
|
|
76
|
+
|
|
77
|
+
To prevent conflicts and ensure a clean state, you MUST use git worktrees for your implementation:
|
|
78
|
+
|
|
79
|
+
1. **Create Worktree:** Before starting code modifications, create a dedicated worktree outside the main directory:
|
|
80
|
+
```bash
|
|
81
|
+
git worktree add ../ff-build-{UUID} -b feature/ff-build-{UUID}
|
|
82
|
+
```
|
|
83
|
+
2. **Use the Worktree:**
|
|
84
|
+
- When using the `bash` tool, always set the `workdir` parameter to the absolute path of your worktree.
|
|
85
|
+
- When using `edit`, `write`, or `read` tools, ensure the `filePath` points to the files inside your worktree (e.g., replace the base project path with the path to your worktree).
|
|
86
|
+
3. **Commit & Push:** Commit your changes and push the branch from within the worktree.
|
|
87
|
+
4. **Cleanup:** After your work is pushed, remove the worktree:
|
|
88
|
+
```bash
|
|
89
|
+
git worktree remove ../ff-build-{UUID} --force
|
|
90
|
+
git branch -D feature/ff-build-{UUID}
|
|
91
|
+
```
|
|
74
92
|
|
|
75
93
|
## File Management Tools
|
|
76
94
|
|
|
@@ -450,3 +468,11 @@ When @reviewing agent returns findings:
|
|
|
450
468
|
```
|
|
451
469
|
|
|
452
470
|
Create todos for each critical/high item, fix them, then re-invoke @reviewing if needed.
|
|
471
|
+
|
|
472
|
+
## Knowledge Management
|
|
473
|
+
|
|
474
|
+
**Always be learning:**
|
|
475
|
+
|
|
476
|
+
- Use `docs/learnings/` to store findings, decisions, and patterns.
|
|
477
|
+
- Search `docs/learnings/` before debugging complex issues.
|
|
478
|
+
- Load the `ff-learning` skill for details on how to write good learning docs.
|
package/agents/ff-acceptance.md
CHANGED
|
@@ -276,3 +276,10 @@ Use ff-severity-classification skill standards:
|
|
|
276
276
|
11. Mark all todos complete before finishing
|
|
277
277
|
|
|
278
278
|
Remember: Your role is to be the "gatekeeper" ensuring requirements are fully and correctly implemented before proceeding.
|
|
279
|
+
|
|
280
|
+
## Knowledge Management
|
|
281
|
+
|
|
282
|
+
**Always be learning:**
|
|
283
|
+
- Use `docs/learnings/` to store findings, decisions, and patterns.
|
|
284
|
+
- Search `docs/learnings/` before debugging complex issues.
|
|
285
|
+
- Load the `ff-learning` skill for details on how to write good learning docs.
|
package/agents/ff-research.md
CHANGED
|
@@ -421,3 +421,10 @@ Structure research findings using ff-report-templates:
|
|
|
421
421
|
- **Stay current** - Technology changes rapidly, verify dates
|
|
422
422
|
|
|
423
423
|
Remember: Your research enables other agents to make informed implementation decisions. Be thorough, current, and precise.
|
|
424
|
+
|
|
425
|
+
## Knowledge Management
|
|
426
|
+
|
|
427
|
+
**Always be learning:**
|
|
428
|
+
- Use `docs/learnings/` to store findings, decisions, and patterns.
|
|
429
|
+
- Search `docs/learnings/` before debugging complex issues.
|
|
430
|
+
- Load the `ff-learning` skill for details on how to write good learning docs.
|
package/agents/ff-review.md
CHANGED
|
@@ -279,3 +279,10 @@ Use ff-severity-classification skill standards:
|
|
|
279
279
|
10. **CRITICAL: Clean up** - `ff-agents-clear()` to remove your context file
|
|
280
280
|
11. Mark all todos complete before finishing
|
|
281
281
|
12. Recommend delegating to other agents if specialized issues found
|
|
282
|
+
|
|
283
|
+
## Knowledge Management
|
|
284
|
+
|
|
285
|
+
**Always be learning:**
|
|
286
|
+
- Use `docs/learnings/` to store findings, decisions, and patterns.
|
|
287
|
+
- Search `docs/learnings/` before debugging complex issues.
|
|
288
|
+
- Load the `ff-learning` skill for details on how to write good learning docs.
|
package/agents/ff-security.md
CHANGED
|
@@ -313,3 +313,10 @@ Use ff-severity-classification skill standards with security-specific definition
|
|
|
313
313
|
10. **CRITICAL: Clean up** - `ff-agents-clear()` to remove your context file
|
|
314
314
|
11. Mark all todos complete before finishing
|
|
315
315
|
12. Recommend delegating to other agents if additional issues found
|
|
316
|
+
|
|
317
|
+
## Knowledge Management
|
|
318
|
+
|
|
319
|
+
**Always be learning:**
|
|
320
|
+
- Use `docs/learnings/` to store findings, decisions, and patterns.
|
|
321
|
+
- Search `docs/learnings/` before debugging complex issues.
|
|
322
|
+
- Load the `ff-learning` skill for details on how to write good learning docs.
|
package/agents/ff-validate.md
CHANGED
|
@@ -307,3 +307,10 @@ When multiple agents report findings:
|
|
|
307
307
|
- **Provide actionable feedback** - Every issue should have a clear fix
|
|
308
308
|
- **Include metrics** - Quantify the validation results where possible
|
|
309
309
|
- **Consider context** - Weight findings based on the scope of changes
|
|
310
|
+
|
|
311
|
+
## Knowledge Management
|
|
312
|
+
|
|
313
|
+
**Always be learning:**
|
|
314
|
+
- Use `docs/learnings/` to store findings, decisions, and patterns.
|
|
315
|
+
- Search `docs/learnings/` before debugging complex issues.
|
|
316
|
+
- Load the `ff-learning` skill for details on how to write good learning docs.
|
|
@@ -275,3 +275,10 @@ Use ff-severity-classification skill standards:
|
|
|
275
275
|
12. Invoke other agents if specialized issues found
|
|
276
276
|
|
|
277
277
|
Focus on providing actionable, specific recommendations that improve the overall architecture quality across all six pillars.
|
|
278
|
+
|
|
279
|
+
## Knowledge Management
|
|
280
|
+
|
|
281
|
+
**Always be learning:**
|
|
282
|
+
- Use `docs/learnings/` to store findings, decisions, and patterns.
|
|
283
|
+
- Search `docs/learnings/` before debugging complex issues.
|
|
284
|
+
- Load the `ff-learning` skill for details on how to write good learning docs.
|
package/agents/planning.md
CHANGED
|
@@ -356,3 +356,10 @@ Recommend escalation to full architectural planning when:
|
|
|
356
356
|
- **Consider edge cases** - Plan for error scenarios
|
|
357
357
|
- **Include validation** - Specify how to verify the implementation
|
|
358
358
|
- **Escalate appropriately** - Don't try to fit complex work into simple plans
|
|
359
|
+
|
|
360
|
+
## Knowledge Management
|
|
361
|
+
|
|
362
|
+
**Always be learning:**
|
|
363
|
+
- Use `docs/learnings/` to store findings, decisions, and patterns.
|
|
364
|
+
- Search `docs/learnings/` before debugging complex issues.
|
|
365
|
+
- Load the `ff-learning` skill for details on how to write good learning docs.
|
package/agents/reviewing.md
CHANGED
|
@@ -480,3 +480,10 @@ Typical workflow:
|
|
|
480
480
|
8. Repeat until clean or only low-priority items remain
|
|
481
481
|
|
|
482
482
|
This creates a tight feedback loop for high-quality output.
|
|
483
|
+
|
|
484
|
+
## Knowledge Management
|
|
485
|
+
|
|
486
|
+
**Always be learning:**
|
|
487
|
+
- Use `docs/learnings/` to store findings, decisions, and patterns.
|
|
488
|
+
- Search `docs/learnings/` before debugging complex issues.
|
|
489
|
+
- Load the `ff-learning` skill for details on how to write good learning docs.
|
package/bin/ff-deploy.js
CHANGED
|
@@ -182,7 +182,9 @@ async function updateMCPConfig() {
|
|
|
182
182
|
|
|
183
183
|
async function deploy() {
|
|
184
184
|
if (isInteractive) {
|
|
185
|
-
|
|
185
|
+
const pkgContent = await fs.readFile(join(PACKAGE_ROOT, 'package.json'), 'utf8');
|
|
186
|
+
const pkgVersion = JSON.parse(pkgContent).version;
|
|
187
|
+
console.log(`🚀 Feature Factory OpenCode Plugin v${pkgVersion} - Deployment`);
|
|
186
188
|
console.log('================================================\n');
|
|
187
189
|
}
|
|
188
190
|
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"$schema": "https://json.schemastore.org/package.json",
|
|
3
3
|
"name": "@syntesseraai/opencode-feature-factory",
|
|
4
|
-
"version": "0.4.
|
|
4
|
+
"version": "0.4.2",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"description": "OpenCode plugin for Feature Factory agents - provides sub-agents and skills for validation, review, security, and architecture assessment",
|
|
7
7
|
"license": "MIT",
|
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
# Feature Factory Learning Protocol
|
|
2
|
+
|
|
3
|
+
This skill enables agents to continuously document and retrieve knowledge across the lifecycle of a task. It replaces the legacy "local-recall" MCP daemon with a lightweight, transparent Markdown-based system that lives directly in the repository's `docs/learnings/` folder.
|
|
4
|
+
|
|
5
|
+
## Core Philosophy
|
|
6
|
+
|
|
7
|
+
1. **Continuous Documentation:** Write down important facts, solutions, architectural decisions, and troubleshooting steps as soon as you verify them.
|
|
8
|
+
2. **Transparent Storage:** Learnings are stored as plain Markdown files in `docs/learnings/` so they are reviewable, searchable, and committable.
|
|
9
|
+
3. **Proactive Retrieval:** Before starting complex tasks or debugging, search the `docs/` and `docs/learnings/` directories to leverage past experience.
|
|
10
|
+
|
|
11
|
+
## How to Use This Skill
|
|
12
|
+
|
|
13
|
+
### 1. Documenting New Knowledge (Writing)
|
|
14
|
+
|
|
15
|
+
Whenever you discover a non-obvious solution, establish a new convention, or resolve a complex bug, create a learning document.
|
|
16
|
+
|
|
17
|
+
**Tool to use:** `write` tool to `docs/learnings/{topic-slug}.md`
|
|
18
|
+
|
|
19
|
+
**Naming Convention:**
|
|
20
|
+
Use descriptive, kebab-case filenames: `docs/learnings/auth-token-refresh-flow.md`, `docs/learnings/docker-build-caching.md`.
|
|
21
|
+
|
|
22
|
+
**Template:**
|
|
23
|
+
|
|
24
|
+
```markdown
|
|
25
|
+
# [Topic Title]
|
|
26
|
+
|
|
27
|
+
**Date:** [Current Date]
|
|
28
|
+
**Tags:** [comma, separated, tags]
|
|
29
|
+
|
|
30
|
+
## Context / Problem
|
|
31
|
+
|
|
32
|
+
[Briefly describe what you were trying to do or the problem you encountered.]
|
|
33
|
+
|
|
34
|
+
## Solution / Discovery
|
|
35
|
+
|
|
36
|
+
[Detail the exact solution, configuration, or architectural decision made.]
|
|
37
|
+
|
|
38
|
+
## Why this matters
|
|
39
|
+
|
|
40
|
+
[Explain why this approach was chosen or why the bug occurred.]
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
### 2. Retrieving Past Knowledge (Reading)
|
|
44
|
+
|
|
45
|
+
Before diving into debugging or implementing features, scan the `docs/` and `docs/learnings/` directories for relevant context.
|
|
46
|
+
|
|
47
|
+
**Tools to use:**
|
|
48
|
+
|
|
49
|
+
- `glob` tool with pattern `docs/learnings/*.md` to see all stored learnings.
|
|
50
|
+
- `grep` tool to search inside `docs/` and `docs/learnings/` for specific keywords (e.g., error messages, library names).
|
|
51
|
+
- `read` tool to pull the full context of relevant markdown files.
|
|
52
|
+
|
|
53
|
+
### 3. Updating Existing Knowledge (Refining)
|
|
54
|
+
|
|
55
|
+
If you find an existing learning document that is outdated or incomplete based on new work, use the `edit` tool to update it. Knowledge should evolve with the codebase.
|
|
56
|
+
|
|
57
|
+
## When to Document a Learning
|
|
58
|
+
|
|
59
|
+
- **Architectural Decisions:** Why a specific library, pattern, or approach was chosen over alternatives.
|
|
60
|
+
- **Environment Quirks:** Specific workarounds needed for local dev, testing, or deployment.
|
|
61
|
+
- **Complex Debugging:** A root cause analysis of a tricky bug and how it was fixed.
|
|
62
|
+
- **Undocumented Behaviors:** Workarounds for third-party API quirks or internal system edge cases.
|
|
63
|
+
|
|
64
|
+
## Checklist for Agents
|
|
65
|
+
|
|
66
|
+
- [ ] Have I encountered a novel problem or established a new pattern? -> **Document it.**
|
|
67
|
+
- [ ] Am I stuck on an error or unclear on a convention? -> **Search `docs/learnings/`.**
|
|
68
|
+
- [ ] Is an existing learning document inaccurate? -> **Update it.**
|