solution-brief

Turn internal planning artifacts into client-facing solution briefs.

solution-brief governs the part of the Software Development Lifecycle where internal planning truth needs to be explained to an external audience. It helps teams rewrite trusted upstream artifacts into concise, readable solution briefs for proposals, pre-sales conversations, job applications, and other outward-facing contexts.

What it does

• Reads the strongest relevant upstream planning artifacts already available in HIRMOS.
• Produces a client-facing brief under _hirmos/artifacts/outputs/solution-brief/.
• Stores run and validation context under _hirmos/artifacts/context/solution-brief/.
• Preserves alignment with upstream truth instead of inventing polished sales language disconnected from the project.
• Pauses when the upstream planning set is too weak to support an honest brief.

Why software teams use it

• It turns internal planning artifacts into language external readers can actually use.
• It reduces the temptation to improvise polished but weak project summaries.
• It creates a consistent bridge between technical planning work and outward-facing communication.
• It helps teams reuse trusted project understanding across proposals and client conversations.

Fast mental model

Key outputs

• Client-facing brief content under _hirmos/artifacts/outputs/solution-brief/
• Run and validation traces under _hirmos/artifacts/context/solution-brief/
• A concise outward-facing narrative grounded in trusted upstream artifacts

Best fit: projects that already have disciplined planning artifacts and now need an honest, readable external summary.

How this extension looks inside HIRMOS

FAQ

When should I use solution-brief?
Use it when you need a concise external summary for proposals, pre-sales follow-up, job applications, or similar client-facing situations.

Where it fits in the Software Development Lifecycle?
– After planning truth exists: it starts once strong upstream artifacts such as requirements, system design, implementation outputs, or presentation artifacts are already available.
– Before external communication: it rewrites internal project understanding into a form external readers can understand while still remaining grounded in reviewed upstream artifacts.

What does it need before it can run well?
It needs a minimum set of strong upstream planning artifacts. If those artifacts are too weak, it should pause instead of faking confidence.

What does it produce?
Its core output is a client-facing brief under _hirmos/artifacts/outputs/solution-brief/, supported by run and validation traces under _hirmos/artifacts/context/solution-brief/.

Does it require system-design-agent specifically?
No. It can consume strong planning artifacts from any disciplined upstream process. system-design-agent is simply a common upstream example in HIRMOS.

What makes it different from a generic summary tool?
Its job is not generic summarization. It governs the rewrite from trusted internal planning artifacts into honest, client-ready language.