AI Skill Report Card
Extracting Frontend Logic for Reuse
Quick Start13 / 15
Given a live page running the target application, perform a three-pronged extraction:
- Network tab → find the XHR/fetch call that loads the app's state/config data (XML, JSON). This reveals the data model.
- Sources tab / view-source → locate the closure (
$(document).ready(), IIFE, bundled module) holding the core logic. Identify what's encapsulated vs. globally exposed. - Asset inspection → download referenced static assets (SVGs, images, fonts) and inspect their internal structure (e.g.,
<path>elements,id/classattributes) for programmatic hooks.
Translate findings into a standalone module with a clean public API — never ship the extraction as copy-pasted legacy code.
Recommendation▾
Add a concrete before/after code snippet (e.g., actual JS showing state object translation) rather than prose descriptions in the examples
Workflow14 / 15
Progress:
- [ ] Load target page, open DevTools (Network + Elements + Sources)
- [ ] Identify encapsulation boundary (what's hidden inside closures/minified scope)
- [ ] Capture dynamic data source(s): intercept XHR/fetch, save sample payloads
- [ ] Map data source fields to visual/UI zones (IDs, selectors, coordinates)
- [ ] Download and inspect static vector/image assets for addressable sub-elements
- [ ] Identify rendering/export dependencies (canvas libs, html2canvas, print logic)
- [ ] Design a new state object replacing domain-specific data with target domain
- [ ] Reimplement rendering against the new stack (not literal CSS/DOM copy)
- [ ] Verify parity: same zones/IDs drive the same visual outcomes
Step details:
- Encapsulation diagnosis: Note whether logic lives in a closure, an IIFE, or is attached to
window. This tells you whether you can hook into the live instance or must fully reimplement. - Data source capture: Record the exact request (URL, method, params) and a sample response. This is the "schema" to replace with your own domain data.
- Resource mapping table: Always produce a table of
Resource Type | Source URL/Selector | Purpose— this is the deliverable that lets someone else reproduce the extraction without re-running DevTools. - Asset ID harvesting: For SVG/vector assets, open the raw file and list every
<path>/<g>id. These become your programmatic hook points (e.g.,document.getElementById(id).style.fill = color). - State translation: Replace the original domain's array/dictionary (e.g., sight words) with the new domain's array (e.g., asset categories), keeping the same shape (
index → zone mapping) so existing wiring logic still works.
Recommendation▾
Include a third example showing a successful full output artifact (e.g., full resource mapping table example) to ground the abstract table concept
Examples16 / 20
Example 1:
Input: A legacy worksheet generator renders fillable shapes via external SVGs loaded in <img> tags, with word data pulled from /xml/word-list.xml, all logic trapped in a jQuery closure.
Output:
- Resource map table identifying state engine script, SVG asset folder, export library.
- Instruction to intercept XHR for
.xmlto recover ID→content mapping. - Note that SVGs must be downloaded (not referenced live) and given unique path IDs since
<img>-embedded SVGs can't be styled via JS. - A new standalone
TrackerAppobject replacing the word dictionary with a domain-specific array, keyed the same way (zones: [{ elementId, assetIdx }]).
Example 2:
Input: A canvas-based drawing tool has its stroke logic bundled in a minified app.min.js with no source map.
Output:
- Note that canvas-based (not SVG) rendering means there's no DOM to inspect; recommend instrumenting via
CanvasRenderingContext2D.prototypemonkey-patching to log draw calls instead of reading source. - Resource map limited to confirmed network/asset findings; flag the rendering logic as "opaque — must reimplement from observed behavior, not extracted source."
Recommendation▾
Clarify what 'parity verification' looks like concretely — a checklist or test approach for confirming visual/behavioral equivalence
Best Practices
- Always produce the Resource Mapping table — it's the single most reusable artifact of an extraction.
- Prefer inline SVG over
<img>-referenced SVG when porting, since only inline/injected SVG DOM nodes can be styled/manipulated with JS. - Keep the shape of the original state mapping (e.g.,
elementId → index) when swapping domains — this minimizes the surface area of required logic changes. - Explicitly separate what was found via DevTools (diagnostic, read-only) from what is proposed as new code (adapted, stack-appropriate) — never present inspected literal CSS/DOM as the final implementation.
- Call out any export/render dependency (e.g.,
html2canvas) as a swappable black box with a clear input (DOM node) and output (image/PDF) contract.
Common Pitfalls
- Don't copy-paste literal CSS selectors or inline styles discovered via DevTools directly into a modern codebase — adapt them to the project's actual styling approach (Tailwind, CSS modules, styled-components, etc.).
- Don't assume
<img>-embedded SVG paths are stylable from JS — they're not; they must be inlined or fetched and injected as DOM. - Don't skip capturing a sample payload of the dynamic data source — without it, the new state engine's shape is guesswork.
- Don't conflate "logic is in a closure" with "logic is inaccessible" — closures just mean you must reimplement rather than monkey-patch; still extract the behavior, not just the bundle reference.
- Don't ship the extraction notes as production code — always route through a translation step that fits the target project's framework and conventions.