DOCS: Support for generating LLM friendy summary for the docs. - #7095
Merged
Merged
Conversation
![scitools-ci[bot]](https://avatars.githubusercontent.com/in/212324?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Templating
This PR includes changes that may be worth sharing via templating. For each file listed below, please either:
- Action the suggestion via a pull request editing/adding the relevant file in the SciTools/.github
templates/directory. 1 - Raise an issue against the SciTools/.github repo for the above action if you really don't have 10mins spare right now. Include an assignee, to avoid it being forgotten.
- Dismiss the suggestion if the changes are not suitable for templating.
You will need to dismiss this review before this PR can be merged. Recommend the reviewer does this as their final action before merging, as this text will continually update as commits come in.
Template candidates
The following changed files are not currently templated, but their parent directories suggest they may be good candidates for a new template to be created:
Footnotes
-
Include this text in the PR body to avoid any notifications about applying the template changes back to the source repo!
@scitools-templating: please no update notification on: iris↩
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #7095 +/- ##
=======================================
Coverage 90.13% 90.13%
=======================================
Files 91 91
Lines 24957 24957
Branches 4684 4684
=======================================
Hits 22496 22496
Misses 1683 1683
Partials 778 778 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Member
|
@tkknight You need to add the |
github-actions
Bot
added
the
benchmark_this
Contributor
⏱️ Performance Benchmark Report: 77c68afPerformance shiftsFull benchmark resultsGenerated by GHA run |
bjlittle
approved these changes
May 26, 2026
* upstream/main: Updated environment lockfiles (SciTools#7097)
Contributor
⏱️ Performance Benchmark Report: aed6370Performance shiftsFull benchmark resultsGenerated by GHA run |
tkknight
added a commit
to tkknight/iris
that referenced
this pull request
May 26, 2026
* upstream/main: DOCS: Support for generating LLM friendy summary for the docs. (SciTools#7095)
7 tasks
bjlittle
added a commit
to bjlittle/iris
that referenced
this pull request
Sep 10, 2026
Adopt the spec/plan convention used in bjlittle/tephpy. Agreed design specs now live in `docs/src/developers_guide/specs/` and are published as part of the documentation. They are written in MyST Markdown, are living documents revised as a design evolves, and each declares a citation prefix so its sections can be cited from issues and pull requests. Implementation plans live in the sibling `docs/src/developers_guide/plans/`. A plan is point-in-time and frozen once its pull request merges, so plans are tracked in the repository but excluded from the Sphinx build. This requires `myst-parser`, added to `requirements/py*.yml` and inserted into the three lock files following the precedent of SciTools#7095 and SciTools#7100. Markdown is used only for specs; all other documentation remains reStructuredText. The merge/concatenate design spec moves here from `docs/superpowers/specs/` and is reworked to the new conventions. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bjlittle
added a commit
that referenced
this pull request
Sep 10, 2026
… and configurable (#7274) * Add design spec for merge/concatenate improvement programme Specifies a twelve-PR programme to make cube merge and concatenate more robust, efficient, configurable, extensible, lazy and lenient, without a rewrite. Each PR is either a behaviour-preserving refactor or a standalone user-visible improvement; together they grow a shared substrate beneath both engines. Includes a confirmed diagnosis and fix for the separability bug open since 2017 (#2761), verified end-to-end against the reporter's case. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Record design-spec location in AGENTS.md Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: publish design specs as MyST Markdown Adopt the spec/plan convention used in bjlittle/tephpy. Agreed design specs now live in `docs/src/developers_guide/specs/` and are published as part of the documentation. They are written in MyST Markdown, are living documents revised as a design evolves, and each declares a citation prefix so its sections can be cited from issues and pull requests. Implementation plans live in the sibling `docs/src/developers_guide/plans/`. A plan is point-in-time and frozen once its pull request merges, so plans are tracked in the repository but excluded from the Sphinx build. This requires `myst-parser`, added to `requirements/py*.yml` and inserted into the three lock files following the precedent of #7095 and #7100. Markdown is used only for specs; all other documentation remains reStructuredText. The merge/concatenate design spec moves here from `docs/superpowers/specs/` and is reworked to the new conventions. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: add a plan roadmap and decision register to the merge spec The spec described a twelve-PR programme but had nowhere to record how far it had got, which assumptions it rested on, or what it had left open. Restructure §6 from a static table of work into the programme's live progress record: dependencies as a partial order rather than a chain, a status vocabulary, an "Outside the roadmap" list, and a numbered register of assumptions and open decisions - each item owned by the pull request that must resolve it. Add §10 for the questions the programme raises but does not answer, renumbering References to §11. Also exclude "_build" and "_static" from the Sphinx build. myst-parser makes ".md" a source suffix, so the README of each was being read as a document. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: record how agentic contributions are pushed and labelled This work is long-running partly because it is also an exercise in earning core-developer buy-in for agentic contributions, so the mechanics of how it reaches them are worth writing down rather than re-deciding each session. Add a "Contribution Workflow" section to AGENTS.md carrying the general rule: branches to the fork, pull requests to a feature branch rather than main, honest "Agentic" labelling, clear attribution, and ask before doing anything outward-facing when unsure. Drop the "Getting Help" link list to stay inside the file's 200-line budget - the links it held are all reachable from CONTRIBUTING.md. The programme-specific parts - base branch "greenfield" and the "Feature: Merge/Concatenate" label - go in the spec's cross-cutting rules instead, where a reviewer can see why these pull requests do not target main. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: add changelog fragments for the design spec Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: rebase the spec baseline onto greenfield The branch was cut from main at c508ac8; greenfield carries #7270 on top of that, which re-solved all three lock files. The lock additions here are re-derived against those fresh locks, and remain minimal - the myst-parser dependency closure and the input_hash, nothing else. The cube.py line references the spec cites are unaffected: #7270's changes are confined to rolling_window, some 4500 lines below the merge and concatenate methods. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Spell out spec section citation runs Give every cited section its own section sign, and separate a run of them with a comma or a solidus rather than a dash. A dashed range such as "5.6-5.7" reads as a single citation carrying a stray suffix, so only its first section is unambiguously identified -- by a reader now, and by any cross-reference tooling later. Records the rule on the Design Specs index page, next to the citation prefix table it belongs with, and applies it to the one occurrence in the merge/concatenate spec. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🚀 Pull Request
Description
Used sphinx_llms_txt to generate
llms.txtandlms-full.txt. The is not fully adopted by LLLM scrapers yet but seems appropriate to add to improve LLM understanding of Iris.Other changes:
conf.pyRef
We should also setup a
robots.txtandsitemap.xmlfile for Iris, this will be a separate PR.Consult Iris pull request check list
Add any of the below labels to trigger actions on this PR: