Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/geq1fan/context-mcp/implementgit clone --depth 1 https://github.com/geq1fan/context-mcpWhat 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 | $0.00014 | $0.00662 |
| Opus 5 | $0.00007 | $0.00331 |
| Sonnet 5 | $0.00003 | $0.00132 |
| Haiku 4.5 | $0.00001 | $0.00066 |
Grade A, and why
implement 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 2d 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
88% identical to implement — 2 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.
What it actually says
The user input can be provided directly by the agent or as a command argument - you MUST consider it before proceeding with the prompt (if not empty).
User input:
$ARGUMENTS
-
Run
.specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasksfrom repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. -
Load and analyze the implementation context:
- REQUIRED: Read tasks.md for the complete task list and execution plan
- REQUIRED: Read plan.md for tech stack, architecture, and file structure
- IF EXISTS: Read data-model.md for entities and relationships
- IF EXISTS: Read contracts/ for API specifications and test requirements
- IF EXISTS: Read research.md for technical decisions and constraints
- IF EXISTS: Read quickstart.md for integration scenarios
-
Parse tasks.md structure and extract:
- Task phases: Setup, Tests, Core, Integration, Polish
- Task dependencies: Sequential vs parallel execution rules
- Task details: ID, description, file paths, parallel markers [P]
- Execution flow: Order and dependency requirements
-
Execute implementation following the task plan:
- Phase-by-phase execution: Complete each phase before moving to the next
- Respect dependencies: Run sequential tasks in order, parallel tasks [P] can run together
- Follow TDD approach: Execute test tasks before their corresponding implementation tasks
- File-based coordination: Tasks affecting the same files must run sequentially
- Validation checkpoints: Verify each phase completion before proceeding
-
Implementation execution rules:
- Setup first: Initialize project structure, dependencies, configuration
- Tests before code: If you need to write tests for contracts, entities, and integration scenarios
- Core development: Implement models, services, CLI commands, endpoints
- Integration work: Database connections, middleware, logging, external services
- Polish and validation: Unit tests, performance optimization, documentation
-
Progress tracking and error handling:
- Report progress after each completed task
- Halt execution if any non-parallel task fails
- For parallel tasks [P], continue with successful tasks, report failed ones
- Provide clear error messages with context for debugging
- Suggest next steps if implementation cannot proceed
- IMPORTANT For completed tasks, make sure to mark the task off as [X] in the tasks file.
-
Completion validation:
- Verify all required tasks are completed
- Check that implemented features match the original specification
- Validate that tests pass and coverage meets requirements
- Confirm the implementation follows the technical plan
- Report final status with summary of completed work
Note: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running /tasks first to regenerate the task list.
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.
- 2d ago First seen · 57 lines · 14 tokens per session scan A a0e5de3b01dd
implement is a command published in the GitHub repository geq1fan/context-mcp (5 stars, last pushed 10mo ago), licensed MIT. It adds 14 tokens to every session and 662 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. It is 88% identical to implement, differing in 2 lines, and is treated as a copy.
Other commands, from other repositories
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
constitution
Create or update the project constitution from interactive or provided principle inputs.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.