hackathon-doc-writer
Goal
Generate structured technical documentation artifacts (ADR, PRD, feature specs) for a hackathon project using the appropriate template.
Trigger Conditions
Use this skill when:
- MVP scope is locked and needs to be documented in a PRD
- An architectural decision has been made that should be recorded in an ADR
- A specific feature needs a formal spec before implementation begins
- Invoked during Phase 4 (Project Planning), after
hackathon-scope-cuttercompletes - Can be re-invoked any time a new architectural decision is made during implementation
Inputs
| Input | Type | Required | Description |
|---|---|---|---|
document_type | enum | Yes | One of: ADR, PRD, feature-spec |
project_title | string | Yes | Name of the project |
problem_statement | string | Yes | Core problem being solved |
mvp_features | string[] | Yes | MVP feature list from hackathon-scope-cutter |
tech_stack | string[] | Yes | Technologies being used |
architecture_decisions | object[] | No | For ADR: list of decisions with context and rationale |
feature_name | string | No | For feature-spec: name of the specific feature |
constraints | string[] | No | Technical or product constraints |
Outputs
| Output | Description |
|---|---|
document | Fully populated document in Markdown |
document_type | Type of document generated |
missing_fields | Sections that could not be completed due to missing input |
Rules
- Use the corresponding template from
templates/directory as the output structure. - Do not omit any section from the template; use
[TBD]for missing information. - Keep language direct and scannable — no filler paragraphs.
- For ADR: capture exactly one architectural decision per document.
- For PRD: include success metrics even if they are estimates.
- For feature-spec: include acceptance criteria as testable conditions.
- Flag all
[TBD]sections inmissing_fieldsoutput.
Output Format
document_type: "<ADR|PRD|feature-spec>"
missing_fields:
- "<section name>"
document: |
<Full Markdown document content>Example
Input:
document_type: "ADR"
project_title: "AnchorAI"
problem_statement: "How might we provide always-available emotional support for college students?"
mvp_features:
- "GPT-4 emotional check-in conversation"
- "Session memory"
tech_stack: ["Python", "FastAPI", "React", "OpenAI API", "Redis"]
architecture_decisions:
- title: "Session memory storage"
context: "Need to persist conversation summaries between sessions"
options: ["Redis (in-memory)", "SQLite (file)", "OpenAI conversation history API"]
decision: "Redis"
rationale: "Fastest to set up; sufficient for demo; team familiar with it"Output:
document_type: "ADR"
missing_fields: []
document: |
# ADR-001: Session Memory Storage
**Date:** 2025-06-14
**Status:** Accepted
## Context
AnchorAI must recall emotional context from past user sessions to deliver its core wow factor.
Memory must persist across browser refreshes for the demo.
## Decision
Use Redis as an in-process session store keyed by a hardcoded demo user ID.
## Consequences
- Positive: Setup takes <30 minutes; team knows Redis well
- Negative: Data is lost on server restart; not production-ready
- Risk: Redis unavailable on demo machine → mitigation: fallback to in-memory dictContext Files
Knowledge Base
knowledge/hackathon-reference-architecture.mdknowledge/hackathon-mvp-strategy.md
Templates
templates/ADR-template.mdtemplates/PRD-template.mdtemplates/feature-spec-template.md
Playbooks
playbooks/hackathon-workflow.md