Claude-skill-registry local-env

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.

install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/local-env" ~/.claude/skills/majiayu000-claude-skill-registry-local-env && rm -rf "$T"
manifest: skills/data/local-env/SKILL.md
source content

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

FieldDescription
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

FieldDescription
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

ValueNameDescription
0UNSPECIFIEDDefault/unset
1DRAFTNot yet published
2LIVEActive and visible
3CLOSEDNo longer active
4IN_REVIEWPending 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:

  1. For SQL queries: First find the postgres container, then execute via docker exec
  2. For fake payments: Determine if they're providing an opportunity ID or organization ID, run the appropriate SQL
  3. Always verify: After changes, run a SELECT to confirm
  4. 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.,
    state
    not
    status
    )
  • 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:

  1. Add them to this file - Update the SKILL.md with new sections or examples
  2. Keep it practical - Focus on operations that are frequently needed
  3. 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.