local-env
Helper tool for interacting with local Docker-based PostgreSQL databases and configuring subscription data.
Install
mkdir -p .claude/skills/local-env && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/5674" && unzip -o skill.zip -d .claude/skills/local-env && rm skill.zipInstalls to .claude/skills/local-env
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Local environment management - run SQL queries, set up fake payments, reset test data. Use when the user needs help with local database operations or test data setup.Key capabilities
- →Execute SQL queries on a local PostgreSQL database
- →Set up fake payment statuses for organizations
- →Set up fake payment statuses for opportunities
- →Reset fake payment data for organizations and opportunities
- →Update the lifecycle state of an opportunity
- →Discover schema information for unknown database operations
How it works
The skill interacts with a local PostgreSQL database running in a Docker container. It executes SQL commands to manage test data, including setting fake payment statuses and updating opportunity states.
Inputs & outputs
When to use local-env
- →Execute SQL queries on local PostgreSQL
- →Set up fake subscription and payment status
- →Reset local test data
- →Verify organization subscription flags
About this skill
Local Environment Management
Help with local development environment tasks for daily-api.
Database Access
PostgreSQL runs locally via Docker in a k8s container.
Finding the Container
docker ps --format "table {{.Names}}" | grep "k8s_app_postgres"
Running Queries
docker exec <CONTAINER_NAME> psql -U postgres -d api -c "YOUR SQL QUERY"
For multi-line queries:
docker exec <CONTAINER_NAME> psql -U postgres -d api <<'EOF'
SELECT * FROM users LIMIT 1;
EOF
Fake Payment Setup
Payment status for opportunities is tracked on the Organization level via recruiterSubscriptionFlags. Opportunities also store subscription info in their flags column.
Organization Subscription Fields
| Field | Description |
|---|---|
status | Must be 'active' for payment validation to pass |
provider | Use 'paddle' |
items[].quantity | Number of opportunity "seats" available |
items[].priceId | Price ID that opportunities reference |
Opportunity Flags Fields
| Field | Description |
|---|---|
plan | Must match a priceId from the org's subscription items |
batchSize | Number of candidates per batch |
Fake Payment for Organization
UPDATE organization
SET "recruiterSubscriptionFlags" = jsonb_build_object(
'status', 'active',
'provider', 'paddle',
'subscriptionId', 'fake_sub_123',
'createdAt', now(),
'updatedAt', now(),
'items', jsonb_build_array(
jsonb_build_object('priceId', 'pri_fake_123', 'quantity', 5)
)
)
WHERE id = 'ORGANIZATION_ID';
Reset: UPDATE organization SET "recruiterSubscriptionFlags" = '{}' WHERE id = 'ORGANIZATION_ID';
Fake Payment for Opportunity
Requires updating both the organization AND the opportunity:
-- Step 1: Update organization subscription
UPDATE organization
SET "recruiterSubscriptionFlags" = jsonb_build_object(
'status', 'active',
'provider', 'paddle',
'subscriptionId', 'fake_sub_123',
'createdAt', now(),
'updatedAt', now(),
'items', jsonb_build_array(
jsonb_build_object('priceId', 'pri_fake_123', 'quantity', 5)
)
)
WHERE id = (SELECT "organizationId" FROM opportunity WHERE id = 'OPPORTUNITY_ID');
-- Step 2: Update opportunity flags
UPDATE opportunity
SET flags = flags || jsonb_build_object(
'plan', 'pri_fake_123',
'batchSize', 50
)
WHERE id = 'OPPORTUNITY_ID';
Reset:
UPDATE organization SET "recruiterSubscriptionFlags" = '{}'
WHERE id = (SELECT "organizationId" FROM opportunity WHERE id = 'OPPORTUNITY_ID');
UPDATE opportunity SET flags = flags - 'plan' - 'batchSize'
WHERE id = 'OPPORTUNITY_ID';
Opportunity State Management
The opportunity table uses a state column (integer) to track lifecycle status. Values come from OpportunityState enum in @dailydotdev/schema.
OpportunityState Values
| Value | Name | Description |
|---|---|---|
| 0 | UNSPECIFIED | Default/unset |
| 1 | DRAFT | Not yet published |
| 2 | LIVE | Active and visible |
| 3 | CLOSED | No longer active |
| 4 | IN_REVIEW | Pending review |
Update Opportunity State
-- Set to LIVE
UPDATE opportunity SET state = 2 WHERE id = 'OPPORTUNITY_ID' RETURNING id, state, title;
-- Set to DRAFT
UPDATE opportunity SET state = 1 WHERE id = 'OPPORTUNITY_ID' RETURNING id, state, title;
-- Set to CLOSED
UPDATE opportunity SET state = 3 WHERE id = 'OPPORTUNITY_ID' RETURNING id, state, title;
-- Set to IN_REVIEW
UPDATE opportunity SET state = 4 WHERE id = 'OPPORTUNITY_ID' RETURNING id, state, title;
Instructions
When the user asks for local environment help:
- For SQL queries: First find the postgres container, then execute via docker exec
- For fake payments: Determine if they're providing an opportunity ID or organization ID, run the appropriate SQL
- Always verify: After changes, run a SELECT to confirm
- Ask if unclear: If the request is ambiguous, ask clarifying questions
Common requests:
- "Set up fake payment for opportunity X" → Run both org and opportunity updates
- "Set up fake payment for org X" → Run only org update
- "Run SQL: ..." → Execute via docker
- "Reset payment for X" → Run reset queries
- "Check subscription for X" → Query and display current state
- "Update opp X to live/draft/closed" → Update opportunity state
Discovering Schema Information
When handling requests not covered in this skill, use these techniques to discover the correct schema:
1. Check Entity Definitions
Entity files define column names and types:
# Find the entity file
grep -r "TableName" src/entity/ --include="*.ts"
# Read the entity to see column definitions
Key location: src/entity/ - TypeORM entities with @Column decorators show actual DB column names.
2. Find Enum Values
Many columns use integer enums from @dailydotdev/schema. To find enum values:
# Search for enum usage in codebase
grep -r "EnumName\." src/ --include="*.ts" | head -20
# Find enum definition in schema package
grep -r "EnumName" node_modules/@dailydotdev/schema/dist/ --include="*.d.ts"
Common enum locations: node_modules/@dailydotdev/schema/dist/daily-api/*_pb.d.ts
3. Query Existing Data
When unsure about column names or values:
-- Check table structure
\d tablename
-- See existing values
SELECT DISTINCT column_name FROM tablename LIMIT 10;
-- Inspect a specific row
SELECT * FROM tablename WHERE id = 'xxx' LIMIT 1;
4. Common Gotchas
- Column naming: Entity property names may differ from DB columns (e.g.,
statenotstatus) - Integer enums: Many "status" fields are integers, not strings - find the enum definition
- JSONB fields: Use
jsonb_build_object()for updates,->or->>for queries - Quoted columns: PostgreSQL requires double quotes for camelCase columns (e.g.,
"organizationId")
Continuous Improvement
This skill should evolve over time. When you discover new local environment operations, common testing patterns, or useful queries:
- Add them to this file - Update the SKILL.md with new sections or examples
- Keep it practical - Focus on operations that are frequently needed
- Document the why - Explain what fields mean and why certain values are used
If a user asks for something not covered here, help them and then offer to add it to this skill for future use.
When not to use it
- →When the database is not PostgreSQL or not running locally via Docker
- →When managing production environments or non-local databases
Prerequisites
Limitations
- →The skill is designed for local development environments.
- →Column naming in entity property names may differ from actual database columns.
- →Many status fields are integer enums, not strings.
How it compares
This skill automates common local development database tasks and test data setup using predefined SQL commands, which is more efficient than manually constructing and executing queries.
Compared to similar skills
local-env side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| local-env (this skill) | 1 | 7mo | Review | Beginner |
| supabase-local-dev-loop | 0 | 27d | Caution | Beginner |
| test-with-postgres | 1 | 2mo | Review | Intermediate |
| supabase-multi-env-setup | 1 | 27d | Review | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by dailydotdev
View all by dailydotdev →You might also like
supabase-local-dev-loop
jeremylongshore
Configure Supabase local development with hot reload and testing. Use when setting up a development environment, configuring test workflows, or establishing a fast iteration cycle with Supabase. Trigger with phrases like "supabase dev setup", "supabase local development", "supabase dev environment", "develop with supabase".
test-with-postgres
storj
Run unit tests that require PostgreSQL. Use this skill when the user wants to run tests with PostgreSQL database backend. Automatically handles checking for and configuring a PostgreSQL Docker container.
supabase-multi-env-setup
jeremylongshore
Configure Supabase across development, staging, and production environments. Use when setting up multi-environment deployments, configuring per-environment secrets, or implementing environment-specific Supabase configurations. Trigger with phrases like "supabase environments", "supabase staging", "supabase dev prod", "supabase environment setup", "supabase config by env".
manage-infra
jpmolinamatute
Starts or stops the Docker Compose infrastructure (Postgres 17).
drizzle-orm
EpicenterHQ
Drizzle ORM patterns for type branding and custom types. Use when working with Drizzle column definitions, branded types, or custom type conversions.
database-design
davila7
Database design principles and decision-making. Schema design, indexing strategy, ORM selection, serverless databases.