superlab 0.1.0 → 0.1.2

package/lib/install.cjs

@@ -30,6 +30,14 @@ const ASSET_GROUPS = {
       from: path.join(REPO_ROOT, "package-assets", "shared", "templates"),
       to: path.join(".superlab", "templates"),
     },
+    {
+      from: path.join(REPO_ROOT, "package-assets", "shared", "config"),
+      to: path.join(".superlab", "config"),
+    },
+    {
+      from: path.join(REPO_ROOT, "package-assets", "shared", "changes"),
+      to: path.join(".superlab", "changes"),
+    },
     {
       from: path.join(REPO_ROOT, "package-assets", "shared", "scripts"),
       to: path.join(".superlab", "scripts"),
@@ -38,6 +46,10 @@ const ASSET_GROUPS = {
       from: path.join(REPO_ROOT, "package-assets", "shared", "examples"),
       to: path.join(".superlab", "examples"),
     },
+    {
+      from: path.join(REPO_ROOT, "package-assets", "shared", "context"),
+      to: path.join(".superlab", "context"),
+    },
   ],
 };
 
@@ -127,9 +139,28 @@ function localizeInstalledAssets(targetDir, lang) {
     path.join(".claude", "commands", "lab", "report.md"),
     path.join(".claude", "commands", "lab", "write.md"),
     path.join(".codex", "skills", "lab", "SKILL.md"),
+    path.join(".codex", "skills", "lab", "stages", "idea.md"),
     path.join(".codex", "skills", "lab", "stages", "write.md"),
     path.join(".claude", "skills", "lab", "SKILL.md"),
+    path.join(".claude", "skills", "lab", "stages", "idea.md"),
     path.join(".claude", "skills", "lab", "stages", "write.md"),
+    path.join(".superlab", "templates", "idea.md"),
+    path.join(".superlab", "templates", "proposal.md"),
+    path.join(".superlab", "templates", "design.md"),
+    path.join(".superlab", "templates", "spec.md"),
+    path.join(".superlab", "templates", "tasks.md"),
+    path.join(".superlab", "templates", "iteration-report.md"),
+    path.join(".superlab", "templates", "review-checklist.md"),
+    path.join(".superlab", "templates", "final-report.md"),
+    path.join(".superlab", "templates", "paper-plan.md"),
+    path.join(".superlab", "templates", "paper-section.md"),
+    path.join(".superlab", "templates", "write-iteration.md"),
+    path.join(".superlab", "config", "workflow.json"),
+    path.join(".superlab", "context", "mission.md"),
+    path.join(".superlab", "context", "state.md"),
+    path.join(".superlab", "context", "decisions.md"),
+    path.join(".superlab", "context", "evidence-index.md"),
+    path.join(".superlab", "context", "open-questions.md"),
   ];
 
   for (const relativePath of relativePaths) {

package/package-assets/claude/commands/lab/spec.md

@@ -1,6 +1,6 @@
 ---
 name: "LAB: Spec"
-description: Convert an approved idea into OpenSpec spec-driven artifacts
+description: Convert an approved idea into a lab change directory
 category: Workflow
 tags: [workflow, research, spec]
 ---

package/package-assets/claude/commands/lab/write.md

@@ -7,4 +7,4 @@ tags: [workflow, research, writing]
 
 Use the installed `lab` skill at `.claude/skills/lab/SKILL.md`.
 
-This command runs the `/lab:write` stage. It must read the matching section reference from the companion `research-paper-writing` skill, plus `paper-review.md` and `does-my-writing-flow-source.md`, before revising one section.
+This command runs the `/lab:write` stage. It must read the matching section reference from `.claude/skills/lab/references/paper-writing/`, plus `paper-review.md` and `does-my-writing-flow-source.md`, build a mini-outline, and then revise only one section.

package/package-assets/codex/prompts/lab-spec.md

@@ -1,5 +1,5 @@
 ---
-description: Convert an approved idea into OpenSpec spec-driven artifacts
+description: Convert an approved idea into a lab change directory
 argument-hint: approved idea context
 ---
 

package/package-assets/codex/prompts/lab-write.md

@@ -5,4 +5,4 @@ argument-hint: section or writing target
 
 Use the installed `lab` skill at `.codex/skills/lab/SKILL.md`.
 
-This command runs the `/lab:write` stage. It must read the matching section reference from the companion `research-paper-writing` skill, plus `paper-review.md` and `does-my-writing-flow-source.md`, before revising one section.
+This command runs the `/lab:write` stage. It must read the matching section reference from `.codex/skills/lab/references/paper-writing/`, plus `paper-review.md` and `does-my-writing-flow-source.md`, build a mini-outline, and then revise only one section.

package/package-assets/shared/changes/README.md

@@ -0,0 +1,10 @@
+# `.superlab/changes`
+
+Each approved `/lab:spec` change lives in one directory:
+
+- `.superlab/changes/<change-id>/proposal.md`
+- `.superlab/changes/<change-id>/design.md`
+- `.superlab/changes/<change-id>/spec.md`
+- `.superlab/changes/<change-id>/tasks.md`
+
+This keeps spec artifacts grouped under `lab` instead of depending on external directory conventions.

package/package-assets/shared/config/workflow.json

@@ -0,0 +1,5 @@
+{
+  "workflow_language": "en",
+  "paper_language": "en",
+  "paper_format": "latex"
+}

package/package-assets/shared/context/decisions.md

@@ -0,0 +1,11 @@
+# Decision Log
+
+Record stable decisions that later stages should not silently overturn.
+
+## Decisions
+
+1. Decision:
+   Reason:
+   Stage:
+   Evidence:
+   Revisit trigger:

package/package-assets/shared/context/evidence-index.md

@@ -0,0 +1,16 @@
+# Evidence Index
+
+Map every important claim to concrete artifacts.
+
+## Claims
+
+1. Claim:
+   Supporting artifacts:
+   Metrics:
+   Limits or caveats:
+
+## Rejected Claims
+
+1. Claim:
+   Why it was weakened or removed:
+   Artifact showing the failure:

package/package-assets/shared/context/mission.md

@@ -0,0 +1,27 @@
+# Research Mission
+
+## Core Problem
+
+- One-sentence problem:
+- Why it matters:
+- Target failure case:
+
+## Success Criteria
+
+- Primary metric:
+- Success threshold:
+- Required baselines:
+- Minimum evidence needed:
+
+## Frozen Boundaries
+
+- Dataset or benchmark scope:
+- Split policy:
+- Evaluation protocol:
+- Hard constraints:
+
+## Campaign Status
+
+- Approved direction:
+- Current owner or session:
+- Last stage that updated this mission:

package/package-assets/shared/context/open-questions.md

@@ -0,0 +1,11 @@
+# Open Questions
+
+Track unresolved issues so the workflow does not invent answers silently.
+
+## Active Questions
+
+1. Question:
+   Why it matters:
+   Best current options:
+   Resolution owner:
+   Target stage:

package/package-assets/shared/context/state.md

@@ -0,0 +1,19 @@
+# Workflow State
+
+## Current Stage
+
+- Active stage:
+- Current objective:
+- Next required output:
+
+## Latest Update
+
+- Last completed action:
+- Latest artifact path:
+- Latest run or report id:
+
+## Next Step
+
+- Immediate next action:
+- Blocking issue:
+- Human decision needed:

package/package-assets/shared/examples/minimal-uplift-workflow.md

@@ -20,10 +20,10 @@ Use `/lab:spec` after approving the idea artifact.
 
 Expected artifacts:
 
-- `proposal.md`
-- `design.md`
-- `specs/<capability>/spec.md`
-- `tasks.md`
+- `.superlab/changes/<change-id>/proposal.md`
+- `.superlab/changes/<change-id>/design.md`
+- `.superlab/changes/<change-id>/spec.md`
+- `.superlab/changes/<change-id>/tasks.md`
 
 ## 3. Run
 

package/package-assets/shared/skills/lab/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lab
-description: Strict research workflow for idea development, OpenSpec specification, small-scale experiment execution, bounded iteration, reviewer-grade critique, final reporting, and paper-writing.
+description: Strict research workflow for idea development, lab change specification, small-scale experiment execution, bounded iteration, reviewer-grade critique, final reporting, and paper-writing.
 ---
 
 # /lab Skill
@@ -9,10 +9,18 @@ Use this skill when the user invokes `/lab:*` or asks for the structured researc
 
 ## Global Rules
 
-- Treat OpenSpec CLI as required from `/lab:spec` onward.
 - Keep idea generation, specification, execution, review, and reporting as separate stages.
 - Keep paper writing separate from experiment execution and reporting.
+- Start each stage with a concise user-facing summary before writing artifacts.
+- After that summary, decide whether immediate artifact creation is useful; if yes, write the artifact and then report the output path plus next step.
+- When a missing assumption would materially change the stage outcome, ask one clarifying question at a time.
+- When there are multiple viable paths, present 2-3 approaches with trade-offs and a recommendation before converging.
+- When a stage materially sets downstream direction, keep an explicit approval gate before proceeding.
 - Write durable artifacts to disk instead of leaving key decisions only in chat.
+- Use `.superlab/config/workflow.json` as the global contract for workflow language, paper language, and paper format.
+- Use `.superlab/context/`` as the shared project state for both Codex and Claude entrypoints.
+- Workflow artifacts should follow the installed workflow language.
+- Final paper output should default to LaTeX, and its manuscript language should be decided separately from the workflow language.
 - Separate sourced facts from model-generated hypotheses.
 - Preserve failed runs, failed ideas, and limitations.
 
@@ -21,23 +29,37 @@ Use this skill when the user invokes `/lab:*` or asks for the structured researc
 ### `/lab:idea`
 
 - Search relevant literature, baselines, datasets, and evaluation metrics before proposing a plan.
+- Read `.superlab/context/`mission.md` and `.superlab/context/`open-questions.md` before drafting.
+- Ask one clarifying question at a time when critical ambiguity remains.
+- State the problem, the failure case, and why the problem matters before proposing solutions.
+- Classify the idea by contribution category and breakthrough level.
+- Compare against existing methods explicitly and state why the idea should be better.
 - Distinguish sourced evidence from generated innovation claims.
+- End with three meaningful points that are clear, short, and easy to scan.
+- Produce 2-3 candidate approaches with trade-offs before recommending one.
 - Critique the idea before converging on it.
+- Keep an explicit approval gate before `/lab:spec`.
 - Write idea artifacts with the template in `.superlab/templates/idea.md`.
+- Update `.superlab/context/`mission.md`, `.superlab/context/`decisions.md`, and `.superlab/context/`open-questions.md` after convergence.
 - Do not implement code in this stage.
 
 ### `/lab:spec`
 
-- Require `bash scripts/check_openspec.sh`.
-- Convert the approved idea into OpenSpec `spec-driven` artifacts using `.superlab/templates/proposal.md`, `.superlab/templates/design.md`, `.superlab/templates/spec.md`, and `.superlab/templates/tasks.md`.
+- Read `.superlab/config/workflow.json` before drafting the change.
+- Read `.superlab/context/`mission.md`, `.superlab/context/`decisions.md`, and `.superlab/context/`state.md` before drafting the change.
+- Use `.superlab/changes/<change-id>/` as the canonical lab change directory.
+- Convert the approved idea into lab change artifacts using `.superlab/templates/proposal.md`, `.superlab/templates/design.md`, `.superlab/templates/spec.md`, and `.superlab/templates/tasks.md`.
+- Update `.superlab/context/`state.md` and `.superlab/context/`decisions.md` after freezing the spec.
 - Do not skip task definition.
 
 ### `/lab:run`
 
 - Start with the smallest meaningful experiment.
+- Read `.superlab/context/`mission.md` and `.superlab/context/`state.md` before choosing the run.
 - Register the run with `.superlab/scripts/register_run.py`.
 - Normalize the result with `.superlab/scripts/eval_report.py`.
 - Validate normalized output with `.superlab/scripts/validate_results.py`.
+- Update `.superlab/context/`state.md` and `.superlab/context/`evidence-index.md` after the run.
 
 ### `/lab:iterate`
 
@@ -47,45 +69,66 @@ Use this skill when the user invokes `/lab:*` or asks for the structured researc
   - primary metric
   - success threshold
   - verification commands
+  - completion_promise
   - maximum iteration count
 - Only change implementation hypotheses within the loop.
 - Require a normalized evaluation report each round.
+- Read `.superlab/context/`mission.md`, `.superlab/context/`state.md`, `.superlab/context/`decisions.md`, and `.superlab/context/`evidence-index.md` at the start of each round.
+- Switch to diagnostic mode if risk increases for two consecutive rounds.
 - Write round reports with `.superlab/templates/iteration-report.md`.
-- Stop at threshold success or iteration cap.
+- Update `.superlab/context/`state.md`, `.superlab/context/`decisions.md`, `.superlab/context/`evidence-index.md`, and `.superlab/context/`open-questions.md` each round as needed.
+- Stop at threshold success or iteration cap, and record blockers plus next-best actions when the campaign ends without success.
 
 ### `/lab:review`
 
 - Work in reviewer mode, not implementation mode.
+- Read `.superlab/context/`mission.md`, `.superlab/context/`decisions.md`, and `.superlab/context/`evidence-index.md` before reviewing.
+- Start with a concise summary of what is being reviewed and the top review question.
 - Prioritize methodology, fairness, leakage, statistics, ablations, and claim discipline.
+- Output findings first, then fatal flaws, then fix priority, then residual risks.
 - Use `.superlab/templates/review-checklist.md`.
+- Write durable review conclusions back to `.superlab/context/`state.md` or `.superlab/context/`open-questions.md` when they affect later stages.
 
 ### `/lab:report`
 
 - Summarize all validated iteration summaries.
+- Read `.superlab/context/`mission.md`, `.superlab/context/`state.md`, `.superlab/context/`decisions.md`, and `.superlab/context/`evidence-index.md` before drafting.
 - Aggregate them with `.superlab/scripts/summarize_iterations.py`.
 - Write the final document with `.superlab/templates/final-report.md`.
 - Keep failed attempts and limitations visible.
+- Update `.superlab/context/`state.md` and `.superlab/context/`evidence-index.md` with report-level handoff notes.
 
 ### `/lab:write`
 
 - Start only after `report` artifacts are stable enough to support paper claims.
+- Read `.superlab/config/workflow.json` before drafting and enforce its `paper_language` and `paper_format`.
+- Read `.superlab/context/`mission.md`, `.superlab/context/`decisions.md`, and `.superlab/context/`evidence-index.md` before drafting.
 - Write one paper section or one explicit subproblem per round.
 - Bind each claim to evidence from `report`, iteration reports, or normalized summaries.
-- Write paper artifacts with `.superlab/templates/paper-plan.md`, `.superlab/templates/paper-section.md`, and `.superlab/templates/write-iteration.md`.
-- Use the companion `research-paper-writing` skill references for the current section and required review passes.
+- Write planning artifacts with `.superlab/templates/paper-plan.md`, `.superlab/templates/paper-section.md`, and `.superlab/templates/write-iteration.md`.
+- Write final manuscript artifacts with `.superlab/templates/paper.tex` and `.superlab/templates/paper-section.tex`.
+- Use the vendored paper-writing references under `skills/lab/references/paper-writing/`.
+- Load only the current section guide, plus `paper-review.md` and `does-my-writing-flow-source.md`.
+- Build a compact mini-outline before prose.
+- For each subsection, explicitly cover motivation, design, and technical advantage when applicable.
+- Keep terminology stable across rounds and sections.
+- If a claim is not supported by evidence, weaken or remove it.
+- Before finalizing a round, append and answer the five-dimension self-review checklist and revise unresolved items.
 - Apply paper-writing discipline without changing experimental truth.
 - If the evidence is insufficient, stop and route back to `review` or `iterate`.
+- Update `.superlab/context/`state.md` and `.superlab/context/`evidence-index.md` when section-level claim status changes.
 
 ## Hard Gates
 
 - No implementation before `/lab:spec`.
 - No unconstrained iteration. Every `/lab:iterate` campaign must declare done criteria and `max_iterations`.
 - No final report without validated normalized results.
-- No paper-writing round without stable report artifacts and evidence links.
+- No paper-writing round without stable report artifacts, evidence links, and LaTeX manuscript output.
 
 ## References
 
 - Workflow summary: `.codex/skills/lab/references/workflow.md` or `.claude/skills/lab/references/workflow.md`
+- Brainstorming integration: `.codex/skills/lab/references/brainstorming-integration.md` or `.claude/skills/lab/references/brainstorming-integration.md`
 - Idea stage guide: `.codex/skills/lab/stages/idea.md` or `.claude/skills/lab/stages/idea.md`
 - Spec stage guide: `.codex/skills/lab/stages/spec.md` or `.claude/skills/lab/stages/spec.md`
 - Run stage guide: `.codex/skills/lab/stages/run.md` or `.claude/skills/lab/stages/run.md`
@@ -94,7 +137,9 @@ Use this skill when the user invokes `/lab:*` or asks for the structured researc
 - Report stage guide: `.codex/skills/lab/stages/report.md` or `.claude/skills/lab/stages/report.md`
 - Write stage guide: `.codex/skills/lab/stages/write.md` or `.claude/skills/lab/stages/write.md`
 - Paper-writing integration: `.codex/skills/lab/references/paper-writing-integration.md` or `.claude/skills/lab/references/paper-writing-integration.md`
-- Companion references: `research-paper-writing/references/{abstract,introduction,related-work,method,experiments,conclusion,paper-review,does-my-writing-flow-source}.md`
+- Vendored paper-writing references: `.codex/skills/lab/references/paper-writing/{abstract,introduction,related-work,method,experiments,conclusion,paper-review,does-my-writing-flow-source}.md` or `.claude/skills/lab/references/paper-writing/{abstract,introduction,related-work,method,experiments,conclusion,paper-review,does-my-writing-flow-source}.md`
 - Command adapters: the installed `/lab:*` command assets
+- Shared workflow config: `.superlab/config/workflow.json`
+- Shared project context: `.superlab/context/`{mission,state,decisions,evidence-index,open-questions}.md`
 - Templates: `.superlab/templates/`
 - Scripts: `.superlab/scripts/`

package/package-assets/shared/skills/lab/references/brainstorming-integration.md

@@ -0,0 +1,21 @@
+# Brainstorming Integration for `/lab`
+
+This reference keeps brainstorming-style interaction rules centralized so each `/lab` stage can stay small and stage-specific.
+
+## Shared Rules
+
+- Start with a concise user-facing summary before creating or revising artifacts.
+- If a missing assumption would materially change the stage outcome, ask one clarifying question at a time.
+- If multiple viable directions exist, present 2-3 approaches with trade-offs and a recommendation before converging.
+- Keep an explicit approval gate when the stage commits downstream direction or locks in scope.
+- Prefer thin stage-specific contracts over copying the full brainstorming workflow into every stage guide.
+
+## Stage Adaptation
+
+- `idea`: use the full pattern most strongly because ambiguity and design exploration are highest here.
+- `spec`: compare viable change decomposition or validation plans before freezing the lab change directory.
+- `run`: compare the smallest meaningful experiment options before spending compute.
+- `iterate`: compare the next 2-3 hypotheses when there is more than one defensible next move.
+- `review`: clarify review scope only when ambiguity changes findings, then stay in reviewer mode.
+- `report`: compare report framing options only when they change interpretation or reader takeaway.
+- `write`: compare section-level narrative structures only when more than one structure is defensible.

package/package-assets/shared/skills/lab/references/paper-writing/abstract.md

@@ -0,0 +1,102 @@
+# Abstract Writing Guide
+
+## Goal
+
+Write a strong abstract by doing three things repeatedly:
+
+1. Think through the abstract logic first.
+2. Follow one template (Version 1/2/3 below).
+3. Revise the abstract many times.
+
+## Pre-Writing Questions (Important)
+
+Answer these before writing:
+
+1. What technical problem do we solve, and why is there no well-established solution? (important)
+2. What is our technical contribution?
+3. Why can our method work in essence?
+4. What technical advantage and new insight do we provide? (important)
+
+## Version 1: Challenge -> Contribution
+
+Introduce the technical challenge, then use one to two sentences to present the technical contribution that solves the challenge.
+
+### Structure
+
+1. Task.
+2. Technical challenge for previous methods.
+3. One to two sentences introducing the technical contribution for solving the challenge.
+4. Benefits of the technical contribution.
+5. Experiment summary.
+
+### Expert Notes
+
+1. Discuss previous work around the technical challenge that we actually solve.
+2. For the contribution sentence(s), usually mention the technical term/name only; do not explain every detailed step.
+3. The technical term must be easy to understand; readers should not feel a jump.
+4. This ability is very important for writing a good abstract.
+
+Version 1 local cite:
+
+1. `references/examples/abstract/template-a.md`
+
+## Version 2: Challenge -> Insight -> Contribution
+
+Introduce the technical challenge, then use one to two sentences to present the insight for solving the challenge, and then one sentence to present the technical contribution that implements this insight.
+
+### Structure
+
+1. Task.
+2. Technical challenge for previous methods.
+3. One sentence introducing the insight for solving the challenge.
+4. One to two sentences introducing the technical contribution that implements the insight.
+5. Benefits of technical novelty.
+6. Experiment summary.
+
+### Expert Notes
+
+1. Discuss previous work around the technical challenge that we actually solve.
+2. Introduce the insight in one clear sentence.
+3. For the implementation sentence(s), usually mention the technical term/name only; do not explain every detailed step.
+4. The technical term must be easy to understand; do not create a jump in reading.
+5. This ability is very important for writing a good abstract.
+
+Version 2 local cite:
+
+1. `references/examples/abstract/template-b.md`
+
+## Version 3: Multiple Contributions
+
+Version 3: When there are multiple technical contributions, describe each contribution together with its technical advantage.
+
+### Structure
+
+1. Task.
+2. If needed, one contrast sentence about prior methods.
+3. Contribution sentence 1 + technical advantage.
+4. Contribution sentence 2 + technical advantage.
+5. Contribution sentence 3 + technical advantage.
+6. Experiment summary.
+
+### Expert Notes
+
+1. When there are multiple technical contributions, describe each contribution together with its technical advantage.
+2. The ability to express "contribution + advantage" in one sentence is very important for writing a good abstract.
+
+Version 3 local cite:
+
+1. `references/examples/abstract/template-c.md`
+
+## Example Bank
+
+1. `references/examples/abstract-examples.md`
+2. `references/examples/abstract/template-a.md`
+3. `references/examples/abstract/template-b.md`
+4. `references/examples/abstract/template-c.md`
+
+## Abstract Quality Checklist
+
+1. Can a reader identify task, challenge, insight/contribution, and results in one pass?
+2. Are all major claims supported by experiments?
+3. Are technical names self-contained and readable?
+4. Is there any sentence that mixes too many messages?

package/package-assets/shared/skills/lab/references/paper-writing/conclusion.md

@@ -0,0 +1,35 @@
+# Conclusion Writing Guide
+
+## Goal
+
+Close the paper with clear takeaways and credible limitations.
+
+## Structure
+
+1. Restate solved problem and core technical idea.
+2. Summarize strongest evidence from experiments.
+3. State practical impact or new insight.
+4. Add limitation paragraph.
+5. End with concrete future direction.
+
+## Limitation Guidance
+
+Prefer limitations tied to task goal/setting boundaries, for example:
+
+1. Data regime limitation (e.g., only short sequences).
+2. Assumption limitation (e.g., controlled viewpoints only).
+3. Deployment scope limitation (e.g., specific sensor setup).
+
+Avoid framing conclusion around fixable implementation flaws unless they critically define your method's scope.
+
+## Distinguish Limitation Types
+
+1. Technical defect: underperforms strong baselines on key metrics or causes unacceptable tradeoff.
+2. Scope limitation: bounded by current task setting and still competitive vs. current SOTA.
+
+## Template
+
+1. This paper addresses [problem] by proposing [method].
+2. The key idea is [core insight], which enables [main benefit].
+3. Experiments show [main gains] across [datasets/settings].
+4. A current limitation is [scope boundary], and extending to [future setting] is an important next step.

package/package-assets/shared/skills/lab/references/paper-writing/does-my-writing-flow-source.md

@@ -0,0 +1,45 @@
+# Does My Writing Flow? 
+
+Note: This file stores the source content extracted from the PDF, with light formatting cleanup for Markdown readability.
+
+## Original Content
+
+### Does My Writing Flow?
+
+One of the most frequent questions writers ask themselves or others is "does my writing flow?" Other variations of this question include "does this make sense?" and "can you understand what I am saying?" The term flow is a vague term that writers use when describing some concern of clarity, coherence, or conciseness. However vague this term may be, writers know it is a very important concern about their work. If you find yourself concerned about the flow of your writing, then here are some strategies to improve it.
+
+1. Pretend you are the reader of your paper.
+
+   - Often when we write, our work makes sense to us because we are the ones who create it. However, at a certain point in the writing process, our writing may become unclear even to us. When we as authors begin to lose sight of our paper's train of thought, other readers are sure to be confused as well.
+   - By looking at your paper from the perspective of a reader, you are checking and making sure your writing is clear to someone who might not be as informed of the paper's topic as you are.
+   - Some questions you might ask to place yourself in the reader's shoes are:
+     1. Would my classmates be able to understand the level of vocabulary I am using?
+     2. How do my body paragraphs connect back to my thesis, and is the connection easy to see?
+     3. Would someone not in my class understand what I am trying to say?
+2. Reverse-outlining
+
+   - Outlining is not only a great pre-writing exercise, but it also can serve as a great post-writing tool. Reverse-outlining means just what it sounds like. It breaks down an already written essay into its basic parts (such as thesis statement, topic-sentences, and the points of proof/explanation used within your body paragraphs), and it allows a writer to see how well topic sentences and paragraphs fit into an essay.
+   - Here is how to reverse outline:
+     1. Write down the thesis statement.
+     2. Write down each topic sentence of each body paragraph.
+     3. Also write down the main points of evidence or explanation used within your body paragraphs.
+     4. Check every topic sentence and make sure it is clearly related to a part of your thesis statement.
+     5. Check all points of proof/explanation and make sure they pertain to the topic of the paragraph and provide adequate support.
+     6. If there is a topic sentence that does not clearly relate to the thesis statement, then either revise it and its supporting points of proof/explanation or take it out entirely.
+   - If it is easy to write a reverse outline, then it's a good sign that your paper is well-organized. If you have a hard time creating a reverse outline, then your thesis statement and topic-sentences might be unclear.
+3. Add headings and sections to your paper.
+
+   - If you are not up to making a complete outline (or if you are not very good at outlining - lots of people aren't), then no need to feel bad. You can add headings and sections to your paper. This method achieves a similar effect to reverse outlining.
+   - By splitting a paper into sections and sub-sections with headings, the paper is telling the reader what each part is all about.
+   - For most papers, headings are not necessary. However, you can still make use of them as a tool for drafting and revision. By adding headers to the different sections of a paper, you can easily begin to see the main parts of your paper and how they work together.
+4. Use transitions or "flow" keywords.
+
+   - Using appropriate transition words improves the flow of your paper. These words act as guide posts, indicating the relationship between thoughts, sentences, or paragraphs. You can always make your essay flow better by adding appropriate transitional words and phrases.
+   - Transitional words and phrases:
+     - To show causes and effects: accordingly, as a result, because, consequently, hence, so, then, therefore, thus
+     - To show comparison: also, in the same way, likewise, similarly
+     - To show contrasts or exceptions: although, but, even though, however, in contrast, instead, nevertheless, nonetheless, on the contrary, on the one hand ... on the other hand, still, yet
+     - To show examples: even, for example, for instance, indeed, in fact, of course, such as
+     - To show place or position: above, adjacent to, below, beyond, finally, furthermore, last, moreover, next, too
+     - To show time: after, as soon as, at first, at the same time, before, eventually, finally, immediately, later, meanwhile, next, simultaneously, so far, soon, then, thereafter
+     - To signal a summary or conclusion: as a result, as we have seen, finally, in a word, in any event, in brief, in conclusion, in other words, in short, in the end, in a final analysis, on the whole, therefore, thus, to summarize