Borrowing it
Nothing to install: this file belongs to sareegpt/edgartools-mcp. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/sareegpt/edgartools-mcp/main/.claude/commands/plan.mdgit clone --depth 1 https://github.com/sareegpt/edgartools-mcpWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/sareegpt/edgartools-mcp/plan)<a href="https://agentmods.dev/commands/sareegpt/edgartools-mcp/plan"><img src="https://agentmods.dev/badge/commands/sareegpt/edgartools-mcp/plan/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/sareegpt/edgartools-mcp/plan"><img src="https://agentmods.dev/badge/commands/sareegpt/edgartools-mcp/plan.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00000 | $0.01729 |
| Opus 5.5 | $0.00000 | $0.00692 |
| Sonnet 5.5 | $0.00000 | $0.00346 |
| Haiku 4.5 | $0.00000 | $0.00173 |
Grade A, and why
plan scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
100% identical to plan — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 272 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Create Plan
You are tasked with creating a detailed implementation plan based on research findings. This is Phase 2 of the Frequent Intentional Compaction (FIC) workflow.
Initial Setup:
When this command is invoked, respond with:
📋 Starting implementation planning (Phase 2 of FIC workflow)
I'll create a detailed implementation plan based on the research findings.
Please provide either:
1. The path to your research document from Phase 1, or
2. A summary of what needs to be implemented
Planning Process:
1. Context Gathering
If research document exists:
- Read the research document from Phase 1
- Extract key findings and open questions
- Identify components that need modification
- For GitHub issues: Extract reproduction steps and root cause
If starting fresh:
- Detect if input is a GitHub issue (#NNN)
- If issue: Read the issue research or fetch with
gh issue view - Otherwise: Conduct quick research using the codebase-locator agent
- Identify key files and patterns
- Understand current implementation
2. Analyze Requirements
- Clarify the desired outcome
- Identify constraints and dependencies
- Consider EdgarTools principles:
- Simple yet powerful
- Beginner-friendly
- Accurate financials
- Joyful UX with rich output
3. Design Solution
Break down the implementation into logical phases:
- Each phase should be independently testable
- Phases should build on each other
- Include verification steps for each phase
- Consider rollback strategies if needed
4. Create Detailed Plan Document
Save to: docs-internal/planning/active-tasks/YYYY-MM-DD-{topic}-plan.md
Structure:
# Implementation Plan: [Feature/Fix Name]
**Date Created**: [Current date]
**Planning Phase**: 2 of 3 (FIC Workflow)
**Based on Research**: [Link to research document if exists]
**Next Phase**: Implementation (`/implement`)
## Overview
[Brief description of what will be implemented and why]
## Current State Analysis
[Summary from research phase]
- What exists today
- Key files involved
- Current limitations
## Desired End State
[Clear description of success]
- Functional requirements
- Performance requirements
- User experience goals
## Out of Scope
[What will NOT be addressed]
- Future enhancements
- Unrelated improvements
- Items for separate tasks
## Implementation Approach
### Phase 1: [Descriptive Name] ⬜
**Goal**: [What this phase accomplishes]
**Changes**:
1. `edgar/module.py`:
- [ ] Add method `new_functionality()`
- [ ] Update class initialization
```python
# Example of key change
def new_functionality(self):
# Implementation approach
pass
tests/test_module.py:- Add test for new functionality
- Update existing tests
Verification:
- Run:
python -m pytest tests/test_module.py - Check: New functionality works with sample data
- Verify: No regression in existing features
Phase 2: [Descriptive Name] ⬜
Goal: [What this phase accomplishes]
Changes: [Similar structure to Phase 1]
Verification: [Specific tests and checks]
Phase 3: [Integration and Polish] ⬜
Goal: Complete integration and user experience
Changes:
- Documentation updates
- Example scripts
- Performance optimization
- Rich output formatting
Verification:
- All tests pass:
python -m pytest - Documentation builds:
mkdocs build - Examples run successfully
- Performance meets requirements
Testing Strategy
Unit Tests
- New test files needed
- Existing tests to update
- Coverage requirements
Integration Tests
- End-to-end scenarios
- Edge cases to handle
- Performance benchmarks
Manual Verification
- User workflows to test
- Visual output checks (rich formatting)
- Error handling scenarios
Risk Mitigation
Potential Issues
-
Issue: [Potential problem] Mitigation: [How to handle]
-
Issue: [Another potential problem] Mitigation: [How to handle]
Rollback Plan
- How to revert changes if needed
- Backup strategies for critical data
Dependencies
- External libraries required
- Internal modules affected
- Documentation updates needed
Success Criteria
- All functional requirements met
- Tests pass with >90% coverage for new code
- Documentation complete
- No performance regression
- Clean code following EdgarTools patterns
Estimated Effort
- Phase 1: [Time estimate]
- Phase 2: [Time estimate]
- Phase 3: [Time estimate]
- Total: [Total estimate]
Notes for Implementation
- Key EdgarTools patterns to follow
- Specific gotchas to watch for
- Performance considerations
- Security considerations (API keys, rate limits)
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2mo ago First seen · 272 lines · 0 tokens per session scan A 273e60f12975
plan is a command published in the GitHub repository sareegpt/edgartools-mcp (19 stars, last pushed 8mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,729 tokens. A static security scan graded it A with 0 findings. It is 100% identical to plan, differing in 0 lines, and is treated as a copy.
plan compared with commands from other repositories
| Mod | Type | Stars | Last push | Licence | Scan | Tokens | Works with |
|---|---|---|---|---|---|---|---|
| plansareegpt/edgartools-mcp | Command | 19 | 8mo ago | MIT | A | 0 | Claude Code |
| checklistgithub/spec-kit | Command | 148k | today | MIT | A | 13 | Claude Code |
| clarifygithub/spec-kit | Command | 148k | today | MIT | A | 27 | Claude Code |
| specifygithub/spec-kit | Command | 148k | today | MIT | A | 13 | Claude Code |
| analyzegithub/spec-kit | Command | 148k | today | MIT | A | 26 | Claude Code |
| convergegithub/spec-kit | Command | 148k | today | MIT | A | 35 | Claude Code |
| implementgithub/spec-kit | Command | 148k | today | MIT | A | 14 | Claude Code |