Menu
File a bug report from the current session. Use when something breaks: /lc-feedback <description of what went wrong>
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Comprehensive reference for the `astra.yaml` specification — top-level structure, sub-analyses, inputs/outputs, decisions and options, prior insights and findings, evidence and quote verification, and composition mechanics. Invoke whenever reading, writing, validating, or debugging an `astra.yaml` spec; whenever working with decisions, options, prior_insights, findings, or evidence; or whenever the user asks about ASTRA schema, spec syntax, or sub-analysis composition.
Sentence-by-sentence audit of a paper against an ASTRA project's code. For every claim about implementation or results in the methodology, results, discussion, and appendices, locate the corresponding code (file:line) or mark NOT FOUND. Only the user can invoke this skill, though this skill can be suggested for the user to invoke during paper reproduction. Other skills may mention this skill as an optional follow-up, but should not invoke it themselves. Run from the project folder containing astra.yaml. In lc-from-paper projects, read paper sources from work/reference/: prefer arXiv TeX under work/reference/source/, fall back to Docling/Pandoc markdown at work/reference/document.md.
Build a self-contained HTML report comparing the figures, tables, and numerical results in lc-from-paper's `work/reference/` paper substrate against artifacts produced under `results/<universe>/`. When `comparison-report.yaml` or `targets/targets.md` exists, use that scoped target set first; otherwise fall back to paper-driven inventory from arXiv TeX or Docling/Pandoc artifacts under `work/reference/`. Images are base64-embedded; missing matches are flagged. Use when the user says "compare results", "side-by-side comparison", "build comparison HTML", or "did we reproduce the paper". Run from the project folder containing astra.yaml.
Bring an existing project into ASTRA / lightcone-cli, starting from the code. Scans the codebase, drafts or augments astra.yaml, parameterizes decisions, and runs until outputs materialize. Triggers on "migrate", "convert", "existing project", "wrap this code", "start from code".
This skill should be used when the user wants to reproduce a published scientific paper in ASTRA — has a DOI, arXiv ID, or PDF — or asks to "reproduce <paper>", "set up reproduction", or "import a paper". Also use when continuing or resuming an existing reproduction workdir. The skill instructs Claude to run ORIENT in the user's main session (paper-extraction + interview + code scan, all grounded), then hand the reproduction off to a ralph loop whose iterations carry the remaining phases (ARCHITECT → SPECIFY → LITERATURE → IMPLEMENT → RUN → COMPARE) until the constitution closes, at which point REVIEW close-out runs back in the user's main session.
Use this skill whenever the user starts a new ASTRA analysis from a research question — scoping the question, structuring inputs and outputs, identifying decisions through literature, and landing astra.yaml + project CLAUDE.md. Triggers on verbs (`new`, `start`, `scope`) combined with nouns (`analysis`, `project`, `question`, `research`) — e.g. "new analysis", "start project", "scope research question" — even if the user doesn't say "project" explicitly. Don't use this for working inside an existing ASTRA project; this is for fresh scoping only.
| name | lc-feedback |
| description | File a bug report from the current session. Use when something breaks: /lc-feedback <description of what went wrong> |
| argument-hint | <what went wrong> |
File a bug report against the right Lightcone repo based on the current session.
Be fast. The user is in the middle of work and wants to get back to it.
Run gh auth status silently. If it fails:
GitHub CLI is not authenticated. Run
gh auth login, then try again.
Stop.
The user should have provided a description inline (e.g., /lc-feedback pipeline dies on second output). If they didn't, ask briefly:
What went wrong?
Triage the repo from context:
astra CLI, schema validation, YAML parsing, helperslc CLI, recipe execution, container builds, scaffolding, skillsDefault to lightcone-cli if ambiguous.
Collect versions silently:
python3 -c "import astra; print(astra.__version__)" 2>/dev/null || echo "n/a"
python3 -c "import lightcone.cli; print(lightcone.cli.__version__)" 2>/dev/null || echo "n/a"
python3 --version 2>&1
uname -s -r
Show the user a single confirmation message with the target repo, title, and body. Use AskUserQuestion with options "File it" / "Let me edit". The issue body format:
## What happened
[1-3 sentences combining user description + session context]
## Error
[Trimmed error/traceback from session, if any]
## Reproduction
[Brief steps from session context]
## Environment
- ASTRA: [version]
- lightcone-cli: [version]
- Python: [version]
- OS: [os]
Omit sections that don't apply (e.g., no Error section if there was no traceback).
gh issue create --repo LightconeResearch/<REPO> --title "<TITLE>" --label "beta-feedback" --body "<BODY>"
If it fails due to the label not existing, retry without --label. Print the issue URL.