speckit-fact-layer

Collect runtime facts from logs, DOM, and computed styles before fixes.

95|39|Updated Dec 15, 2025
One-click install
npx skills add https://github.com/liuminxin45/auto-podcast --skill speckit-fact-layer
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: speckit-fact-layer
Source: https://github.com/liuminxin45/auto-podcast/tree/main/.agents/spec-kit/skills/speckit-fact-layer
Command: npx skills add https://github.com/liuminxin45/auto-podcast --skill speckit-fact-layer

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents repeated, evidence-poor fixes by gathering concrete runtime facts before another patch is attempted. It helps resolve UI, layout, device, permission, connection, and bridge issues when source code alone is not enough.

Core Features & Use Cases

  • Log-Based Fact Gathering: Reads the latest local SDK and service bridge logs to align debugging with the actual runtime timeline.
  • Real Electron Inspection: Uses Chrome DevTools or direct CDP target selection to inspect the live host application instead of relying on assumptions.
  • Source-to-Runtime Validation: Checks DOM structure, computed styles, box metrics, console output, and built artifact consistency before recommending the next fix.
  • Use Case: A UI change still looks wrong after the first patch, so the Skill collects a fact pack that confirms the real layout owner, runtime target, and likely next implementation step.

Quick Start

Ask the AI to create a fact pack for the current issue by gathering repository facts, the newest logs, and the real Electron target before proposing another fix.

Frequently Asked Questions about speckit-fact-layer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I collect runtime facts before retrying Electron layout fixes?

To collect runtime facts for Electron layout fixes, you read the newest local logs, inspect the live host using Chrome DevTools or CDP target selection, and validate source-to-runtime DOM consistency before proposing another patch.

Why does my UI layout still look wrong after the first patch in Spec-Kit?

Your UI layout may still look wrong because source code alone is insufficient. You need to gather a fact pack that checks computed styles, box metrics, and console output to confirm the real layout owner before the next fix.

How do I select the correct Chrome DevTools target for Electron runtime debugging?

For Electron runtime debugging, you select the direct CDP target to inspect the live host application instead of relying on assumptions, ensuring your computed style and DOM structure checks reflect the actual runtime environment.

Can I validate source-to-runtime consistency for Spec-Kit bridge troubleshooting?

Yes, you can validate source-to-runtime consistency for Spec-Kit bridge troubleshooting by reading the latest local SDK and service bridge logs to align your debugging timeline with the actual runtime behavior before attempting a fix.

What is the best way to debug device state and permission issues without source code?

The best way to debug device state and permission issues without source code is to gather concrete runtime facts, including log reviews and built artifact consistency checks, to ground your troubleshooting in actual runtime evidence.

When should I not use source code alone for UI parity troubleshooting?

You should not rely on source code alone for UI parity troubleshooting when repeated evidence-poor fixes fail, requiring you to collect DOM structure and console output facts from the live Electron target to identify the true layout owner.