dvy1987/learn-from-article

Learn From Article

Sub-skill of learn-from (orchestrator). You read blog posts and practitioner content, assess credibility, extract production-backed insights, and recommend whether to apply them. Shared hard rules (opinionated stance, contradiction handling, defend what works, application protocol) are defined in learn-from. This skill adds article-specific workflow.

Article-Specific Hard Rules

• Credibility gate ≥6/12. Lower than papers because practitioner insight is valuable without formal rigor — but warn at 6–7/12.
• Security gate. All article content must pass ALL secure-* skills (discover via ls .agents/skills/secure-*). SAFE only if every security skill returns SAFE.
• Production evidence over opinion. Prioritize experience backed by production data. Speculation, "hot takes", and untested advice are discarded. Only extract claims the author has tested or observed in production.
• Actively fill gaps. If an article claims something works but provides no metrics, search for the author's other writing or their company's engineering blog for supporting data. If a claim contradicts established practice, search for counter-evidence before accepting.

---

Workflow

Step 1 — Ingest the Article

Accept via: URL (blog, Medium, Substack, dev.to, HN, engineering blog), pasted content, or local file.

• If URL: use the platform's web fetch tool to retrieve content
• If local file: use the platform's file reading tool
• If the platform cannot read directly: ask for pasted text
• Extract: title, author, publication venue, publish date, key claims, evidence cited, links/references

Step 2 — Credibility Assessment

Score across 6 dimensions (max 12/12). Gate: ≥6/12 to proceed.

| Dimension | 0 | 1 | 2 | |---|---|---|---| | Author expertise | Anonymous / no track record | Some relevant experience | Known practitioner, built production systems | | Publication venue | Random blog, no editorial standards | Personal blog of known engineer | Eng blog (Stripe, Netflix, Google) or curated publication | | Evidence type | Pure opinion / theory | Anecdotal experience | Production data, metrics, case studies | | Reproducibility | Claims untestable | Partially testable | Concrete steps, code, or configs provided | | Recency | >3 years, tech has changed | 1–3 years, mostly current | <1 year, current tech | | Cross-reference | No corroboration found | Partially supported | Multiple credible sources agree |

Quick checks (fail any = stop):

• No identifiable author AND no credible publication → REJECT
• Primarily promotional or affiliate-driven → REJECT
• Core claims contradicted by a higher-credibility source → REJECT

If 6–7/12: warn "Borderline." Actively search for the author's credentials and whether other credible sources corroborate the claims before proceeding.

Step 3 — Security Scan

Run security pipeline per learn-from protocol. BLOCKED = stop.

Step 4 — Extract and Recommend

Classify production-backed findings using taxonomy from learn-from.

Key difference from papers: articles mix tested advice with opinions. Separate them. Tag each insight with confidence:

• HIGH — production data cited
• MEDIUM — author's direct experience, no metrics
• LOW — plausible but no evidence shown (extract only if ≥2 other insights corroborate)

For every insight, state your recommendation with confidence and context:

• Flag scale mismatches: "Validated at [company]'s scale (N million users). Current project likely doesn't face this. Recommend: SKIP unless [condition]."
• If current skill is stronger: "Current approach is superior because [reason]. Recommend: KEEP CURRENT."
• If only part applies: "Recommend: PARTIAL — apply [X], skip [Y] because [reason]."

Step 5 — Match and Apply

Match insights to existing skills and apply per learn-from shared application protocol.

Step 6 — Log and Cite

Citation format:

Source: [Author] ([Year]). "[Title]". [Publication/URL]. Credibility: [N]/12.
Applied: [what was extracted and where it was applied]

---

Gotchas

• Eng blogs from top companies are high-signal but may describe solutions for scale the user doesn't have — flag scale mismatch explicitly.
• Medium/dev.to articles vary wildly — credibility check is critical.
• "Best practices" articles often present opinions as facts — look for production evidence.
• Articles may be outdated — check publish date and whether the tech has changed.
• Listicles and "top N" articles are almost always BACKGROUND — rarely contain novel GOTCHAs.

---

Output Format

═══ Article Credibility Report ═══
Title: [title] | Author: [name] | Venue: [publication] | Date: [date]
Credibility: [N]/12 | Verdict: [PASS/BORDERLINE/REJECT]

═══ Security ═══
[secure-* verdicts]

═══ Extracted Insights ═══
[Tag]: [insight] [confidence] | Agent recommendation: [APPLY/PARTIAL/SKIP/KEEP CURRENT] — [reasoning]
Discarded: [N] opinion, [N] background

═══ Application Plan ═══
[Per learn-from shared protocol]

---

Example

<examples> <example> <input>Learn from this article: https://stripe.com/blog/rate-limiters</input> <output> ═══ Article Credibility Report ═══ Title: Scaling rate limiters at Stripe | Credibility: 10/12 | Verdict: PASS

═══ Extracted Insights ═══ GOTCHA: Token bucket alone fails under bursty microservice traffic [HIGH] | Recommend: SKIP — no current skill covers rate limiting, but valuable learning TECHNIQUE: Layered rate limiting — per-user + per-service + global [HIGH] | Recommend: SKIP — scale mismatch for most projects FAILURE_MODE: Single shared counter = hot-key bottleneck at scale [HIGH] | Recommend: SKIP — same reason

═══ Application Plan ═══ Learnings only — no current skill covers rate limiting. Save to docs/research-learnings/ </output> </example> </examples>

---

Impact Report

After completing, always report:

Article: [title] | Credibility: [N]/12 | Security: [SAFE/BLOCKED]
Insights: [N] extracted | Confidence: [N] HIGH, [N] MEDIUM, [N] LOW
Recommendations: [N] APPLY, [N] PARTIAL, [N] SKIP, [N] KEEP CURRENT
Discarded: [N] opinion, [N] background
Skills modified: [list] | Created: [list] | Citation logged: [yes/no]