添加deepseek api 支持
This commit is contained in:
zhaoyanchao
parent
7fa548e273
commit
94383375d6
|
|
@ -0,0 +1,156 @@
|
|||
---
|
||||
name: openspec-apply-change
|
||||
description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.2.0"
|
||||
---
|
||||
|
||||
Implement tasks from an OpenSpec change.
|
||||
|
||||
**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
|
||||
|
||||
**Steps**
|
||||
|
||||
1. **Select the change**
|
||||
|
||||
If a name is provided, use it. Otherwise:
|
||||
- Infer from conversation context if the user mentioned a change
|
||||
- Auto-select if only one active change exists
|
||||
- If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
|
||||
|
||||
Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
|
||||
|
||||
2. **Check status to understand the schema**
|
||||
```bash
|
||||
openspec status --change "<name>" --json
|
||||
```
|
||||
Parse the JSON to understand:
|
||||
- `schemaName`: The workflow being used (e.g., "spec-driven")
|
||||
- Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
|
||||
|
||||
3. **Get apply instructions**
|
||||
|
||||
```bash
|
||||
openspec instructions apply --change "<name>" --json
|
||||
```
|
||||
|
||||
This returns:
|
||||
- Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
|
||||
- Progress (total, complete, remaining)
|
||||
- Task list with status
|
||||
- Dynamic instruction based on current state
|
||||
|
||||
**Handle states:**
|
||||
- If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
|
||||
- If `state: "all_done"`: congratulate, suggest archive
|
||||
- Otherwise: proceed to implementation
|
||||
|
||||
4. **Read context files**
|
||||
|
||||
Read the files listed in `contextFiles` from the apply instructions output.
|
||||
The files depend on the schema being used:
|
||||
- **spec-driven**: proposal, specs, design, tasks
|
||||
- Other schemas: follow the contextFiles from CLI output
|
||||
|
||||
5. **Show current progress**
|
||||
|
||||
Display:
|
||||
- Schema being used
|
||||
- Progress: "N/M tasks complete"
|
||||
- Remaining tasks overview
|
||||
- Dynamic instruction from CLI
|
||||
|
||||
6. **Implement tasks (loop until done or blocked)**
|
||||
|
||||
For each pending task:
|
||||
- Show which task is being worked on
|
||||
- Make the code changes required
|
||||
- Keep changes minimal and focused
|
||||
- Mark task complete in the tasks file: `- [ ]` → `- [x]`
|
||||
- Continue to next task
|
||||
|
||||
**Pause if:**
|
||||
- Task is unclear → ask for clarification
|
||||
- Implementation reveals a design issue → suggest updating artifacts
|
||||
- Error or blocker encountered → report and wait for guidance
|
||||
- User interrupts
|
||||
|
||||
7. **On completion or pause, show status**
|
||||
|
||||
Display:
|
||||
- Tasks completed this session
|
||||
- Overall progress: "N/M tasks complete"
|
||||
- If all done: suggest archive
|
||||
- If paused: explain why and wait for guidance
|
||||
|
||||
**Output During Implementation**
|
||||
|
||||
```
|
||||
## Implementing: <change-name> (schema: <schema-name>)
|
||||
|
||||
Working on task 3/7: <task description>
|
||||
[...implementation happening...]
|
||||
✓ Task complete
|
||||
|
||||
Working on task 4/7: <task description>
|
||||
[...implementation happening...]
|
||||
✓ Task complete
|
||||
```
|
||||
|
||||
**Output On Completion**
|
||||
|
||||
```
|
||||
## Implementation Complete
|
||||
|
||||
**Change:** <change-name>
|
||||
**Schema:** <schema-name>
|
||||
**Progress:** 7/7 tasks complete ✓
|
||||
|
||||
### Completed This Session
|
||||
- [x] Task 1
|
||||
- [x] Task 2
|
||||
...
|
||||
|
||||
All tasks complete! Ready to archive this change.
|
||||
```
|
||||
|
||||
**Output On Pause (Issue Encountered)**
|
||||
|
||||
```
|
||||
## Implementation Paused
|
||||
|
||||
**Change:** <change-name>
|
||||
**Schema:** <schema-name>
|
||||
**Progress:** 4/7 tasks complete
|
||||
|
||||
### Issue Encountered
|
||||
<description of the issue>
|
||||
|
||||
**Options:**
|
||||
1. <option 1>
|
||||
2. <option 2>
|
||||
3. Other approach
|
||||
|
||||
What would you like to do?
|
||||
```
|
||||
|
||||
**Guardrails**
|
||||
- Keep going through tasks until done or blocked
|
||||
- Always read context files before starting (from the apply instructions output)
|
||||
- If task is ambiguous, pause and ask before implementing
|
||||
- If implementation reveals issues, pause and suggest artifact updates
|
||||
- Keep code changes minimal and scoped to each task
|
||||
- Update task checkbox immediately after completing each task
|
||||
- Pause on errors, blockers, or unclear requirements - don't guess
|
||||
- Use contextFiles from CLI output, don't assume specific file names
|
||||
|
||||
**Fluid Workflow Integration**
|
||||
|
||||
This skill supports the "actions on a change" model:
|
||||
|
||||
- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
|
||||
- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
|
||||
|
|
@ -0,0 +1,114 @@
|
|||
---
|
||||
name: openspec-archive-change
|
||||
description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.2.0"
|
||||
---
|
||||
|
||||
Archive a completed change in the experimental workflow.
|
||||
|
||||
**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
|
||||
|
||||
**Steps**
|
||||
|
||||
1. **If no change name provided, prompt for selection**
|
||||
|
||||
Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
|
||||
|
||||
Show only active changes (not already archived).
|
||||
Include the schema used for each change if available.
|
||||
|
||||
**IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
|
||||
|
||||
2. **Check artifact completion status**
|
||||
|
||||
Run `openspec status --change "<name>" --json` to check artifact completion.
|
||||
|
||||
Parse the JSON to understand:
|
||||
- `schemaName`: The workflow being used
|
||||
- `artifacts`: List of artifacts with their status (`done` or other)
|
||||
|
||||
**If any artifacts are not `done`:**
|
||||
- Display warning listing incomplete artifacts
|
||||
- Use **AskUserQuestion tool** to confirm user wants to proceed
|
||||
- Proceed if user confirms
|
||||
|
||||
3. **Check task completion status**
|
||||
|
||||
Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
|
||||
|
||||
Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
|
||||
|
||||
**If incomplete tasks found:**
|
||||
- Display warning showing count of incomplete tasks
|
||||
- Use **AskUserQuestion tool** to confirm user wants to proceed
|
||||
- Proceed if user confirms
|
||||
|
||||
**If no tasks file exists:** Proceed without task-related warning.
|
||||
|
||||
4. **Assess delta spec sync state**
|
||||
|
||||
Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
|
||||
|
||||
**If delta specs exist:**
|
||||
- Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
|
||||
- Determine what changes would be applied (adds, modifications, removals, renames)
|
||||
- Show a combined summary before prompting
|
||||
|
||||
**Prompt options:**
|
||||
- If changes needed: "Sync now (recommended)", "Archive without syncing"
|
||||
- If already synced: "Archive now", "Sync anyway", "Cancel"
|
||||
|
||||
If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
|
||||
|
||||
5. **Perform the archive**
|
||||
|
||||
Create the archive directory if it doesn't exist:
|
||||
```bash
|
||||
mkdir -p openspec/changes/archive
|
||||
```
|
||||
|
||||
Generate target name using current date: `YYYY-MM-DD-<change-name>`
|
||||
|
||||
**Check if target already exists:**
|
||||
- If yes: Fail with error, suggest renaming existing archive or using different date
|
||||
- If no: Move the change directory to archive
|
||||
|
||||
```bash
|
||||
mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
|
||||
```
|
||||
|
||||
6. **Display summary**
|
||||
|
||||
Show archive completion summary including:
|
||||
- Change name
|
||||
- Schema that was used
|
||||
- Archive location
|
||||
- Whether specs were synced (if applicable)
|
||||
- Note about any warnings (incomplete artifacts/tasks)
|
||||
|
||||
**Output On Success**
|
||||
|
||||
```
|
||||
## Archive Complete
|
||||
|
||||
**Change:** <change-name>
|
||||
**Schema:** <schema-name>
|
||||
**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
|
||||
**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
|
||||
|
||||
All artifacts complete. All tasks complete.
|
||||
```
|
||||
|
||||
**Guardrails**
|
||||
- Always prompt for change selection if not provided
|
||||
- Use artifact graph (openspec status --json) for completion checking
|
||||
- Don't block archive on warnings - just inform and confirm
|
||||
- Preserve .openspec.yaml when moving to archive (it moves with the directory)
|
||||
- Show clear summary of what happened
|
||||
- If sync is requested, use openspec-sync-specs approach (agent-driven)
|
||||
- If delta specs exist, always run the sync assessment and show the combined summary before prompting
|
||||
|
|
@ -0,0 +1,288 @@
|
|||
---
|
||||
name: openspec-explore
|
||||
description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.2.0"
|
||||
---
|
||||
|
||||
Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
|
||||
|
||||
**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
|
||||
|
||||
**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
|
||||
|
||||
---
|
||||
|
||||
## The Stance
|
||||
|
||||
- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
|
||||
- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
|
||||
- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
|
||||
- **Adaptive** - Follow interesting threads, pivot when new information emerges
|
||||
- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
|
||||
- **Grounded** - Explore the actual codebase when relevant, don't just theorize
|
||||
|
||||
---
|
||||
|
||||
## What You Might Do
|
||||
|
||||
Depending on what the user brings, you might:
|
||||
|
||||
**Explore the problem space**
|
||||
- Ask clarifying questions that emerge from what they said
|
||||
- Challenge assumptions
|
||||
- Reframe the problem
|
||||
- Find analogies
|
||||
|
||||
**Investigate the codebase**
|
||||
- Map existing architecture relevant to the discussion
|
||||
- Find integration points
|
||||
- Identify patterns already in use
|
||||
- Surface hidden complexity
|
||||
|
||||
**Compare options**
|
||||
- Brainstorm multiple approaches
|
||||
- Build comparison tables
|
||||
- Sketch tradeoffs
|
||||
- Recommend a path (if asked)
|
||||
|
||||
**Visualize**
|
||||
```
|
||||
┌─────────────────────────────────────────┐
|
||||
│ Use ASCII diagrams liberally │
|
||||
├─────────────────────────────────────────┤
|
||||
│ │
|
||||
│ ┌────────┐ ┌────────┐ │
|
||||
│ │ State │────────▶│ State │ │
|
||||
│ │ A │ │ B │ │
|
||||
│ └────────┘ └────────┘ │
|
||||
│ │
|
||||
│ System diagrams, state machines, │
|
||||
│ data flows, architecture sketches, │
|
||||
│ dependency graphs, comparison tables │
|
||||
│ │
|
||||
└─────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**Surface risks and unknowns**
|
||||
- Identify what could go wrong
|
||||
- Find gaps in understanding
|
||||
- Suggest spikes or investigations
|
||||
|
||||
---
|
||||
|
||||
## OpenSpec Awareness
|
||||
|
||||
You have full context of the OpenSpec system. Use it naturally, don't force it.
|
||||
|
||||
### Check for context
|
||||
|
||||
At the start, quickly check what exists:
|
||||
```bash
|
||||
openspec list --json
|
||||
```
|
||||
|
||||
This tells you:
|
||||
- If there are active changes
|
||||
- Their names, schemas, and status
|
||||
- What the user might be working on
|
||||
|
||||
### When no change exists
|
||||
|
||||
Think freely. When insights crystallize, you might offer:
|
||||
|
||||
- "This feels solid enough to start a change. Want me to create a proposal?"
|
||||
- Or keep exploring - no pressure to formalize
|
||||
|
||||
### When a change exists
|
||||
|
||||
If the user mentions a change or you detect one is relevant:
|
||||
|
||||
1. **Read existing artifacts for context**
|
||||
- `openspec/changes/<name>/proposal.md`
|
||||
- `openspec/changes/<name>/design.md`
|
||||
- `openspec/changes/<name>/tasks.md`
|
||||
- etc.
|
||||
|
||||
2. **Reference them naturally in conversation**
|
||||
- "Your design mentions using Redis, but we just realized SQLite fits better..."
|
||||
- "The proposal scopes this to premium users, but we're now thinking everyone..."
|
||||
|
||||
3. **Offer to capture when decisions are made**
|
||||
|
||||
| Insight Type | Where to Capture |
|
||||
|--------------|------------------|
|
||||
| New requirement discovered | `specs/<capability>/spec.md` |
|
||||
| Requirement changed | `specs/<capability>/spec.md` |
|
||||
| Design decision made | `design.md` |
|
||||
| Scope changed | `proposal.md` |
|
||||
| New work identified | `tasks.md` |
|
||||
| Assumption invalidated | Relevant artifact |
|
||||
|
||||
Example offers:
|
||||
- "That's a design decision. Capture it in design.md?"
|
||||
- "This is a new requirement. Add it to specs?"
|
||||
- "This changes scope. Update the proposal?"
|
||||
|
||||
4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
|
||||
|
||||
---
|
||||
|
||||
## What You Don't Have To Do
|
||||
|
||||
- Follow a script
|
||||
- Ask the same questions every time
|
||||
- Produce a specific artifact
|
||||
- Reach a conclusion
|
||||
- Stay on topic if a tangent is valuable
|
||||
- Be brief (this is thinking time)
|
||||
|
||||
---
|
||||
|
||||
## Handling Different Entry Points
|
||||
|
||||
**User brings a vague idea:**
|
||||
```
|
||||
User: I'm thinking about adding real-time collaboration
|
||||
|
||||
You: Real-time collab is a big space. Let me think about this...
|
||||
|
||||
COLLABORATION SPECTRUM
|
||||
════════════════════════════════════════════
|
||||
|
||||
Awareness Coordination Sync
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
┌────────┐ ┌────────┐ ┌────────┐
|
||||
│Presence│ │Cursors │ │ CRDT │
|
||||
│ "3 │ │ Multi │ │Conflict│
|
||||
│online" │ │ select │ │ free │
|
||||
└────────┘ └────────┘ └────────┘
|
||||
│ │ │
|
||||
trivial moderate complex
|
||||
|
||||
Where's your head at?
|
||||
```
|
||||
|
||||
**User brings a specific problem:**
|
||||
```
|
||||
User: The auth system is a mess
|
||||
|
||||
You: [reads codebase]
|
||||
|
||||
┌─────────────────────────────────────────────┐
|
||||
│ CURRENT AUTH FLOW │
|
||||
└─────────────────────────────────────────────┘
|
||||
│
|
||||
┌─────────────┼─────────────┐
|
||||
▼ ▼ ▼
|
||||
┌─────────┐ ┌─────────┐ ┌─────────┐
|
||||
│ Google │ │ GitHub │ │ Email │
|
||||
│ OAuth │ │ OAuth │ │ Magic │
|
||||
└────┬────┘ └────┬────┘ └────┬────┘
|
||||
│ │ │
|
||||
└─────────────┼─────────────┘
|
||||
▼
|
||||
┌───────────┐
|
||||
│ Session │
|
||||
└─────┬─────┘
|
||||
│
|
||||
▼
|
||||
┌───────────┐
|
||||
│ Perms │
|
||||
└───────────┘
|
||||
|
||||
I see three tangles. Which one's burning?
|
||||
```
|
||||
|
||||
**User is stuck mid-implementation:**
|
||||
```
|
||||
User: /opsx:explore add-auth-system
|
||||
The OAuth integration is more complex than expected
|
||||
|
||||
You: [reads change artifacts]
|
||||
|
||||
You're on task 4: "Implement OAuth flow"
|
||||
|
||||
Let me trace what's involved...
|
||||
|
||||
[draws diagram, explores options, suggests paths]
|
||||
|
||||
Want to update the design to reflect this?
|
||||
Or add a spike task to investigate?
|
||||
```
|
||||
|
||||
**User wants to compare options:**
|
||||
```
|
||||
User: Should we use Postgres or SQLite?
|
||||
|
||||
You: Generic answer is boring. What's the context?
|
||||
|
||||
User: A CLI tool that tracks local dev environments
|
||||
|
||||
You: That changes everything.
|
||||
|
||||
┌─────────────────────────────────────────────────┐
|
||||
│ CLI TOOL DATA STORAGE │
|
||||
└─────────────────────────────────────────────────┘
|
||||
|
||||
Key constraints:
|
||||
• No daemon running
|
||||
• Must work offline
|
||||
• Single user
|
||||
|
||||
SQLite Postgres
|
||||
Deployment embedded ✓ needs server ✗
|
||||
Offline yes ✓ no ✗
|
||||
Single file yes ✓ no ✗
|
||||
|
||||
SQLite. Not even close.
|
||||
|
||||
Unless... is there a sync component?
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Ending Discovery
|
||||
|
||||
There's no required ending. Discovery might:
|
||||
|
||||
- **Flow into a proposal**: "Ready to start? I can create a change proposal."
|
||||
- **Result in artifact updates**: "Updated design.md with these decisions"
|
||||
- **Just provide clarity**: User has what they need, moves on
|
||||
- **Continue later**: "We can pick this up anytime"
|
||||
|
||||
When it feels like things are crystallizing, you might summarize:
|
||||
|
||||
```
|
||||
## What We Figured Out
|
||||
|
||||
**The problem**: [crystallized understanding]
|
||||
|
||||
**The approach**: [if one emerged]
|
||||
|
||||
**Open questions**: [if any remain]
|
||||
|
||||
**Next steps** (if ready):
|
||||
- Create a change proposal
|
||||
- Keep exploring: just keep talking
|
||||
```
|
||||
|
||||
But this summary is optional. Sometimes the thinking IS the value.
|
||||
|
||||
---
|
||||
|
||||
## Guardrails
|
||||
|
||||
- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
|
||||
- **Don't fake understanding** - If something is unclear, dig deeper
|
||||
- **Don't rush** - Discovery is thinking time, not task time
|
||||
- **Don't force structure** - Let patterns emerge naturally
|
||||
- **Don't auto-capture** - Offer to save insights, don't just do it
|
||||
- **Do visualize** - A good diagram is worth many paragraphs
|
||||
- **Do explore the codebase** - Ground discussions in reality
|
||||
- **Do question assumptions** - Including the user's and your own
|
||||
|
|
@ -0,0 +1,110 @@
|
|||
---
|
||||
name: openspec-propose
|
||||
description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: openspec
|
||||
version: "1.0"
|
||||
generatedBy: "1.2.0"
|
||||
---
|
||||
|
||||
Propose a new change - create the change and generate all artifacts in one step.
|
||||
|
||||
I'll create a change with artifacts:
|
||||
- proposal.md (what & why)
|
||||
- design.md (how)
|
||||
- tasks.md (implementation steps)
|
||||
|
||||
When ready to implement, run /opsx:apply
|
||||
|
||||
---
|
||||
|
||||
**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
|
||||
|
||||
**Steps**
|
||||
|
||||
1. **If no clear input provided, ask what they want to build**
|
||||
|
||||
Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
|
||||
> "What change do you want to work on? Describe what you want to build or fix."
|
||||
|
||||
From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
|
||||
|
||||
**IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
|
||||
|
||||
2. **Create the change directory**
|
||||
```bash
|
||||
openspec new change "<name>"
|
||||
```
|
||||
This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
|
||||
|
||||
3. **Get the artifact build order**
|
||||
```bash
|
||||
openspec status --change "<name>" --json
|
||||
```
|
||||
Parse the JSON to get:
|
||||
- `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
|
||||
- `artifacts`: list of all artifacts with their status and dependencies
|
||||
|
||||
4. **Create artifacts in sequence until apply-ready**
|
||||
|
||||
Use the **TodoWrite tool** to track progress through the artifacts.
|
||||
|
||||
Loop through artifacts in dependency order (artifacts with no pending dependencies first):
|
||||
|
||||
a. **For each artifact that is `ready` (dependencies satisfied)**:
|
||||
- Get instructions:
|
||||
```bash
|
||||
openspec instructions <artifact-id> --change "<name>" --json
|
||||
```
|
||||
- The instructions JSON includes:
|
||||
- `context`: Project background (constraints for you - do NOT include in output)
|
||||
- `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
|
||||
- `template`: The structure to use for your output file
|
||||
- `instruction`: Schema-specific guidance for this artifact type
|
||||
- `outputPath`: Where to write the artifact
|
||||
- `dependencies`: Completed artifacts to read for context
|
||||
- Read any completed dependency files for context
|
||||
- Create the artifact file using `template` as the structure
|
||||
- Apply `context` and `rules` as constraints - but do NOT copy them into the file
|
||||
- Show brief progress: "Created <artifact-id>"
|
||||
|
||||
b. **Continue until all `applyRequires` artifacts are complete**
|
||||
- After creating each artifact, re-run `openspec status --change "<name>" --json`
|
||||
- Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
|
||||
- Stop when all `applyRequires` artifacts are done
|
||||
|
||||
c. **If an artifact requires user input** (unclear context):
|
||||
- Use **AskUserQuestion tool** to clarify
|
||||
- Then continue with creation
|
||||
|
||||
5. **Show final status**
|
||||
```bash
|
||||
openspec status --change "<name>"
|
||||
```
|
||||
|
||||
**Output**
|
||||
|
||||
After completing all artifacts, summarize:
|
||||
- Change name and location
|
||||
- List of artifacts created with brief descriptions
|
||||
- What's ready: "All artifacts created! Ready for implementation."
|
||||
- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
|
||||
|
||||
**Artifact Creation Guidelines**
|
||||
|
||||
- Follow the `instruction` field from `openspec instructions` for each artifact type
|
||||
- The schema defines what each artifact should contain - follow it
|
||||
- Read dependency artifacts for context before creating new ones
|
||||
- Use `template` as the structure for your output file - fill in its sections
|
||||
- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
|
||||
- Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
|
||||
- These guide what you write, but should never appear in the output
|
||||
|
||||
**Guardrails**
|
||||
- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
|
||||
- Always read dependency artifacts before creating a new one
|
||||
- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
|
||||
- If a change with that name already exists, ask if user wants to continue it or create a new one
|
||||
- Verify each artifact file exists after writing before proceeding to next
|
||||
150
PHILOSOPHY.md
150
PHILOSOPHY.md
|
|
@ -1,114 +1,114 @@
|
|||
# Claw Code Philosophy
|
||||
# Claw Code 哲学
|
||||
|
||||
## Stop Staring at the Files
|
||||
## 不要只盯着文件看
|
||||
|
||||
If you only look at the generated files in this repository, you are looking at the wrong layer.
|
||||
如果你只看这个仓库里生成的那些文件，那你就看错了层面。
|
||||
|
||||
The Python rewrite was a byproduct. The Rust rewrite was also a byproduct. The real thing worth studying is the **system that produced them**: a clawhip-based coordination loop where humans give direction and autonomous claws execute the work.
|
||||
Python 重写只是一个副产品。Rust 重写也同样如此。真正值得研究的是背后那个**产生这一切的系统**：一个基于 clawhip 的协同循环，人类给出方向，多个 autonomous claws 负责执行工作。
|
||||
|
||||
Claw Code is not just a codebase. It is a public demonstration of what happens when:
|
||||
Claw Code 不只是一个代码库。它是一个公开的示范，展示了当以下条件具备时会发生什么：
|
||||
|
||||
- a human provides clear direction,
|
||||
- multiple coding agents coordinate in parallel,
|
||||
- notification routing is pushed out of the agent context window,
|
||||
- planning, execution, review, and retry loops are automated,
|
||||
- and the human does **not** sit in a terminal micromanaging every step.
|
||||
- 人类提供清晰的方向；
|
||||
- 多个编码 agent 并行协作；
|
||||
- 通知路由被移出 agent 的上下文窗口；
|
||||
- 规划、执行、评审、重试循环实现自动化；
|
||||
- 人类**并不**坐在终端里一步步微观管理。
|
||||
|
||||
## The Human Interface Is Discord
|
||||
## 人类的界面是 Discord
|
||||
|
||||
The important interface here is not tmux, Vim, SSH, or a terminal multiplexer.
|
||||
重要的界面不是 tmux、Vim、SSH 或者终端复用器。
|
||||
|
||||
The real human interface is a Discord channel.
|
||||
真正的人类界面是一个 Discord 频道。
|
||||
|
||||
A person can type a sentence from a phone, walk away, sleep, or do something else. The claws read the directive, break it into tasks, assign roles, write code, run tests, argue over failures, recover, and push when the work passes.
|
||||
一个人可以用手机打出一句话，然后走开、睡觉、或者去做别的事。claws 读取指令，拆解成任务，分配角色，编写代码，运行测试，争论失败，自动恢复，在所有工作通过后推送代码。
|
||||
|
||||
That is the philosophy: **humans set direction; claws perform the labor.**
|
||||
这就是哲学的核心：**人类设定方向；claws 承担劳动。**
|
||||
|
||||
## The Three-Part System
|
||||
## 三部分系统
|
||||
|
||||
### 1. OmX (`oh-my-codex`)
|
||||
[oh-my-codex](https://github.com/Yeachan-Heo/oh-my-codex) provides the workflow layer.
|
||||
### 1. OmX（`oh-my-codex`）
|
||||
[oh-my-codex](https://github.com/Yeachan-Heo/oh-my-codex) 提供了工作流层。
|
||||
|
||||
It turns short directives into structured execution:
|
||||
- planning keywords
|
||||
- execution modes
|
||||
- persistent verification loops
|
||||
- parallel multi-agent workflows
|
||||
它把简短的指令转化为结构化的执行过程：
|
||||
- 规划关键词
|
||||
- 执行模式
|
||||
- 持久化的验证循环
|
||||
- 并行的多 agent 工作流
|
||||
|
||||
This is the layer that converts a sentence into a repeatable work protocol.
|
||||
这一层将一句话转化成一个可重复的工作协议。
|
||||
|
||||
### 2. clawhip
|
||||
[clawhip](https://github.com/Yeachan-Heo/clawhip) is the event and notification router.
|
||||
[clawhip](https://github.com/Yeachan-Heo/clawhip) 是事件与通知路由器。
|
||||
|
||||
It watches:
|
||||
- git commits
|
||||
- tmux sessions
|
||||
- GitHub issues and PRs
|
||||
- agent lifecycle events
|
||||
- channel delivery
|
||||
它监听：
|
||||
- git 提交
|
||||
- tmux 会话
|
||||
- GitHub issues 和 PRs
|
||||
- agent 生命周期事件
|
||||
- 频道消息分发
|
||||
|
||||
Its job is to keep monitoring and delivery **outside** the coding agent's context window so the agents can stay focused on implementation instead of status formatting and notification routing.
|
||||
它的职责是把监控和通知的负担**放到 coding agent 的上下文窗口之外**，让 agents 能集中精力于实现本身，而不是处理状态格式化和通知路由。
|
||||
|
||||
### 3. OmO (`oh-my-openagent`)
|
||||
[oh-my-openagent](https://github.com/code-yeongyu/oh-my-openagent) handles multi-agent coordination.
|
||||
### 3. OmO（`oh-my-openagent`）
|
||||
[oh-my-openagent](https://github.com/code-yeongyu/oh-my-openagent) 处理多 agent 协作。
|
||||
|
||||
This is where planning, handoffs, disagreement resolution, and verification loops happen across agents.
|
||||
这里包含了规划、任务交接、分歧解决以及跨 agents 的验证循环。
|
||||
|
||||
When Architect, Executor, and Reviewer disagree, OmO provides the structure for that loop to converge instead of collapse.
|
||||
当 Architect、Executor 和 Reviewer 出现分歧时，OmO 提供结构化框架让这个循环收敛，而不是崩溃。
|
||||
|
||||
## The Real Bottleneck Changed
|
||||
## 真正的瓶颈已经变了
|
||||
|
||||
The bottleneck is no longer typing speed.
|
||||
瓶颈不再是打字速度。
|
||||
|
||||
When agent systems can rebuild a codebase in hours, the scarce resource becomes:
|
||||
- architectural clarity
|
||||
- task decomposition
|
||||
- judgment
|
||||
- taste
|
||||
- conviction about what is worth building
|
||||
- knowing which parts can be parallelized and which parts must stay constrained
|
||||
当 agent 系统可以在几小时内重新构建一个代码库时，稀缺的资源变成了：
|
||||
- 架构清晰度
|
||||
- 任务拆解能力
|
||||
- 判断力
|
||||
- 品味
|
||||
- 对什么值得构建的笃定
|
||||
- 识别哪些部分可以并行、哪些部分必须保持约束
|
||||
|
||||
A fast agent team does not remove the need for thinking. It makes clear thinking even more valuable.
|
||||
一个快速的 agent 团队不会消除思考的需求。相反，它让清晰的思考变得更有价值。
|
||||
|
||||
## What Claw Code Demonstrates
|
||||
## Claw Code 演示了什么
|
||||
|
||||
Claw Code demonstrates that a repository can be:
|
||||
Claw Code 展示了一个代码库可以：
|
||||
|
||||
- **autonomously built in public**
|
||||
- coordinated by claws/lobsters rather than human pair-programming alone
|
||||
- operated through a chat interface
|
||||
- continuously improved by structured planning/execution/review loops
|
||||
- maintained as a showcase of the coordination layer, not just the output files
|
||||
- **在公开场合被自主构建**
|
||||
- 由 claws/lobsters 协作完成，而不只是人和人结对编程
|
||||
- 通过聊天界面来驱动
|
||||
- 通过结构化的规划/执行/评审循环持续改进
|
||||
- 作为协作层的展示而存在，而不仅仅是输出文件
|
||||
|
||||
The code is evidence.
|
||||
The coordination system is the product lesson.
|
||||
代码是证据。
|
||||
协同系统才是产品层面的经验。
|
||||
|
||||
## What Still Matters
|
||||
## 什么依然重要
|
||||
|
||||
As coding intelligence gets cheaper and more available, the durable differentiators are not raw coding output.
|
||||
随着编码智能变得越来越便宜和易得，持续的差异化因素不再是原始的编码产出。
|
||||
|
||||
What still matters:
|
||||
- product taste
|
||||
- direction
|
||||
- system design
|
||||
- human trust
|
||||
- operational stability
|
||||
- judgment about what to build next
|
||||
依然重要的东西是：
|
||||
- 产品品味
|
||||
- 方向感
|
||||
- 系统设计
|
||||
- 人类的信任
|
||||
- 运营稳定性
|
||||
- 关于下一步构建什么的判断
|
||||
|
||||
In that world, the job of the human is not to out-type the machine.
|
||||
The job of the human is to decide what deserves to exist.
|
||||
在那个世界里，人类的工作不是超过机器的打字速度。
|
||||
人类的工作是决定什么值得存在。
|
||||
|
||||
## Short Version
|
||||
## 短版本
|
||||
|
||||
**Claw Code is a demo of autonomous software development.**
|
||||
**Claw Code 是一个自主软件开发的演示。**
|
||||
|
||||
Humans provide direction.
|
||||
Claws coordinate, build, test, recover, and push.
|
||||
The repository is the artifact.
|
||||
The philosophy is the system behind it.
|
||||
人类提供方向。
|
||||
Claws 协作、构建、测试、恢复、推送。
|
||||
仓库是产物。
|
||||
哲学是背后支撑这一切的系统。
|
||||
|
||||
## Related explanation
|
||||
## 相关解释
|
||||
|
||||
For the longer public explanation behind this philosophy, see:
|
||||
关于这一哲学的更长公开说明，请参考：
|
||||
|
||||
- https://x.com/realsigridjin/status/2039472968624185713
|
||||
- https://x.com/realsigridjin/status/2039472968624185713
|
||||
24
README.md
24
README.md
|
|
@ -1,2 +1,24 @@
|
|||
## 项目介绍
|
||||
本项目是claude code 的rust 版本，基于
|
||||
本项目是claude code 的rust 版本，基于 https://github.com/ultraworkers/claw-code.git 分叉而来。提供可直接下载执行的文件。目前支持linux, macOS 系统。
|
||||
|
||||
## 快速入手
|
||||
1. 在 https://github.com/davids-dot/claw-code/releases 页面下载对应环境的压缩包。
|
||||
2. 解压，把解压产生的文件重命名为claw
|
||||
3. 运行
|
||||
|
||||
### 运行方式
|
||||
1. 使用 百炼平台的apiKey, 模型 glm-5.1
|
||||
```
|
||||
export DASHSCOPE_API_KEY=sk-your-key
|
||||
export ANTHROPIC_MODEL="glm-5.1"
|
||||
|
||||
./claw
|
||||
```
|
||||
|
||||
2. 使用deepseek的apiKey, 模型 qwen-plus
|
||||
```
|
||||
export DEEPSEEK_API_KEY=sk-your-key
|
||||
export DEEPSEEK_MODEL="qwen-plus"
|
||||
|
||||
./claw
|
||||
```
|
||||
7
debug.sh
7
debug.sh
|
|
@ -1,3 +1,10 @@
|
|||
cargo check
|
||||
cargo fmt --all
|
||||
cargo test
|
||||
|
||||
|
||||
|
||||
|
||||
echo $DASHSCOPE_API_KEY
|
||||
echo $ANTHROPIC_MODEL
|
||||
claw "帮我看看这个项目的内容"
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
schema: spec-driven
|
||||
|
||||
# Project context (optional)
|
||||
# This is shown to AI when creating artifacts.
|
||||
# Add your tech stack, conventions, style guides, domain knowledge, etc.
|
||||
# Example:
|
||||
# context: |
|
||||
# Tech stack: TypeScript, React, Node.js
|
||||
# We use conventional commits
|
||||
# Domain: e-commerce platform
|
||||
|
||||
# Per-artifact rules (optional)
|
||||
# Add custom rules for specific artifacts.
|
||||
# Example:
|
||||
# rules:
|
||||
# proposal:
|
||||
# - Keep proposals under 500 words
|
||||
# - Always include a "Non-goals" section
|
||||
# tasks:
|
||||
# - Break tasks into chunks of max 2 hours
|
||||
|
|
@ -39,6 +39,9 @@ impl ProviderClient {
|
|||
Some(meta) if meta.auth_env == "DASHSCOPE_API_KEY" => {
|
||||
OpenAiCompatConfig::dashscope()
|
||||
}
|
||||
Some(meta) if meta.auth_env == "DEEPSEEK_API_KEY" => {
|
||||
OpenAiCompatConfig::deepseek()
|
||||
}
|
||||
_ => {
|
||||
if crate::providers::openai_compat::has_api_key("DASHSCOPE_API_KEY")
|
||||
&& !crate::providers::openai_compat::has_api_key("OPENAI_API_KEY")
|
||||
|
|
|
|||
|
|
@ -223,6 +223,16 @@ pub fn metadata_for_model(model: &str) -> Option<ProviderMetadata> {
|
|||
default_base_url: openai_compat::DEFAULT_DASHSCOPE_BASE_URL,
|
||||
});
|
||||
}
|
||||
// DeepSeek models (deepseek-coder, deepseek-chat, deepseek-reasoner).
|
||||
// Routes deepseek/* and deepseek-* model names to DeepSeek endpoint.
|
||||
if canonical.starts_with("deepseek/") || canonical.starts_with("deepseek-") {
|
||||
return Some(ProviderMetadata {
|
||||
provider: ProviderKind::OpenAi,
|
||||
auth_env: "DEEPSEEK_API_KEY",
|
||||
base_url_env: "DEEPSEEK_BASE_URL",
|
||||
default_base_url: openai_compat::DEFAULT_DEEPSEEK_BASE_URL,
|
||||
});
|
||||
}
|
||||
None
|
||||
}
|
||||
|
||||
|
|
@ -252,6 +262,9 @@ pub fn detect_provider_kind(model: &str) -> ProviderKind {
|
|||
if openai_compat::has_api_key("DASHSCOPE_API_KEY") {
|
||||
return ProviderKind::OpenAi;
|
||||
}
|
||||
if openai_compat::has_api_key("DEEPSEEK_API_KEY") {
|
||||
return ProviderKind::OpenAi;
|
||||
}
|
||||
// Last resort: if OPENAI_BASE_URL is set without OPENAI_API_KEY (some
|
||||
// local providers like Ollama don't require auth), still route there.
|
||||
if std::env::var_os("OPENAI_BASE_URL").is_some() {
|
||||
|
|
@ -363,6 +376,11 @@ const FOREIGN_PROVIDER_ENV_VARS: &[(&str, &str, &str)] = &[
|
|||
"Alibaba DashScope",
|
||||
"prefix your model name with `qwen/` or `qwen-` (e.g. `--model qwen-plus`) so prefix routing selects the DashScope backend",
|
||||
),
|
||||
(
|
||||
"DEEPSEEK_API_KEY",
|
||||
"DeepSeek",
|
||||
"prefix your model name with `deepseek/` or `deepseek-` (e.g. `--model deepseek-coder`) so prefix routing selects the DeepSeek backend",
|
||||
),
|
||||
];
|
||||
|
||||
/// Check whether an env var is set to a non-empty value either in the real
|
||||
|
|
|
|||
|
|
@ -0,0 +1,23 @@
|
|||
use super::OpenAiCompatConfig;
|
||||
|
||||
pub const DEFAULT_DASHSCOPE_BASE_URL: &str = "https://dashscope.aliyuncs.com/compatible-mode/v1";
|
||||
pub const DASHSCOPE_ENV_VARS: &[&str] = &["DASHSCOPE_API_KEY"];
|
||||
const DASHSCOPE_MAX_REQUEST_BODY_BYTES: usize = 6_291_456; // 6MB (observed limit in dogfood)
|
||||
|
||||
impl OpenAiCompatConfig {
|
||||
/// Alibaba `DashScope` compatible-mode endpoint (Qwen family models).
|
||||
/// Uses the OpenAI-compatible REST shape at /compatible-mode/v1.
|
||||
/// Requested via Discord #clawcode-get-help: native Alibaba API for
|
||||
/// higher rate limits than going through `OpenRouter`.
|
||||
#[must_use]
|
||||
pub const fn dashscope() -> Self {
|
||||
Self {
|
||||
provider_name: "DashScope",
|
||||
api_key_env: "DASHSCOPE_API_KEY",
|
||||
base_url_env: "DASHSCOPE_BASE_URL",
|
||||
default_base_url: DEFAULT_DASHSCOPE_BASE_URL,
|
||||
credential_env_vars: DASHSCOPE_ENV_VARS,
|
||||
max_request_body_bytes: DASHSCOPE_MAX_REQUEST_BODY_BYTES,
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
use super::OpenAiCompatConfig;
|
||||
|
||||
pub const DEFAULT_DEEPSEEK_BASE_URL: &str = "https://api.deepseek.com";
|
||||
pub const DEEPSEEK_ENV_VARS: &[&str] = &["DEEPSEEK_API_KEY"];
|
||||
const DEEPSEEK_MAX_REQUEST_BODY_BYTES: usize = 104_857_600; // 100MB (Using OpenAI default for now)
|
||||
|
||||
impl OpenAiCompatConfig {
|
||||
#[must_use]
|
||||
pub const fn deepseek() -> Self {
|
||||
Self {
|
||||
provider_name: "DeepSeek",
|
||||
api_key_env: "DEEPSEEK_API_KEY",
|
||||
base_url_env: "DEEPSEEK_BASE_URL",
|
||||
default_base_url: DEFAULT_DEEPSEEK_BASE_URL,
|
||||
credential_env_vars: DEEPSEEK_ENV_VARS,
|
||||
max_request_body_bytes: DEEPSEEK_MAX_REQUEST_BODY_BYTES,
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -16,9 +16,16 @@ use crate::types::{
|
|||
|
||||
use super::{preflight_message_request, Provider, ProviderFuture};
|
||||
|
||||
pub const DEFAULT_XAI_BASE_URL: &str = "https://api.x.ai/v1";
|
||||
pub const DEFAULT_OPENAI_BASE_URL: &str = "https://api.openai.com/v1";
|
||||
pub const DEFAULT_DASHSCOPE_BASE_URL: &str = "https://dashscope.aliyuncs.com/compatible-mode/v1";
|
||||
pub mod dashscope;
|
||||
pub mod deepseek;
|
||||
pub mod openai;
|
||||
pub mod xai;
|
||||
|
||||
pub use dashscope::DEFAULT_DASHSCOPE_BASE_URL;
|
||||
pub use deepseek::DEFAULT_DEEPSEEK_BASE_URL;
|
||||
pub use openai::DEFAULT_OPENAI_BASE_URL;
|
||||
pub use xai::DEFAULT_XAI_BASE_URL;
|
||||
|
||||
const REQUEST_ID_HEADER: &str = "request-id";
|
||||
const ALT_REQUEST_ID_HEADER: &str = "x-request-id";
|
||||
const DEFAULT_INITIAL_BACKOFF: Duration = Duration::from_secs(1);
|
||||
|
|
@ -31,6 +38,7 @@ pub struct OpenAiCompatConfig {
|
|||
pub api_key_env: &'static str,
|
||||
pub base_url_env: &'static str,
|
||||
pub default_base_url: &'static str,
|
||||
pub credential_env_vars: &'static [&'static str],
|
||||
/// Maximum request body size in bytes. Provider-specific limits:
|
||||
/// - `DashScope`: 6MB (`6_291_456` bytes) - observed in dogfood testing
|
||||
/// - `OpenAI`: 100MB (`104_857_600` bytes)
|
||||
|
|
@ -38,64 +46,6 @@ pub struct OpenAiCompatConfig {
|
|||
pub max_request_body_bytes: usize,
|
||||
}
|
||||
|
||||
const XAI_ENV_VARS: &[&str] = &["XAI_API_KEY"];
|
||||
const OPENAI_ENV_VARS: &[&str] = &["OPENAI_API_KEY"];
|
||||
const DASHSCOPE_ENV_VARS: &[&str] = &["DASHSCOPE_API_KEY"];
|
||||
|
||||
// Provider-specific request body size limits in bytes
|
||||
const XAI_MAX_REQUEST_BODY_BYTES: usize = 52_428_800; // 50MB
|
||||
const OPENAI_MAX_REQUEST_BODY_BYTES: usize = 104_857_600; // 100MB
|
||||
const DASHSCOPE_MAX_REQUEST_BODY_BYTES: usize = 6_291_456; // 6MB (observed limit in dogfood)
|
||||
|
||||
impl OpenAiCompatConfig {
|
||||
#[must_use]
|
||||
pub const fn xai() -> Self {
|
||||
Self {
|
||||
provider_name: "xAI",
|
||||
api_key_env: "XAI_API_KEY",
|
||||
base_url_env: "XAI_BASE_URL",
|
||||
default_base_url: DEFAULT_XAI_BASE_URL,
|
||||
max_request_body_bytes: XAI_MAX_REQUEST_BODY_BYTES,
|
||||
}
|
||||
}
|
||||
|
||||
#[must_use]
|
||||
pub const fn openai() -> Self {
|
||||
Self {
|
||||
provider_name: "OpenAI",
|
||||
api_key_env: "OPENAI_API_KEY",
|
||||
base_url_env: "OPENAI_BASE_URL",
|
||||
default_base_url: DEFAULT_OPENAI_BASE_URL,
|
||||
max_request_body_bytes: OPENAI_MAX_REQUEST_BODY_BYTES,
|
||||
}
|
||||
}
|
||||
|
||||
/// Alibaba `DashScope` compatible-mode endpoint (Qwen family models).
|
||||
/// Uses the OpenAI-compatible REST shape at /compatible-mode/v1.
|
||||
/// Requested via Discord #clawcode-get-help: native Alibaba API for
|
||||
/// higher rate limits than going through `OpenRouter`.
|
||||
#[must_use]
|
||||
pub const fn dashscope() -> Self {
|
||||
Self {
|
||||
provider_name: "DashScope",
|
||||
api_key_env: "DASHSCOPE_API_KEY",
|
||||
base_url_env: "DASHSCOPE_BASE_URL",
|
||||
default_base_url: DEFAULT_DASHSCOPE_BASE_URL,
|
||||
max_request_body_bytes: DASHSCOPE_MAX_REQUEST_BODY_BYTES,
|
||||
}
|
||||
}
|
||||
|
||||
#[must_use]
|
||||
pub fn credential_env_vars(self) -> &'static [&'static str] {
|
||||
match self.provider_name {
|
||||
"xAI" => XAI_ENV_VARS,
|
||||
"OpenAI" => OPENAI_ENV_VARS,
|
||||
"DashScope" => DASHSCOPE_ENV_VARS,
|
||||
_ => &[],
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
#[derive(Debug, Clone)]
|
||||
pub struct OpenAiCompatClient {
|
||||
http: reqwest::Client,
|
||||
|
|
@ -133,7 +83,7 @@ impl OpenAiCompatClient {
|
|||
let Some(api_key) = read_env_non_empty(config.api_key_env)? else {
|
||||
return Err(ApiError::missing_credentials(
|
||||
config.provider_name,
|
||||
config.credential_env_vars(),
|
||||
config.credential_env_vars,
|
||||
));
|
||||
};
|
||||
Ok(Self::new(api_key, config))
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
use super::OpenAiCompatConfig;
|
||||
|
||||
pub const DEFAULT_OPENAI_BASE_URL: &str = "https://api.openai.com/v1";
|
||||
pub const OPENAI_ENV_VARS: &[&str] = &["OPENAI_API_KEY"];
|
||||
const OPENAI_MAX_REQUEST_BODY_BYTES: usize = 104_857_600; // 100MB
|
||||
|
||||
impl OpenAiCompatConfig {
|
||||
#[must_use]
|
||||
pub const fn openai() -> Self {
|
||||
Self {
|
||||
provider_name: "OpenAI",
|
||||
api_key_env: "OPENAI_API_KEY",
|
||||
base_url_env: "OPENAI_BASE_URL",
|
||||
default_base_url: DEFAULT_OPENAI_BASE_URL,
|
||||
credential_env_vars: OPENAI_ENV_VARS,
|
||||
max_request_body_bytes: OPENAI_MAX_REQUEST_BODY_BYTES,
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
use super::OpenAiCompatConfig;
|
||||
|
||||
pub const DEFAULT_XAI_BASE_URL: &str = "https://api.x.ai/v1";
|
||||
pub const XAI_ENV_VARS: &[&str] = &["XAI_API_KEY"];
|
||||
const XAI_MAX_REQUEST_BODY_BYTES: usize = 52_428_800; // 50MB
|
||||
|
||||
impl OpenAiCompatConfig {
|
||||
#[must_use]
|
||||
pub const fn xai() -> Self {
|
||||
Self {
|
||||
provider_name: "xAI",
|
||||
api_key_env: "XAI_API_KEY",
|
||||
base_url_env: "XAI_BASE_URL",
|
||||
default_base_url: DEFAULT_XAI_BASE_URL,
|
||||
credential_env_vars: XAI_ENV_VARS,
|
||||
max_request_body_bytes: XAI_MAX_REQUEST_BODY_BYTES,
|
||||
}
|
||||
}
|
||||
}
|
||||
Loading…
Reference in New Issue