Shape partner-facing and institutional surfaces so they read as credible operating systems rather than generic SaaS templates. Use for corporate landings, capability pages, partner sections, investor-facing surfaces, and other public pages that must feel clear, evidence-backed, and commercially serious.
Scanned 9/5/2026
Install to Claude Code
npx -y skills add markoblogo/abvx-agent-skills --skill corporate-surface --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Corporate Surface?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/markoblogo-corporate-surface)More formats (shields.io, HTML) on the badges page.
---
name: corporate-surface
description: Shape partner-facing and institutional surfaces so they read as credible operating systems rather than generic SaaS templates. Use for corporate landings, capability pages, partner sections, investor-facing surfaces, and other public pages that must feel clear, evidence-backed, and commercially serious.
license: MIT
metadata:
abvx_status: experimental
abvx_origin: adapted
abvx_eval_tier: structural_only
---
# Corporate Surface
Make the page feel credible before trying to make it impressive.
Use this when a public business surface risks sliding into generic dark SaaS, empty architecture diagrams, abstract platform jargon, or decorative product cards without proof.
## Best Fit
- corporate landings;
- institutional/product capability pages;
- partner-facing and investor-facing sections;
- ecosystem and product-overview pages;
- contact/CTA flows where seriousness matters more than novelty.
## Core Rule
Lead with real operating proof.
If the project has real interfaces, systems, publications, methods, or public outputs, they should carry more weight than abstract feature boxes.
## Workflow
1. State the business job:
- what a serious partner should understand, trust, and do after the first screen.
2. Identify proof surfaces:
- real product interfaces;
- real outputs or methods;
- real links to operating systems or publications;
- concrete capability labels.
3. Check for generic-template failure modes:
- too many equal cards;
- pseudo-metrics with no business meaning;
- heavy jargon before outcomes are clear;
- architecture talk replacing real products;
- CTAs that look active but do not support the commercial path.
4. Rebalance toward:
- clearer outcome language;
- fewer but stronger structural blocks;
- bigger visual weight for real product proof;
- tighter headline/subhead rhythm;
- explicit partner pathways.
5. Keep the page institutional:
- restrained motion;
- deliberate spacing;
- strong alignment;
- no novelty-for-novelty styling.
6. Verify desktop and mobile credibility:
- hierarchy still reads;
- proof assets remain visible;
- CTA path stays obvious.
## Output Shape
Return:
- `business job`
- `proof surfaces`
- `generic-template risks removed`
- `rebalanced hierarchy`
- `desktop/mobile credibility checks`
## Guardrails
- Do not invent new capabilities or clients.
- Do not replace approved corporate direction with startup trend styling.
- Do not let architecture diagrams outrank real products unless the page is explicitly methodology-first.
- Do not hide the contact or partner path behind decorative sections.
- Do not treat “premium” as permission for empty space without proof.
## Final Report
Include:
- the primary business job;
- the proof surfaces promoted;
- the main template-risk correction;
- desktop/mobile credibility evidence;
- any remaining issue better handled by `wireframe-preflight`, `frontend-taste-layer`, or `anti-slop-review`.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!