Stop telling LLMs what to do. Tell them what NOT to do.
A port of NeoVertex1/context-field for Factory Droid. 21 composable cognitive constraints that reshape how Droid thinks through inhibition-based prompting.
Standard prompt engineering uses instructions: "Consider edge cases. Write secure code."
These create preferences. When the easy path is obvious, preferences lose.
Context Fields use inhibitions: "Do not handle only the happy path."
These create blockers. The model cannot proceed without addressing them.
# Project-level (everyone on the project gets it)
cd /your/project
bash ~/context-fields-droid/install.sh
# User-level (just you, across all projects)
bash ~/context-fields-droid/install.sh --user# Copy commands to your project
cp context-fields-droid/plugins/context-fields/commands/cf-*.md .factory/commands/
# Copy the skill
mkdir -p .factory/skills/context-fields
cp context-fields-droid/plugins/context-fields/skills/context-fields/SKILL.md .factory/skills/context-fields/
# Copy the hook script
mkdir -p .factory/hooks
cp context-fields-droid/plugins/context-fields/hooks/inject-fields.sh .factory/hooks/
chmod +x .factory/hooks/inject-fields.shThen add the hook to .factory/settings.json:
{
"hooks": {
"UserPromptSubmit": [
{
"matcher": ".*",
"hooks": [
{
"type": "command",
"command": "$FACTORY_PROJECT_DIR/.factory/hooks/inject-fields.sh"
}
]
}
]
}
}This repo is structured as a Factory Droid plugin marketplace. If Factory supports custom marketplaces, point it at this directory.
After installation, fields auto-activate based on your request type, or use them explicitly:
/cf-code Write a function to validate email addresses
/cf-debug My React app crashes on button click
/cf-interview Should I quit my job?
Stack multiple fields for complex tasks:
/cf-interview + /cf-scope
I want to build a social media app.
| Command | Purpose | Key Constraint |
|---|---|---|
/cf-code |
Assumption-stating before coding | Do not write code before stating assumptions |
/cf-interview |
Questions before advice | Do not answer before understanding the real problem |
/cf-critic |
Rigorous examination | Do not accept the premise without examining it |
/cf-debug |
Root cause analysis | Do not propose fixes before understanding failure |
/cf-creative |
Unfiltered ideation | Do not filter ideas before expressing them |
/cf-simplify |
Reduction to essentials | Do not add abstraction before proving it's needed |
/cf-empathy |
Emotional acknowledgment first | Do not solve before acknowledging feelings |
/cf-concise |
Brevity and directness | Do not write more when less would suffice |
/cf-planning |
Structure before execution | Do not execute before planning |
/cf-scope |
Explicit boundaries | Do not start without defining what's in and out |
/cf-teacher |
Understanding verification | Do not explain next concept before verifying previous |
/cf-steelman |
Strongest version of arguments | Do not attack the weak version |
/cf-adversarial |
Failure mode identification | Do not assume good faith inputs |
/cf-explore |
Delayed commitment, retain ambiguity | Do not conclude when the question is still opening |
/cf-novel |
Non-obvious, original thinking | Do not suggest the first idea that comes to mind |
For when you want the normally-discouraged behavior:
| Command | Inverse Of | Purpose |
|---|---|---|
/cf-elaborate |
/cf-simplify | Explore full complexity |
/cf-trust |
/cf-critic | Build on ideas, assume good faith |
/cf-conventional |
/cf-creative | Prefer proven patterns |
/cf-verbose |
/cf-concise | Full explanations with context |
/cf-solve |
/cf-interview | Immediate solutions over questions |
/cf-generate |
(tool) | Create new fields from failures |
Every field is built from these components:
- Inhibition: "Do not X" - Creates a blocker that must be resolved
- Forcing Function: "What/Why/How?" - Redirects processing
- Meta-monitor: "Before X, do Y" - Creates a checkpoint
- Scope Bound: "Under what conditions..." - Forces explicit limitation
The UserPromptSubmit hook runs inject-fields.sh on every prompt. This injects field detection instructions so Droid auto-selects the right field(s):
| Request Type | Auto-Applies |
|---|---|
| Code errors/bugs | /cf-debug |
| Writing code | /cf-code |
| Advice/decisions | /cf-interview |
| Evaluating ideas | /cf-critic |
| Brainstorming | /cf-creative |
| Emotional content | /cf-empathy |
| Simple questions | /cf-concise |
Droid announces which fields are active: [Context Fields: /cf-debug + /cf-empathy]
| Composition | Use Case |
|---|---|
| /cf-code + /cf-critic | Code review (finds bugs AND design flaws) |
| /cf-interview + /cf-scope | Requirements (asks context AND bounds scope) |
| /cf-creative + /cf-critic | Brainstorming (generates THEN evaluates) |
| /cf-debug + /cf-adversarial | Security (diagnoses with threat modeling) |
| /cf-empathy + /cf-interview | Life decisions (acknowledges feelings, then explores) |
| Claude Code | Factory Droid | Notes |
|---|---|---|
.claude-plugin/plugin.json |
.factory-plugin/plugin.json |
Same JSON structure |
.claude-plugin/marketplace.json |
.factory-plugin/marketplace.json |
Same marketplace format |
commands/*.md |
commands/cf-*.md |
Same YAML frontmatter + $ARGUMENTS format |
traits/*.md |
traits/*.md |
Personality constraints (reference files) |
skills/*/SKILL.md |
skills/context-fields/SKILL.md |
Same skill format with frontmatter |
hooks/hooks.json |
hooks/hooks.json |
Same JSON hook structure |
${CLAUDE_PLUGIN_ROOT} |
${DROID_PLUGIN_ROOT} |
Different env var name |
UserPromptSubmit event |
UserPromptSubmit event |
Identical hook event |
- Command naming: Claude uses
context-fields:code(plugin-namespaced). Factory uses flatcf-code(prefix-namespaced) since commands are top-level. - Plugin env var:
${CLAUDE_PLUGIN_ROOT}becomes${DROID_PLUGIN_ROOT}. - Traits: Factory Droid doesn't have a native "traits" concept, but the trait files are included as reference material in the plugin's
traits/directory. - Hook events: Factory has more hook events (
PreToolUse,PostToolUse,SessionStart,Stop, etc.) than justUserPromptSubmit.
context-fields-droid/
├── .factory-plugin/
│ └── marketplace.json # Marketplace distribution metadata
├── plugins/
│ └── context-fields/
│ ├── .factory-plugin/
│ │ └── plugin.json # Plugin metadata
│ ├── commands/ # 21 slash commands
│ │ ├── cf-adversarial.md
│ │ ├── cf-code.md
│ │ ├── cf-concise.md
│ │ ├── cf-conventional.md
│ │ ├── cf-creative.md
│ │ ├── cf-critic.md
│ │ ├── cf-debug.md
│ │ ├── cf-elaborate.md
│ │ ├── cf-empathy.md
│ │ ├── cf-explore.md
│ │ ├── cf-generate.md
│ │ ├── cf-interview.md
│ │ ├── cf-novel.md
│ │ ├── cf-planning.md
│ │ ├── cf-scope.md
│ │ ├── cf-simplify.md
│ │ ├── cf-solve.md
│ │ ├── cf-steelman.md
│ │ ├── cf-teacher.md
│ │ ├── cf-trust.md
│ │ └── cf-verbose.md
│ ├── skills/
│ │ └── context-fields/
│ │ └── SKILL.md # Auto-detection + all field definitions
│ ├── traits/ # Personality constraint files
│ │ ├── adversarial.md
│ │ ├── code.md
│ │ ├── ... (20 total)
│ │ └── verbose.md
│ └── hooks/
│ ├── hooks.json # Hook configuration
│ └── inject-fields.sh # Auto-activation script
├── install.sh # Installation helper
└── README.md
Use /cf-generate or follow this template:
Do not [blocker 1 - common failure mode].
Do not [blocker 2 - common failure mode].
Do not [blocker 3 - common failure mode].
[Forcing function question]?
Do not suggest tactics without understanding the power dynamic.
Do not assume the relationship is purely transactional.
Do not optimize for winning at the cost of the relationship.
What happens if this negotiation fails?
MIT (following the original context-field project)
- Original research and Claude Code plugin: NeoVertex1/context-field
- Factory Droid port: Adapted for Factory's plugin/command/hook system