| name | autogen-guide |
| description | Generate interactive guide content.json files from source code. Analyzes React/TypeScript UI components to extract structure, selectors, field metadata, and conditional logic, then produces a Pathfinder guide JSON. Use when the user provides GitHub links to source code and wants to create a guide from it, or asks to auto-generate a guide from code. |
AutoGen Guide from Source Code
Generate an interactive guide content.json by analyzing UI source code. This skill orchestrates a multi-phase pipeline where each phase runs in a sub-agent that loads only the context it needs. The orchestrator (you) manages the workflow, user interactions, and handoffs.
Do NOT read external reference files upfront. Each phase's sub-agent loads its own references. Everything the orchestrator needs is inline below.
This skill implements the skill-memory convention. See .cursor/skills/skill-memory.md for the shared assets/, manifest, and frontmatter standards that this skill extends.
Workflow Overview
Input (GitHub URLs)
ā
āā Phase 0: Check for Prior Run āā orchestrator
ā Output: skip or warm-start based on manifest
ā
āā Phase 1: Acquire & Scope āāāāāā orchestrator (no external reads)
ā Runs: extract_components.py ā assets/component-extraction.json
ā Writes: source files fetched, scope confirmed by user
ā Creates: {guide_dir}/assets/
ā
āā Phase 2: Extract & Assess āāāāā sub-agent loads shared/critical-rules.md
ā ā + extraction-patterns.md + selector-strategies.md
ā ā + reads assets/component-extraction.json
ā Writes: {guide_dir}/assets/extraction-report.md
ā
āā Checkpoint: Plan āāāāāāāāāāāāāā orchestrator builds plan, user confirms
ā Writes: {guide_dir}/assets/guide-plan.md
ā
āā Checkpoint: Package Metadata āā orchestrator gathers manifest fields from user
ā Writes: {guide_dir}/assets/package-metadata.json
ā
āā Phase 3: Generate Guide āāāāāāāā per-section sub-agents, each loads authoring-guide.mdc
ā ā + shared/critical-rules.md
ā ā + receives component-extraction.json context for its section
ā ā 3.1 Create guide shell (orchestrator)
ā ā 3.2 For each section ā sub-agent generates section JSON
ā ā 3.3 Assemble via assemble_guide.py ā content.json (with validation)
ā ā 3.4 Generate assets/selector-report.md (orchestrator)
ā Writes: {guide_dir}/content.json + {guide_dir}/assets/selector-report.md
ā
āā Phase 4: Review & Fix āāāāāāāā sub-agent loads review-guide-pr.mdc
ā Writes: fixed content.json + change report
ā
āā Phase 5a: Write Skill Memory āā orchestrator
ā Writes: {guide_dir}/assets/manifest.yaml
ā
āā Phase 5b: Generate Package Manifest āā orchestrator
ā Runs: generate_manifest.py ā {guide_dir}/manifest.json
ā
āā Phase 6: Validate Package āāāā orchestrator
Runs: assemble_guide.py --validate-only + optional CLI validate --package
Critical Rules
Read .cursor/skills/shared/critical-rules.md for rules 1ā15. These apply to ALL generated guides and are passed to sub-agents in their prompts.
Generated Files
The skill's deliverable lives at the output directory root. Everything in assets/ is skill-internal context ā not consumed by the end product.
{guide_dir}/
content.json ā the deliverable (Pathfinder guide)
manifest.json ā the package manifest (generated in Phase 5b)
assets/
extraction-report.md ā component analysis, fields, selectors, grades
guide-plan.md ā section structure and source file assignments
selector-report.md ā selector quality assessment
package-metadata.json ā manifest fields gathered at Package Metadata checkpoint
manifest.yaml ā provenance, drift detection, skill memory
assets/ files are auto-generated and should not be edited manually.
Frontmatter disclaimer
Every generated markdown file in assets/ must start with the standard frontmatter from the skill-memory convention, extended with source-specific fields:
---
disclaimer: Auto-generated by autogen-guide skill. Do not edit manually.
notice: To regenerate, re-run the skill against this source.
input_sha256: {hex digest}
source: {owner}/{repo}@{commit_sha}:{path}
---
Manifest file
After all phases complete, write {guide_dir}/assets/manifest.yaml:
schema_version: 1
skill_name: "autogen-guide"
generated_at: "{ISO 8601 timestamp}"
input_sha256: "{hex digest ā see below}"
source:
repo: "{owner}/{repo}"
branch: "{branch}"
path: "{path}"
commit_sha: "{sha}"
guide:
id: "{guide_id}"
sections:
- "{section-id-1}"
- "{section-id-2}"
total_steps: {N}
selector_quality:
green: {N}
yellow: {N}
red: {N}
files:
extraction_report: "assets/extraction-report.md"
guide_plan: "assets/guide-plan.md"
selector_report: "assets/selector-report.md"
Compute input_sha256 by hashing the source identity ā the commit SHA is the natural fingerprint for source code drift:
echo -n "{owner}/{repo}:{path}@{commit_sha}" | shasum -a 256
This means cosmetic guide edits (title wording, step reordering) do not trigger re-extraction ā only an actual source code change does.
Golden Examples
These examples show the target output quality for common UI patterns. Pass the relevant ones to each section's sub-agent.
Example A: Tab with conditional fields
The most common section pattern. Tab click ā fields ā conditional fields with skippable + hint.
{
"type": "section",
"id": "authentication-settings",
"title": "Authentication Settings",
"requirements": ["on-page:/connections/datasources/edit"],
"blocks": [
{
"type": "markdown",
"content": "Choose how the datasource authenticates with your API. Most public APIs need no auth; private APIs typically use Bearer tokens or API keys."
},
{
"type": "interactive",
"action": "button",
"reftarget": "Authentication",
"content": "Click the **Authentication** tab.",
"tooltip": "Configure credentials for APIs that require authentication."
},
{
"type": "interactive",
"action": "button",
"reftarget": "Bearer Token",
"doIt": false,
"content": "**Bearer Token** sends a static token in the Authorization header.",
"tooltip": "Use for JWT-based APIs or personal access tokens.",
"skippable": true,
"hint": "Select the auth method that matches your API."
},
{
"type": "interactive",
"action": "highlight",
"reftarget": "[aria-label='bearer token']",
"doIt": false,
"content": "Paste your **Bearer token** here.",
"tooltip": "Stored encrypted. Sent as Authorization: Bearer <token> with every request.",
"skippable": true,
"hint": "Select Bearer Token auth first to reveal this field."
},
{
"type": "markdown",
"content": "Each auth method reveals its own credential fields when selected."
}
]
}
Key things: section bookends (intro + summary), tab-click before fields, skippable: true with hint on conditional fields, doIt: false on secrets, no exists-reftarget, concise tooltips that don't name the highlighted element.
Example B: Card grid selection
When the UI uses clickable cards (not a dropdown) for choosing an option. Each card is a button action with doIt: false.
{
"type": "interactive",
"action": "button",
"reftarget": "Basic Authentication",
"doIt": false,
"content": "**Basic Authentication** encodes username and password in the Authorization header.",
"tooltip": "Sends credentials with every request. Use for simple APIs.",
"skippable": true,
"hint": "Click any auth card to see its fields."
}
Key things: action: "button" with the card's visible text, doIt: false so the user makes the choice, skippable because only one card applies.
Example C: Toggle switches and field arrays
Toggles get doIt: false with an explanatory tooltip. Field arrays (add/remove) get the "Add" button highlighted with doIt: false.
[
{
"type": "interactive",
"action": "highlight",
"reftarget": "label:has(span:contains('Skip TLS Verify'))",
"doIt": false,
"content": "**Skip TLS Verify** disables certificate validation.",
"tooltip": "Not recommended for production. Only for dev with self-signed certs.",
"skippable": true,
"hint": "Scroll to TLS / SSL Settings within the Network tab."
},
{
"type": "interactive",
"action": "button",
"reftarget": "Add Custom HTTP Header",
"doIt": false,
"content": "Click **Add Custom HTTP Header** to add key-value headers sent with every request.",
"tooltip": "Common uses: API versioning, content type, request tracing.",
"skippable": true
}
]
Key things: toggles always doIt: false, field array uses button action on "Add" text with doIt: false (don't try to interact with dynamic row items).
Example D: Tab navigation when tab has no stable selector
When a tab has no data-testid, use :contains() pseudo-selector with doIt: false and a hint. If the tab text is unique, action: "button" with the tab text can work.
{
"type": "interactive",
"action": "button",
"reftarget": "Network",
"doIt": false,
"content": "Click the **Network** tab for timeout, TLS/SSL, and proxy settings.",
"tooltip": "Configure connection behavior and security certificates."
}
Key things: action: "button" with the tab label text. If the text isn't unique on the page, use "reftarget": "div[role='tab']:contains('Network')" or similar structural selector. Always doIt: false when the selector is fragile.
Example E: noop for complex concepts
When no single element can be targeted but the user needs context.
{
"type": "interactive",
"action": "noop",
"content": "**Proxy Settings** offer three modes: **Default** (uses environment vars), **None** (direct), and **URL** (custom proxy). Select **URL** to see proxy fields.",
"skippable": true
}
Key things: noop when there's no sensible element to highlight. Keep it brief. Use skippable if the information isn't essential to the guide flow.
Phase 0: Check for Prior Run (Orchestrator)
Before starting the full generation pipeline, check whether this guide has been generated before.
- Check whether
{guide_dir}/assets/manifest.yaml exists
- If it does: read the manifest, extract
input_sha256 and generated_at
- Re-hash the current input:
echo -n "{owner}/{repo}:{path}@{current_commit_sha}" | shasum -a 256
- Compare hashes:
- Match ā no drift; tell the user the guide is up to date and offer options: skip to Phase 4 review, re-generate a specific section, or proceed with a full fresh run
- Mismatch ā drift detected; tell the user the source has changed since
{generated_at} (commit {stored_sha} ā {current_sha}), then proceed with a delta-aware re-run using prior assets/extraction-report.md as warm-start context for the Phase 2 sub-agent
- If manifest does not exist: fresh run ā proceed to Phase 1
assets/manifest.yaml exists?
No ā full generation pipeline (Phase 1 onward)
Yes ā re-hash input
matches stored hash?
Yes ā offer user: skip to review, re-gen section, or fresh run
No ā delta re-run (use prior assets/ as warm start, then Phase 1 onward)
Phase 1: Acquire and Scope (Orchestrator)
You handle this phase directly. No sub-agent needed -- it's mostly tool calls.
1.1 Parse the Input
The user provides GitHub references:
- File URL:
https://github.com/org/repo/blob/main/src/ConfigEditor.tsx
- Directory URL:
https://github.com/org/repo/tree/main/src/editors/config/
- Repo + path hint:
https://github.com/org/repo with "look at src/editors/"
Extract: owner, repo, branch, path(s).
1.2 Fetch the Source Code
Shallow-clone the repo:
git clone --depth 1 --single-branch --branch <branch> https://github.com/<owner>/<repo>.git /tmp/autogen-<repo>
Or for individual files, use the GitHub MCP tools (get_file_contents) or gh CLI.
If the user has already cloned the repo or provides local file paths, use those directly.
1.3 Assess Scope
After fetching the source files, run the component extraction script to get a deterministic count:
python .cursor/tools/extract_components.py {source_file_1} {source_file_2} ... > {guide_dir}/assets/component-extraction.json
Use the scopeEstimate output to present scope to the user:
"The linked directory contains {totalFieldSets} field groups and {totalComponents} interactive elements. This will produce a guide with approximately {N} sections and {M} steps. Should I proceed, narrow, or expand?"
Scope guidelines:
- < 5 elements: Too small. Suggest expanding.
- 5-40 elements: Good scope for one guide.
- 40-80 elements: Large. Consider splitting into multiple guides.
- > 80 elements: Must split or narrow.
1.4 Identify the Entry Point
Look for:
- The file the user linked directly
- Default exports named
ConfigEditor, QueryEditor, SettingsPage, or similar
- The component registered in
module.ts or plugin.json
1.5 Map the Component Tree
From the entry point:
- Read the entry file, identify local imports (skip
@grafana/*, react, etc.)
- For each imported component, read its file (one level deep max)
- Note which file renders which sub-components
Record the commit SHA for provenance:
git -C /tmp/autogen-<repo> rev-parse HEAD
1.6 Create the Guide Directory
Create {guide-id}/ in the workspace root and {guide-id}/assets/ for generated analysis files. The guide-id should be kebab-case, derived from the component's purpose (e.g., infinity-config-tour).
Proceed to Phase 2 after the user confirms scope.
Phase 2: Extract & Assess (Sub-Agent)
Launch a sub-agent using the Task tool. This sub-agent loads the extraction and selector reference files, analyzes the source code, and writes a structured report.
Sub-agent prompt template
Before launching the sub-agent, the orchestrator runs the extraction script:
python .cursor/tools/extract_components.py {source_files} > {guide_dir}/assets/component-extraction.json
The sub-agent receives this structured JSON as context (instead of reading raw source files to enumerate components), and its job shifts to interpreting the extraction ā identifying section groupings, assessing UI patterns, and writing the prose extraction report.
Fill in {placeholders} and pass as the Task prompt:
You are analyzing React/TypeScript UI source code to produce an extraction report for a Pathfinder guide.
**Read these reference files first:**
1. `.cursor/skills/shared/critical-rules.md` -- rules 1-15 that apply to all guides
2. `.cursor/skills/autogen-guide/extraction-patterns.md` -- component patterns, props extraction, conditional logic
3. `.cursor/skills/autogen-guide/selector-strategies.md` -- selector grading (Green/Yellow/Red), quality report template
**Pre-computed component extraction** (read this file ā components, selectors, and grades are already computed):
{guide_dir}/assets/component-extraction.json
**Source files for context** (read only sections relevant to your section grouping decisions):
{list_of_source_file_paths}
**Entry point component**: {entry_point_file}
**Your task:**
1. Read the component-extraction.json ā component inventory, selector grades, and FieldSet groupings are already computed; DO NOT re-count or re-grade from scratch
2. Interpret the extraction: identify logical section groupings (FieldSets map to sections; tabs/sub-components may also create sections)
3. Note UI patterns per section (tab nav, card grid, toggles, field arrays, nested conditionals)
4. Check for plugin.json if present -- extract plugin ID and name
5. Flag any grading caveats (HOC wrapping risks, wrapper mismatches noted in selector-strategies.md)
**Write your results** to `{guide_dir}/assets/extraction-report.md` using the standard frontmatter followed by this structure:
---
disclaimer: Auto-generated by autogen-guide skill. Do not edit manually.
notice: To regenerate, re-run the skill against this source.
input_sha256: {hex digest}
source: {owner}/{repo}@{commit_sha}:{path}
---
## Extraction Report
**Source**: {repo}@{sha} -- {path}
**Entry point**: {entry_point}
**Files analyzed**: N
**Sections identified**: N (list names)
**Interactive elements**: N (from component-extraction.json scopeEstimate)
### Selector Quality
- N/N Green (data-testid or id)
- N/N Yellow (aria-label, button text, name)
- N/N Red (structural only)
### Sections
For each section:
#### Section Name
- Source: file.tsx (lines NāM)
- Fields: (table with columns: Label, Type, Best Selector, Grade, Conditional?)
- UI patterns: tab nav | card grid | toggles | field array | nested conditionals | none
### Conditional Fields
- field ā depends on condition
### Weak Selectors
(table with: Element, File:Line, Best Available, Suggested Fix)
**Return** a brief summary: sections found, element count, selector quality breakdown, and any concerns.
After the sub-agent completes, present the extraction report summary to the user.
Checkpoint: Build the Guide Plan (Orchestrator)
After the user sees the extraction report, build a structural plan. Read {guide_dir}/assets/extraction-report.md and produce {guide_dir}/assets/guide-plan.md with the standard frontmatter followed by:
---
disclaimer: Auto-generated by autogen-guide skill. Do not edit manually.
notice: To regenerate, re-run the skill against this source.
input_sha256: {hex digest}
source: {owner}/{repo}@{commit_sha}:{path}
---
## Guide Plan
**Guide ID**: {guide-id}
**Title**: {Guide Title}
**Guide type**: Product Tour | Setup Guide | Feature Deep-Dive | Workflow Guide
**Target page**: /connections/datasources/edit (or wherever the guide operates)
**Plugin ID**: {plugin-id} (if applicable)
### Navigation Sequence
How the user reaches the target page (e.g., Main menu ā Connections ā Data sources ā [instance])
### Sections
#### 1. {Section Name}
- Section ID: {kebab-case-id}
- Source file: {path/to/component.tsx} (lines NāM)
- Tab/navigation prerequisite: "Click the Authentication tab" (or none)
- Fields: {count} (target 3ā8 interactive steps)
- Key fields: {list of field labels}
- Conditional groups: {e.g., "Bearer Token fields shown when auth type = bearer"}
- UI patterns: tab nav | card grid | toggles | field array | nested conditionals
- Requirements: [on-page:/path]
- Objectives: [] (if any)
- Chains from: independent | section-completed:{previous-id} (only if dependent)
#### 2. {Section Name}
...
### Section Chaining
Only chain when section N creates something section N+1 depends on.
Independent tabs/pages should NOT chain ā use `on-page:/path` instead.
### Notes
- Conditional field handling strategy
- Known weak selectors and how they'll be handled
- Any sections that should be skippable
- Step budget concerns (any sections that may exceed 8 steps)
Present the plan to the user. Let them adjust section order, add/remove sections, or change the navigation sequence before proceeding. Confirm the source file mapping is correct ā Phase 3 will pass these code snippets to per-section sub-agents.
Checkpoint: Package Metadata (Orchestrator)
Before generating guide content, gather package metadata from the user.
Present defaults where possible and ask for confirmation or overrides.
Auto-derived (confirm with user):
id: {guide-id from plan}
description: {1-line summary derived from extraction report}
type: "guide"
Requires user input:
category: What category does this guide belong to?
Suggest based on context (e.g., "data-availability" for datasource guides,
"general" as fallback). Present as a question.
startingLocation: Where in Grafana does this guide launch?
Suggest from target page in plan (e.g., "/connections/datasources/edit").
targeting.match: Where should this guide be recommended?
Suggest { "urlPrefix": "..." } based on startingLocation.
Present the suggestion and ask the user to confirm or customize.
testEnvironment: Where should this guide be tested?
Default suggestion: { "tier": "cloud" }.
author.team: Default "interactive-learning". Ask if different.
Store the confirmed metadata in {guide_dir}/assets/package-metadata.json
for use in Phase 5b manifest generation.
{
"contentJsonPath": "{guide_dir}/content.json",
"type": "guide",
"description": "...",
"category": "...",
"author": { "team": "interactive-learning" },
"startingLocation": "...",
"targeting": { "match": { "urlPrefix": "..." } },
"testEnvironment": { "tier": "cloud" }
}
Phase 3: Generate Guide (Per-Section Sub-Agents)
Instead of one monolithic sub-agent, generate the guide section by section. This keeps each sub-agent's context small and focused, prevents quality degradation in later sections, and allows source code context to flow through.
3.1 Orchestrator: Create the Guide Shell
Write the initial {guide_dir}/content.json with root structure and intro markdown:
{
"id": "{guide_id}",
"title": "{guide_title}",
"blocks": [
{
"type": "markdown",
"content": "{brief intro ā what the guide covers, no markdown title}"
}
]
}
3.2 For Each Section: Launch a Sub-Agent
Iterate through the sections in {guide_dir}/assets/guide-plan.md. For each section, launch a sub-agent that generates just that section's JSON.
Step budget: aim for 3ā8 interactive steps per section. If a section would need more than 10, split it into sub-sections in the plan first. A complete guide should have 25ā50 interactive steps total.
Per-section sub-agent prompt template
Fill in {placeholders} and launch via the Task tool:
You are generating ONE section of a Pathfinder interactive guide as a JSON object.
**Read these reference files first:**
1. `.cursor/authoring-guide.mdc` -- block types, action types, requirements, best practices
2. `.cursor/skills/shared/critical-rules.md` -- rules 1-15 that apply to all guides (violations are blocking)
**Section to generate:**
- Section ID: {section_id}
- Section title: {section_title}
- Requirements: {section_requirements_array}
- Objectives: {section_objectives_array_or_none}
- Tab/navigation prerequisite: {tab_click_description_or_none}
- Fields in this section (from component-extraction.json for this section's FieldSet):
{extraction_data_for_this_section}
**Source code context** (relevant JSX for this section):
```tsx
{source_code_snippet_for_this_section}
Action decision tree:
- Select/dropdown ā
highlight with doIt: false, explain options in tooltip
- Input with sensible default ā
formfill with targetvalue
- Input without sensible default ā
highlight with doIt: false, tooltip explains
- Switch/toggle ā
highlight with doIt: false, tooltip explains when to enable
- Button with stable text ā
action: "button", reftarget: "Button Text"
- SecretInput ā always
doIt: false, never fill secrets
- Red/Yellow selector for input ā always
doIt: false
- Card grid (clickable cards) ā
action: "button" with card text, doIt: false, skippable: true
- Field array (add/remove) ā highlight "Add" button with
doIt: false, explain the pattern
- Collapsible section ā add expand step before child fields
- Tab with no data-testid ā
action: "button" with tab text, doIt: false
Step budget: Generate 3ā8 interactive steps for this section. If the section has more fields than that, prioritize the most important ones and mention the rest in the intro or summary markdown.
Golden example:
{paste the matching golden example from SKILL.md ā choose the example that best matches this section's UI patterns}
Your task:
- Return a single JSON object:
{"type": "section", "id": "{section_id}", ...}
- First block: brief intro markdown (what the user will do in this section)
- If a tab click is needed, that's the first interactive step
- Generate steps for each field per the action decision tree
- Last block: brief summary markdown (what the user configured)
- Return ONLY the section JSON object ā no wrapper, no root structure
Also return a brief text summary: step count, any selectors you're uncertain about, any fields you omitted and why.
#### Building the source code context
For each section, include the **relevant source code snippet** ā the JSX that renders this section's UI. Extract this during Phase 2 or at orchestration time:
1. Read the component file identified in the extraction report for this section
2. Find the JSX fragment that renders this section's fields (search for the FieldSet, tab panel, or component boundary)
3. Include 30ā80 lines of the relevant JSX in the prompt (trim imports and unrelated code)
4. If the section maps to a sub-component, include that sub-component's full JSX return
This gives the sub-agent direct access to prop names, conditional rendering, and selector attributes ā not just the extraction summary.
#### Choosing which golden example to pass
Match the section's UI patterns to the golden examples:
| Section pattern | Golden example |
|----------------|---------------|
| Tab with form fields + conditionals | Example A |
| Card/button grid for selection | Example B |
| Toggle switches or field arrays | Example C |
| Tab with no stable selector | Example D |
| Complex concept needing noop | Example E |
| Mix of patterns | Pass Examples A + the most relevant other |
### 3.3 Orchestrator: Assemble the Guide
After all section sub-agents complete:
1. **Write each returned section JSON** to a temporary file: `{guide_dir}/assets/section-{section_id}.json`
2. **Add the closing summary markdown** to the guide shell as the final block:
```json
{
"type": "markdown",
"content": "{summary of what the user explored/configured, list the key sections, suggest next steps}"
}
- Run the assembly script to assemble and validate in one step:
python .cursor/tools/assemble_guide.py \
--shell {guide_dir}/assets/guide-shell.json \
--sections {guide_dir}/assets/section-*.json \
--output {guide_dir}/content.json
The script validates: unique section IDs, no multistep singletons, no exists-reftarget, tooltip lengths, section bookends, step counts, and no noop-only sections.
- If validation fails: fix the flagged issues in the section JSON files and re-run.
- Spot-check: read the first and last sections to verify structure and bookends.
3.4 Orchestrator: Generate Selector Report
After assembly, write {guide_dir}/assets/selector-report.md by collating sub-agent feedback. Start the file with the standard frontmatter disclaimer, then:
---
disclaimer: Auto-generated by autogen-guide skill. Do not edit manually.
notice: To regenerate, re-run the skill against this source.
input_sha256: {hex digest}
source: {owner}/{repo}@{commit_sha}:{path}
---
## Selector Quality Report
**Generated from**: `{owner}/{repo}@{sha}`
**Date**: {date}
**Guide**: `{guide_id}/content.json`
### Summary
- **Total interactive steps**: N
- **Green (data-testid/id)**: n (percent%)
- **Yellow (aria-label/button text)**: n (percent%)
- **Red (structural only)**: n (percent%)
### Uncertain Selectors
(list selectors that sub-agents flagged as uncertain)
### Suggestions for Source Code Authors
(list elements that would benefit from `data-testid` attributes)
Section chaining guidance
Not every section needs section-completed:previous. Use chaining only when a prior section creates something the next section depends on:
| Relationship | Use section-completed? |
|---|
| Section 1 creates a datasource, section 2 queries it | Yes |
| Section 1 is "Authentication," section 2 is "Network" (independent tabs) | No |
| Section 1 navigates to a page, section 2 uses elements on that page | No ā use on-page:/path instead |
| Section is optional / educational only | No |
Phase 4: Review & Fix (Sub-Agent)
Launch a sub-agent to review and fix the assembled guide.
Sub-agent prompt template
You are reviewing an auto-generated Pathfinder guide for quality and correctness.
**Read this reference file first:**
1. `.cursor/review-guide-pr.mdc` -- complete review protocol (sections 1-4 are blocking checks)
**Then read the guide:**
2. `{guide_dir}/content.json`
**Apply every check from sections 1-4** of the review protocol against the guide JSON.
**Additionally check for these auto-generation-specific issues:**
{tailored_items}
For each issue found, **fix it directly** in `{guide_dir}/content.json`.
After fixing all issues, **return a report**:
- List of issues found and how each was fixed
- Any issues that couldn't be auto-fixed (need human decision)
- Confirmation that the guide JSON is valid/parseable
- Confirmation that all section IDs are unique
- Confirmation that the requirements chain is logical
- Step count per section (flag any section with 0 interactive steps or >10)
Building the tailored review checklist
Before launching the review sub-agent, build {tailored_items} systematically from the Phase 2 extraction report. Walk through each category and include the item if it applies:
**Conditional fields** (include if extraction found conditional rendering):
- These fields are conditional: {list field labels and their conditions}
- Verify each has `skippable: true` and `hint` text explaining the prerequisite
- Verify the prerequisite step (e.g., auth method selection) appears before dependent fields
**Yellow selectors** (include if Yellow-grade selectors were used):
- These steps use Yellow selectors: {list step descriptions and selectors}
- For inputs: verify `doIt: false`
- For buttons: verify `action: "button"` with text match
- Verify tooltips explain the interaction
**Red selectors** (include if Red-grade selectors were used):
- These steps use Red (fragile) selectors: {list step descriptions and selectors}
- ALL must have `doIt: false`
- ALL must have educational tooltips
**Tab navigation** (include if the guide has tabbed UI):
- Tabs in this guide: {list tab names}
- Verify each tab section starts with an interactive step targeting the tab
- Verify the tab-click step uses `action: "button"` with tab text or a stable selector
- Tabs should NOT be targeted via markdown "Click the X tab" ā use an interactive step
**Secret fields** (include if SecretInput components were found):
- These fields are secrets: {list labels}
- ALL must have `doIt: false`
- Tooltip should mention values are stored encrypted
**Section chaining** (include always):
- Verify `section-completed` is only used when section N creates something section N+1 depends on
- Independent sections (e.g., different config tabs) should NOT chain
- Every section should have `on-page:/path` if its elements are page-specific
**Step budget** (include always):
- Verify each section has 3ā8 interactive steps
- Flag sections with 0 or 1 interactive steps (too thin)
- Flag sections with >10 interactive steps (should be split)
Phase 5a: Write Skill Memory Manifest (Orchestrator)
After Phase 4 completes, write {guide_dir}/assets/manifest.yaml. Gather the values from prior phases:
generated_at: current ISO 8601 timestamp
input_sha256: computed in Phase 0 / Phase 1 (same value used in frontmatter)
commit_sha: recorded in Phase 1.5
sections: list of section IDs from the assembled guide
total_steps, selector_quality: from Phase 4 review report output
schema_version: 1
skill_name: "autogen-guide"
generated_at: "{ISO 8601 timestamp}"
input_sha256: "{hex digest}"
source:
repo: "{owner}/{repo}"
branch: "{branch}"
path: "{path}"
commit_sha: "{sha}"
guide:
id: "{guide_id}"
sections:
- "{section-id-1}"
- "{section-id-2}"
total_steps: {N}
selector_quality:
green: {N}
yellow: {N}
red: {N}
files:
extraction_report: "assets/extraction-report.md"
guide_plan: "assets/guide-plan.md"
selector_report: "assets/selector-report.md"
This manifest is the entry point for future maintenance runs (Phase 0).
Phase 5b: Generate Package Manifest (Orchestrator)
Generate the Pathfinder package manifest.json using the metadata gathered at the Package Metadata checkpoint.
-
Run the manifest generation script:
python .cursor/tools/generate_manifest.py \
--input {guide_dir}/assets/package-metadata.json \
--content {guide_dir}/content.json \
--output {guide_dir}/manifest.json
-
The script validates that the id in package-metadata.json matches the id in content.json and exits with an error if they differ.
-
Present the generated manifest.json to the user for final review before proceeding.
Phase 6: Validate Package (Orchestrator)
After manifest generation:
-
Run structural validation on the assembled guide:
python .cursor/tools/assemble_guide.py --validate-only {guide_dir}/content.json
-
Run Pathfinder CLI validation if available (check for a grafana-pathfinder-app checkout):
node {pathfinder-app}/dist/cli/cli/index.js validate --package {guide_dir}
If the CLI is not available, report this as incomplete and instruct the user to run validation manually. The package is still usable but unvalidated.
Final Delivery (Orchestrator)
After Phase 6 completes:
- Read the review report -- check if any issues couldn't be auto-fixed
- Validate JSON -- ensure
{guide_dir}/content.json parses correctly
- Spot-check -- read the first and last sections to verify bookends and structure
- Present to the user -- summarize what was generated:
- Guide location:
{guide_dir}/content.json
- Package manifest:
{guide_dir}/manifest.json
- Sections: N (list names)
- Total interactive steps: N (average per section)
- Selector quality: N Green, N Yellow, N Red
- Any compromises, omitted fields, or known issues
- Review fixes applied
- Note the manifest -- the
manifest.json has been generated alongside the guide. If you need this guide to appear in contextual recommendations, verify the targeting.match rules.
- Note selector improvements -- point the user to
assets/selector-report.md for upstream data-testid suggestions
External Dependencies
This skill reads two files outside its own directory. If they are moved or renamed, sub-agent phases will fail silently:
.cursor/authoring-guide.mdc ā block types, action types, requirements (read by Phase 3 section sub-agents)
.cursor/review-guide-pr.mdc ā complete review protocol (read by Phase 4 review sub-agent)
This skill implements the skill-memory convention. See .cursor/skills/skill-memory.md for the shared assets/, manifest, and frontmatter standards that this skill extends.
Optional Inputs
The user may provide additional context. Use it when available:
| Input | How to Use |
|---|
| Guide type hint | "config tour", "setup guide" ā influences plan structure |
| Target page path | /connections/datasources/edit ā use in on-page: requirements |
| Plugin ID | yesoreyeram-infinity-datasource ā use in plugin-enabled: requirement |
| Audience | "beginners", "admins" ā adjust tone and skippable steps |
Error Handling
Source code is not React/TypeScript
Report immediately. This skill is designed for React/TSX UI components. For other frameworks, describe what you found and suggest manual guide authoring with the /new command.
No stable selectors found
Generate the guide anyway with all doIt: false steps. Every step becomes educational (show-only). Include a prominent note in the extraction report. The guide is still valuable for learning the UI, even if it can't automate interactions.
Imports from external packages
When a component imports from packages you can't read (e.g., @company/shared-components), note the gap. Use the component's props and surrounding context to infer what it renders. Flag uncertainty in the extraction report.
Very large codebase
If the component tree exceeds 15 files or 3000 lines, stop expanding imports and work with what you have. Report the boundary. Suggest the user narrow scope or split into multiple guides.
Sub-agent failures
If a sub-agent returns an error or incomplete result, read its output, diagnose the issue, and either retry with adjusted parameters or handle the phase manually as a fallback.