research-proposal-structure

name	research-proposal-structure
description	Use when an agent needs to produce, update, validate, or normalize a standardized research proposal artifact without running an interview. Defines the canonical structure, confidence-tag semantics, decision logic, and completion checks for proposal.md-style research plans.
version	1.0.0
author	Hermes Agent
license	MIT
metadata	{"hermes":{"tags":["research","proposal","structure","standardization","agents"],"related_skills":["research-proposal-interview","experiment-log-structure"]}}

Research Proposal Structure

Overview

This skill defines the artifact contract for a standardized research proposal. It is for agents that already have the necessary content and need to turn it into a durable, comparable, machine-readable markdown proposal — or check whether an existing proposal meets the standard.

Use this when the task is to write, clean up, standardize, audit, or update a proposal document. Unlike research-proposal-interview, this skill does not prescribe a Socratic questioning flow. It assumes the content is already available or is being generated by another process.

The governing principle is: specificity decays gracefully with distance from the present. The root question and success criteria stay fixed, immediate experiments are fully specified, and future work is represented as conditional branches instead of fake certainty.

When to Use

Use when:

• An agent must draft a proposal directly from provided context.
• A rough proposal needs to be normalized into the canonical markdown structure.
• You want to validate whether a proposal is decision-useful before handing it to another agent or human.
• You want a reusable scaffold for research planning without the interview UX.
• You need consistency across many proposal artifacts.

Do not use when:

• The main need is to elicit missing information from a human collaborator. Use research-proposal-interview.
• The artifact is a post-hoc experiment entry rather than a forward-looking proposal. Use experiment-log-structure.
• The task is a literature review with no empirical decision process.

Canonical Output

Create or normalize a markdown proposal using references/template.md as the authoritative skeleton.

Default filename: proposal.md in the working directory unless the caller specifies another path.

Every proposal should be legible to:

1. the original author,
2. a skeptical collaborator,
3. a future agent deciding what to do next.

Section Contract

1. Question & Significance (fixed)

• State one root question the whole proposal serves.
• Explain why the answer matters.
• Record the current best guess honestly as a prior, not as a conclusion.

2. Success Criteria (fixed)

• Define what strong-yes, strong-no, and inconclusive evidence look like.
• Make the criteria externally checkable.
• If inconclusive, specify what the process does next.

3. Prior Work & Gap

• Summarize the relevant baseline, known results, or prior attempts.
• Make the gap explicit: what is still not known or not resolved.
• Links/citations are preferred when available.

4. Theory of the Problem (semi-fixed)

• Describe the mechanism or framing that makes the question tractable.
• Separate your own theory from the literature summary.
• List the implicit assumptions the theory depends on.

5. Lines of Attack (semi-fixed)

• Give 2–4 plausible strategies.
• Rank them by current credence.
• For each line: state what it is, why it might work, what must be true, and rough cost/time.
• Mark weaker or contingent lines as [conditional] rather than pretending they are committed.

6. Immediate Experiment(s) (fully specified)

• At least one immediate experiment must be concrete enough to execute.
• Each immediate experiment needs:
  • hypothesis,
  • method,
  • primary metric,
  • decision gate,
  • interpretation of outcomes.
• The "adversarial trio" is mandatory:
  • confirmatory test,
  • falsification test,
  • alternative-explanation test.

7. Conditional Next Steps (branching)

• Do not write a fake roadmap.
• Express next steps as branches conditioned on the outcome of section 6.
• Include explicit kill criteria for abandoning the whole line of inquiry.

8. Speculative Horizon (speculative)

• Describe the end-state if the line of inquiry works.
• This section is intentionally aspirational and should stay clearly marked as speculative.

9. Risks & Assumptions (revisited)

• Use a table with likelihood, impact, and mitigation/contingency.
• Include both technical and epistemic risks.

10. Decision Log

• The proposal is a contract about how decisions will be made.
• Actual findings belong in experiment entries / research logs.
• Record material updates with dates.

Confidence Tags

Use these tags exactly and consistently:

• [committed] — fully specified, ready to execute, owned.
• [planned] — intended next work, but not yet execution-ready.
• [conditional] — only makes sense under specific decision-gate outcomes.
• [speculative] — directional, aspirational, or long-horizon thinking.

Downgrade tags when uncertain. Honest tagging is more valuable than impressive-sounding overcommitment.

Standardization Rules

1. One root question. If the document seems to answer multiple unrelated questions, split it.
2. Decision-useful over comprehensive. The proposal should tell an agent what to do next under plausible outcomes.
3. No fake certainty. Future branches must be conditional, not narrated as foregone conclusions.
4. Experiments must inform the root question. If section 6 cannot change a decision in section 7, it is probably drift.
5. Kill criteria are required. A proposal that cannot fail is not a proposal; it is a wish.
6. Findings live elsewhere. Do not smuggle post-hoc results into the proposal body; send those to experiment entries.

Update Procedure

When revising an existing proposal:

1. Read the whole file first.
2. Preserve the root question unless the user explicitly wants a different proposal.
3. Normalize headings and tags to the canonical template.
4. Update the decision log with a dated entry when the change is material.
5. If new evidence changes the plan, update sections 5–9 accordingly while keeping section 1 aligned.

Validation Checklist

A proposal is ready when:

• The root question is one sentence and unambiguous.
• Success criteria are concrete enough for a third party to judge.
• Immediate experiment(s) are executable without hidden assumptions.
• At least one falsification path exists.
• Conditional branches are driven by explicit outcomes.
• Kill criteria exist for the broader line of inquiry.
• Confidence tags reflect actual certainty.
• The decision log notes major changes.

Common Pitfalls

1. Proposal drift. Immediate experiments become interesting but no longer answer the root question.
2. Fake roadmaps. Distant future work is written with [planned] when it should be [conditional] or [speculative].
3. No kill criteria. The project can absorb endless weak evidence without a stopping rule.
4. Missing falsifier. The document lists only confirmatory tests.
5. Result leakage. Post-hoc findings creep into the planning artifact instead of the experiment log.

Reference Files

• references/template.md — canonical proposal skeleton.