{"id":4533,"date":"2026-07-08T22:58:56","date_gmt":"2026-07-08T22:58:56","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/07\/08\/automating-cross-repo-documentation-with-github-agentic-workflows\/"},"modified":"2026-07-08T22:58:56","modified_gmt":"2026-07-08T22:58:56","slug":"automating-cross-repo-documentation-with-github-agentic-workflows","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/07\/08\/automating-cross-repo-documentation-with-github-agentic-workflows\/","title":{"rendered":"Automating cross-repo documentation with GitHub Agentic Workflows"},"content":{"rendered":"<p class=\"wp-block-paragraph\">\u201cWhere are the docs?\u201d It\u2019s a question nobody on a product team enjoys answering. The honest reply is usually some variant of \u201cbehind.\u201d A writer is staring at a closed pull request, trying to reverse-engineer what changed. The pull request\u2019s author has already moved on. By the time the doc actually publishes, the feature has shipped, sometimes more than once.<\/p>\n<p class=\"wp-block-paragraph\">That used to be us on the <a href=\"http:\/\/aspire.dev\/\">Aspire<\/a> team (we\u2019re a small team of 10 building dev tools for distributed apps). A few months back, we were trying to figure out how to safely bring AI into automations we already trusted. That\u2019s when we discovered GitHub Agentic Workflows. I started bolting prototypes into <code>microsoft\/aspire<\/code>.<\/p>\n<p class=\"wp-block-paragraph\">Here\u2019s what that bought us, in numbers pulled straight out of GitHub: for Aspire 13.3 and 13.4, <strong>82 feature-docs pull requests merged at a median of 44.8 hours after the product pull request<\/strong>, every one of them reviewed by the engineer who shipped the feature. No new headcount. No process retraining. Just a different way of asking \u201cwho writes this?\u201d<\/p>\n<h2 class=\"wp-block-heading\">\ud83d\udd12 The constraint: cross-repo automation is the hard part<\/h2>\n<p class=\"wp-block-paragraph\">Our product lives in <code>microsoft\/aspire<\/code> and our docs site lives in <code>microsoft\/aspire.dev<\/code>\u2014different repo, deploy target, and review chain. Most teams figure out same-repo automation pretty quickly; cross-repo automation is where things get sharp. Broad repo-scoped tokens belong in a museum, and any responsible security posture (ours included) restricts them accordingly. That\u2019s a good thing. It\u2019s also a real bottleneck if the place where you write the docs isn\u2019t the place where you write the code.<\/p>\n<p class=\"wp-block-paragraph\">The default workflow for years was:<\/p>\n<ol class=\"wp-block-list\">\n<li>Engineer ships a feature in <code>microsoft\/aspire<\/code>.<\/li>\n<li>Docs writer notices weeks later.<\/li>\n<li>Docs writer opens the pull request, reads the diff, and pings the engineer to clarify what changed.<\/li>\n<li>Engineer is on the next feature, vaguely remembers, replies with half the picture.<\/li>\n<li>Docs draft ships, sometimes against a release that\u2019s already out.<\/li>\n<\/ol>\n<p class=\"wp-block-paragraph\">This is the reverse-engineering tax. We needed automation that crossed repos without handing an agent a write-everywhere token. GitHub Agentic Workflows turned out to be the answer.<\/p>\n<h2 class=\"wp-block-heading\">\ud83e\udd16 Why GitHub Agentic Workflows<\/h2>\n<p class=\"wp-block-paragraph\">GitHub Agentic Workflows is a project from the GitHub Next team that I keep describing to people as \u201cGitHub Actions, but with a model as the work-item processor and guard rails that satisfy security review.\u201d That\u2019s reductive, but it\u2019s close.<\/p>\n<p class=\"wp-block-paragraph\">The shape of it:<\/p>\n<ul class=\"wp-block-list\">\n<li>You author a workflow as a <strong>single markdown file<\/strong> (<code>.github\/workflows\/my-thing.md<\/code>). YAML-style frontmatter on top, an English-language prompt underneath.<\/li>\n<li>You run GitHub Agentic Workflows compile, and it generates a sibling <code>.lock.yml<\/code> (a normal GitHub Actions workflow) that you commit alongside.<\/li>\n<li>At runtime, the workflow runs an agent against your prompt with a constrained toolset.<\/li>\n<li>Critically, <strong>the agent doesn\u2019t write to GitHub directly<\/strong>. It emits intent (a JSON blob describing the pull requests, issues, and comments it wants to create), and a separate, narrowly scoped job (the <strong>safe-outputs handler<\/strong>) materializes that intent against a per-workflow GitHub app.<\/li>\n<\/ul>\n<p class=\"wp-block-paragraph\">That last bullet is the unlock. The agent gets read access and a prompt. Writes go through a tiny verifiable pipeline with explicit allow-lists. Security review nods. We ship.<\/p>\n<h2 class=\"wp-block-heading\">\ud83d\udc9a A small aside: kindred stacks<\/h2>\n<p class=\"wp-block-paragraph\">I love when the tools you\u2019re using to build are built with the same tools you\u2019re using to build with. The <a href=\"https:\/\/gh.io\/gh-aw\">GitHub Agentic Workflows docs<\/a> are built with Astro and Starlight. So is aspire.dev\u2014Astro with Starlight, dressed up with the wider Starlight plugin ecosystem (astro-mermaid, starlight-llms-txt, starlight-sidebar-topics, starlight-image-zoom, the gorgeous @catppuccin\/starlight theme, and more. Shout-out to Chris Swithinbank and the Starlight maintainers, the entire ecosystem feels designed by people who genuinely care).<\/p>\n<p class=\"wp-block-paragraph\">There\u2019s a real kinship there. The tool we use to automate docs and the docs site we automate into share the same foundation. Convenient, because the Mermaid sequence diagram in the next section renders the exact same way in both worlds.<\/p>\n<h2 class=\"wp-block-heading\">The end-to-end pipeline<\/h2>\n<p class=\"wp-block-paragraph\">Here\u2019s the flow we landed on. The protagonist is a workflow called <code>pr-docs-check.md<\/code> living in <code>microsoft\/aspire<\/code>.<\/p>\n<figure class=\"wp-block-image size-large\"><img data-opt-id=1713265096  fetchpriority=\"high\" decoding=\"async\" data-recalc-dims=\"1\" height=\"355\" width=\"1024\" src=\"https:\/\/github.blog\/wp-content\/uploads\/2026\/07\/diagram.png?resize=1024%2C355\" alt=\"Sequence diagram showing an automated docs workflow: merging a feature pull request in microsoft\/aspire triggers a GitHub Actions check that has an agent draft the documentation, open a draft pull request in microsoft\/aspire.dev, and request SME review\u2014so docs ship with the feature.\" class=\"wp-image-97406\" \/><\/figure>\n<p class=\"wp-block-paragraph\">A run starts on <code>pull_request: closed<\/code> against <code>main<\/code> or <code>release\/*<\/code>, gated by <code>merged == true<\/code>. From there, the workflow first runs a deterministic target branch resolver in plain bash before the agent ever wakes up:<\/p>\n<ol class=\"wp-block-list\">\n<li>Pull request milestone title (e.g. 13.4 \u2192 release\/13.4 on <code>aspire.dev<\/code>).<\/li>\n<li>Linked-issue milestone title (parse Fixes\/Closes\/Resolves #N from the body, fetch each issue, take the first non-empty milestone).<\/li>\n<li>Pull request base ref, if it matches release\/X.Y[.Z].<\/li>\n<li>Fall back to main.<\/li>\n<\/ol>\n<p class=\"wp-block-paragraph\">This is the linchpin. <strong>Milestones in the product repo map cleanly to release branches in the docs<\/strong> repo. When the agent finally runs, it knows exactly where the docs should land without any creative writing about target branches or guessing.<\/p>\n<p class=\"wp-block-paragraph\">The agent reads the diff, scans linked issues, and decides: does this need docs? If yes, it drafts the actual content in a checked-out <code>microsoft\/aspire.dev<\/code> workspace, following our existing doc-writer skill (voice, MDX conventions, Starlight components). It then emits a <code>create_pull_request<\/code> safe-output and hands off.<\/p>\n<p class=\"wp-block-paragraph\">The safe-outputs handler takes over:<\/p>\n<ul class=\"wp-block-list\">\n<li>Title prefix: [docs]<\/li>\n<li>Label: docs-from-code<\/li>\n<li>draft: true (we never auto-merge)<\/li>\n<li>Base branch: agent-supplied, restricted to <code>main<\/code> or <code>release\/*<\/code><\/li>\n<li>Target repo: <code>microsoft\/aspire.dev<\/code><\/li>\n<li>Reviewer: the <strong>SME identified from the source pull request<\/strong>\u2019s reviews\u2014i.e., whoever the product team trusted to approve the feature, now gets asked to approve the doc for that feature.<\/li>\n<\/ul>\n<p class=\"wp-block-paragraph\">A companion job posts a marker comment back on the source pull request with the docs pull request link and minimizes any older <code>pr-docs-check<\/code> comments on re-run. The engineer who just hit <strong>Merge<\/strong> gets a notification within a few minutes: \u201cHere\u2019s the docs draft. Look it over?\u201d<\/p>\n<h2 class=\"wp-block-heading\">\ud83d\udd10 The safe-outputs contract<\/h2>\n<p class=\"wp-block-paragraph\">The whole security story comes down to a small, boring stretch of frontmatter:<\/p>\n<div class=\"wp-block-code-wrapper\">\n<pre class=\"wp-block-code language-plaintext\"><code>tools: \n  github: \n    toolsets: [repos, issues, pull_requests] \n    min-integrity: approved          # only run pinned, integrity-checked actions \n    allowed-repos: \n      - microsoft\/* \n    github-app: \n      app-id: ${{ secrets.ASPIRE_BOT_APP_ID }} \n      private-key: ${{ secrets.ASPIRE_BOT_PRIVATE_KEY }} \n      owner: \"microsoft\" \n      repositories: [\"aspire.dev\", \"aspire\"] \n\nsafe-outputs: \n  create-pull-request: \n    title-prefix: \"[docs] \" \n    labels: [docs-from-code] \n    draft: true                      # human-in-the-loop, always \n    base-branch: main \n    allowed-base-branches: [main, release\/*] \n    target-repo: \"microsoft\/aspire.dev\" \n    protected-files: blocked         # AGENTS.md, manifests, security config: hands off \n    fallback-as-issue: true <\/code><\/pre>\n<\/div>\n<p class=\"wp-block-paragraph\">That\u2019s the deal in plain text. The agent gets a GitHub App token whose installation is scoped to <strong>exactly two repositories<\/strong>\u2014the product repo and the docs repo\u2014and nothing else in the org is reachable. It can only land pull requests against <code>main<\/code> or <code>release\/*<\/code>. <code>AGENTS.md<\/code> and dependency manifests are off-limits by policy. If the pull request creation fails (network blip, conflict, anything), the framework falls back to filing an issue, so nothing is silently dropped.<\/p>\n<p class=\"wp-block-paragraph\">This is the part security review actually liked. The agent\u2019s reasoning is fuzzy. The action surface is not.<\/p>\n<h2 class=\"wp-block-heading\">\ud83d\udcca By the numbers<\/h2>\n<p class=\"wp-block-paragraph\">Here are the stats from a rolling 30-day window (<strong>May 3 \u2013 June 2, 2026<\/strong>) spanning the back end of the Aspire 13.3 release and the run-up to 13.4:<\/p>\n<figure class=\"wp-block-table\">\n<table class=\"has-fixed-layout\">\n<thead>\n<tr>\n<th><strong>Metric<\/strong>\u00a0<\/th>\n<th><strong>Value<\/strong>\u00a0<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Product pull requests merged in\u00a0microsoft\/aspire\u00a0<\/td>\n<td>396 (338 main \/ 50 release\/13.3 \/ 8 release\/13.2)\u00a0<\/td>\n<\/tr>\n<tr>\n<td>pr-docs-check workflow runs\u00a0<\/td>\n<td>396\u00a0<\/td>\n<\/tr>\n<tr>\n<td>Draft docs pull requests created on\u00a0microsoft\/aspire.dev\u00a0<\/td>\n<td>82\u00a0<\/td>\n<\/tr>\n<tr>\n<td>\u00a0 \u2013 Merged\u00a0<\/td>\n<td>82 (100%)\u00a0<\/td>\n<\/tr>\n<tr>\n<td>\u00a0 \u2013 Closed without merge\u00a0<\/td>\n<td>0\u00a0<\/td>\n<\/tr>\n<tr>\n<td>\u00a0 \u2013 Still open\u00a0<\/td>\n<td>0\u00a0<\/td>\n<\/tr>\n<tr>\n<td>Docs pull requests target branches\u00a0<\/td>\n<td>52\u00a0\u2192\u00a0release\/13.3, 27\u00a0\u2192\u00a0release\/13.4, 3\u00a0\u2192\u00a0main\u00a0<\/td>\n<\/tr>\n<tr>\n<td>Median time-to-merge (docs)\u00a0<\/td>\n<td>44.8 hours\u00a0<\/td>\n<\/tr>\n<tr>\n<td>Merged within 24 h \/ 7 days\u00a0<\/td>\n<td>38% \/ 96%\u00a0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<p class=\"wp-block-paragraph\"><em>Note: <\/em><em>Numbers captured at the time of writing; the workflows keep running, so the totals only go up.<\/em>\u00a0<\/p>\n<p class=\"wp-block-paragraph\">A few of those numbers deserve a second look:<\/p>\n<ul class=\"wp-block-list\">\n<li><strong>396 runs<\/strong> \u2192 82 pull requests is not a defect. The workflow runs on every merged pull request; most of them are internal refactors, test fixes, or dependency bumps with no user-facing surface. The agent saying \u201cno docs needed\u201d 300+ times is a feature.<\/li>\n<li><strong>100% merge rate<\/strong> says the agent\u2019s docs picks are right. The tighter prompt we shipped after the v1 false-positive phase is paying off.<\/li>\n<\/ul>\n<h2 class=\"wp-block-heading\">\u2705 What worked, <strong>\u274c<\/strong> what didn<em>\u2019<\/em>t<\/h2>\n<p class=\"wp-block-paragraph\"><strong>What worked<\/strong><\/p>\n<ul class=\"wp-block-list\">\n<li>\u2705 <strong>Milestone<\/strong> \u2192 release-branch mapping. This was the single highest-leverage choice we made. Engineers already set milestones on pull requests and issues; we got accurate target-branch routing for free.<\/li>\n<li>\u2705 <strong>Draft-only, SME-as-reviewer<\/strong>. The agent never merges. The engineer who shipped the feature is the one who confirms the docs are right. We\u2019ve stopped reverse-engineering features at the doc layer. The engineer just tells the docs draft what to say, in the place where they already are.<\/li>\n<li>\u2705 <strong>Scoped GitHub app per workflow<\/strong>. Each workflow gets its own app token with explicit repo and permission scopes. Security review approved. We approved too; the first time we needed to rotate keys.<\/li>\n<li>\u2705 <strong>protected-files: blocked<\/strong>. The agent cannot touch <code>AGENTS.md<\/code>, package manifests, or repo security config. Period.<\/li>\n<\/ul>\n<p class=\"wp-block-paragraph\"><strong>What didn\u2019t (at first)<\/strong><\/p>\n<ul class=\"wp-block-list\">\n<li>\u274c The agent\u2019s \u201cis this docs-worthy?\u201d gate was too generous in the first version. It drafted pull requests for changes that were genuinely internal, such as a CI tweak or a logging refactor. The result: 9 closures of 69 pull requests (\u224813%), so we tightened the prompt\u2019s user-facing-change definition and added explicit negative examples (CI, internal helpers, tests-only). Now, the rate is trending down.<\/li>\n<li>\u274c Cross-repo pull request creation needed a <strong>mirrored checkout pattern<\/strong> that wasn\u2019t obvious from the docs. The agent works in one repo; safe-outputs needs to find the target repo to push a branch. We solved it by checking out <code>microsoft\/aspire.dev<\/code> twice\u2014once as the current workspace, once <code>under _repos\/aspire.dev<\/code>\u2014so the safe-outputs handler can rediscover it deterministically.<\/li>\n<li>\u274c Big diffs blow prompt budgets. We pre-extract pull request metadata (linked issues, milestone, base ref) in pre-agent-steps bash, so the agent gets a small, structured summary instead of a giant payload. This is GitHub Agentic Workflow\u2019s designed-in pattern, and it works.<\/li>\n<\/ul>\n<h2 class=\"wp-block-heading\">Wrapping up<\/h2>\n<p class=\"wp-block-paragraph\">The changes we made shifted our thinking. A feature wasn\u2019t considered done until the docs were. Docs no longer trail along behind it like a tin can on a string. The engineer\u2019s review is the gate; the bot does the typing.<\/p>\n<p class=\"wp-block-paragraph\">Critically, <strong>this doesn\u2019t replace docs writers<\/strong>; it un-burdens them. Our writers used to spend most of their time reverse-engineering features. Now they spend their time on the things only a human can do well: narrative pages, sample programs, conceptual walkthroughs, the parts of the docs that don\u2019t fall out of a diff. The bot handles the mechanical \u201cthis new option was added; here\u2019s the reference page update\u201d work that was never enjoyable for anyone.<\/p>\n<p class=\"wp-block-paragraph\">Huge thanks to the GitHub Next team for GitHub Agentic Workflows (and for making the safe-outputs primitive a first-class part of the design), and to Chris Swithinbank and the Starlight maintainers for the docs platform we automate into. A genuine thank-you, too, to the security folks whose guardrails forced us to design this the right way the first time. The boring secret of good automation is that strong security constraints make the system more trustworthy and more correct.<\/p>\n<p class=\"wp-block-paragraph\">If you build a product in one repo and ship docs in another\u2014and especially if you have to do it inside any nontrivial security boundary\u2014GitHub Agentic Workflows is worth a serious look. Start with one workflow, such as <code>pr-docs-check<\/code>, and watch what happens to your median time-to-docs.<\/p>\n<h2 class=\"wp-block-heading\">\ud83d\udd17 The other workflows<\/h2>\n<p class=\"wp-block-paragraph\"><code>pr-docs-check<\/code> is the one I wrote this post about, but it\u2019s not running alone. If you\u2019re curious about the rest, the source is public:<\/p>\n<ul class=\"wp-block-list\">\n<li><code>milestone-changelog.md<\/code>: runs every two hours, picks up newly merged pull requests in the active milestone, and maintains a 13.x-Change-log wiki page (new features, improvements, notable bug fixes) with a companion editorial-feedback issue. <strong>346 runs.<\/strong><\/li>\n<li><code>release-update-support-mdx.md<\/code>: on a stable Aspire release, drafts a [support] pull request on <code>aspire.dev<\/code> that updates the support policy page (promotes the new version, demotes the previous one, refreshes the \u201cLast updated\u201d badge).<\/li>\n<li><code>update-integration-data.md<\/code>: lives in the docs repo; runs pnpm update:all daily, refreshes NuGet metadata + GitHub stats + sample data, and opens a chore: Update integration data PR with supersede-and-close logic for stale runs. <strong>27 runs, eight merged pull requests.<\/strong><\/li>\n<li><code>repo-pulse.md<\/code>: a rolling three-day repo dashboard pinned to a single issue and updated in place: recent merges, pull requests awaiting review, new issues, discussion activity. One issue, always fresh.<\/li>\n<\/ul>\n<p class=\"wp-block-paragraph\">Happy automating, friends! \ud83e\udd16\ud83d\ude80<\/p>\n<p>The post <a href=\"https:\/\/github.blog\/ai-and-ml\/github-copilot\/automating-cross-repo-documentation-with-github-agentic-workflows\/\">Automating cross-repo documentation with GitHub Agentic Workflows<\/a> appeared first on <a href=\"https:\/\/github.blog\/\">The GitHub Blog<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"<p>\u201cWhere are the docs?\u201d It\u2019s a question nobody on a product team enjoys answering. The honest reply is usually some [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4534,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[8],"tags":[],"class_list":["post-4533","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-github-engineering"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4533","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=4533"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4533\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media\/4534"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=4533"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=4533"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=4533"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}