chrissgon
@chrissgon
Public Skills
eng-architecture
by chrissgon
Design how a feature will be built from an approved specification: components, the data or content model with its validation rules, contracts (routes, APIs, file formats, component interfaces, generated artifacts), flows with failure paths, build and deploy shape, ADRs with alternatives considered, and a verification plan mapping every acceptance criterion to a check, each element traced to a requirement. Use this skill after product-feature-spec and before product-backlog or implementation, when someone asks how to structure, design or architect a feature, or when a technical decision needs an ADR. Use it also to check an existing design against its specification ("run the traceability check", "does the design cover the spec", "fix what the check flags") or to revise an ADR. Not for describing existing code (eng-codebase-map) nor for comparing many options in depth (eng-tradeoffs).
eng-codebase-map
by chrissgon
Describe how an existing codebase is actually built: structure, stack, entry points, the components and their measured coupling, data and control flow along the main paths, integration points, security boundaries, and observations where code and documentation disagree. Use this skill when someone says "map this codebase", "map the repo", "how is this put together", "walk me through the architecture" or "I'm new here", when onboarding to a repository, before impact analysis, refactoring or a migration plan, when a project has no architecture document, or when an architecture document exists and must be compared with the code. It reads and reports only: it never changes code and never recommends.
brand-guidelines
by chrissgon
Consolidate a brand's profile, name, strategy, identity and voice into one guide that a person and an agent both follow before writing, designing or replying in the brand's name: who the brand is, the name and label, what it talks about, what may and may never be said, the sensitive-topics lock, how it sounds, how it looks, do and don't examples quoted from real material, and a pre-publish checklist of commands. It adds nothing new: every line points to the brand file it comes from, and a script flags quotes and colours that drifted from those files. Use this skill when someone asks for a brand guide, brand book or style guide, when an agent is about to act for the brand, or after any brand file changes. Not for deciding any of the brand's choices (the other brand skills do that).
biz-market-analysis
by chrissgon
Analyze the market for a business or an offer and write docs/business/market.md: who the buyers are and how many, what they use today and what it costs, who competes, what trends help or hurt, and a ranked comparison of the offers or segments on explicit criteria, every number sourced. Use this skill when someone asks for a market analysis, market size, competitors, "is there demand for", "which of my services should I sell first", or before ICP, positioning, pricing or go-to-market work, even if they do not say "market". It sizes the market to the business in front of it (a one-person service firm is not a venture startup), asks for scope before searching, and never fills a gap with a plausible number. Not for choosing the ideal customer (biz-icp-positioning) or validating a raw idea (biz-validate-idea, planned).
biz-icp-positioning
by chrissgon
Choose the ideal customer profile and the positioning for one offer: compare candidate segments on sourced evidence (pain, reachable base, ability to pay, incumbents, reach, regulation), write docs/business/icp.md with a primary profile, a secondary one, who not to sell to and a plan to validate it in customer conversations, and docs/business/positioning.md with the alternatives buyers use today and only the differentiators the business can truly claim. Use this skill when someone asks who to sell to, for an ICP, a target customer, a niche, personas for an offer, "how do we stand out", or before pricing, go-to-market, messaging or a landing page, even if they do not say "ICP". It asks for the segments and the claims it cannot know, and treats the profile as a hypothesis until customers confirm it. Not for sizing the market (biz-market-analysis) or writing copy (mkt-messaging).
brand-voice
by chrissgon
Write the voice guide a person or brand writes and replies in, derived from texts they wrote themselves: the habits to keep with evidence from each sample, the habits to drop, the register, a post structure, rules for replies to comments, checkable limits (emojis, hashtags, exclamations, closing question, banned phrases) that drafts are linted against, and rewrites of real samples that the person calibrates. Use this skill when someone wants posts or replies to sound like them, asks for a tone of voice or style guide, says their old posts "are not them anymore", or before any agent writes in their name, even if they never say "voice". Not for choosing what to post about (brand-strategy) or writing a specific post (mkt-social-copy).
brand-strategy
by chrissgon
Decide how a person or a company shows up in public: the goal with measured starting points, the audiences, a positioning statement that claims only what is proven, the label or headline, three or so content pillars tied to the goal, what may and may not be claimed, and proposed changes to public profiles. For a person it reads the brand profile; for a company, the ICP and positioning. Use this skill when someone asks what to post about, how to position themselves, what their headline should say, which topics to own, or how to turn a profile into a content plan, even if they never say "strategy". Not for gathering the person's facts (brand-profile), the voice guide (brand-voice) or the calendar and posts (mkt-content-plan, mkt-social-copy).
brand-profile
by chrissgon
Build the profile a personal brand stands on: who the person is and since when, the proof they may cite, the goal of the brand, the audiences, the themes they want to own set against the proof they have, what is never exposed, and samples of their own writing. It reads what exists first (the export of their social profile, the code-host profile, posts the user links), removes contact data, lists where sources disagree, and asks only what no source answers. Use this skill when someone wants to build or grow a personal brand, be known for a topic, get an audience for their products, write as themselves on social networks, or set up an agent that posts or replies in their name, even if they never say "profile". Not for a company's brand (the business skills and brand-strategy) or for writing posts (mkt-social-copy).
brand-identity
by chrissgon
Define the visual identity of a person or a brand and prove it on a first real piece: colours with WCAG contrast computed per use, typefaces with their licences checked, the recurring elements, the formats with their safe areas, and machine-readable tokens, all derived from an existing design system when the brand has one. Produces the pieces as HTML rendered to exact-size images, in variants the person chooses from. Use this skill when someone needs a cover or banner, a visual style for posts, colours or fonts for their brand, a look for their site, or asks what their brand should look like, even if they never say "identity". Not for the voice (brand-voice), a full design system for a product (design-system) or the layout of an application (design-brief).
brand-name
by chrissgon
Research a name or handle for a person or a brand, or audit one already in use: where it exists (domains through RDAP, code hosts, package registries, video and social networks), who else uses it, how it reads in each language the brand posts in, and whether it is the same everywhere. Checks are made by a script and dated; ownership and preferences are asked. Use this skill when someone needs a name, a username or @, wants to know if a name is free, is about to buy a domain, or wants their handle consistent across networks, even if they never say "naming". Not for writing a tagline or positioning (brand-strategy) or the visual logo (brand-identity).
eng-docs
by chrissgon
Bring the documentation in line with a code change: find every document whose sentences the change makes false, incomplete or newly true, verify each claim you write by running it, edit the documents in the project's conventions, leave generated documents to their generators, and list what other repositories must change. Use this skill after a change is implemented and before it is reviewed or released, or when someone asks "refresh the docs", "update the docs for this" or "does the documentation still hold", even if they only mention the code. Also use it when a guide makes a promise the code does not keep. Also use it when someone asks to document a feature that is not built yet, to say the documentation follows the implementation.
core-orchestrator
by chrissgon
Route a request to the one skill or flow that should handle it, across business, product, brand, design, engineering, delivery, marketing, AI and the workbench itself. Use this skill first for any request to build, implement, fix, design, plan, write, publish, schedule or send something, including one that names an external system (a ticket, a post): before checking whether a tool for that system exists, and even when no other skill is installed. Use it too when a request spans more than one area, continues a previous multi-phase effort, or when it is unclear whether a skill applies at all, and when the user asks "where are we", "what's next" or "what can you do here". Do not use it for a one-step request that needs no specialized knowledge and has no side effects; answer that directly.
design-execute
by chrissgon
Run a design brief in the AI design tool the user chooses (a design tool with an integration, a design-system or generative tool, an image generator, or a prototype in code), collect what it returns, critique it against the brief's criteria and record the chosen direction. It runs automatically when the agent can drive the tool and in assisted mode otherwise: it prepares the exact prompt and attachments per direction, the user runs them and brings the results back. When the request has no brief or a thin one ("make the landing in" a named design tool), it asks for design-brief first. Use this skill when someone asks to generate, create, render or produce a screen, mockup, logo, presentation, animation or image, to run or execute a brief, or to review what a design tool produced. Not for writing the brief itself (design-brief) or implementing the chosen design in the product (design-handoff, eng-implement).
core-skill-creator
by chrissgon
Create a new skill for this workbench or improve an existing one, and prove it works: ground the content in real expertise, scaffold from the templates, write it for the weakest model without capping strong ones, validate the conventions, write realistic evals, run them with and without the skill on a strong and a floor model, review its security, grade, analyze, iterate. Use this skill when the user asks to add, rewrite, fix or evaluate a skill, when the orchestrator recorded a skill gap, or when a skill failed on a real task. It refuses to write a skill from generic knowledge when no real task or expertise exists, and says what is needed first.
design-brief
by chrissgon
Write the design brief an AI design tool needs to produce a strong visual artifact: a screen or page, a mockup, a logo, a presentation, an animation or a still image such as a social card. The brief carries the subject, audience and voice, the copy verbatim from its source, the design system (values written out, or referenced when the tool already loaded it), named creative directions, the content the artifact must hold, constraints, deliverables per round, evaluation criteria and a ready-to-paste prompt. Use this skill when someone asks to design, mock up, draw or generate any visual artifact, to brief a design tool, or when a request to a design tool is too thin to produce good work, even if the word "brief" is never said. design-execute then runs the brief in a tool. Not for tokens and components (design-system), flows and screen inventory (design-ux-flows) or copy (mkt-messaging).
design-ux-flows
by chrissgon
Define the information architecture, the screen inventory and the user flows of a product from its PRD and feature specs, before any screen is drawn: which pages exist and how they nest, which screens the design must produce with their regions and states, and how each user group moves through them step by step, including failure branches and the keyboard path. Use this skill at the start of the design phase, when someone asks for user flows, a site map, navigation structure, wireframe notes, "how does the user get from A to B", or which screens are needed; also when a new feature changes navigation. Use it too when flows are asked for and no PRD exists, to say what must come first instead of drawing an invented flow. Every node, screen and flow traces to a PRD feature, a spec requirement or the user's words; nothing is drawn from taste. Not for visual decisions (design-system, design-brief) or for requirements (product-feature-spec).
core-research
by chrissgon
Research a question and return a sourced brief: every claim cited with URL, publisher, publication date and access date; key claims backed by two independent sources; facts separated from estimates and opinions; contradictions and unknowns listed. Use this skill whenever a decision needs facts from outside the repository: market size, competitors, prices, adoption, regulations, library comparisons, best practices, or "is this true?". Also use it when another skill needs evidence it does not have. Without a web search capability it still produces a limited brief and says so; it never invents a source.
core-agents-md
by chrissgon
Create, update or audit a project's AGENTS.md so that any AI tool works from the same, verified conventions: what the project is, where its architecture is documented, the exact build, test, lint and release commands, code style, testing, security and commit rules, and the working rules the maintainer wants followed. Use this skill when the user asks for an AGENTS.md, when a project was initialized for the workbench but has no conventions yet, when a tool-specific instruction file should become tool-neutral, or after build or test tooling changed. Every command is checked against the repository; nothing is written from memory.
core-clarify
by chrissgon
Interview the user about a plan, idea, design or request until there is a shared, written understanding: goal, scope, constraints, decisions and what stays open. Use this skill when the user asks to be grilled, to stress-test a plan, to clarify requirements, or says "ask me anything you need"; when the orchestrator finds a request ambiguous; and as the first phase of any flow that starts from a loose description. Every question comes with a recommended answer; anything the codebase or existing artifacts can answer is never asked.
core-project-init
by chrissgon
Set up a project so the workbench can operate it: create docs/workbench/state.md with the autonomy mode the user chooses, register documents the project already has as artifacts in place, and add the workbench section to the project's AGENTS.md without touching anything else. Use this skill when a flow needs project state and none exists, when the user asks to set up, initialize or onboard a project for the workbench, or when the orchestrator reports a missing state file. Also use it later to change the autonomy mode or to register more existing documents.
design-handoff
by chrissgon
Turn an approved design into the implementation spec engineering builds from: unpack what the design tool exported (a single-file HTML bundle, code, or a design file), separate the reference from what must not ship (the tool's runtime, inlined copies of libraries, font CDNs), map every value to a design-system token or flag it, and specify per screen the components with their content source, the layout per breakpoint, every state, the motion with timings and reduced-motion behaviour, the assets, the deviations from the brief and the specs, and the acceptance screenshots. Use this skill after design-execute records an approved direction, when someone says the design is ready, asks for specs, a hand-off, or how to build a screen from a mockup or an export. Not for choosing a design (design-execute), for the system's tokens (design-system) or for the code architecture (eng-architecture), which reads this spec.
design-system
by chrissgon
Define the visual foundations a product's screens are built from and, when a design-tool integration is available, build them in the design tool: colour tokens with light and dark values, type scale, spacing, radii, borders, elevation, layout grid and reading width, the component inventory with variants and states, and the rules for using them, every value traced to an existing component library, a brand artifact or a user answer. Use this skill after design-ux-flows and before design-brief, when someone asks for tokens, a style guide, a design system, variables in the design tool, light and dark modes, or which components exist; also when a library ships its own token specification that must be mirrored. It never invents a palette or a font: what no source gives is a question with a recommended answer. Not for screens and other visual artifacts (design-brief) or for brand strategy (brand-identity).
eng-code-review
by chrissgon
Review a code change before it merges (working tree, commit range, branch, pull request or patch file) against the task it implements, the design contracts and the project's conventions, from six perspectives: scope and contracts, quality, edge cases, regression and performance, security and data, tests; plus a bug-fix checklist when the change fixes a bug. It measures the diff with a script, re-runs the project's checks instead of trusting the implementation report, reads the changed code and its consumers, and returns findings that each have a location, quoted evidence, a severity and a fix, closed by a verdict: approve, approve with changes or request changes. Use this skill when the user asks to review code, a diff, a PR, a commit or a fix, asks "is this ready to merge" or "LGTM?", or when a flow reaches the review step after eng-implement, even for a change called trivial. Not for plans or documents (core-critique), finding a bug's cause (eng-root-cause) or fixing findings (eng-implement).
core-critique
by chrissgon
Adversarially review a plan, proposal, artifact or proposed solution before anyone acts on it: find the concrete ways it fails, each with a trigger, an impact and a test or mitigation, and give a verdict with conditions. Use this skill when the user asks for a critique, a stress test, a devil's advocate, "what could go wrong", or a second opinion on a business model, a PRD, a design, a launch plan, an AI feature or a bug-fix approach; and as the review step of flows before implementation or publication. Not for reviewing code diffs (that is eng-code-review) or for resolving open decisions (that is core-clarify).