Install
$ agentstack add skill-danielkinneyspears-federal-proposal-skills-developing-solution-approach ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Developing Solution Approach
Design the solution before anyone drafts a section. Storyboarding and section drafting both assume a solution already exists — a technical approach, a staffing model, a transition plan, a management structure, a risk and quality approach. Solutioning is the work of designing those, deliberately, from the requirements, the win themes, and the cost constraints. Skipping it means the solution gets invented one paragraph at a time by separate authors, and the proposal describes something incoherent.
When to use this skill
Use this skill after the win strategy is set and the solicitation has been shredded (between capture and full proposal development) to design the solution the proposal will sell. It feeds outlining-proposals (the storyboards need a solution to storyboard) and drafting-proposal-sections (the sections need a solution to describe). On a fast task order it may run in a single solutioning session; on a large bid it is an iterative workshop series.
It does not write proposal narrative (drafting-proposal-sections) and does not set win themes (developing-win-strategy). It designs the what and how that the narrative will then present persuasively.
Inputs
Preferred upstream artifacts:
10-compliance-matrix.md: the requirements the solution must satisfy.05-win-strategy.md: the win themes and discriminators the solution must
embody. A solution that does not deliver the discriminators makes the win themes empty.
04-price-to-win.md: the cost target the solution must be designed to hit.03-competitive-assessment.md: what the solution must beat.00-opportunity-profile.mdand02-capture-plan.md— customer context.
Without the compliance matrix, run shredding-solicitations first — the solution must be designed against real requirements.
Read ../../shared/glossary.md and ../../shared/pursuit-workspace.md if not already read this session.
Intake
Ask these as a numbered list. Skip what upstream artifacts answer.
- The requirement. What is the work — the scope, the performance standards,
the constraints (period of performance, place, security, contract type)?
- The win themes. What discriminators and win themes must the solution
embody (from 05-win-strategy.md)?
- The cost target. What price-to-win target must the solution be designed
to hit (from 04-price-to-win.md)? Is the evaluation best-value or LPTA?
- The customer's hot buttons. What risks and priorities must the solution
visibly address — transition risk, staffing, performance, mission urgency?
- Constraints and assets. What does the team bring — existing capability,
tools, methods, people, partners — and what hard constraints bound the design (clearances, facilities, mandated standards)?
Workflow
Solution Design:
- [ ] Step 1: Read upstream artifacts; complete intake
- [ ] Step 2: Frame the design problem — requirements, themes, cost, constraints
- [ ] Step 3: Design each solution element
- [ ] Step 4: Check the design against requirements, themes, and cost
- [ ] Step 5: Resolve trade-offs and record decisions
- [ ] Step 6: Write the solution design (08-solution-design.md)
Step 1: Read and intake. Read the upstream artifacts; run intake for the rest.
Step 2: Frame the problem. State what the solution must do: satisfy the compliance-matrix requirements, embody the win themes, fit the price-to-win target, and address the customer's hot buttons. Use references/solutioning-method.md. A solution designed against only the requirements is compliant and undifferentiated; a solution designed against only the themes is differentiated and non-compliant. It must do all of it.
Step 3: Design each element. Design the solution elements (solutioning-method.md defines them): the technical approach, the staffing and management model, the transition approach, the risk approach, and the quality approach. Each element is designed concretely enough that a section author could describe it (named methods, defined structure, specific decisions) not left as a slogan.
Step 4: Check the design. Verify the design against three standards:
- Requirements: every compliance-matrix requirement is satisfied by some
element of the design.
- Win themes: every discriminator in the win strategy is actually delivered
by the design. A discriminator the design does not deliver is a theme the proposal cannot honestly make.
- Cost: the design can be delivered within the price-to-win target. This is
the design-to-cost discipline: a solution that cannot be priced to win is not a solution. Where it cannot, redesign or flag it back to pricing and capture.
Step 5: Trade-offs. Solutioning involves trade-offs — richness vs. cost, innovation vs. risk, scope of the offered approach. Resolve each consciously, guided by the evaluation approach (best-value rewards value; LPTA rewards clean, lean acceptability), and record the decision and its rationale so the proposal is internally consistent and the team does not relitigate it mid-draft.
Step 6: Write. Write 08-solution-design.md using templates/solution-design.md.
Output
One artifact: 08-solution-design.md in the pursuit workspace — the designed solution the storyboards and section drafts build from.
Present the user with: the solution design by element, confirmation that it covers the requirements and delivers the discriminators, the cost-fit check, and the trade-off decisions made.
References
references/solutioning-method.md: the solutioning workshop, the solution elements, designing against requirements/themes/cost, trade-offs, and the design-to-cost discipline.templates/solution-design.md: the solution design artifact template.
Guardrails
- Design before drafting. The solution is designed here, deliberately, not
improvised by authors during drafting. If asked to skip solutioning, produce the design first and explain why.
- Design against requirements, themes, and cost together. All three. A
solution missing any one of them fails.
- Deliver the discriminators. A win theme the design does not actually
deliver is a claim the proposal cannot support. Either the design delivers it or the win strategy is wrong.
- Design to cost. A solution that cannot be delivered within the
price-to-win target is not done. Redesign, or escalate to pricing and capture.
- Concrete, not aspirational. Design the solution the team can actually
deliver and staff. An aspirational design becomes a performance failure.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: danielkinneyspears
- Source: danielkinneyspears/federal-proposal-skills
- License: Apache-2.0
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.