Skill Concept Brief — Terminology
Locked Terms
| Term | Means | NOT |
|---|---|---|
| Concept brief | A validated direction doc that sources IP, checks constraints, and feeds the Skill Build Kit | A project plan, a PRD, a feature spec |
| IP direction | Kathryn's concepts — titles, framings, angles she provides for what the skill should do | Existing angle files or campaign tools (those are reference) |
| Design constraints | Can't fail, sustainable, win fast — the three gates every skill must pass | Nice-to-haves or aspirational goals |
| Quality bar | "Feel fortunate they got it free, slightly guilty they didn't pay" | "Good enough" or "functional" |
| Signal type | A category of pattern the skill detects in the input | A feature or a section heading |
| Foundational dependency | A prerequisite skill (Service List, ICP, Voice) that makes this skill work better | A required input — the skill must work without foundations |
| Teaching story | Real results from Kathryn testing the skill on real data | Hypothetical examples or made-up numbers |
| Golden example | The actual brief that sets the standard — currently the Hidden Revenue Scan brief | A template or a blank form |
Brief Voice
The concept brief is an internal working document. It's not customer-facing. Write it to be:
- Scannable — tables over paragraphs. One idea per row.
- Decisive — "This is what we're building" not "We could consider building"
- Traceable — every design decision maps back to an IP concept or a constraint
- Honest about gaps — "TBD — needs testing" is better than faking it
What a Brief Is NOT
- Not a skill file. The brief validates direction. The Skill Build Kit produces the file.
- Not a project plan. No timelines, no task lists, no assignments.
- Not a pitch. No selling the idea internally. State the problem, source the IP, check the constraints.