|
WE3 builds products and companies with senior Product, Design, and Engineering teams. This repository is part of our open-source community offerings. Start your brief. |
This repository contains a small, reusable set of AI agent skills designed to support disciplined, low-ceremony software development.
These skills are not a framework, not a workflow, and not a ticketing system.
They are portable, team-level behaviours that help humans and AI assistants work together safely and effectively in real codebases.
They’ve been designed and exercised across:
- solo developers and distributed teams,
- greenfield projects and legacy systems,
- exploratory work and production changes.
- Lightweight AI Development Agent Skills
The canonical source of truth is the skills/ directory:
skills/
work-item-designer/
SKILL.md
implementation-executor/
SKILL.md
decision-lens/
SKILL.md
documentation-lens/
SKILL.md
safety-lens/
SKILL.md
Each directory maps one-to-one to the five roles below.
Tool-specific directories are mirrors created from this source; they are not edited directly.
AI assistants are fast, tireless, and increasingly capable — but without constraints they tend to:
- guess when requirements are unclear,
- expand scope opportunistically,
- introduce accidental architectural decisions,
- and create documentation sprawl.
This repo provides five narrowly scoped skills that address those failure modes without introducing process overhead.
Each skill behaves like a bounded professional role you invoke at the right moment:
- to clarify work,
- to execute safely,
- to notice decisions early,
- to keep documentation coherent,
- or to pause when something looks risky.
Humans remain in control at all times.
Turn vague requests into clear, executable work items with explicit:
- outcomes,
- constraints,
- acceptance checks,
- and non-goals.
Used during backlog intake, grooming, or whenever a request feels underspecified.
Execute exactly one well-formed work item:
- minimal changes,
- explicit verification,
- no scope creep,
- and a small, durable record that the work happened.
Used once the task is genuinely ready to build.
Surface when work starts to lock in long-term choices:
- API shapes,
- data schemas,
- coupling,
- irreversible patterns.
It flags decision-ness without enforcing documentation or blocking progress.
Prevent documentation drift by:
- encouraging a single source of truth,
- preferring links over duplication,
- keeping docs lightweight and intentional,
- and applying the principle: document to position the reader in the system, state only durable contracts, and include detail solely when its long-term value exceeds its maintenance cost.
It reviews; it does not rewrite or enforce structure.
See skills/documentation-lens/documentation-principles.md for full documentation guidance.
Detect ambiguity, risk, or large blast radius early:
- missing requirements,
- destructive operations,
- irreversible changes.
It pauses and asks for clarification instead of guessing.
Humans can explicitly accept risk and move on.
Think of the skills as specialist colleagues, not automation.
A common (but optional) flow looks like this:
-
Define the work
Use Work Item Designer to shape a vague request. -
Check for risk
Use Safety Lens if anything feels unclear or risky. -
Build
Use Implementation Executor to make the change. -
Sense-check decisions
Use Decision Lens if APIs, schemas, or architecture are touched. -
Handle docs
Use Documentation Lens to avoid duplication or misplaced explanation.
You don’t have to use every skill every time.
“No signal detected” is a perfectly good outcome.
Use plain requests in your assistant:
Use work-item-designer to shape this into one executable task.Run safety-lens on this plan and flag any risky assumptions.Use implementation-executor to implement this item exactly as written.Run decision-lens on this diff and flag potential architectural decisions.Use documentation-lens to check for duplication or misplaced docs.
Most skills operate in two modes:
-
Ephemeral (default)
Think, explore, review.
Nothing is written unless you ask. -
Persistent (opt-in)
Backlog items, decision records, or docs are written deliberately.
Never automatic. Never surprising.
If you want something saved, say so.
If you don’t, nothing will be created.
Scenario: You’ve just created an empty repo for a new internal service.
- Shape the work with Work Item Designer from a vague request like:
"We need a simple todo app to validate the flow."
- Run Safety Lens for a quick pre-flight risk check.
- Implement with Implementation Executor using the accepted work item only.
- Run Decision Lens on the diff if architecture might have changed.
- Use Documentation Lens only if new durable knowledge was introduced.
Outcome:
Working code, minimal structure, no process overhead.
Scenario: You’re modifying a large, older codebase.
- Shape a risky request with Work Item Designer, for example:
"Change how user IDs are generated."
- Run Safety Lens and explicitly confirm risk when identifier changes are involved.
- Execute with Implementation Executor and keep scope tight.
- Run Decision Lens and record only meaningful, long-term decisions.
- Run Documentation Lens to consolidate duplicated explanation into canonical docs.
Outcome:
The change is intentional, risk-aware, and legible to future developers.
This repo does not:
- automate project management,
- replace human judgement,
- enforce approvals or governance,
- standardise how every team works,
- or promise autonomous agents.
skills/ is the only source of truth. Installation mirrors that directory into tool discovery paths.
Use the installer script:
scripts/install-skills.sh --target /path/to/target-repoFor full target paths, options (--scope, --dry-run, --skip-existing, --overwrite), and safety behavior, see INSTALLATION.md.
Installation is opt-in: run when you want to refresh mirrors, not automatically on clone, CI, or deploy.
If you’re looking for a workflow engine or ticket system, this is probably not the right tool.
Everything here is guided by a few simple ideas:
- Clarity beats completeness
- Judgement over automation
- Signals, not gates
- Artifacts without bureaucracy
- Human authority is non-negotiable
If a change adds ceremony, it’s probably the wrong change.
Most teams:
- copy the skills they want,
- change wording only when real friction appears,
- and let usage evolve through practice rather than rules.
The skills are intentionally small so they can be understood, trusted, and adapted.
AI Assistant Rules — Unified rules and best practices for AI coding assistants (Cursor, Claude Code, Codex, Gemini CLI, Antigravity), derived from AI Blindspots. Use it alongside these skills for comprehensive guidance across tools.
See also CONTRIBUTING.md for contribution scope and review expectations.