forgehive 0.7.3 → 0.7.4
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.
|
@@ -0,0 +1,69 @@
|
|
|
1
|
+
You are running a Design Party using ForgeHive.
|
|
2
|
+
|
|
3
|
+
## Design Party
|
|
4
|
+
|
|
5
|
+
**Agents:** Suki (Experience Designer), Viktor (Systems Architect)
|
|
6
|
+
|
|
7
|
+
**Mission:** UX design and technical architecture in parallel — align on what to build and how to build it before any code is written.
|
|
8
|
+
|
|
9
|
+
## Protocol
|
|
10
|
+
|
|
11
|
+
### Step 1: Launch the party
|
|
12
|
+
|
|
13
|
+
Run:
|
|
14
|
+
```bash
|
|
15
|
+
fh party run --set design
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
This spins up isolated worktrees for Suki and Viktor. Both work from the same brief in parallel.
|
|
19
|
+
|
|
20
|
+
### Step 2: Write the brief
|
|
21
|
+
|
|
22
|
+
Before the party starts, write a one-paragraph brief:
|
|
23
|
+
- What problem are we solving?
|
|
24
|
+
- Who is the user?
|
|
25
|
+
- What outcome do we want?
|
|
26
|
+
|
|
27
|
+
This brief is the shared input for both agents.
|
|
28
|
+
|
|
29
|
+
### Step 3: Parallel design work
|
|
30
|
+
|
|
31
|
+
**Suki** (Experience Designer) — in her worktree:
|
|
32
|
+
- Maps user journeys: what does the user want to accomplish?
|
|
33
|
+
- Designs interaction flows: what steps does the user take?
|
|
34
|
+
- Identifies friction points and moments of delight
|
|
35
|
+
- Produces: a user journey map and a list of UX requirements
|
|
36
|
+
- Empathy-first: designs with users, not for them
|
|
37
|
+
|
|
38
|
+
**Viktor** (Systems Architect) — in his worktree:
|
|
39
|
+
- Designs the system architecture for the feature
|
|
40
|
+
- Defines module boundaries, data models, and API contracts
|
|
41
|
+
- Identifies infrastructure requirements and integration points
|
|
42
|
+
- Flags technical constraints that will affect the UX
|
|
43
|
+
- Produces: an architecture diagram (text-based) and a list of technical constraints
|
|
44
|
+
|
|
45
|
+
### Step 4: Check status
|
|
46
|
+
|
|
47
|
+
After both agents complete:
|
|
48
|
+
```bash
|
|
49
|
+
fh party status
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
### Step 5: Alignment review
|
|
53
|
+
|
|
54
|
+
Present both outputs side by side:
|
|
55
|
+
|
|
56
|
+
1. **UX requirements** (Suki) — what the system must feel like
|
|
57
|
+
2. **Technical constraints** (Viktor) — what the system can and cannot do
|
|
58
|
+
3. **Conflicts** — where UX desires clash with technical reality
|
|
59
|
+
4. **Resolution** — agree on trade-offs before any implementation begins
|
|
60
|
+
|
|
61
|
+
Ask the user: **"Sind Suki und Viktor aligned? Soll ich mit der Implementierung beginnen?"**
|
|
62
|
+
|
|
63
|
+
Do NOT proceed to implementation until alignment is confirmed.
|
|
64
|
+
|
|
65
|
+
### Step 6: Cleanup
|
|
66
|
+
|
|
67
|
+
```bash
|
|
68
|
+
fh party cleanup
|
|
69
|
+
```
|
|
@@ -0,0 +1,88 @@
|
|
|
1
|
+
You are running a Full Party using ForgeHive.
|
|
2
|
+
|
|
3
|
+
## Full Party
|
|
4
|
+
|
|
5
|
+
**Agents:** Nora (Senior Research Analyst), Eli (Documentation Architect), Remy (Product Strategist), Suki (Experience Designer), Viktor (Systems Architect), Kai (Principal Engineer), Sam (Quality Architect)
|
|
6
|
+
|
|
7
|
+
**Mission:** Comprehensive multi-discipline review of a major feature or release — all seven specialists working in parallel on their domain.
|
|
8
|
+
|
|
9
|
+
> **Warning:** This party spins up 7 worktrees simultaneously. Reserve this for major milestones, release candidates, and significant architectural changes. For smaller reviews, use `/review-party` or `/design-party` instead.
|
|
10
|
+
|
|
11
|
+
## Protocol
|
|
12
|
+
|
|
13
|
+
### Step 1: Launch the party
|
|
14
|
+
|
|
15
|
+
Run:
|
|
16
|
+
```bash
|
|
17
|
+
fh party run --set full
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
This spins up isolated worktrees for all 7 agents. Each works their specialization in parallel.
|
|
21
|
+
|
|
22
|
+
### Step 2: Define the milestone
|
|
23
|
+
|
|
24
|
+
Before the party starts, describe what is being reviewed — be specific:
|
|
25
|
+
- Which release or feature?
|
|
26
|
+
- What are the success criteria?
|
|
27
|
+
- Are there known risk areas to highlight?
|
|
28
|
+
|
|
29
|
+
### Step 3: Parallel work by specialization
|
|
30
|
+
|
|
31
|
+
**Nora** (Senior Research Analyst) — structured evidence, surfaces hidden constraints:
|
|
32
|
+
- Reviews assumptions and surfaces what we don't know
|
|
33
|
+
- Checks for hidden constraints in requirements or architecture
|
|
34
|
+
- Produces: a risk and assumptions report
|
|
35
|
+
|
|
36
|
+
**Eli** (Documentation Architect) — turns systems into navigable knowledge:
|
|
37
|
+
- Audits all documentation for accuracy and completeness
|
|
38
|
+
- Flags missing docs for new features and changed APIs
|
|
39
|
+
- Produces: a documentation gap report
|
|
40
|
+
|
|
41
|
+
**Remy** (Product Strategist) — jobs-to-be-done, user value over technical elegance:
|
|
42
|
+
- Reviews the feature against user jobs-to-be-done
|
|
43
|
+
- Checks if technical decisions serve user value
|
|
44
|
+
- Produces: a product alignment report
|
|
45
|
+
|
|
46
|
+
**Suki** (Experience Designer) — empathy-first design:
|
|
47
|
+
- Reviews UX and interaction flows
|
|
48
|
+
- Flags friction points and accessibility concerns
|
|
49
|
+
- Produces: a UX review with specific improvement suggestions
|
|
50
|
+
|
|
51
|
+
**Viktor** (Systems Architect) — proven technology, developer experience as architecture:
|
|
52
|
+
- Reviews architecture for scalability, maintainability, and DX
|
|
53
|
+
- Flags over-engineering and missing abstractions
|
|
54
|
+
- Produces: an architecture review
|
|
55
|
+
|
|
56
|
+
**Kai** (Principal Engineer) — test-first, ship-ready, zero ambiguity:
|
|
57
|
+
- Reviews code quality, correctness, and implementation discipline
|
|
58
|
+
- Flags ambiguity, untested code, and production risks
|
|
59
|
+
- Produces: a code review with blocking / non-blocking findings
|
|
60
|
+
|
|
61
|
+
**Sam** (Quality Architect) — risk-based testing, full-stack automation:
|
|
62
|
+
- Reviews test coverage and testing strategy
|
|
63
|
+
- Identifies high-risk paths with insufficient coverage
|
|
64
|
+
- Produces: a test coverage and risk report
|
|
65
|
+
|
|
66
|
+
### Step 4: Check status
|
|
67
|
+
|
|
68
|
+
After all agents complete:
|
|
69
|
+
```bash
|
|
70
|
+
fh party status
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
### Step 5: Synthesize into a unified report
|
|
74
|
+
|
|
75
|
+
Collect all 7 reports and synthesize:
|
|
76
|
+
|
|
77
|
+
1. **Blockers** — anything that must be resolved before release
|
|
78
|
+
2. **Risks** — issues to monitor post-release
|
|
79
|
+
3. **Improvements** — non-blocking suggestions by priority
|
|
80
|
+
4. **Overall verdict**: ready to release / needs work
|
|
81
|
+
|
|
82
|
+
Present the unified report and ask: **"Soll ich die Blocker direkt angehen?"**
|
|
83
|
+
|
|
84
|
+
### Step 6: Cleanup
|
|
85
|
+
|
|
86
|
+
```bash
|
|
87
|
+
fh party cleanup
|
|
88
|
+
```
|
|
@@ -0,0 +1,64 @@
|
|
|
1
|
+
You are running a Build Party using ForgeHive.
|
|
2
|
+
|
|
3
|
+
## Build Party
|
|
4
|
+
|
|
5
|
+
**Agents:** Viktor (Systems Architect), Kai (Principal Engineer), Sam (Quality Architect)
|
|
6
|
+
|
|
7
|
+
**Mission:** Architecture, implementation, and QA in parallel — design the system, write the code, and test it simultaneously.
|
|
8
|
+
|
|
9
|
+
## Protocol
|
|
10
|
+
|
|
11
|
+
### Step 1: Launch the party
|
|
12
|
+
|
|
13
|
+
Run:
|
|
14
|
+
```bash
|
|
15
|
+
fh party run --set build
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
This spins up isolated git worktrees for Viktor, Kai, and Sam. Each agent works in their own worktree in parallel.
|
|
19
|
+
|
|
20
|
+
### Step 2: Define the scope
|
|
21
|
+
|
|
22
|
+
Before the party starts, state clearly what is being built — one paragraph is enough. Each agent will interpret this through their own lens.
|
|
23
|
+
|
|
24
|
+
### Step 3: Parallel work
|
|
25
|
+
|
|
26
|
+
**Viktor** (Systems Architect) — in his worktree:
|
|
27
|
+
- Proposes the architecture: module boundaries, data flow, API shape
|
|
28
|
+
- Documents key decisions and trade-offs
|
|
29
|
+
- Flags any infrastructure or dependency requirements
|
|
30
|
+
|
|
31
|
+
**Kai** (Principal Engineer) — in his worktree:
|
|
32
|
+
- Implements the feature following Viktor's architecture proposal
|
|
33
|
+
- Writes ship-ready code — no placeholders, no TODOs
|
|
34
|
+
- Follows test-first discipline: failing test → implementation → passing test
|
|
35
|
+
|
|
36
|
+
**Sam** (Quality Architect) — in his worktree:
|
|
37
|
+
- Writes the test suite for the feature in parallel with Kai's implementation
|
|
38
|
+
- Covers happy paths, edge cases, and error states
|
|
39
|
+
- Identifies risk areas that need additional coverage
|
|
40
|
+
|
|
41
|
+
### Step 4: Check status
|
|
42
|
+
|
|
43
|
+
After each agent signals completion:
|
|
44
|
+
```bash
|
|
45
|
+
fh party status
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
Review what each agent produced before merging.
|
|
49
|
+
|
|
50
|
+
### Step 5: Review and integrate
|
|
51
|
+
|
|
52
|
+
1. Read Viktor's architecture notes
|
|
53
|
+
2. Review Kai's implementation against Viktor's proposal — flag divergence
|
|
54
|
+
3. Run Sam's tests against Kai's implementation — all must pass
|
|
55
|
+
4. Resolve any conflicts between the three worktrees
|
|
56
|
+
5. Merge the agreed result into main
|
|
57
|
+
|
|
58
|
+
### Step 6: Cleanup
|
|
59
|
+
|
|
60
|
+
```bash
|
|
61
|
+
fh party cleanup
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
This tears down all worktrees and cleans up the party state.
|
|
@@ -0,0 +1,72 @@
|
|
|
1
|
+
You are running a Review Party using ForgeHive.
|
|
2
|
+
|
|
3
|
+
## Review Party
|
|
4
|
+
|
|
5
|
+
**Agents:** Kai (Principal Engineer), Sam (Quality Architect), Eli (Documentation Architect)
|
|
6
|
+
|
|
7
|
+
**Mission:** Code review, test coverage check, and docs audit in parallel — three disciplines reviewing the same changeset simultaneously.
|
|
8
|
+
|
|
9
|
+
## Protocol
|
|
10
|
+
|
|
11
|
+
### Step 1: Launch the party
|
|
12
|
+
|
|
13
|
+
Run:
|
|
14
|
+
```bash
|
|
15
|
+
fh party run --set review
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
This spins up isolated git worktrees for Kai, Sam, and Eli. Each agent reviews the current diff in parallel.
|
|
19
|
+
|
|
20
|
+
### Step 2: Set the scope
|
|
21
|
+
|
|
22
|
+
Before the party starts, specify what is being reviewed — a branch name, a PR, or a commit range:
|
|
23
|
+
|
|
24
|
+
```bash
|
|
25
|
+
git diff main...HEAD --stat # show what changed
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
Share this with the party so all three agents review the same surface area.
|
|
29
|
+
|
|
30
|
+
### Step 3: Parallel review
|
|
31
|
+
|
|
32
|
+
**Kai** (Principal Engineer) — in his worktree:
|
|
33
|
+
- Reviews code quality and correctness
|
|
34
|
+
- Flags bugs, logic errors, and anti-patterns
|
|
35
|
+
- Checks for ambiguous naming, hidden coupling, and missing error handling
|
|
36
|
+
- Labels findings: `[BUG]`, `[DESIGN]`, `[NIT]`, `[Q]`, `[+]`
|
|
37
|
+
|
|
38
|
+
**Sam** (Quality Architect) — in his worktree:
|
|
39
|
+
- Checks test coverage for the changed code
|
|
40
|
+
- Identifies missing edge cases, error states, and boundary conditions
|
|
41
|
+
- Flags paths that are high-risk but untested
|
|
42
|
+
- Proposes specific tests for any gaps found
|
|
43
|
+
|
|
44
|
+
**Eli** (Documentation Architect) — in his worktree:
|
|
45
|
+
- Checks if README and docs reflect the changes
|
|
46
|
+
- Flags missing or outdated inline documentation
|
|
47
|
+
- Reviews any CHANGELOG entries for accuracy
|
|
48
|
+
- Checks that public API changes are documented
|
|
49
|
+
|
|
50
|
+
### Step 4: Check status
|
|
51
|
+
|
|
52
|
+
After each agent completes their review:
|
|
53
|
+
```bash
|
|
54
|
+
fh party status
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
### Step 5: Synthesize findings
|
|
58
|
+
|
|
59
|
+
Collect the three reports and merge them into a unified review:
|
|
60
|
+
|
|
61
|
+
1. **Blocking issues** — anything from Kai or Sam that must be fixed before merge
|
|
62
|
+
2. **Test gaps** — Sam's missing coverage items
|
|
63
|
+
3. **Docs debt** — Eli's documentation updates needed
|
|
64
|
+
4. **Overall verdict**: approve / request changes
|
|
65
|
+
|
|
66
|
+
Present the synthesized report to the user and ask: **"Soll ich die Blocking Issues direkt fixen?"**
|
|
67
|
+
|
|
68
|
+
### Step 6: Cleanup
|
|
69
|
+
|
|
70
|
+
```bash
|
|
71
|
+
fh party cleanup
|
|
72
|
+
```
|
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
You are running a Security Party using ForgeHive.
|
|
2
|
+
|
|
3
|
+
## Security Party
|
|
4
|
+
|
|
5
|
+
**Agents:** Vera (Security Analyst), Sam (Quality Architect)
|
|
6
|
+
|
|
7
|
+
**Mission:** Security review and QA in parallel — audit for vulnerabilities while checking test coverage for security-critical paths.
|
|
8
|
+
|
|
9
|
+
## Protocol
|
|
10
|
+
|
|
11
|
+
### Step 1: Launch the party
|
|
12
|
+
|
|
13
|
+
Run:
|
|
14
|
+
```bash
|
|
15
|
+
fh party run --set security
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
This spins up isolated worktrees for Vera and Sam. Both work in parallel on the current codebase or changeset.
|
|
19
|
+
|
|
20
|
+
### Step 2: Set the scope
|
|
21
|
+
|
|
22
|
+
Specify what is being reviewed:
|
|
23
|
+
- A specific branch or PR: `git diff main...HEAD --stat`
|
|
24
|
+
- A full security audit of the codebase
|
|
25
|
+
- A pre-release security check
|
|
26
|
+
|
|
27
|
+
### Step 3: Parallel security work
|
|
28
|
+
|
|
29
|
+
**Vera** (Security Analyst) — in her worktree:
|
|
30
|
+
|
|
31
|
+
Run the automated scan first:
|
|
32
|
+
```bash
|
|
33
|
+
fh security scan
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
Then perform a manual audit covering:
|
|
37
|
+
- **OWASP Top 10** — injection, broken auth, XSS, IDOR, security misconfiguration, etc.
|
|
38
|
+
- **Auth/Auth review** — authentication flows, authorization checks, session handling
|
|
39
|
+
- **Secrets and credentials** — hardcoded tokens, API keys, or credentials in code
|
|
40
|
+
- **Dependency vulnerabilities** — outdated packages with known CVEs
|
|
41
|
+
- **Compliance flags** — GDPR, SOC2, or HIPAA relevant data handling
|
|
42
|
+
|
|
43
|
+
Produces: a security findings report with severity ratings (CRITICAL, HIGH, MEDIUM, LOW)
|
|
44
|
+
|
|
45
|
+
**Sam** (Quality Architect) — in his worktree:
|
|
46
|
+
- Identifies security-critical code paths (auth, payments, data access, input handling)
|
|
47
|
+
- Checks test coverage for each identified path
|
|
48
|
+
- Flags paths that are high-risk but have no security-focused tests
|
|
49
|
+
- Proposes specific security tests: auth bypass attempts, injection tests, boundary inputs
|
|
50
|
+
|
|
51
|
+
Produces: a security test coverage report with specific test recommendations
|
|
52
|
+
|
|
53
|
+
### Step 4: Check status
|
|
54
|
+
|
|
55
|
+
After both agents complete:
|
|
56
|
+
```bash
|
|
57
|
+
fh party status
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
### Step 5: Merge into a security + quality report
|
|
61
|
+
|
|
62
|
+
Combine both outputs:
|
|
63
|
+
|
|
64
|
+
1. **CRITICAL findings** (Vera) — must fix before any deployment
|
|
65
|
+
2. **HIGH findings** (Vera) — fix before production release
|
|
66
|
+
3. **Untested security paths** (Sam) — add tests before release
|
|
67
|
+
4. **MEDIUM/LOW findings** — schedule for next sprint
|
|
68
|
+
5. **Overall verdict**: safe to deploy / needs remediation
|
|
69
|
+
|
|
70
|
+
Ask: **"Soll ich die CRITICAL und HIGH Findings direkt fixen?"**
|
|
71
|
+
|
|
72
|
+
Do NOT deploy if CRITICAL or HIGH findings are unresolved.
|
|
73
|
+
|
|
74
|
+
### Step 6: Cleanup
|
|
75
|
+
|
|
76
|
+
```bash
|
|
77
|
+
fh party cleanup
|
|
78
|
+
```
|