fathom-cli 0.3.1 → 0.3.3
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/README.md +0 -1
- package/dist/index.js +924 -186
- package/dist/index.js.map +1 -1
- package/package.json +7 -6
- package/plugins/fathom/.claude-plugin/plugin.json +13 -0
- package/plugins/fathom/.mcp.json +8 -0
- package/plugins/fathom/skills/budget/.gitkeep +0 -0
- package/plugins/fathom/skills/budget/SKILL.md +40 -0
- package/plugins/fathom/skills/budget-warning/.gitkeep +0 -0
- package/plugins/fathom/skills/budget-warning/SKILL.md +52 -0
- package/plugins/fathom/skills/cost-preview/.gitkeep +0 -0
- package/plugins/fathom/skills/cost-preview/SKILL.md +70 -0
- package/plugins/fathom/skills/estimate/.gitkeep +0 -0
- package/plugins/fathom/skills/estimate/SKILL.md +58 -0
- package/plugins/fathom/skills/gsd/SKILL.md +35 -0
- package/plugins/fathom/skills/projections/.gitkeep +0 -0
- package/plugins/fathom/skills/projections/SKILL.md +36 -0
- package/plugins/fathom/skills/recommend-model/.gitkeep +0 -0
- package/plugins/fathom/skills/recommend-model/SKILL.md +53 -0
- package/plugins/fathom/skills/status/.gitkeep +0 -0
- package/plugins/fathom/skills/status/SKILL.md +42 -0
- package/plugins/fathom/tests/integrations.test.ts +66 -0
- package/plugins/fathom/tests/plugin.test.ts +49 -0
- package/plugins/fathom/tests/skills.test.ts +135 -0
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "fathom-cli",
|
|
3
|
-
"version": "0.3.
|
|
3
|
+
"version": "0.3.3",
|
|
4
4
|
"description": "Headless intelligence layer for AI-augmented development — intent-driven, provider-agnostic, self-improving. Active development.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|
|
@@ -17,6 +17,7 @@
|
|
|
17
17
|
"files": [
|
|
18
18
|
"dist",
|
|
19
19
|
"dist/data",
|
|
20
|
+
"plugins/fathom",
|
|
20
21
|
"README.md"
|
|
21
22
|
],
|
|
22
23
|
"keywords": [
|
|
@@ -67,15 +68,15 @@
|
|
|
67
68
|
"tsup": "^8.3.0",
|
|
68
69
|
"typescript": "^5.7.0",
|
|
69
70
|
"vitest": "^2.1.0",
|
|
70
|
-
"@fathom/intent": "0.1.0",
|
|
71
|
-
"@fathom/core": "0.1.0",
|
|
72
|
-
"@fathom/intake": "0.1.0",
|
|
73
71
|
"@fathom/projections": "0.1.0",
|
|
72
|
+
"@fathom/intent": "0.1.0",
|
|
74
73
|
"@fathom/reports": "0.1.0",
|
|
75
74
|
"@fathom/store": "0.1.0",
|
|
76
75
|
"@fathom/sync": "0.1.0",
|
|
77
|
-
"@fathom/
|
|
78
|
-
"@fathom/
|
|
76
|
+
"@fathom/tracker": "0.1.0",
|
|
77
|
+
"@fathom/core": "0.1.0",
|
|
78
|
+
"@fathom/intake": "0.1.0",
|
|
79
|
+
"@fathom/velocity": "0.1.0"
|
|
79
80
|
},
|
|
80
81
|
"scripts": {
|
|
81
82
|
"build": "tsup",
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "fathom",
|
|
3
|
+
"description": "AI cost intelligence for Claude Code. Estimate token costs, get model recommendations, track budgets, and generate tool-specific rules -- all without leaving your workflow.",
|
|
4
|
+
"version": "0.1.0",
|
|
5
|
+
"author": {
|
|
6
|
+
"name": "Fathom"
|
|
7
|
+
},
|
|
8
|
+
"repository": {
|
|
9
|
+
"type": "git",
|
|
10
|
+
"url": "https://github.com/olive/fathom"
|
|
11
|
+
},
|
|
12
|
+
"license": "MIT"
|
|
13
|
+
}
|
|
File without changes
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: budget
|
|
3
|
+
description: Check the project's AI spending budget status including monthly limit, current spend, remaining balance, and burn rate.
|
|
4
|
+
argument-hint: "[optional: budget question]"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Check Budget
|
|
8
|
+
|
|
9
|
+
Check the project's current AI spending budget status.
|
|
10
|
+
|
|
11
|
+
## Steps
|
|
12
|
+
|
|
13
|
+
1. Call `fathom_check_budget` with no arguments
|
|
14
|
+
2. Present the budget status clearly
|
|
15
|
+
|
|
16
|
+
## Output Format
|
|
17
|
+
|
|
18
|
+
| Metric | Value |
|
|
19
|
+
|--------|-------|
|
|
20
|
+
| Monthly Limit | ${monthlyLimit} |
|
|
21
|
+
| Current Spend | ${currentSpend} |
|
|
22
|
+
| Remaining | ${remaining} |
|
|
23
|
+
| Burn Rate | ${dailyBurnRate}/day |
|
|
24
|
+
| Days Until Limit | {daysRemaining} |
|
|
25
|
+
|
|
26
|
+
## Threshold Interpretation
|
|
27
|
+
|
|
28
|
+
Interpret the spending level for the user:
|
|
29
|
+
- **Below 50%** -- Healthy. Plenty of budget remaining.
|
|
30
|
+
- **50-79%** -- Moderate. On track but worth monitoring.
|
|
31
|
+
- **80-89%** -- Caution. Approaching the monthly limit.
|
|
32
|
+
- **90%+** -- Warning. Budget nearly exhausted. Consider using more economical models or deferring non-critical tasks.
|
|
33
|
+
|
|
34
|
+
## Error Handling
|
|
35
|
+
|
|
36
|
+
If no budget is configured, tell the user to set one up:
|
|
37
|
+
- Run `fathom init` to create a project configuration, or
|
|
38
|
+
- Manually add a budget section to `.fathom/intent.yaml`
|
|
39
|
+
|
|
40
|
+
If the `fathom_check_budget` MCP tool is not available, tell the user to check their MCP configuration. They may need to run `npx fathom-mcp` or verify that the Fathom MCP server is configured in their `.mcp.json`.
|
|
File without changes
|
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: budget-warning
|
|
3
|
+
description: Check project budget status and warn proactively when spending approaches the configured monthly limit. Activate when the user is about to start work that will consume tokens, especially at the beginning of work sessions or before large tasks.
|
|
4
|
+
user-invocable: false
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Proactive Budget Warning
|
|
8
|
+
|
|
9
|
+
Check the project's budget status and warn if spending is approaching or has exceeded the configured monthly limit.
|
|
10
|
+
|
|
11
|
+
## Activation
|
|
12
|
+
|
|
13
|
+
Trigger at natural checkpoints:
|
|
14
|
+
- Start of a new work session
|
|
15
|
+
- Before the user begins a large task (L or XL complexity)
|
|
16
|
+
- When budget-related context is relevant
|
|
17
|
+
|
|
18
|
+
## Steps
|
|
19
|
+
|
|
20
|
+
1. Call `fathom_check_budget` to get current budget status
|
|
21
|
+
2. Evaluate the spending level against thresholds:
|
|
22
|
+
- Below 50%: No warning needed
|
|
23
|
+
- 50-79%: No warning, but note if asked
|
|
24
|
+
- 80-89%: Gentle note about approaching limit
|
|
25
|
+
- 90-99%: Clear warning with remaining budget
|
|
26
|
+
- 100%+: Strong warning that budget is exceeded
|
|
27
|
+
3. If a warning is warranted, present it briefly using the appropriate format below
|
|
28
|
+
|
|
29
|
+
## Warning Behavior
|
|
30
|
+
|
|
31
|
+
- Warn at most ONCE per conversation at each threshold level
|
|
32
|
+
- If you already warned about 80% in this conversation, only warn again if it crosses 90%
|
|
33
|
+
- Never repeat the same warning in the same session
|
|
34
|
+
- Do not warn at all if budget data is unavailable -- just skip silently
|
|
35
|
+
|
|
36
|
+
## Format
|
|
37
|
+
|
|
38
|
+
At 80-89%:
|
|
39
|
+
|
|
40
|
+
> Budget note: You've used {percent}% of your ${monthlyLimit}/month budget (${remaining} remaining). Current burn rate: ${dailyBurnRate}/day.
|
|
41
|
+
|
|
42
|
+
At 90-99%:
|
|
43
|
+
|
|
44
|
+
> Budget warning: ${remaining} remaining of ${monthlyLimit}/month budget ({percent}% used). At current rate, budget runs out in {daysRemaining} days. Consider using a more economical model or deferring non-critical tasks.
|
|
45
|
+
|
|
46
|
+
At 100%+:
|
|
47
|
+
|
|
48
|
+
> Budget exceeded: You've spent ${currentSpend} against a ${monthlyLimit}/month limit. All further AI usage is over budget. Consider pausing non-essential tasks or adjusting your monthly limit in .fathom/intent.yaml.
|
|
49
|
+
|
|
50
|
+
## Fallback
|
|
51
|
+
|
|
52
|
+
If budget data is not configured, skip silently. The user can configure a budget via `fathom init` or by editing `.fathom/intent.yaml`.
|
|
File without changes
|
|
@@ -0,0 +1,70 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: cost-preview
|
|
3
|
+
description: Automatically preview estimated cost when the user describes building, implementing, creating, or writing code for a specific feature or task. Do not activate for questions, discussions, debugging, or code review.
|
|
4
|
+
user-invocable: false
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Inline Cost Preview
|
|
8
|
+
|
|
9
|
+
When the user describes a concrete implementation task, automatically provide a brief cost estimate alongside your normal response.
|
|
10
|
+
|
|
11
|
+
## Activation Criteria
|
|
12
|
+
|
|
13
|
+
ACTIVATE when the user says things like:
|
|
14
|
+
- "Build a user authentication system"
|
|
15
|
+
- "Create a React component for..."
|
|
16
|
+
- "Implement the payment integration"
|
|
17
|
+
- "Write tests for the API"
|
|
18
|
+
- "Add a new database table for..."
|
|
19
|
+
- "Set up CI/CD pipeline"
|
|
20
|
+
|
|
21
|
+
DO NOT activate for:
|
|
22
|
+
- Questions ("How does X work?")
|
|
23
|
+
- Discussions ("Should we use React or Vue?")
|
|
24
|
+
- Code review ("Can you review this PR?")
|
|
25
|
+
- Debugging ("Why is this test failing?")
|
|
26
|
+
- Reading/exploring code ("Show me the auth module")
|
|
27
|
+
- Planning ("What should we build next?")
|
|
28
|
+
|
|
29
|
+
## Task Type Mapping
|
|
30
|
+
|
|
31
|
+
Map the user's description to one of these task types:
|
|
32
|
+
- **scaffold**: Project setup, boilerplate, initial structure
|
|
33
|
+
- **api-endpoint**: REST/GraphQL endpoints, server routes, handlers
|
|
34
|
+
- **react-component**: UI components, pages, forms, layouts
|
|
35
|
+
- **complex-ui**: Animations, data visualizations, interactive widgets
|
|
36
|
+
- **database-schema**: Schema design, migrations, ORM models
|
|
37
|
+
- **integration**: Third-party APIs, OAuth, webhooks, external services
|
|
38
|
+
- **test-unit**: Unit tests, test utilities, mocking
|
|
39
|
+
- **test-e2e**: End-to-end tests, integration tests, test infrastructure
|
|
40
|
+
- **devops**: CI/CD, Docker, deployment configs, infrastructure
|
|
41
|
+
- **documentation**: README, API docs, guides, comments
|
|
42
|
+
- **refactoring**: Code restructuring, performance optimization, cleanup
|
|
43
|
+
- **architecture**: System design, major structural changes
|
|
44
|
+
- **debugging**: Bug fixes, error investigation, troubleshooting
|
|
45
|
+
|
|
46
|
+
## Complexity Guide
|
|
47
|
+
|
|
48
|
+
- **S**: Quick change, 1-2 files, well-understood pattern
|
|
49
|
+
- **M**: Standard feature, 3-5 files, some design decisions
|
|
50
|
+
- **L**: Complex feature, 5-10 files, significant design work
|
|
51
|
+
- **XL**: Major system change, 10+ files, cross-cutting concerns
|
|
52
|
+
|
|
53
|
+
## Steps
|
|
54
|
+
|
|
55
|
+
1. Identify the task type from the user's description using the mapping above
|
|
56
|
+
2. Estimate complexity (S/M/L/XL) based on the scope described
|
|
57
|
+
3. Call `fathom_estimate_task_cost` with the inferred taskType and complexity
|
|
58
|
+
4. Present a 1-line cost note appended to your normal response
|
|
59
|
+
|
|
60
|
+
## Format
|
|
61
|
+
|
|
62
|
+
Keep it to one line appended to your normal response:
|
|
63
|
+
|
|
64
|
+
> Cost estimate: ~${cost} ({tokens} tokens on {model}) for this {complexity} {taskType} task.
|
|
65
|
+
|
|
66
|
+
Do NOT make this the focus of your response. It is supplementary information. Do not interrupt your normal response flow.
|
|
67
|
+
|
|
68
|
+
## Fallback
|
|
69
|
+
|
|
70
|
+
If the cost-preview didn't auto-trigger, the user can always run /fathom:estimate manually.
|
|
File without changes
|
|
@@ -0,0 +1,58 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: estimate
|
|
3
|
+
description: Estimate the token cost and dollar amount for an AI task before starting work. Use when the user asks about cost, tokens, or wants to know how expensive a task will be.
|
|
4
|
+
argument-hint: "[task description]"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Estimate Task Cost
|
|
8
|
+
|
|
9
|
+
Estimate how many tokens and dollars a task will cost before the user starts working on it.
|
|
10
|
+
|
|
11
|
+
## Input
|
|
12
|
+
|
|
13
|
+
The user provides a task description via $ARGUMENTS. If no arguments provided, ask what task they want to estimate.
|
|
14
|
+
|
|
15
|
+
## Task Type Mapping
|
|
16
|
+
|
|
17
|
+
Map the user's description to one of these task types:
|
|
18
|
+
- **scaffold**: Project setup, boilerplate, initial structure
|
|
19
|
+
- **api-endpoint**: REST/GraphQL endpoints, server routes, handlers
|
|
20
|
+
- **react-component**: UI components, pages, forms, layouts
|
|
21
|
+
- **complex-ui**: Animations, data visualizations, interactive widgets
|
|
22
|
+
- **database-schema**: Schema design, migrations, ORM models
|
|
23
|
+
- **integration**: Third-party APIs, OAuth, webhooks, external services
|
|
24
|
+
- **test-unit**: Unit tests, test utilities, mocking
|
|
25
|
+
- **test-e2e**: End-to-end tests, integration tests, test infrastructure
|
|
26
|
+
- **devops**: CI/CD, Docker, deployment configs, infrastructure
|
|
27
|
+
- **documentation**: README, API docs, guides, comments
|
|
28
|
+
- **refactoring**: Code restructuring, performance optimization, cleanup
|
|
29
|
+
- **architecture**: System design, major structural changes
|
|
30
|
+
- **debugging**: Bug fixes, error investigation, troubleshooting
|
|
31
|
+
|
|
32
|
+
## Complexity Guide
|
|
33
|
+
|
|
34
|
+
- **S**: Quick change, 1-2 files, well-understood pattern
|
|
35
|
+
- **M**: Standard feature, 3-5 files, some design decisions
|
|
36
|
+
- **L**: Complex feature, 5-10 files, significant design work
|
|
37
|
+
- **XL**: Major system change, 10+ files, cross-cutting concerns
|
|
38
|
+
|
|
39
|
+
## Steps
|
|
40
|
+
|
|
41
|
+
1. Infer taskType and complexity from the description
|
|
42
|
+
2. Call `fathom_estimate_task_cost` with taskType and complexity
|
|
43
|
+
3. Present results as a clear summary
|
|
44
|
+
|
|
45
|
+
## Output Format
|
|
46
|
+
|
|
47
|
+
| Metric | Value |
|
|
48
|
+
|--------|-------|
|
|
49
|
+
| Task | {taskType} ({complexity}) |
|
|
50
|
+
| Tokens | {input + output with overhead} |
|
|
51
|
+
| Cost | ${estimatedCost} |
|
|
52
|
+
| Model | {recommendedModel} |
|
|
53
|
+
|
|
54
|
+
If overhead is significant, briefly note the breakdown (retries, context loading, iteration).
|
|
55
|
+
|
|
56
|
+
## Error Handling
|
|
57
|
+
|
|
58
|
+
If the `fathom_estimate_task_cost` MCP tool is not available, tell the user to check their MCP configuration. They may need to run `npx fathom-mcp` or verify that the Fathom MCP server is configured in their `.mcp.json`.
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: estimate-phase
|
|
3
|
+
description: Estimate token cost and recommend a model for a development phase. Use when planning a phase and wanting to know the expected AI cost before starting.
|
|
4
|
+
argument-hint: "[phase goal or description]"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Estimate Phase Cost
|
|
8
|
+
|
|
9
|
+
Estimate the total token cost and optimal model for a development phase.
|
|
10
|
+
|
|
11
|
+
## Input
|
|
12
|
+
|
|
13
|
+
The user provides a phase goal or description via $ARGUMENTS. This should describe what the phase will accomplish (e.g., "Add authentication with JWT tokens, login/signup pages, and password reset flow").
|
|
14
|
+
|
|
15
|
+
## Steps
|
|
16
|
+
|
|
17
|
+
1. Call the `fathom_estimate_task_cost` MCP tool with the phase description from $ARGUMENTS as the task description
|
|
18
|
+
2. Call the `fathom_recommend_model` MCP tool to get the optimal model recommendation for this type of work
|
|
19
|
+
3. Present results in a clear summary:
|
|
20
|
+
- **Estimated tokens**: input + output token counts
|
|
21
|
+
- **Estimated cost**: dollar amount
|
|
22
|
+
- **Recommended model**: which model to use and why
|
|
23
|
+
- **Confidence level**: how confident the estimate is
|
|
24
|
+
|
|
25
|
+
## Output Format
|
|
26
|
+
|
|
27
|
+
Present a concise summary:
|
|
28
|
+
|
|
29
|
+
**Phase Estimate: [phase name]**
|
|
30
|
+
- Tokens: ~X input / ~Y output
|
|
31
|
+
- Cost: ~$Z
|
|
32
|
+
- Model: [recommended model] — [reason]
|
|
33
|
+
- Confidence: [high/medium/low]
|
|
34
|
+
|
|
35
|
+
If the estimate confidence is low, suggest breaking the phase into smaller tasks for more accurate estimates.
|
|
File without changes
|
|
@@ -0,0 +1,36 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: projections
|
|
3
|
+
description: Generate tool-specific rules and configuration files (Cursor, Copilot, Windsurf, Claude) from your project's intent.yaml.
|
|
4
|
+
argument-hint: "[optional: specific tool to generate for]"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Generate Projections
|
|
8
|
+
|
|
9
|
+
Generate tool-specific configuration and rules files from the project's intent.yaml. These files encode your project's intent, constraints, and guardrails into formats that each AI coding tool understands natively.
|
|
10
|
+
|
|
11
|
+
## Steps
|
|
12
|
+
|
|
13
|
+
1. Call `fathom_generate_tool_configs` with no arguments
|
|
14
|
+
2. Report which files were generated and where they are located
|
|
15
|
+
|
|
16
|
+
## Output Format
|
|
17
|
+
|
|
18
|
+
List the generated files under `.fathom/projections/`:
|
|
19
|
+
|
|
20
|
+
| Tool | Generated File |
|
|
21
|
+
|------|---------------|
|
|
22
|
+
| Claude | `.fathom/projections/claude/SKILL.md` |
|
|
23
|
+
| Cursor | `.fathom/projections/cursor/.cursorrules` |
|
|
24
|
+
| Copilot | `.fathom/projections/copilot/copilot-instructions.md` |
|
|
25
|
+
| Windsurf | `.fathom/projections/windsurf/.windsurfrules` |
|
|
26
|
+
| Generic | `.fathom/projections/generic/SYSTEM_PROMPT.md` |
|
|
27
|
+
|
|
28
|
+
After presenting the list, note:
|
|
29
|
+
|
|
30
|
+
> These files are auto-generated from your intent.yaml. Edit intent.yaml to change the rules, then re-run this skill.
|
|
31
|
+
|
|
32
|
+
## Error Handling
|
|
33
|
+
|
|
34
|
+
If intent.yaml is not found, tell the user to run `fathom init` first to create a project configuration with an intent file.
|
|
35
|
+
|
|
36
|
+
If the `fathom_generate_tool_configs` MCP tool is not available, tell the user to check their MCP configuration. They may need to run `npx fathom-mcp` or verify that the Fathom MCP server is configured in their `.mcp.json`.
|
|
File without changes
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: recommend-model
|
|
3
|
+
description: Get the best AI model for a task based on complexity, requirements, and budget. Use when the user wants to know which model to use.
|
|
4
|
+
argument-hint: "[task description]"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Recommend Model
|
|
8
|
+
|
|
9
|
+
Get the optimal AI model recommendation for a specific task based on its complexity, requirements, and the project's budget constraints.
|
|
10
|
+
|
|
11
|
+
## Input
|
|
12
|
+
|
|
13
|
+
The user provides a task description via $ARGUMENTS. If no arguments provided, ask what task they need a model recommendation for.
|
|
14
|
+
|
|
15
|
+
## Complexity Guide
|
|
16
|
+
|
|
17
|
+
- **S**: Quick change, 1-2 files, well-understood pattern
|
|
18
|
+
- **M**: Standard feature, 3-5 files, some design decisions
|
|
19
|
+
- **L**: Complex feature, 5-10 files, significant design work
|
|
20
|
+
- **XL**: Major system change, 10+ files, cross-cutting concerns
|
|
21
|
+
|
|
22
|
+
## Steps
|
|
23
|
+
|
|
24
|
+
1. Infer complexity (S/M/L/XL) from the task description
|
|
25
|
+
2. Call `fathom_recommend_model` with:
|
|
26
|
+
- `description`: the user's task description
|
|
27
|
+
- `complexity`: the inferred complexity level
|
|
28
|
+
- `budget`: if the user mentions a budget limit (e.g., "under $5"), pass it as a number
|
|
29
|
+
3. Present the recommendation clearly
|
|
30
|
+
|
|
31
|
+
## Output Format
|
|
32
|
+
|
|
33
|
+
| Detail | Value |
|
|
34
|
+
|--------|-------|
|
|
35
|
+
| Recommended Model | {model name} |
|
|
36
|
+
| Reasoning | {why this model fits the task} |
|
|
37
|
+
| Estimated Cost | ${cost} |
|
|
38
|
+
| Confidence | {confidence level} |
|
|
39
|
+
|
|
40
|
+
### Alternatives
|
|
41
|
+
|
|
42
|
+
If the tool returns alternative models, list them:
|
|
43
|
+
|
|
44
|
+
| Model | Cost | Tradeoff |
|
|
45
|
+
|-------|------|----------|
|
|
46
|
+
| {alt1} | ${cost} | {what you gain/lose} |
|
|
47
|
+
| {alt2} | ${cost} | {what you gain/lose} |
|
|
48
|
+
|
|
49
|
+
If the user provided a budget, note how the recommendation accounts for their budget.
|
|
50
|
+
|
|
51
|
+
## Error Handling
|
|
52
|
+
|
|
53
|
+
If the `fathom_recommend_model` MCP tool is not available, tell the user to check their MCP configuration. They may need to run `npx fathom-mcp` or verify that the Fathom MCP server is configured in their `.mcp.json`.
|
|
File without changes
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: status
|
|
3
|
+
description: Get a quick project overview showing feature progress, budget status, and configuration summary.
|
|
4
|
+
argument-hint: "[optional: specific area to check]"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Project Status
|
|
8
|
+
|
|
9
|
+
Get a quick overview of the current project's state including feature progress, budget, and configuration.
|
|
10
|
+
|
|
11
|
+
## Steps
|
|
12
|
+
|
|
13
|
+
1. Call `fathom_get_project_status` with no arguments
|
|
14
|
+
2. Present the results organized into clear sections
|
|
15
|
+
|
|
16
|
+
## Output Format
|
|
17
|
+
|
|
18
|
+
### Features
|
|
19
|
+
|
|
20
|
+
| Status | Count | Features |
|
|
21
|
+
|--------|-------|----------|
|
|
22
|
+
| Complete | {count} | {list of completed features} |
|
|
23
|
+
| In Progress | {count} | {list of in-progress features} |
|
|
24
|
+
| Pending | {count} | {list of pending features} |
|
|
25
|
+
|
|
26
|
+
### Budget
|
|
27
|
+
|
|
28
|
+
{One-line summary: "${spent} of ${limit} used ({percent}%) -- {status}"}
|
|
29
|
+
|
|
30
|
+
### Configuration
|
|
31
|
+
|
|
32
|
+
| Setting | Value |
|
|
33
|
+
|---------|-------|
|
|
34
|
+
| Store Type | {file or convex} |
|
|
35
|
+
| Intent Loaded | {yes/no} |
|
|
36
|
+
| Projections | {which tools configured} |
|
|
37
|
+
|
|
38
|
+
## Error Handling
|
|
39
|
+
|
|
40
|
+
If the project is not initialized, tell the user to run `fathom init` to set up a Fathom project in the current directory.
|
|
41
|
+
|
|
42
|
+
If the `fathom_get_project_status` MCP tool is not available, tell the user to check their MCP configuration. They may need to run `npx fathom-mcp` or verify that the Fathom MCP server is configured in their `.mcp.json`.
|
|
@@ -0,0 +1,66 @@
|
|
|
1
|
+
import { readFileSync, existsSync } from "node:fs";
|
|
2
|
+
import { resolve } from "node:path";
|
|
3
|
+
import { describe, it, expect } from "vitest";
|
|
4
|
+
|
|
5
|
+
const DOCS_ROOT = resolve(__dirname, "../../../docs/integrations");
|
|
6
|
+
|
|
7
|
+
const INTEGRATION_DOCS = [
|
|
8
|
+
{
|
|
9
|
+
file: "cursor.md",
|
|
10
|
+
rootKey: "mcpServers",
|
|
11
|
+
configPath: ".cursor/mcp.json",
|
|
12
|
+
},
|
|
13
|
+
{
|
|
14
|
+
file: "vscode.md",
|
|
15
|
+
rootKey: "servers", // VS Code uses different root key!
|
|
16
|
+
configPath: ".vscode/mcp.json",
|
|
17
|
+
},
|
|
18
|
+
{
|
|
19
|
+
file: "windsurf.md",
|
|
20
|
+
rootKey: "mcpServers",
|
|
21
|
+
configPath: "~/.codeium/windsurf/mcp_config.json",
|
|
22
|
+
},
|
|
23
|
+
{
|
|
24
|
+
file: "cline.md",
|
|
25
|
+
rootKey: "mcpServers",
|
|
26
|
+
configPath: "cline_mcp_settings.json",
|
|
27
|
+
},
|
|
28
|
+
];
|
|
29
|
+
|
|
30
|
+
for (const doc of INTEGRATION_DOCS) {
|
|
31
|
+
describe(`${doc.file}`, () => {
|
|
32
|
+
const filePath = resolve(DOCS_ROOT, doc.file);
|
|
33
|
+
|
|
34
|
+
it("exists", () => {
|
|
35
|
+
expect(existsSync(filePath)).toBe(true);
|
|
36
|
+
});
|
|
37
|
+
|
|
38
|
+
it("has 3-section structure (Prerequisites, Configuration, Verify)", () => {
|
|
39
|
+
const content = readFileSync(filePath, "utf-8");
|
|
40
|
+
expect(content).toContain("## Prerequisites");
|
|
41
|
+
expect(content).toContain("## Configuration");
|
|
42
|
+
expect(content).toContain("## Verify It Works");
|
|
43
|
+
});
|
|
44
|
+
|
|
45
|
+
it(`uses correct root key "${doc.rootKey}"`, () => {
|
|
46
|
+
const content = readFileSync(filePath, "utf-8");
|
|
47
|
+
expect(content).toContain(`"${doc.rootKey}"`);
|
|
48
|
+
});
|
|
49
|
+
|
|
50
|
+
it("references fathom-mcp", () => {
|
|
51
|
+
const content = readFileSync(filePath, "utf-8");
|
|
52
|
+
expect(content).toContain("fathom-mcp@latest");
|
|
53
|
+
});
|
|
54
|
+
|
|
55
|
+
it("contains copy-pasteable JSON config block", () => {
|
|
56
|
+
const content = readFileSync(filePath, "utf-8");
|
|
57
|
+
expect(content).toContain("```json");
|
|
58
|
+
expect(content).toContain('"fathom"');
|
|
59
|
+
});
|
|
60
|
+
|
|
61
|
+
it(`mentions config file path ${doc.configPath}`, () => {
|
|
62
|
+
const content = readFileSync(filePath, "utf-8");
|
|
63
|
+
expect(content).toContain(doc.configPath);
|
|
64
|
+
});
|
|
65
|
+
});
|
|
66
|
+
}
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
import { readFileSync, existsSync } from "node:fs";
|
|
2
|
+
import { resolve } from "node:path";
|
|
3
|
+
import { describe, it, expect } from "vitest";
|
|
4
|
+
|
|
5
|
+
const PLUGIN_ROOT = resolve(__dirname, "..");
|
|
6
|
+
|
|
7
|
+
describe("plugin.json", () => {
|
|
8
|
+
const pluginPath = resolve(PLUGIN_ROOT, ".claude-plugin/plugin.json");
|
|
9
|
+
|
|
10
|
+
it("exists", () => {
|
|
11
|
+
expect(existsSync(pluginPath)).toBe(true);
|
|
12
|
+
});
|
|
13
|
+
|
|
14
|
+
it("is valid JSON with required fields", () => {
|
|
15
|
+
const raw = readFileSync(pluginPath, "utf-8");
|
|
16
|
+
const manifest = JSON.parse(raw);
|
|
17
|
+
|
|
18
|
+
expect(manifest.name).toBe("fathom");
|
|
19
|
+
expect(manifest.description).toBeTypeOf("string");
|
|
20
|
+
expect(manifest.description.length).toBeGreaterThan(0);
|
|
21
|
+
expect(manifest.version).toMatch(/^\d+\.\d+\.\d+$/);
|
|
22
|
+
expect(manifest.author?.name).toBeTypeOf("string");
|
|
23
|
+
expect(manifest.license).toBeTypeOf("string");
|
|
24
|
+
});
|
|
25
|
+
});
|
|
26
|
+
|
|
27
|
+
describe(".mcp.json", () => {
|
|
28
|
+
const mcpPath = resolve(PLUGIN_ROOT, ".mcp.json");
|
|
29
|
+
|
|
30
|
+
it("exists", () => {
|
|
31
|
+
expect(existsSync(mcpPath)).toBe(true);
|
|
32
|
+
});
|
|
33
|
+
|
|
34
|
+
it("is valid JSON with fathom MCP server config", () => {
|
|
35
|
+
const raw = readFileSync(mcpPath, "utf-8");
|
|
36
|
+
const config = JSON.parse(raw);
|
|
37
|
+
|
|
38
|
+
expect(config.mcpServers.fathom.command).toBe("npx");
|
|
39
|
+
expect(config.mcpServers.fathom.args).toBeInstanceOf(Array);
|
|
40
|
+
expect(config.mcpServers.fathom.args).toContain("fathom-mcp@latest");
|
|
41
|
+
expect(config.mcpServers.fathom.args).toContain("--project-dir");
|
|
42
|
+
});
|
|
43
|
+
});
|
|
44
|
+
|
|
45
|
+
describe("directory structure", () => {
|
|
46
|
+
it("skills directory exists", () => {
|
|
47
|
+
expect(existsSync(resolve(PLUGIN_ROOT, "skills"))).toBe(true);
|
|
48
|
+
});
|
|
49
|
+
});
|