kaddo-kdd/kaddo/poc-report-writing

POC Final Report Writing Skill

Purpose

Turn a supplied deterministic POC report context into a concise, traceable final report.

When to use

After a POC has a canonical conclusion and Core has prepared its deterministic report context.

Rules

• Use only the supplied context; do not scan the repository or infer missing results.
• Treat poc.md as canonical for the conclusion. Never contradict it.
• Keep facts, measurements, calculations, estimates, and recommendations distinct.
• Never include credential values, tokens, private keys, passwords, or connection strings.
• Use Not evaluated in this POC., Not applicable., or No evidence available. when sources do not support a section.
• Return a proposal for human review; Core persists it only after confirmation.

Representation selection

• Use prose for context, interpretation, rationale, findings, and conclusions.
• Use a Markdown table when supplied evidence has comparable rows, such as success criteria and

outcomes, resources, experiments, measurements, costs, risks, recommendations, or traceability.

• Use Mermaid only for architecture, topology, or flow relationships explicitly supported by the

supplied sources. Prefer it to an ASCII diagram when both can represent the same grounded flow.

• Tables and diagrams are communication tools, not completeness requirements. Do not produce one

when the context does not support a useful representation.

• Never invent table rows, diagram nodes or edges, statuses, priorities, metrics, or relationships

to make a report look more complete.

• Preserve measured, calculated, estimated, and projected semantics in every representation.
• In Traceability, use repository-relative Markdown links or paths; never emit file:/// URLs or

local absolute filesystem paths.

Section representation guide

Quality checklist

• Structured evidence uses tables when clearer than prose.
• Grounded architecture or flows use Mermaid when useful; no decorative or unsupported diagrams exist.
• Tables and Mermaid preserve source grounding and measurement semantics.
• Traceability contains repository-portable paths.
• The report is scannable before reading the full narrative.

Required structure

1. Executive Summary
2. Problem and Objective
3. Hypothesis and Success Criteria
4. Scope, Constraints and Non-goals
5. Technical Approach and Architecture
6. Infrastructure and Project Resources
7. Implementation and Relevant Technical Decisions
8. Experiments and Validation
9. Results and Measurements
10. Cost and Efficiency Analysis
11. Observability and Operational Findings
12. Findings, Learnings, Limitations and Risks
13. Conclusion
14. Recommendation and Next Steps
15. Traceability and Sources