// verdict #18 · 17 Sep 2026 · 21:47 UTC

github.com/mattpocock/skills

HOLD

the voices disagreed — or rivera asked for redesign before adoption. held for more information, or wider reach.

submitted by Rob Berkeley · BLKOUT · model anthropic/claude-sonnet-4 · against wishlist of 2026-08-06T19:25:52z · visit the tool → · back to history

// the four voices, in parallel

What the Council said

// 01 · critic

Baldwin

hold

technical risk, lock-in, sequencing — the master's tools.

This is a collection of AI agent skills/prompts for software development, not a tool that would be deployed on BLKOUT's infrastructure. Let me evaluate it against the context. **What this actually is**: A set of prompt templates and workflows for AI coding agents (Claude, Codex, etc.) designed to improve software development processes. The skills include things like `/grill-me` for requirements gathering, `/grill-with-docs` for creating shared vocabulary, and various development workflow improvements. **Guardrail compliance**: Clean. This doesn't touch infrastructure, schemas, or any of the technical constraints. It's methodology, not deployment. **Wishlist mapping**: This could potentially support **Tech stability and system resilience** (Tier 1) by improving code review processes and development workflows. The emphasis on "small, deliberate steps" and feedback loops aligns with the documented need for "routine code and security review — a rhythm, not an event." **Critical concerns**: 1. **Sequencing problem**: The wishlist explicitly states "Infrastructure before application" and "Debug infrastructure... before application code." BLKOUT's current challenge isn't development methodology — it's having twenty-four deployed applications that nobody can hold in their head, half of which might be dead weight. 2. **Capacity mismatch**: These skills are designed for "real engineering" and active development. But BLKOUT's Tier 1 priority is rationalisation and resilience of existing systems, not building new ones. The team needs to understand what they have before optimising how they build. 3. **Operational overhead**: While the skills themselves are just prompts, adopting structured development workflows adds process overhead. For a small team already struggling with estate management, this could be premature optimisation. 4. **Missing the actual problem**: The documented failures (tools offline for months, admin areas with no auth, passwords compiled into published code) weren't methodology failures — they were visibility and review failures on existing systems. **Verdict**: This is well-designed methodology for active development, but BLKOUT is in a consolidation and stabilisation phase. The right development practices matter, but not until there's a rationalised estate to apply them to. The foundation needs fixing before the building process gets optimised. RECOMMENDATION: HOLD

// 02 · ethicist

Murray

hold

values, sovereignty, community benefit.

This is a collection of AI agent skills/prompts for software development, created by Matt Pocock. The tool provides structured prompts and workflows to help AI coding assistants work more effectively - things like `/grill-me` for requirements gathering, `/triage` for issue management, and various development workflow skills. **Values Assessment:** **DATA SOVEREIGNTY & ANTI-SURVEILLANCE**: This tool operates entirely within your existing development environment. Skills are either read-only plugins or files you own and edit locally. No data leaves your system to Matt Pocock's servers - the skills just improve how you interact with AI agents you're already using. This aligns well with data sovereignty principles. **COMMUNITY BENEFIT**: The skills are open source and designed to be adapted. The "tinkerers" installation path specifically encourages forking and modification. However, this is primarily a productivity tool for individual developers rather than something that directly serves community needs. **TRANSPARENCY & CO-PRODUCTION**: The skills are fully transparent - you can read exactly what each one does. The editable installation path supports customisation to your context. **Wishlist Mapping:** This doesn't directly map to any specific wishlist item. It's a developer productivity tool, not infrastructure, member experience, or co-production capability. The closest connection might be to **"Tech stability and system resilience"** - if these skills help BLKOUT's developers write better code more efficiently, that could contribute to overall system quality. **Guardrails Check:** No guardrails violations. This doesn't touch the CRM schema, doesn't require n8n, doesn't affect the pre-order model, and doesn't need Stripe integration. It's purely a development workflow enhancement. **Assessment:** This is a well-designed, values-aligned tool that could improve development quality and efficiency. However, it doesn't address any priority need from the wishlist. Given BLKOUT's current focus on foundational infrastructure and the fifteen specific capabilities they're trying to build, developer productivity tooling feels like a nice-to-have rather than a strategic necessity. The tool itself is solid, but the timing doesn't match BLKOUT's priorities. They need to build specific capabilities (CRM member pages, AI policy, system resilience) more than they need to optimise how they build things. RECOMMENDATION: HOLD

// 03 · builder

Rustin

vibe-codeability, stack fit, lift — what'll actually ship.

Looking at Matt Pocock's skills repository, this is a collection of AI agent "skills" (structured prompts/workflows) designed to improve coding productivity with AI assistants like Claude and Cursor. Let me evaluate this against BLKOUT's context. ## VIBE-CODEABILITY **Strong**. These are well-documented, modular prompt templates that integrate with existing coding workflows. The DX is excellent — 30-second setup, clear documentation, and the skills are designed to be hackable. Matt Pocock has a solid reputation in the TypeScript/developer tooling space. ## STACK COMPATIBILITY **Perfect fit**. This isn't infrastructure — it's workflow tooling that sits on top of whatever stack you're already using. No containers, no services, no VPS requirements. Just better prompts for AI-assisted development. ## SPEED OF DEPLOYMENT **Immediate**. Literally `npx skills@latest add mattpocock/skills` and you're running. The setup skill asks a few configuration questions and you're operational. ## LIFT ASSESSMENT **Accessible**. This is a learning and workflow investment, not a development project. The "lift" is adopting better practices with AI coding assistants, which BLKOUT is already using. ## MAINTAINABILITY **Self-maintaining**. These are prompt templates that live in your repo. No services to monitor, no dependencies to update. The failure mode is "prompts stop being useful" which is easily recoverable. ## INTEGRATION POTENTIAL **Workflow-level**. This doesn't integrate with CRM or member pages — it integrates with how Rob and the team write code for those systems. The `/grill-with-docs` skill for building shared language could be particularly valuable for a small team building multiple interconnected systems. ## GUARDRAIL CHECK **Clean**. No guardrail violations. This doesn't touch the CRM schema, doesn't add operational complexity, doesn't duplicate existing functionality. It's pure workflow enhancement. ## WISHLIST MAPPING This maps most directly to **"Tech stability and system resilience"** — specifically the "routine code and security review" component. The skills include patterns for better testing, documentation, and systematic approaches to code quality. The `/grill-with-docs` skill could help with the "knowing what is live, what is dead" problem by establishing better documentation practices. It also supports the general infrastructure goal of building more systematically rather than reactively. ## REAL-WORLD FIT For a small team juggling 24 deployed applications who've had multiple silent failures (rotated keys, missed migrations, no-login admin areas), better AI-assisted development practices could prevent future technical debt. The cost is near-zero and the potential upside is significant. The skills are particularly relevant because BLKOUT is already using AI for development work — this just makes that work more systematic and effective. RECOMMENDATION: GO

// 04 · inclusion

Rivera

pass

reach, the under-served, who's on the street.

Looking at Matt Pocock's skills repository, I need to interrogate this through the lens of who gets left out when BLKOUT adopts developer tooling. **ACCESSIBILITY FLOOR VIOLATIONS** This tool assumes: - Command line literacy (`npx skills@latest add`) - GitHub/development environment access - English fluency with technical jargon ("materialization cascade", "red-green-refactor loop") - Paid Claude Code or Codex subscriptions - Stable internet for plugin installations A community organizer in Birmingham who needs to update BLKOUT's website but learned HTML through YouTube tutorials? Locked out completely. The tool speaks exclusively to people who are already developers or have developer budgets. **PERFORMANCE DEMANDS** The entire framework assumes you can articulate technical requirements clearly enough for an AI to "grill" you about them. Quote from the page: "getting the agent to ask you detailed questions about what you're building." Who does this exclude? Anyone who: - Knows they need something but can't describe it in developer terms - Is building their first community website - Speaks community needs, not technical specifications - Needs to collaborate with non-technical community members **REGISTER AND LANGUAGE** The shared language concept is telling. It creates efficiency for people who already speak code, but builds higher walls for everyone else. "Variables, functions and files are named consistently" - great if you know what variables are, exclusionary if you don't. **COST TO USER** Beyond the obvious subscription costs, this has hidden expenses: - Time investment to learn the system - Mental overhead of maintaining "shared language" documentation - Dependency on commercial AI services that could price out small orgs **WHO THIS SERVES VS. WHO IT ABANDONS** This serves: Experienced developers who want to work faster with AI coding assistants. This abandons: Community members who need to build digital tools but aren't professional developers. The exact people BLKOUT should be empowering to create their own digital infrastructure. **MAPPING TO BLKOUT'S WISHLIST** Looking at the wishlist, BLKOUT needs "Tech stability and system resilience" but this tool adds complexity rather than stability. It introduces new dependencies (Claude Code, Codex, skills.sh) when the guardrails explicitly call for reducing and understanding the estate first. The wishlist emphasizes "member-controlled data as feature" and "values-embedded member system" - this tool is about making developers more efficient, not about putting community members in control of their own technology. **THE SYLVIA RIVERA TEST** Would Sylvia Rivera approve of a tool that makes the people who already have technical skills more productive, while creating no pathway for the people on the street to build their own solutions? Absolutely not. This is a tool that deepens the divide between who can build technology and who must depend on others to build it for them. It's optimization for the over-served. RECOMMENDATION: PASS

// context at time of judgement

The Wishlist, as it was then +

this is the document the council was asked to hold this tool against. click to expand.

BLKOUT Digital Strategy — Living Document

This document is the authoritative context for the Dreamcatcher Council. It combines BLKOUT's Year One guardrails with the fifteen-item wish list. The Council reads this fresh on every evaluation — edits here immediately reshape every future verdict.

Last revised April 2026. For board and community input.

Year One Guardrails

Rules that hold while foundational infrastructure is being built. Harder than tier priorities — these do not negotiate.

— No n8n. All automations use node-cron or Supabase triggers. n8n was tried and removed; the operational cost of a workflow engine outweighed the benefit for a small team.

— Schema ownership. The CRM's 001_crm_complete_schema.sql is authoritative. Any new tool that touches member data reads from CRM tables — it does not maintain a separate schema.

— Pre-order model, not always-on store. The BLKOUT shop is a waiting-list / pre-order surface with CBS tiers (free / £3 per month / £10 per month). Tools that assume always-on e-commerce are a category mismatch.

— Stripe pre-flight. Stripe routes stay disabled until credentials are confirmed in Coolify. Test mode only — no tool that requires live payment provisioning on adoption.

— CRM mock data stays until migrations verified. Nothing removes CRM mock data until the equivalent migration has been confirmed via supabase-query.mjs. Tools that auto-migrate are held until verification is possible.

— RSVP and Stripe are already built. Frontend and backend exist in the platform. Tools that duplicate these are a category mismatch — the gap is credentials and tables, not code.

— Infrastructure before application. Debug infrastructure (CPU, disk, running services, Docker images) before application code. Tools that add operational complexity must justify themselves against this order.

Wish List — fifteen capabilities

Prioritised by potential impact and capacity to instigate change. First draft March 2026, living document since.

Tiers: do now (accessible) — plan and build (moderate lift) — develop with intent (significant undertaking)

Categories: infrastructure — member experience — co-production

Tier 1 — do now

High impact, low barrier — no dependency blockers.

— AI policy, à la New Public infrastructure accessible Unlocks the integrity of everything beneath it. Determines what BLKOUT will and won't do with AI, and why. Data sovereignty and privacy follow from this document, not the other way around. Mainly a thinking and writing exercise — the hardest part is the thinking.

— CRM — values-embedded member system member experience accessible Already in active use. Develop with transparency and member control principles baked in before habits calcify around the wrong defaults. Needs connecting to member pages, AIvor, and the directory as those mature.

— Leania.ai — AI ops audit infrastructure accessible Quick diagnostic of workflows, tools and bottlenecks. Keep / kill / replace / automate recommendations. Low cost, high information value. Caveat: recommendations will skew commercial — use the diagnostic layer, not the prescription.

— Tech stability and system resilience infrastructure moderate lift Without this, everything built on the infrastructure will fail. The VPS, Coolify, and all modules need to be reliable and recoverable before more is added. Foundational before ambitious.

This item is deliberately broader than uptime, and the breadth has been lost in translation before. It explicitly covers four things.

Rationalisation of the estate. Twenty-four deployed applications and a longer list of repositories. Knowing what is live, what is dead, what duplicates what, and retiring the remainder. An estate nobody can hold in their head is one nobody can secure.

Routine code and security review — a rhythm, not an event. The recurring failure mode is silent: things stop working, or stop being safe, without erroring. In 2026 alone — a tool offline for a month on a rotated key; four applications missed in a key migration, each surfacing only when something visibly broke; an administrative area running with no login at all; a second application protecting its admin with a password compiled into its published code. None of these announced themselves. Review is what finds the thing that is not complaining.

Separation of front of house and back of house. Public pages and administrative tooling currently share one application, one bundle, one key and one pair of hostnames — so every anonymous visitor is served the whole admin interface, and data access depends on a publishable key rather than a server. Back of house should share none of those things with front of house. See the data exposure of 6 August 2026, which followed directly from their being one thing.

Recoverability. Backups that have been restored from, not merely taken. Logs retained long enough to investigate an incident rather than 24 hours. A documented way back from each failure we have actually had.

What we will not do: buy a monitoring product to sit on top of an estate we have not yet rationalised. Reduce and understand first; instrument second.

Tier 2 — plan and build

High impact, requires resourcing, people or sequencing.

— Bookkeeping, financial regulations and fundraising infrastructure moderate lift CBS obligation, funder pipeline active. Needs the right person as much as the right tool — the Treasurer role is load-bearing. Required before significant grant income flows through the organisation.

— Compliance infrastructure — demonstration not monitoring infrastructure moderate lift Mission risk if left too long. Evidence of governance, financial stewardship, and community benefit must be buildable in real time, not reconstructed after challenge. Systems need building before they are needed.

— Regular events calendar and Brunch 2030 member experience moderate lift Visible, reliable rhythm signals organisational health. Monthly social, film screening at The Arzner, community organisers gathering, seasonal specials, Berto Pasuka day. Key venue relationships held — Stanley Arts, The Arzner. Delegate the programming.

— Non-intrusive lead generation member experience moderate lift Community-appropriate discovery. Transparent about the win on all sides. Values-consistent methodology — games welcome if honest, surveillance mechanics excluded. The question is whether the constraint is capacity, visibility, or trust, because each has a different solution.

— Live directory of Black queer civil society co-production moderate lift Co-production and community research — built by the community, kept live by the community. Feeds CRM, AIvor, lead generation, and network mapping simultaneously. The gaps in the directory are as revealing as what is in it.

— Partner tool and project management dashboard infrastructure moderate lift Operational capacity for transparent relationships with organisations of all sizes. Sits on stable infrastructure. Enables partnerships to be held without depending on founder memory.

— Network mapping — loneliness co-production moderate lift How loneliness manifests for Black queer men — which responses are proximate, which require greater effort. Research question still needs articulating before design. Board community lead to own this. Brunch network exercise as potential methodology.

Tier 3 — develop with intent

Transformative — significant undertaking, dependencies to resolve first.

— Unique member pages — member-controlled data as feature member experience significant Members see exactly what BLKOUT holds about them, can edit or delete any of it, and are equipped to ask the same of others. Policy as education. Significant data architecture. Needs CRM foundation first. The feature that most visibly demonstrates the values.

— Next-level AIvor — orchestration on member need member experience significant From broadcaster to responder — receiving member need signals and acting on them, with care and ethical guardrails. The line between care and surveillance must be designed in from the start. Depends on knowing what members actually need. Network mapping and directory must precede.

— Co-designed member consultation with iterative learning loop co-production significant Design the consultation process in consultation. Radical transparency, shared results, member agency in decisions that follow insight. Includes autoresearch-style closed feedback cycle with co-designed metrics. Never a failure, always a lesson — at organisational scale. The most ambitious item on the list and the one that could make every other item more effective.

— Youth leadership intervention co-production significant Form and content both need co-producing — this cannot be designed for young people, only with them. Requires funding. Can begin relationship-building and scoping conversations now, against the backdrop of Black youth unemployment returning to 1981 levels.

— Enterprise and wealth — pop-up / shebeen / art model co-production significant Still forming. The relationship between enterprise, workplaces, community and intergenerational wealth remains to be discovered. An inquiry that in its form embodies potential elements of the final proposal — collaborative, cultural, accessible, profitable, sociable. Trust for London proposal as the discovery vehicle.

BLKOUT Creative Ltd — Community Benefit Society Living document — edited in situ via the Dreamcatcher editor

---Podcast hosting — added April 2026, surfaced via Commons page build

What we want: A hosted podcast platform with a brand-themeable embeddable player (we'll skin to obsidian/gold), an RSS feed for distribution to Spotify/Apple Podcasts, and basic listener analytics. Should integrate with the Commons + Critical Frequency pages without a generic Drive iframe.

Why now: We're starting to publish AI-generated audio (NotebookLM Deep Dives, future episodes from the Compass material). Drive embed is the current workaround — generic player, no podcast-app distribution, no analytics, asset lives in personal Drive.

Constraints / what we won't: Free tier or low monthly cost (BLKOUT is small); no extractive licensing on community audio; option to self-host or export RSS to migrate (no lock-in); accessible player UI; no Spotify exclusivity.

On the radar for Council review when surfaced: Castopod (open source, self-hostable on Coolify — natural fit), Transistor (paid, neutral, RSS-first), Buzzsprout, Spotify for Podcasters / Anchor (free + reach but sovereignty concerns).

CONSOLIDATE MISSION CONTROL INTO THE COMMS ADMIN HUB (added 6 Aug 2026)

The need: two dashboards do overlapping work. Mission Control is file-based (commitments.json, finance.json, tasks-inbox.md), generated to static HTML and served on 127.0.0.1:8765 — it exists on one laptop and is invisible from a phone. The comms-blkout admin hub is deployed, Supabase-backed and, since 6 Aug, actually authenticated. The daily surface holding Rob's commitments is the one he cannot reach when he is out, which is most of the time.

Why now: the hub had no login until 6 Aug, so putting commitments or finances in it would have published them. Mission Control existed partly because the hub was not safe to hold anything real. That constraint is gone.

What actually moves: three things — the commitments list, the tasks inbox, and the bank-CSV upload flow. They would sit as an /admin/today page. Everything else already exists in the hub.

Constraints / what we won't: keep generate.mjs as a local fallback — Mission Control is the only surface on the estate that works when Supabase, Coolify or an API key is broken, and 2026 has proved that matters (Dreamcatcher down a month on a dead key; four surfaces broken by the July key migration). Do not rebuild the three pieces, move them. No new dependency, no monthly cost.

Open question for the Council: does reachable-from-anywhere beat resilient-when-offline for something checked daily — or is the right answer to deploy Mission Control behind the same auth instead of merging?