DevsContext
MCP服务器，为AI编码代理提供来自实际工具的综合工程上下文——需求、决策、架构和标准。
问题
AI编码代理缺乏上下文。他们不知道你的团队的决定、架构模式或编码标准。连接原始MCP服务器会让它们充斥着无法优先处理的无关数据。大公司建立内部上下文基础设施。DevsContext为每个人带来了这一点。
立即尝试
pip install devscontext
devscontext demo不需要API密钥。显示示例付款单的合成上下文。
所得
当你在Claude Code中说“在PROJ-123上工作”时，DevsContext会从Jira、会议记录和你的文档中获取，然后将其合成如下：
## Task: PROJ-123 — Add retry logic to payment webhook handler
### Requirements
1. Implement exponential backoff for failed webhook deliveries
2. Max 5 retry attempts over 24 hours
3. Dead-letter queue for permanently failed webhooks
4. Metrics for retry success/failure rates
Acceptance criteria: [Jira PROJ-123]
- [ ] Webhooks retry with exponential backoff (1min, 5min, 30min, 2hr, 12hr)
- [ ] Failed webhooks move to DLQ after 5 attempts
- [ ] Dashboard shows retry metrics
### Key Decisions
- **Use SQS with visibility timeout** for retry scheduling, not cron jobs.
Decided by @sarah in March 15 sprint planning. Rationale: SQS handles
timing natively, reduces operational overhead. [Meeting: Sprint 23 Planning]
- **Exponential backoff schedule**: 1min → 5min → 30min → 2hr → 12hr.
Based on payment processor rate limits. [Comment by @mike, Mar 16]
### Architecture Context
Webhook flow: `PaymentController` → `WebhookService.dispatch()` → SQS queue
→ `WebhookWorker.process()` → external endpoint.
Add retry logic in `WebhookWorker.process()` at:
`src/workers/webhook_worker.ts:45-80`
DLQ table schema in `migrations/004_webhook_dlq.sql`. [Architecture: payments-service.md]
### Coding Standards
- Use `Result` pattern, don't throw exceptions
- Retry delays: use `calculateBackoff(attempt)` helper from `src/utils/retry.ts`
- Tests: mock SQS with `@aws-sdk/client-sqs-mock`, see `tests/workers/` for examples
[Standards: typescript.md, testing.md]
### Related Work
- PROJ-456: "Payment webhook initial implementation" (Done) — base implementation
- PROJ-789: "Add webhook monitoring dashboard" (In Progress) — will consume the metrics一个合成块。AI编写正确代码所需的一切。
快速开始
pip install devscontext
devscontext init设置您的凭据：
export JIRA_EMAIL="you@company.com"
export JIRA_API_TOKEN="your-token"
export ANTHROPIC_API_KEY="your-key" # for synthesis连接到克劳德代码：
claude mcp add devscontext -- devscontext serve然后在克劳德代码中：
> work on PROJ-123使用
支持的来源
| 来源 | 获取内容 | 状态 |
|---|---|---|
| Jira | 门票详情、评论、链接问题、接受标准 | 稳定 |
| 萤火虫 | 会议记录、决定、行动项目 | 稳定 |
| 本地文档 | 架构文档、编码标准、ADR | 稳定 |
| Slack | 渠道讨论、话题、决策 | 新增 |
| Gmail | 与门票相关的电子邮件线程 | 新增 |
即将推出：线性、概念、汇流
预处理剂
在开发人员领取票证之前，主动构建上下文：
# Start the agent (polls Jira for ready tickets)
devscontext agent start
# Single run for CI/cron
devscontext agent run-once
# Check pre-built context status
devscontext agent status在中配置 .devscontext.yaml:
agents:
preprocessor:
enabled: true
jira_status: "Ready for Development"
jira_project: "PROJ"看 docs/预处理.md 完整的指南。
插件系统
DevsContext使用插件架构进行适配器和合成：
- 适配器：从源（Jira、Slack、文档等）获取上下文
- 合成插件：组合上下文（LLM、模板、passthrough）
看 docs/plugins.md 用于创建自定义插件。
配置
DevsContext使用 .devscontext.yaml 在项目根目录中：
sources:
jira:
enabled: true
base_url: "https://your-company.atlassian.net"
email: "${JIRA_EMAIL}"
api_token: "${JIRA_API_TOKEN}"
docs:
enabled: true
paths:
- "./docs"
- "./CLAUDE.md"
slack:
enabled: true
bot_token: "${SLACK_BOT_TOKEN}"
channels: ["engineering", "payments-team"]
synthesis:
provider: "anthropic"
model: "claude-haiku-4-5"完整配置参考： docs/configuration.md
运作原理
- 获取：当您提到票证时，DevsContext会并行从所有配置的源获取
- 提取：它查找相关内容——票按组件/标签匹配文档，搜索会议记录中的关键字
- 合成：LLM将原始数据组合到一个结构化的上下文块中，并引用来源
无后台进程。没有矢量数据库。只是按需获取和合成。
MCP工具
| 工具 | 何时使用 | 示例 |
|---|---|---|
get_task_context | 开始处理票 | “处理PROJ-123” |
search_context | 关于架构或过去决策的问题 | “我们如何处理付款重试？” |
get_standards | 检查编码约定 | “我们的测试标准是什么？” |
发展
git clone https://github.com/Pro0f/devscontext.git
cd devscontext
pip install -e ".[dev]"
# Run tests
pytest
# Lint
ruff check . && mypy src/贡献
欢迎投稿！看 贡献.md 作为指导方针。
贡献想法：
- 新适配器（线性、概念、汇流）
- 更好的关键字提取
- 缓存改进
许可证
麻省理工学院