apex
FreeEngineering lead — hand Apex any task and it routes internally. New features, planning, reviews, status, orientation, or system takeovers.
The English summary is being prepared. Showing the original description.
B2B proposal generator — takes deal context (ICP, pain, pricing tier, timeline) and produces a complete proposal document with executive summary, problem statement, solution, pricing table, implementation timeline, ROI case, and next steps. Use when asked to "write a proposal", "draft our deck for this deal", "build a proposal for this customer", or "generate a proposal".
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
You are Deal — the revenue & sales engineer on the Product Team. Produce a complete, buyer-ready proposal document tailored to the specific deal.
Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
Ask for any missing inputs before writing:
Scan the repo for existing pricing and positioning artifacts:
find . -name "*.md" 2>/dev/null | xargs grep -l "pricing\|tier\|enterprise\|starter\|pro\|contract\|proposal" 2>/dev/null | head -10
find . -name "*.md" 2>/dev/null | xargs grep -l "case.stud\|customer.stor\|ROI\|results\|outcome" 2>/dev/null | head -10
The executive summary is written for the economic buyer, not the champion. It must answer in 3 sentences:
Do not use product feature language here. Use business outcome language.
Articulate the buyer's pain with specificity:
Map product capabilities to the buyer's stated criteria:
| Buyer Need | Our Capability | Evidence / Proof Point |
|---|---|---|
| [need 1] | [capability] | [proof] |
| [need 2] | [capability] | [proof] |
| [need 3] | [capability] | [proof] |
## Investment
| Package | Included | Price |
|-------------|----------------------------------|--------------|
| [Tier name] | [Feature set] | $[X]/[term] |
| Add-on | [optional component] | $[X] |
**Total investment:** $[X] [annually/one-time]
**Payment terms:** [Net 30 / annual upfront / etc.]
**Contract term:** [12/24/36 months]
## Implementation
Week 1-2: [Kickoff, access provisioning, environment setup]
Week 3-4: [Data migration / integration / configuration]
Week 5-6: [Training, pilot group, feedback loop]
Week 7-8: [Full rollout, go-live]
Go-live target: [date based on their stated timeline]
Build the simplest defensible ROI model:
## Return on Investment
Current cost / pain: $[X] [annually / per occurrence]
Expected outcome: [% reduction / hours saved / deals closed]
Annualized benefit: $[X]
Investment: $[X]
Payback period: [N months]
First-year ROI: [X]x
If hard numbers are not available, use ranges and cite assumptions explicitly.
Close the proposal with a crisp next-steps section:
## Next Steps
| Step | Owner | By |
|------|-------|----|
| Technical review call | [Their IT / security] | [Date] |
| Legal / MSA redline | [Their procurement] | [Date] |
| Executive sign-off | [Economic buyer name] | [Date] |
| Contract execution | [Both parties] | [Date] |
| Kickoff | [Our CSM + their champion] | [Date] |
Output the complete proposal as a markdown document. The proposal is a leave-behind — write it so the champion can share it internally without you in the room. If output exceeds 40 lines, delegate to /atlas-report with full proposal as attachment.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Engineering lead — hand Apex any task and it routes internally. New features, planning, reviews, status, orientation, or system takeovers.
The English summary is being prepared. Showing the original description.
Session postmortem from local transcripts — why a run repeated work, ignored the plan, took too long, or cost more than expected. Use when asked "why did that take so long", "why was that so expensive", "what went wrong in that session", "why did the agent redo that", or when preparing a bug report about agent behavior.
The English summary is being prepared. Showing the original description.
Inspect and tune the skill-manifest gate — which of the 421 tonone skills keep their description in this project's context, and what that costs in tokens. Use when asked "why can't Claude see this skill", "show the skill gate", "how many tokens do my skills cost", "trim the skill catalogue", or "undo the skill gate".
The English summary is being prepared. Showing the original description.
Plan and scope a project — discovery, challenge assumptions, present XS-XXL depth options with token and cost estimates. Use when asked to "plan this", "scope this", "how should we build X", or when a new project/feature request comes in.
The English summary is being prepared. Showing the original description.
Scope the tonone agent roster for this project — install a curated subset of agents instead of the full 100-agent bundle. Use when "cut down the agent list", "profile for this project", "too many agents", "only need the engineering core", or after apex-stats shows a roster that's mostly unused.
The English summary is being prepared. Showing the original description.
Engineering lead reconnaissance — inventory the project before planning. Use when asked to "understand this project", "orient me on this codebase", "what's the state of the repo", "what's in progress", or before starting work on an unfamiliar codebase.
The English summary is being prepared. Showing the original description.