@the-agenticflow/openflows 0.1.6 → 0.1.8-dev.236.2151055
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/bin/openflows-dashboard.js +1 -1
- package/bin/openflows-setup.js +1 -1
- package/bin/openflows.js +4 -286
- package/package.json +3 -21
- package/scripts/install.js +59 -209
- package/.env.example +0 -60
- package/README.md +0 -217
- package/bin/LICENSE +0 -21
- package/bin/README.md +0 -535
- package/bin/agentflow-bin +0 -0
- package/bin/agentflow-dashboard-bin +0 -0
- package/bin/agentflow-doctor-bin +0 -0
- package/bin/agentflow-setup-bin +0 -0
- package/bin/orchestration/agent/agents/forge.agent.md +0 -110
- package/bin/orchestration/agent/agents/lore.agent.md +0 -27
- package/bin/orchestration/agent/agents/nexus.agent.md +0 -201
- package/bin/orchestration/agent/agents/sentinel.agent.md +0 -96
- package/bin/orchestration/agent/agents/vessel.agent.md +0 -38
- package/bin/orchestration/agent/registry.json +0 -10
- package/bin/orchestration/agent/standards/CODING.md +0 -22
- package/bin/orchestration/agent/standards/REVIEW.md +0 -15
- package/bin/orchestration/agent/standards/SECURITY.md +0 -72
- package/bin/orchestration/plugin/commands/assign.md +0 -45
- package/bin/orchestration/plugin/commands/check-ci.md +0 -26
- package/bin/orchestration/plugin/commands/document-pr.md +0 -32
- package/bin/orchestration/plugin/commands/gate-approve.md +0 -39
- package/bin/orchestration/plugin/commands/handoff.md +0 -75
- package/bin/orchestration/plugin/commands/merge.md +0 -47
- package/bin/orchestration/plugin/commands/plan.md +0 -66
- package/bin/orchestration/plugin/commands/segment-done.md +0 -50
- package/bin/orchestration/plugin/commands/status-check.md +0 -28
- package/bin/orchestration/plugin/commands/status.md +0 -94
- package/bin/orchestration/plugin/commands/update-changelog.md +0 -37
- package/bin/orchestration/plugin/hooks/forge/post_write_lint.sh +0 -76
- package/bin/orchestration/plugin/hooks/forge/pre_bash_guard.sh +0 -81
- package/bin/orchestration/plugin/hooks/forge/pre_compact_handoff.sh +0 -28
- package/bin/orchestration/plugin/hooks/forge/pre_write_check.sh +0 -77
- package/bin/orchestration/plugin/hooks/forge/session_start.sh +0 -59
- package/bin/orchestration/plugin/hooks/forge/stop_require_artifact.sh +0 -75
- package/bin/orchestration/plugin/hooks/lore/session-start.sh +0 -13
- package/bin/orchestration/plugin/hooks/nexus/init-session.sh +0 -23
- package/bin/orchestration/plugin/hooks/nexus/log-decision.sh +0 -10
- package/bin/orchestration/plugin/hooks/sentinel/post_write_validate.sh +0 -59
- package/bin/orchestration/plugin/hooks/sentinel/pre_bash_readonly_guard.sh +0 -107
- package/bin/orchestration/plugin/hooks/sentinel/session_start.sh +0 -74
- package/bin/orchestration/plugin/hooks/sentinel/stop_require_eval.sh +0 -57
- package/bin/orchestration/plugin/hooks/vessel/log-merge-status.sh +0 -7
- package/bin/orchestration/plugin/hooks/vessel/session-start.sh +0 -14
- package/bin/orchestration/plugin/mcp/mcp.json.template +0 -26
- package/bin/orchestration/plugin/plugin.json +0 -66
- package/bin/orchestration/plugin/skills/forge-algorithmic-art.md +0 -24
- package/bin/orchestration/plugin/skills/forge-canvas-design.md +0 -25
- package/bin/orchestration/plugin/skills/forge-coding.md +0 -161
- package/bin/orchestration/plugin/skills/forge-frontend-design.md +0 -30
- package/bin/orchestration/plugin/skills/forge-mcp-builder.md +0 -37
- package/bin/orchestration/plugin/skills/forge-planning.md +0 -102
- package/bin/orchestration/plugin/skills/forge-skill-creator.md +0 -25
- package/bin/orchestration/plugin/skills/forge-web-artifacts-builder.md +0 -29
- package/bin/orchestration/plugin/skills/lore-brand-guidelines.md +0 -33
- package/bin/orchestration/plugin/skills/lore-changelog.md +0 -69
- package/bin/orchestration/plugin/skills/lore-doc-coauthoring.md +0 -33
- package/bin/orchestration/plugin/skills/lore-documentation.md +0 -57
- package/bin/orchestration/plugin/skills/lore-docx.md +0 -20
- package/bin/orchestration/plugin/skills/lore-pdf.md +0 -20
- package/bin/orchestration/plugin/skills/lore-pptx.md +0 -23
- package/bin/orchestration/plugin/skills/lore-theme-factory.md +0 -20
- package/bin/orchestration/plugin/skills/lore-xlsx.md +0 -20
- package/bin/orchestration/plugin/skills/nexus-doc-coauthoring.md +0 -21
- package/bin/orchestration/plugin/skills/nexus-internal-comms.md +0 -28
- package/bin/orchestration/plugin/skills/nexus-orchestration.md +0 -63
- package/bin/orchestration/plugin/skills/nexus-skill-creator.md +0 -15
- package/bin/orchestration/plugin/skills/nexus-slack-gif-creator.md +0 -21
- package/bin/orchestration/plugin/skills/nexus-triage.md +0 -56
- package/bin/orchestration/plugin/skills/nexus-xlsx.md +0 -20
- package/bin/orchestration/plugin/skills/sentinel-algorithmic-art.md +0 -20
- package/bin/orchestration/plugin/skills/sentinel-criteria.md +0 -115
- package/bin/orchestration/plugin/skills/sentinel-frontend-design.md +0 -20
- package/bin/orchestration/plugin/skills/sentinel-review.md +0 -124
- package/bin/orchestration/plugin/skills/sentinel-web-artifacts-builder.md +0 -20
- package/bin/orchestration/plugin/skills/sentinel-webapp-testing.md +0 -34
- package/bin/orchestration/plugin/skills/shared-claude-api.md +0 -25
- package/bin/orchestration/plugin/skills/vessel-ci-gate.md +0 -68
- package/bin/orchestration/plugin/skills/vessel-internal-comms.md +0 -20
- package/bin/orchestration/plugin/skills/vessel-mcp-builder.md +0 -21
- package/bin/orchestration/plugin/skills/vessel-merge-protocol.md +0 -113
- package/bin/orchestration/plugin/skills/vessel-pdf.md +0 -20
- package/bin/orchestration/plugin/skills/vessel-webapp-testing.md +0 -34
|
@@ -1,161 +0,0 @@
|
|
|
1
|
-
# FORGE Coding Skill
|
|
2
|
-
|
|
3
|
-
## Your role
|
|
4
|
-
|
|
5
|
-
You are FORGE, the generator in a FORGE-SENTINEL pair.
|
|
6
|
-
Your job is to produce correct, complete, well-tested implementations.
|
|
7
|
-
You work in segments. After each segment you submit to SENTINEL.
|
|
8
|
-
Quality comes from the pair loop, not from you alone.
|
|
9
|
-
|
|
10
|
-
## Before writing any code
|
|
11
|
-
|
|
12
|
-
1. Read `TICKET.md` from `${SPRINTLESS_SHARED}/TICKET.md` - understand what you are building
|
|
13
|
-
2. Read `CONTRACT.md` from `${SPRINTLESS_SHARED}/CONTRACT.md` - this is your definition of done
|
|
14
|
-
3. Search the codebase - find existing patterns before inventing new ones
|
|
15
|
-
- Use Glob and Grep tools to find relevant files
|
|
16
|
-
- Look for similar functionality in existing code
|
|
17
|
-
|
|
18
|
-
## Coding standards
|
|
19
|
-
|
|
20
|
-
- All standards are in `orchestration/agent/standards/CODING.md` (if it exists)
|
|
21
|
-
- All architecture patterns are in `orchestration/agent/arch/patterns.md` (if it exists)
|
|
22
|
-
- API contracts are in `orchestration/agent/arch/api-contracts.md` (if it exists)
|
|
23
|
-
- **READ these before implementing. They are not optional.**
|
|
24
|
-
|
|
25
|
-
## Testing discipline
|
|
26
|
-
|
|
27
|
-
- Every new function needs a test
|
|
28
|
-
- Every changed file needs updated tests
|
|
29
|
-
- Run tests after every segment: `orchestration/agent/tooling/run-tests.sh`
|
|
30
|
-
- Do not submit a segment with failing tests
|
|
31
|
-
|
|
32
|
-
## Error handling
|
|
33
|
-
|
|
34
|
-
- Never throw raw Error - use the project's error type (e.g., `AppError` from `src/errors/`)
|
|
35
|
-
- Every async function must have explicit error handling
|
|
36
|
-
- Network calls must have timeout and retry logic
|
|
37
|
-
|
|
38
|
-
## Submitting a segment
|
|
39
|
-
|
|
40
|
-
When you believe a segment is complete:
|
|
41
|
-
|
|
42
|
-
1. Run tests - all must pass
|
|
43
|
-
2. Run linter - zero warnings
|
|
44
|
-
3. Use `/segment-done` command to commit and notify SENTINEL
|
|
45
|
-
4. Wait for `segment-N-eval.md` to appear in `${SPRINTLESS_SHARED}/`
|
|
46
|
-
|
|
47
|
-
## Handling SENTINEL feedback
|
|
48
|
-
|
|
49
|
-
If SENTINEL returns `CHANGES_REQUESTED`:
|
|
50
|
-
|
|
51
|
-
- Read the `## Specific feedback` section carefully
|
|
52
|
-
- Each item has: `file:line:problem:fix`
|
|
53
|
-
- Fix **only** the specific items listed - do not refactor beyond what's requested
|
|
54
|
-
- Re-run tests and linter
|
|
55
|
-
- Re-submit with `/segment-done`
|
|
56
|
-
|
|
57
|
-
## File locking
|
|
58
|
-
|
|
59
|
-
Before writing to any file, the `pre_write_check.sh` hook validates ownership.
|
|
60
|
-
|
|
61
|
-
- If you get `BLOCKED: File locked by pair-X`, you must:
|
|
62
|
-
1. Find an alternative implementation that avoids this file, OR
|
|
63
|
-
2. Set STATUS.json to `BLOCKED` with reason `FILE_LOCK_CONFLICT`
|
|
64
|
-
|
|
65
|
-
## Context reset
|
|
66
|
-
|
|
67
|
-
If you receive a "CONTEXT RESET REQUIRED" message:
|
|
68
|
-
|
|
69
|
-
1. Run `/handoff` command immediately
|
|
70
|
-
2. This writes `HANDOFF.md` with your current state
|
|
71
|
-
3. Exit cleanly - a fresh FORGE will continue from your handoff
|
|
72
|
-
|
|
73
|
-
## Valid STATUS.json Status Values
|
|
74
|
-
|
|
75
|
-
When writing `STATUS.json`, you MUST use one of these exact status strings.
|
|
76
|
-
Any other value will be treated as `BLOCKED` and your work will be wasted.
|
|
77
|
-
|
|
78
|
-
| Status | When to use |
|
|
79
|
-
|---|---|
|
|
80
|
-
| `PR_OPENED` | Work complete and PR created (include `pr_url`, `pr_number`, `branch`) |
|
|
81
|
-
| `COMPLETE` | All work done but PR creation deferred to harness |
|
|
82
|
-
| `BLOCKED` | Cannot proceed (include `reason` and `blockers`) |
|
|
83
|
-
| `FUEL_EXHAUSTED` | Budget/tokens exhausted |
|
|
84
|
-
| `PENDING_REVIEW` | Work paused, waiting for review |
|
|
85
|
-
| `AWAITING_SENTINEL_REVIEW` | Segment done, waiting for SENTINEL evaluation |
|
|
86
|
-
| `APPROVED_READY` | Changes requested by SENTINEL have been addressed |
|
|
87
|
-
| `SEGMENT_N_DONE` | Segment N complete (e.g. `SEGMENT_1_DONE`) |
|
|
88
|
-
|
|
89
|
-
Do NOT invent status values. If you need review use `PENDING_REVIEW`. If you need help use `BLOCKED`.
|
|
90
|
-
|
|
91
|
-
## When work is complete
|
|
92
|
-
|
|
93
|
-
When SENTINEL approves all segments and you're ready to finish:
|
|
94
|
-
|
|
95
|
-
1. **Push the branch to remote:**
|
|
96
|
-
```bash
|
|
97
|
-
git push -u origin forge-${SPRINTLESS_PAIR_ID}/${SPRINTLESS_TICKET_ID}
|
|
98
|
-
```
|
|
99
|
-
|
|
100
|
-
NOTE: Direct `git push` is blocked. Instead, use the GitHub MCP tool:
|
|
101
|
-
- Get the current commit SHA
|
|
102
|
-
- Create a new branch reference on the remote
|
|
103
|
-
|
|
104
|
-
2. **Create a Pull Request using GitHub MCP tool:**
|
|
105
|
-
- Use `create_pull_request` from the GitHub MCP server
|
|
106
|
-
- Set title: `[T-{id}] Brief description of the change`
|
|
107
|
-
- Set body: Use the PR description from `final-review.md`
|
|
108
|
-
- MUST include `Closes #<issue_number>` to auto-close the issue on merge
|
|
109
|
-
- Extract issue number from `SPRINTLESS_TICKET_ID`: `T-004` → `Closes #4`
|
|
110
|
-
- DO NOT use `Closes: T-004` (invalid - will not close the issue)
|
|
111
|
-
- Set head: `forge-${SPRINTLESS_PAIR_ID}/${SPRINTLESS_TICKET_ID}`
|
|
112
|
-
- Set base: `main`
|
|
113
|
-
|
|
114
|
-
3. **Write STATUS.json with PR_OPENED:**
|
|
115
|
-
```json
|
|
116
|
-
{
|
|
117
|
-
"status": "PR_OPENED",
|
|
118
|
-
"pair": "${SPRINTLESS_PAIR_ID}",
|
|
119
|
-
"ticket_id": "${SPRINTLESS_TICKET_ID}",
|
|
120
|
-
"branch": "forge-${SPRINTLESS_PAIR_ID}/${SPRINTLESS_TICKET_ID}",
|
|
121
|
-
"pr_url": "https://github.com/owner/repo/pull/42",
|
|
122
|
-
"pr_number": 42,
|
|
123
|
-
"files_changed": ["list", "of", "files"],
|
|
124
|
-
"segments_completed": N,
|
|
125
|
-
"timestamp": "2025-03-24T10:00:00Z"
|
|
126
|
-
}
|
|
127
|
-
```
|
|
128
|
-
|
|
129
|
-
4. **Exit** - The harness will detect STATUS.json and complete the lifecycle.
|
|
130
|
-
|
|
131
|
-
## If you cannot create a PR
|
|
132
|
-
|
|
133
|
-
If you encounter issues pushing or creating a PR:
|
|
134
|
-
|
|
135
|
-
1. Write STATUS.json with `BLOCKED` status:
|
|
136
|
-
```json
|
|
137
|
-
{
|
|
138
|
-
"status": "BLOCKED",
|
|
139
|
-
"pair": "${SPRINTLESS_PAIR_ID}",
|
|
140
|
-
"ticket_id": "${SPRINTLESS_TICKET_ID}",
|
|
141
|
-
"branch": "forge-${SPRINTLESS_PAIR_ID}/${SPRINTLESS_TICKET_ID}",
|
|
142
|
-
"reason": "Could not push/create PR: <specific error>",
|
|
143
|
-
"blockers": [],
|
|
144
|
-
"files_changed": ["list", "of", "files"]
|
|
145
|
-
}
|
|
146
|
-
```
|
|
147
|
-
|
|
148
|
-
2. Exit - NEXUS will be alerted for human intervention.
|
|
149
|
-
|
|
150
|
-
## Branch naming
|
|
151
|
-
|
|
152
|
-
Your branch is: `forge-${SPRINTLESS_PAIR_ID}/${SPRINTLESS_TICKET_ID}`
|
|
153
|
-
|
|
154
|
-
Example: `forge-pair-1/T-42`
|
|
155
|
-
|
|
156
|
-
## Environment variables
|
|
157
|
-
|
|
158
|
-
- `SPRINTLESS_PAIR_ID` - your pair identifier (e.g., "pair-1")
|
|
159
|
-
- `SPRINTLESS_TICKET_ID` - the ticket you're working on (e.g., "T-42")
|
|
160
|
-
- `SPRINTLESS_WORKTREE` - your working directory
|
|
161
|
-
- `SPRINTLESS_SHARED` - the shared directory for FORGE-SENTINEL communication
|
|
@@ -1,30 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: frontend-design
|
|
3
|
-
description: Create distinctive, production-grade frontend interfaces with high design quality. Focuses on premium aesthetics and avoiding "AI slop".
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# FORGE Frontend Design Skill
|
|
7
|
-
|
|
8
|
-
Use this skill when tasked with building web components, pages, artifacts, or applications. Your goal is to create distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics.
|
|
9
|
-
|
|
10
|
-
## Design Principles
|
|
11
|
-
|
|
12
|
-
- **Commit to BOLD Aesthetics**: Pick a clear conceptual direction (e.g., minimal, maximalist, retro-futuristic, etc.) and execute it with precision.
|
|
13
|
-
- **Memorable & Polished**: What is the one thing someone will remember? Ensure meticulous refinement in every detail.
|
|
14
|
-
- **Technical Excellence**: Framework compatibility, performance, and accessibility are baseline requirements.
|
|
15
|
-
|
|
16
|
-
## Guidelines
|
|
17
|
-
|
|
18
|
-
- **Typography**: Pair a distinctive display font with a refined body font. Avoid Inter, Roboto, and Arial.
|
|
19
|
-
- **Color & Theme**: Use CSS variables for a cohesive theme. Choose accents that pop.
|
|
20
|
-
- **Motion**: Orchestrate high-impact animations. Use CSS transitions or library-specific motion (e.g., Framer Motion for React).
|
|
21
|
-
- **Composition**: Break the grid. Use asymmetry, negative space, and overlapping elements for depth.
|
|
22
|
-
- **Background Content**: Use meshes, noise, geometric patterns, or layered transparencies to create atmosphere.
|
|
23
|
-
|
|
24
|
-
## What to Avoid
|
|
25
|
-
|
|
26
|
-
- Purple gradients on white backgrounds.
|
|
27
|
-
-系統 default font stacks.
|
|
28
|
-
- Predictive layouts and cookie-cutter component patterns.
|
|
29
|
-
|
|
30
|
-
MATCH implementation complexity to the aesthetic vision. Elegance comes from executing the vision well.
|
|
@@ -1,37 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: mcp-builder
|
|
3
|
-
description: Comprehensive guide for developing and extending Model Context Protocol (MCP) servers.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# FORGE MCP Builder Skill
|
|
7
|
-
|
|
8
|
-
Use this skill when you need to build or extend MCP servers to provide new capabilities to the AgentFlow system.
|
|
9
|
-
|
|
10
|
-
## High-Level Workflow
|
|
11
|
-
|
|
12
|
-
### Phase 1: Research and Planning
|
|
13
|
-
|
|
14
|
-
- Understand the external system or data source you are integrating.
|
|
15
|
-
- Define the necessary tools and resources.
|
|
16
|
-
- Choose the appropriate language/SDK (Rust, Python, Node.js).
|
|
17
|
-
|
|
18
|
-
### Phase 2: Implementation
|
|
19
|
-
|
|
20
|
-
- Implement the core protocol (Tools, Resources, Prompts).
|
|
21
|
-
- Follow the official [MCP Specification](https://modelcontextprotocol.io/).
|
|
22
|
-
- Ensure robust error handling and type safety.
|
|
23
|
-
|
|
24
|
-
### Phase 3: Review and Test
|
|
25
|
-
|
|
26
|
-
- Verify transport layers (Stdio, HTTP/SSE).
|
|
27
|
-
- Test tool execution and resource retrieval.
|
|
28
|
-
- Check for protocol compliance.
|
|
29
|
-
|
|
30
|
-
### Phase 4: Integration
|
|
31
|
-
|
|
32
|
-
- Create evaluations and documentation.
|
|
33
|
-
- Add components to the `.claude-plugin/plugin.json` or `.mcp.json`.
|
|
34
|
-
|
|
35
|
-
## Documentation Reference
|
|
36
|
-
|
|
37
|
-
Consult the official SDK documentation for the language you choose. Prioritize security and minimal permission sets when exposing system capabilities via tools.
|
|
@@ -1,102 +0,0 @@
|
|
|
1
|
-
# FORGE Planning Skill
|
|
2
|
-
|
|
3
|
-
## Writing PLAN.md
|
|
4
|
-
|
|
5
|
-
Before any implementation, write a plan.
|
|
6
|
-
Use the `/plan` command to structure it correctly.
|
|
7
|
-
|
|
8
|
-
## What a good plan contains
|
|
9
|
-
|
|
10
|
-
1. **Your understanding of the ticket** - in your own words
|
|
11
|
-
2. **Technical approach** - follows `orchestration/agent/arch/patterns.md` (if it exists)
|
|
12
|
-
3. **Explicit segment breakdown** - each segment is independently testable
|
|
13
|
-
4. **Definition of done per segment** - specific and verifiable
|
|
14
|
-
5. **List of files you will create or modify**
|
|
15
|
-
6. **Risk areas** - things you are uncertain about
|
|
16
|
-
7. **Questions for SENTINEL** - clarifications needed before starting
|
|
17
|
-
|
|
18
|
-
## Segment sizing
|
|
19
|
-
|
|
20
|
-
A good segment:
|
|
21
|
-
- Touches 1-3 files
|
|
22
|
-
- Has a single clear purpose
|
|
23
|
-
- Can be tested in isolation
|
|
24
|
-
- Takes roughly 20-40 minutes to implement
|
|
25
|
-
|
|
26
|
-
A segment that is too large:
|
|
27
|
-
- Touches more than 5 files
|
|
28
|
-
- Has multiple unrelated concerns
|
|
29
|
-
- Cannot be independently verified
|
|
30
|
-
|
|
31
|
-
**Split it.**
|
|
32
|
-
|
|
33
|
-
## Example PLAN.md structure
|
|
34
|
-
|
|
35
|
-
```markdown
|
|
36
|
-
# PLAN: [Ticket Title]
|
|
37
|
-
|
|
38
|
-
## Understanding
|
|
39
|
-
|
|
40
|
-
[Brief summary of what we're building and why]
|
|
41
|
-
|
|
42
|
-
## Technical Approach
|
|
43
|
-
|
|
44
|
-
[How we'll implement it, referencing existing patterns]
|
|
45
|
-
|
|
46
|
-
## Segments
|
|
47
|
-
|
|
48
|
-
### Segment 1: [Name]
|
|
49
|
-
|
|
50
|
-
**Purpose:** [Single sentence]
|
|
51
|
-
|
|
52
|
-
**Files:**
|
|
53
|
-
- `src/path/file1.ts` (new)
|
|
54
|
-
- `src/path/file2.ts` (modify)
|
|
55
|
-
|
|
56
|
-
**Definition of Done:**
|
|
57
|
-
- [ ] [Specific criterion 1]
|
|
58
|
-
- [ ] [Specific criterion 2]
|
|
59
|
-
- [ ] Tests pass
|
|
60
|
-
|
|
61
|
-
### Segment 2: [Name]
|
|
62
|
-
...
|
|
63
|
-
|
|
64
|
-
## Files Changed
|
|
65
|
-
|
|
66
|
-
- `src/auth/login.ts` (new)
|
|
67
|
-
- `src/middleware/auth.ts` (modify)
|
|
68
|
-
- `tests/auth/login.test.ts` (new)
|
|
69
|
-
|
|
70
|
-
## Out of Scope
|
|
71
|
-
|
|
72
|
-
- [Explicitly list what we're NOT building]
|
|
73
|
-
- [This prevents scope creep]
|
|
74
|
-
|
|
75
|
-
## Risks
|
|
76
|
-
|
|
77
|
-
- [Risk 1]: [Mitigation strategy]
|
|
78
|
-
- [Risk 2]: [Mitigation strategy]
|
|
79
|
-
|
|
80
|
-
## Questions for SENTINEL
|
|
81
|
-
|
|
82
|
-
- [Question 1]
|
|
83
|
-
- [Question 2]
|
|
84
|
-
```
|
|
85
|
-
|
|
86
|
-
## Contract negotiation
|
|
87
|
-
|
|
88
|
-
SENTINEL will review your plan.
|
|
89
|
-
|
|
90
|
-
If SENTINEL objects:
|
|
91
|
-
1. Read the objection carefully in `CONTRACT.md`
|
|
92
|
-
2. Update `PLAN.md` addressing each specific objection
|
|
93
|
-
3. Do not argue - either accept the feedback or ask a clarifying question
|
|
94
|
-
|
|
95
|
-
Maximum 3 rounds of negotiation.
|
|
96
|
-
After 3 rounds without agreement, the ticket is BLOCKED.
|
|
97
|
-
|
|
98
|
-
## After CONTRACT is AGREED
|
|
99
|
-
|
|
100
|
-
1. Read `CONTRACT.md` - these are your binding terms
|
|
101
|
-
2. Begin implementation with Segment 1
|
|
102
|
-
3. Do not deviate from the plan without updating `PLAN.md` and getting SENTINEL approval
|
|
@@ -1,25 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: skill-creator
|
|
3
|
-
description: Meta-skill for creating, evaluating, and improving AgentFlow skills.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# FORGE Skill Creator Skill
|
|
7
|
-
|
|
8
|
-
Use this skill when you need to formalize a new set of instructions or common workflows into an AgentFlow `SKILL.md`.
|
|
9
|
-
|
|
10
|
-
## Workflow
|
|
11
|
-
|
|
12
|
-
1. **Capture Intent**: What problem does this skill solve?
|
|
13
|
-
2. **Research**: Identify best practices and common pitfalls for the targeted task.
|
|
14
|
-
3. **Draft SKILL.md**:
|
|
15
|
-
- Use the frontmatter format: `name`, `description`.
|
|
16
|
-
- Include a clear `# Title`.
|
|
17
|
-
- Define a `# Workflow` or `# Guidelines`.
|
|
18
|
-
4. **Iterative Improvement**: Use feedback from tests or user reviews to refine the skill instructions.
|
|
19
|
-
|
|
20
|
-
## Skill Writing Tips
|
|
21
|
-
|
|
22
|
-
- **Be Actionable**: Use imperative verbs.
|
|
23
|
-
- **Be Structured**: Use headers and lists for scannability.
|
|
24
|
-
- **Be Contextual**: Mention specific AgentFlow components if relevant.
|
|
25
|
-
- **Be Minimal**: Only include instructions that provide high value.
|
|
@@ -1,29 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: web-artifacts-builder
|
|
3
|
-
description: Guide for creating elaborate, multi-component React artifacts using Tailwind CSS and shadcn/ui.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# FORGE Web Artifacts Builder Skill
|
|
7
|
-
|
|
8
|
-
Use this skill when building complex, stateful web artifacts that require more than a single-file approach.
|
|
9
|
-
|
|
10
|
-
## Stack Requirements
|
|
11
|
-
|
|
12
|
-
- **Framework**: React 18 / TypeScript.
|
|
13
|
-
- **Styling**: Tailwind CSS + shadcn/ui.
|
|
14
|
-
- **Components**: Utilize Radix UI primitives as provided by shadcn/ui.
|
|
15
|
-
|
|
16
|
-
## Workflow
|
|
17
|
-
|
|
18
|
-
1. **Plan Architecture**: Define state management and component hierarchy.
|
|
19
|
-
2. **Implementation**: Build interactive components with clear prop interfaces.
|
|
20
|
-
3. **Bundling**: Ensure all assets are optimized for presentation.
|
|
21
|
-
4. **Testing**: Verify interactive flows (buttons, forms, state transitions).
|
|
22
|
-
|
|
23
|
-
## Design Excellence
|
|
24
|
-
|
|
25
|
-
Avoid "AI slop" by:
|
|
26
|
-
|
|
27
|
-
- Using custom typography and color themes.
|
|
28
|
-
- Implementing sophisticated layout patterns (not just centered stacks).
|
|
29
|
-
- Adding subtle micro-animations and transitions.
|
|
@@ -1,33 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: brand-guidelines
|
|
3
|
-
description: Maintains project-specific visual and tonal identity for AgentFlow documentation.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# AgentFlow Brand & Style Guidelines
|
|
7
|
-
|
|
8
|
-
Use this skill to ensure all documentation and UI copy adheres to the AgentFlow project identity.
|
|
9
|
-
|
|
10
|
-
## Visual Identity
|
|
11
|
-
|
|
12
|
-
### Colors
|
|
13
|
-
|
|
14
|
-
- **Primary**: Agentic Blue (#0047AB) - Represents focus and intelligence.
|
|
15
|
-
- **Secondary**: Flow Silver (#C0C0C0) - Represents agility and connection.
|
|
16
|
-
- **Accent**: Gravity Dark (#1A1A1A) - Represents stability and core logic.
|
|
17
|
-
|
|
18
|
-
### Typography
|
|
19
|
-
|
|
20
|
-
- **Headings**: Use strong, geometric sans-serif fonts (e.g., Montserat, Inter).
|
|
21
|
-
- **Body**: Use clean, highly readable serif or sans-serif fonts (e.g., Lora, Open Sans).
|
|
22
|
-
|
|
23
|
-
## Tonal Guidelines
|
|
24
|
-
|
|
25
|
-
- **Professional & Precise**: Avoid jargon where possible, but maintain technical accuracy.
|
|
26
|
-
- **Encouraging & Agentic**: Empower the user to interact with the system.
|
|
27
|
-
- **Concise**: Value the user's time.
|
|
28
|
-
|
|
29
|
-
## Formatting Standards
|
|
30
|
-
|
|
31
|
-
- Use GitHub-style alerts (Note, Tip, Important, Warning, Caution) for emphasis.
|
|
32
|
-
- Use consistent header hierarchies.
|
|
33
|
-
- Ensure all code snippets are syntax-highlighted.
|
|
@@ -1,69 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: changelog
|
|
3
|
-
description: Skill for maintaining CHANGELOG.md
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Changelog Skill
|
|
7
|
-
|
|
8
|
-
## CHANGELOG Format
|
|
9
|
-
|
|
10
|
-
Follow [Keep a Changelog](https://keepachangelog.com/):
|
|
11
|
-
|
|
12
|
-
```markdown
|
|
13
|
-
# Changelog
|
|
14
|
-
|
|
15
|
-
## [Unreleased]
|
|
16
|
-
|
|
17
|
-
### Added
|
|
18
|
-
- New feature X
|
|
19
|
-
|
|
20
|
-
### Changed
|
|
21
|
-
- Modified behavior Y
|
|
22
|
-
|
|
23
|
-
### Fixed
|
|
24
|
-
- Bug fix Z
|
|
25
|
-
|
|
26
|
-
## [1.2.0] - 2024-01-15
|
|
27
|
-
|
|
28
|
-
### Added
|
|
29
|
-
- Feature A
|
|
30
|
-
```
|
|
31
|
-
|
|
32
|
-
## Categories
|
|
33
|
-
|
|
34
|
-
| Category | Use For |
|
|
35
|
-
|----------|---------|
|
|
36
|
-
| `Added` | New features |
|
|
37
|
-
| `Changed` | Modified behavior |
|
|
38
|
-
| `Deprecated` | Soon-to-be removed |
|
|
39
|
-
| `Removed` | Removed features |
|
|
40
|
-
| `Fixed` | Bug fixes |
|
|
41
|
-
| `Security` | Security fixes |
|
|
42
|
-
|
|
43
|
-
## Entry Style
|
|
44
|
-
|
|
45
|
-
### Good Entry
|
|
46
|
-
```
|
|
47
|
-
- Add OAuth2 authentication support (#42)
|
|
48
|
-
```
|
|
49
|
-
|
|
50
|
-
### Bad Entry
|
|
51
|
-
```
|
|
52
|
-
- Fixed stuff
|
|
53
|
-
- Updated code
|
|
54
|
-
```
|
|
55
|
-
|
|
56
|
-
## Process
|
|
57
|
-
|
|
58
|
-
1. Read PR description from SENTINEL's final-review.md
|
|
59
|
-
2. Categorize changes
|
|
60
|
-
3. Write concise, user-focused entry
|
|
61
|
-
4. Place under `[Unreleased]` section
|
|
62
|
-
5. Commit with message: `docs: update CHANGELOG for T-{id}`
|
|
63
|
-
|
|
64
|
-
## Release
|
|
65
|
-
|
|
66
|
-
When version is released:
|
|
67
|
-
1. Rename `[Unreleased]` to `[version] - date`
|
|
68
|
-
2. Add new `[Unreleased]` section
|
|
69
|
-
3. Tag release in git
|
|
@@ -1,33 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: doc-coauthoring
|
|
3
|
-
description: Advanced workflow for iterative documentation refinement and reader testing.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# LORE Doc Co-Authoring Skill
|
|
7
|
-
|
|
8
|
-
Use this skill when tasked with creating or refining complex documentation. This workflow ensures that the final output is contextually accurate and reader-friendly.
|
|
9
|
-
|
|
10
|
-
## Workflow Stages
|
|
11
|
-
|
|
12
|
-
### Stage 1: Context Gathering
|
|
13
|
-
|
|
14
|
-
- **Identify Goals**: What is the purpose of the document? Who is the audience?
|
|
15
|
-
- **Gather Info**: Interview the user or research the codebase to capture all necessary details.
|
|
16
|
-
|
|
17
|
-
### Stage 2: Refinement & Structure
|
|
18
|
-
|
|
19
|
-
- **Iterative Drafting**: Start with a structure and refine it based on feedback.
|
|
20
|
-
- **Gap Check**: Identify missing information and resolve contradictions.
|
|
21
|
-
- **Drafting**: Write clear, professional content.
|
|
22
|
-
|
|
23
|
-
### Stage 3: Reader Testing
|
|
24
|
-
|
|
25
|
-
- **Predict Reader Questions**: What will the reader be confused about?
|
|
26
|
-
- **Sub-Agent Testing**: If possible, ask a sub-agent to "read" the doc and provide feedback.
|
|
27
|
-
- **Iterate**: Fix issues identified during testing.
|
|
28
|
-
|
|
29
|
-
## Quality Standards
|
|
30
|
-
|
|
31
|
-
- Clarity, conciseness, and accuracy are paramount.
|
|
32
|
-
- Maintain a consistent tone throughout the document.
|
|
33
|
-
- Use visual hierarchy (headers, lists, alerts) to improve readability.
|
|
@@ -1,57 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: documentation
|
|
3
|
-
description: Skill for maintaining project documentation
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Documentation Skill
|
|
7
|
-
|
|
8
|
-
## Documentation Types
|
|
9
|
-
|
|
10
|
-
### User Documentation
|
|
11
|
-
- `README.md`: Project overview, setup, usage
|
|
12
|
-
- `docs/usage/`: How-to guides
|
|
13
|
-
- `docs/api/`: API reference
|
|
14
|
-
|
|
15
|
-
### Developer Documentation
|
|
16
|
-
- `CONTRIBUTING.md`: Contribution guidelines
|
|
17
|
-
- `docs/architecture/`: System design
|
|
18
|
-
- `.agent/standards/`: Coding standards
|
|
19
|
-
|
|
20
|
-
### Changelog
|
|
21
|
-
- `CHANGELOG.md`: User-facing changes
|
|
22
|
-
|
|
23
|
-
## When to Update
|
|
24
|
-
|
|
25
|
-
Update documentation when:
|
|
26
|
-
- New feature added
|
|
27
|
-
- Breaking change introduced
|
|
28
|
-
- API modified
|
|
29
|
-
- Configuration changed
|
|
30
|
-
- Dependencies updated
|
|
31
|
-
|
|
32
|
-
## Documentation Style
|
|
33
|
-
|
|
34
|
-
### README Updates
|
|
35
|
-
- Keep concise
|
|
36
|
-
- Update examples
|
|
37
|
-
- Reflect current API
|
|
38
|
-
|
|
39
|
-
### API Documentation
|
|
40
|
-
- Document all public interfaces
|
|
41
|
-
- Include examples
|
|
42
|
-
- Document error conditions
|
|
43
|
-
|
|
44
|
-
### Architecture Docs
|
|
45
|
-
- Update diagrams if structure changed
|
|
46
|
-
- Document new patterns
|
|
47
|
-
- Update decision records
|
|
48
|
-
|
|
49
|
-
## Commit Format
|
|
50
|
-
|
|
51
|
-
```
|
|
52
|
-
docs: update README for new auth feature
|
|
53
|
-
|
|
54
|
-
- Add OAuth2 setup instructions
|
|
55
|
-
- Update configuration example
|
|
56
|
-
- Add troubleshooting section
|
|
57
|
-
```
|
|
@@ -1,20 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: docx
|
|
3
|
-
description: Advanced document generation, analysis, and refinement for team reports and external docs.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# LORE Advanced Document Skill
|
|
7
|
-
|
|
8
|
-
Use this skill when processing Word documents (.docx) or generating formal reports in document formats.
|
|
9
|
-
|
|
10
|
-
## Capabilities
|
|
11
|
-
|
|
12
|
-
- **Structure Analysis**: Verify document hierarchy and style consistency.
|
|
13
|
-
- **New Doc Generation**: Create professional reports from markdown context.
|
|
14
|
-
- **XML Refinement**: Perform low-level XML edits for tracking changes or complex formatting (Table of Contents, Headers).
|
|
15
|
-
|
|
16
|
-
## Critical Rules
|
|
17
|
-
|
|
18
|
-
- **No Unicode Bullets**: Always use standard list formatting.
|
|
19
|
-
- **Style Overrides**: Ensure headers match the Brand Style Guidelines.
|
|
20
|
-
- **Table Formatting**: Use consistent borders and cell padding for readability.
|
|
@@ -1,20 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: pdf
|
|
3
|
-
description: Advanced PDF processing, including creation, analysis, text extraction, and watermarking.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# LORE Advanced PDF Skill
|
|
7
|
-
|
|
8
|
-
Use this skill to process incoming PDF reference material or to generate formal, secure PDF outputs.
|
|
9
|
-
|
|
10
|
-
## Processing Tasks
|
|
11
|
-
|
|
12
|
-
- **Extraction**: Extract text and tables from complex PDF layouts using `pdfplumber`.
|
|
13
|
-
- **Generation**: Create formal reports with consistent branding using `reportlab`.
|
|
14
|
-
- **Security**: Apply watermarking or password protection to sensitive documents.
|
|
15
|
-
|
|
16
|
-
## Quality Standards
|
|
17
|
-
|
|
18
|
-
- Ensure all generated PDFs are searchable (OCR/embedded text).
|
|
19
|
-
- Maintain high-resolution assets for images and charts within the PDF.
|
|
20
|
-
- Follow the visual identity from `Brand & Style Guidelines`.
|
|
@@ -1,23 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: pptx
|
|
3
|
-
description: Professional presentation design and generation using a theme-first approach.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# LORE Presentation Design Skill
|
|
7
|
-
|
|
8
|
-
Use this skill to create high-impact, professional slide decks (.pptx) from project data or documentation.
|
|
9
|
-
|
|
10
|
-
## Design Workflow
|
|
11
|
-
|
|
12
|
-
1. **Choose a Theme**: Select an established goal (see `theme-factory`) or define a new one.
|
|
13
|
-
2. **Slide Architecture**:
|
|
14
|
-
- One primary idea per slide.
|
|
15
|
-
- Use high-quality typography and consistent color palettes.
|
|
16
|
-
- Maintain a 16:9 aspect ratio.
|
|
17
|
-
3. **Execution**: Use `python-pptx` or equivalent libraries to generate the deck.
|
|
18
|
-
|
|
19
|
-
## Quality Assurance
|
|
20
|
-
|
|
21
|
-
- **Visual QA**: Check for text overflows, color contrast, and font consistency.
|
|
22
|
-
- **Content QA**: Ensure the message flows logically across the deck.
|
|
23
|
-
- **Brand Alignment**: Follow the `Brand & Style Guidelines` strictly.
|
|
@@ -1,20 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: theme-factory
|
|
3
|
-
description: Professional visual styling and theming for AgentFlow documentation and reports.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# LORE Theme & Styling Skill
|
|
7
|
-
|
|
8
|
-
Use this skill to apply consistent, professional themes to all documentation, changelogs, and generated reports.
|
|
9
|
-
|
|
10
|
-
## Themes & Atmosphere
|
|
11
|
-
|
|
12
|
-
- **The "Agentic" Theme**: Blue/Silver/Dark Grey. High-tech, professional.
|
|
13
|
-
- **The "Focus" Theme**: Monochrome/High-Contrast. Minimalist, objective.
|
|
14
|
-
- **The "Warning" Theme**: Amber/Black. Used for critical alerts or post-mortem reports.
|
|
15
|
-
|
|
16
|
-
## Styling Rules
|
|
17
|
-
|
|
18
|
-
- Apply font pairings consistently (Display for headers, Serif/Sans for body).
|
|
19
|
-
- Use color accents for data visualization and call-to-action blocks.
|
|
20
|
-
- Ensure all styling enhances readability and doesn't distract from the content.
|
|
@@ -1,20 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: xlsx
|
|
3
|
-
description: Advanced Excel document creation, editing, and technical data analysis.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# LORE Advanced Excel Skill
|
|
7
|
-
|
|
8
|
-
Use this skill for generating complex reports that involve budgeting, technical metrics, or financial modeling.
|
|
9
|
-
|
|
10
|
-
## Core Requirements
|
|
11
|
-
|
|
12
|
-
- **Use Formulas**: NEVER hardcode values that can be calculated.
|
|
13
|
-
- **Data Integrity**: Use `pandas` for large dataset analysis before writing to Excel.
|
|
14
|
-
- **Formatting**: Apply professional formatting (headers, borders, number formats) for all outputs.
|
|
15
|
-
|
|
16
|
-
## Analysis Patterns
|
|
17
|
-
|
|
18
|
-
- **Summary Sheets**: Create high-level dashboards at the beginning of the workbook.
|
|
19
|
-
- **Validation**: Include formula testing strategies to ensure zero erroneous calculations.
|
|
20
|
-
- **Documentation**: Comment complex formulas or data sources within the sheet.
|