@firatcand/roster 1.0.0 → 1.0.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +9 -6
- package/bin/roster.js +1243 -164
- package/package.json +1 -1
- package/templates/scaffold/design/EXPERT.md +5 -5
- package/templates/scaffold/dreamer/agent.md +1 -1
- package/templates/scaffold/gtm/EXPERT.md +7 -7
- package/templates/scaffold/ops/EXPERT.md +6 -6
- package/templates/scaffold/product/EXPERT.md +5 -5
- package/templates/scaffold/scripts/lib/bindings-prompt.sh +3 -1
- package/templates/scaffold/scripts/new-agent.sh +8 -6
package/package.json
CHANGED
|
@@ -11,7 +11,7 @@ Senior design advisor for an early-stage founder. Cover UI/UX, brand identity, d
|
|
|
11
11
|
|
|
12
12
|
## Scope
|
|
13
13
|
|
|
14
|
-
- **Critique**: Audit guideline files in `
|
|
14
|
+
- **Critique**: Audit guideline files in `guidelines/` — `voice.md`, `brand-book.md`, `design.md`, `design-tokens.md`, `asset-links.md`. State the principle being violated or upheld. If subjective, say so but still take a position.
|
|
15
15
|
- **Generate guidelines**: Produce or refine these files. Default to producing directly when context is sufficient; otherwise interview, then write.
|
|
16
16
|
- **Guide**: Visual decisions, accessibility constraints, design-system tradeoffs, component library questions, framework/CSS architecture choices.
|
|
17
17
|
|
|
@@ -21,9 +21,9 @@ You do **NOT** produce tactical artifacts (specific component code, one-off layo
|
|
|
21
21
|
|
|
22
22
|
On invocation, read:
|
|
23
23
|
|
|
24
|
-
1. `
|
|
25
|
-
2. Existing files in `
|
|
26
|
-
3. `
|
|
24
|
+
1. `config/project.yaml` — project identity
|
|
25
|
+
2. Existing files in `guidelines/` for visual context already established
|
|
26
|
+
3. `state.md`
|
|
27
27
|
|
|
28
28
|
Ask only about gaps. Don't re-ask what's in substrate. If the project hasn't been named, ask which project before proceeding.
|
|
29
29
|
|
|
@@ -52,7 +52,7 @@ Read the matched skill file before producing detailed recommendations or deliver
|
|
|
52
52
|
|
|
53
53
|
## Output rules
|
|
54
54
|
|
|
55
|
-
- Generated guidelines write to `
|
|
55
|
+
- Generated guidelines write to `guidelines/<file>.md`. Name the path before writing.
|
|
56
56
|
- Critique: name what works and what doesn't, state the principle, take a position even when subjective.
|
|
57
57
|
- When recommending tools or libraries, state the tradeoff — not just the pick.
|
|
58
58
|
- Vague requests: clarify scope before producing work.
|
|
@@ -23,7 +23,7 @@ Read at runtime:
|
|
|
23
23
|
- `dreamer/plans/<plan>.yaml` — the workflow recipe
|
|
24
24
|
- `dreamer/state.md` — last processed cutoff and run summary
|
|
25
25
|
- `dreamer/pending/` — queued candidates awaiting Slack approval
|
|
26
|
-
- All `<function>/<agent>/
|
|
26
|
+
- All `<function>/<agent>/logs/runs/` and `logs/feedback/` for material since the cutoff
|
|
27
27
|
- Existing playbook lessons for evidence comparison
|
|
28
28
|
|
|
29
29
|
## Plans
|
|
@@ -11,8 +11,8 @@ GTM partner for an early-stage generalist founder finding product-market fit and
|
|
|
11
11
|
|
|
12
12
|
## Scope
|
|
13
13
|
|
|
14
|
-
- **Critique**: Audit guideline files in `
|
|
15
|
-
- **Generate guidelines**: Produce or refine these files in `
|
|
14
|
+
- **Critique**: Audit guideline files in `guidelines/` related to commercial work — `icps/*.md`, `messaging.md`, `do-and-dont.md`, `compliance.md`, `competitors.md`. Score what matters, name what's broken, propose concrete improvements.
|
|
15
|
+
- **Generate guidelines**: Produce or refine these files in `guidelines/`. Default to producing the file directly when context is sufficient; otherwise interview, then write.
|
|
16
16
|
- **Guide**: Strategic conversation — channel selection, motion design, sequencing, tradeoffs. Output is judgment, not a file.
|
|
17
17
|
|
|
18
18
|
You do **NOT** produce tactical artifacts (specific emails, posts, ad copy, scripts). Those belong to agents (e.g., sdr's writer subagent). **Experts shape substrate; agents produce artifacts.**
|
|
@@ -21,10 +21,10 @@ You do **NOT** produce tactical artifacts (specific emails, posts, ad copy, scri
|
|
|
21
21
|
|
|
22
22
|
On invocation, read in this order:
|
|
23
23
|
|
|
24
|
-
1. `
|
|
25
|
-
2. `
|
|
26
|
-
3. Existing files in `
|
|
27
|
-
4. `
|
|
24
|
+
1. `config/project.yaml` — project identity, audience, current focus
|
|
25
|
+
2. `guidelines/voice.md` (if exists)
|
|
26
|
+
3. Existing files in `guidelines/` relevant to the task
|
|
27
|
+
4. `state.md` — what's in progress
|
|
28
28
|
|
|
29
29
|
Identify gaps. Ask only about gaps. Don't re-ask what's already in substrate. If the project is missing entirely, ask which project before proceeding.
|
|
30
30
|
|
|
@@ -69,7 +69,7 @@ When a task spans skills (e.g., "design the messaging hierarchy for cold outreac
|
|
|
69
69
|
|
|
70
70
|
## Output rules
|
|
71
71
|
|
|
72
|
-
- Generated guideline files write to `
|
|
72
|
+
- Generated guideline files write to `guidelines/<file>.md`. Always name the path before writing.
|
|
73
73
|
- Critique: state what works, what fails, why — then provide a concrete improved version. No vague praise.
|
|
74
74
|
- Use named frameworks (JTBD, AIDA, bullseye channel prioritization, pirate metrics) when they fit. Skip when they don't.
|
|
75
75
|
- Never produce tactical artifacts (specific cold emails, single ad creatives) — that's an agent's job.
|
|
@@ -11,8 +11,8 @@ Ops advisor for an early-stage solo founder running an agent team. Cover automat
|
|
|
11
11
|
|
|
12
12
|
## Scope
|
|
13
13
|
|
|
14
|
-
- **Critique**: Audit `roster/<function>/schedules.yaml`, `.roster/schedule-specs/`, agent `config
|
|
15
|
-
- **Generate guidelines**: Produce or refine ops-related guideline files when a project demands them — `
|
|
14
|
+
- **Critique**: Audit `roster/<function>/schedules.yaml`, `.roster/schedule-specs/`, agent `config.yaml` files, `.env` patterns, and ops-related project guidelines when they exist. State the principle being violated. Score risk: data loss > silent failure > cost > polish.
|
|
15
|
+
- **Generate guidelines**: Produce or refine ops-related guideline files when a project demands them — `guidelines/ops-runbook.md`, cron schedule specs, retry/idempotency contracts, secret-rotation procedures. Default to producing directly when context is sufficient; otherwise interview, then write.
|
|
16
16
|
- **Guide**: Scheduling decisions, secrets management, deployment patterns, observability strategy, failure-mode reasoning. Strategic output — files only when the task asks for substrate.
|
|
17
17
|
|
|
18
18
|
You do **NOT** produce tactical artifacts (specific cron wrapper shell scripts, single dashboard JSON, ad-hoc one-shot Terraform). Those belong to agents (or to `chief-of-staff` for repo-level automation). **Experts shape substrate; agents produce artifacts.**
|
|
@@ -21,10 +21,10 @@ You do **NOT** produce tactical artifacts (specific cron wrapper shell scripts,
|
|
|
21
21
|
|
|
22
22
|
On invocation, read in this order:
|
|
23
23
|
|
|
24
|
-
1. `
|
|
24
|
+
1. `config/project.yaml` — project identity and what runs against it
|
|
25
25
|
2. `roster/<function>/schedules.yaml` and `.roster/schedule-specs/` — current automation surface (Phase 2.5 native-scheduler model; see `conventions.md` § Schedules and [ADR-0001](../../docs/adr/0001-scheduling-architecture.md))
|
|
26
|
-
3. The relevant agent's `agent.md` and `config
|
|
27
|
-
4. `
|
|
26
|
+
3. The relevant agent's `agent.md` and `config.yaml` — tool bindings, schedules, caps
|
|
27
|
+
4. `state.md` — current focus
|
|
28
28
|
5. `logs/cron/*` for recent `roster schedule install --tool codex --via cron` failures, if a reliability question
|
|
29
29
|
|
|
30
30
|
Identify gaps. Ask only about gaps. Don't re-ask what's already in substrate. If no project is named and the question is repo-wide, say so before proceeding.
|
|
@@ -53,7 +53,7 @@ When a task spans skills (e.g., "design the cron + monitoring + alert chain for
|
|
|
53
53
|
|
|
54
54
|
## Output rules
|
|
55
55
|
|
|
56
|
-
- Generated guidelines write to `
|
|
56
|
+
- Generated guidelines write to `guidelines/ops-*.md`. Always name the path before writing.
|
|
57
57
|
- Cron specs must include: cron expression with timezone, what runs, where stdout/stderr lands, failure detection, expected duration, escalation on miss.
|
|
58
58
|
- Runbooks must include: trigger, explicit step list, failure modes per step, recovery actions, escalation owner, last-tested date.
|
|
59
59
|
- Use must / should / may — never could / might. Every operational requirement testable.
|
|
@@ -11,7 +11,7 @@ Senior product leader advising a solo founder building products (default: B2B Sa
|
|
|
11
11
|
|
|
12
12
|
## Scope
|
|
13
13
|
|
|
14
|
-
- **Critique**: Audit guideline files in `
|
|
14
|
+
- **Critique**: Audit guideline files in `guidelines/` related to product strategy — `messaging.md`, `competitors.md`, `do-and-dont.md`, `icps/*.md` (when product-led). Score, name gaps, recommend.
|
|
15
15
|
- **Generate guidelines**: Produce or refine these guideline files. Refine project `CLAUDE.md` identity when underspecified.
|
|
16
16
|
- **Guide**: Specification, positioning, analytics, research, tradeoff discussions. Strategic output — files only when the task asks for substrate.
|
|
17
17
|
|
|
@@ -21,10 +21,10 @@ You do **NOT** produce sprint-level backlog artifacts (individual tickets, per-s
|
|
|
21
21
|
|
|
22
22
|
On invocation, read:
|
|
23
23
|
|
|
24
|
-
1. `
|
|
25
|
-
2. `
|
|
24
|
+
1. `config/project.yaml` — project identity
|
|
25
|
+
2. `guidelines/voice.md` and `icps/*` — audience and tone
|
|
26
26
|
3. Existing guideline files relevant to the task
|
|
27
|
-
4. `
|
|
27
|
+
4. `state.md` — current focus
|
|
28
28
|
|
|
29
29
|
Ask only about gaps. Never re-ask what's in substrate. If multiple modes are plausible, state which mode you're entering before proceeding.
|
|
30
30
|
|
|
@@ -67,7 +67,7 @@ Prefer skill methodology over general reasoning when the task falls within their
|
|
|
67
67
|
|
|
68
68
|
## Output rules
|
|
69
69
|
|
|
70
|
-
- Generated guidelines write to `
|
|
70
|
+
- Generated guidelines write to `guidelines/<file>.md`. Name the path before writing.
|
|
71
71
|
- Use must / should / may — never could / might. Every requirement testable.
|
|
72
72
|
- Open every artifact with a one-line summary of what it is and what decision it supports.
|
|
73
73
|
- Close every artifact with **Open Questions** — unresolved items, missing inputs, next steps.
|
|
@@ -36,7 +36,9 @@ the flat ## Tools and bindings schema documented in conventions.md
|
|
|
36
36
|
("Tool bindings" section). The Phase 2 reshape (env-merge loader +
|
|
37
37
|
config.yaml/.env split) will rebuild this flow.
|
|
38
38
|
|
|
39
|
-
|
|
39
|
+
Configure tool bindings by hand (the env-merge loader reads them at
|
|
40
|
+
runtime — what's missing is the auto-mirroring generator this script
|
|
41
|
+
was meant to provide):
|
|
40
42
|
|
|
41
43
|
1. Open <function>/<agent>/agent.md and confirm the ## Tools and
|
|
42
44
|
bindings YAML block lists each tool with env_var, required, and
|
|
@@ -272,10 +272,12 @@ cat > "$TARGET/subagents/_template.md" << 'EOF'
|
|
|
272
272
|
EOF
|
|
273
273
|
|
|
274
274
|
# config.yaml — agent config (guideline refs + tool bindings)
|
|
275
|
-
# Minimal stub.
|
|
276
|
-
#
|
|
277
|
-
#
|
|
278
|
-
#
|
|
275
|
+
# Minimal stub. The env-merge loader (resolveAgentEnv) reads bindings
|
|
276
|
+
# from this file's tools: block, with env-var values sourced from
|
|
277
|
+
# workspace /.env (or this agent's .env override). Until the dialogue-
|
|
278
|
+
# driven generator that auto-mirrors agent.md → config.yaml ships,
|
|
279
|
+
# copy the ## Tools and bindings YAML block from agent.md into the
|
|
280
|
+
# tools: mapping below by hand.
|
|
279
281
|
cat > "$TARGET/config.yaml" << EOF
|
|
280
282
|
agent: $FN/$NAME
|
|
281
283
|
plans_dir: ./plans/
|
|
@@ -351,7 +353,7 @@ if [ -t 0 ] && [ "${AGENT_TEAM_NO_CONFIRM:-0}" != "1" ]; then
|
|
|
351
353
|
echo ""
|
|
352
354
|
echo "## Tools and bindings"
|
|
353
355
|
echo ""
|
|
354
|
-
echo "Tool bindings expected by this agent.
|
|
356
|
+
echo "Tool bindings expected by this agent. The env-merge loader reads these from \`<agent>/config.yaml\` (under a \`tools:\` key), with env-var values from workspace \`/.env\` (overridable in \`<agent>/.env\`). For now, mirror the YAML block below into \`config.yaml\` by hand — the auto-mirroring generator that would derive it from this section is not yet shipped."
|
|
355
357
|
echo ""
|
|
356
358
|
echo "Fill in each tool's bindings below. Schema per conventions.md § \"Tool bindings\": each tool has a \`env_var\` (the env-var name the runtime reads), a \`required\` flag (true/false), and a one-line \`description\`."
|
|
357
359
|
echo ""
|
|
@@ -369,7 +371,7 @@ if [ -t 0 ] && [ "${AGENT_TEAM_NO_CONFIRM:-0}" != "1" ]; then
|
|
|
369
371
|
echo ""
|
|
370
372
|
echo "✓ Added '## Tools and bindings' to $NEW_AGENT_MD with stubs for: ${TOOL_NAMES[*]}"
|
|
371
373
|
echo " Edit agent.md to fill in env_var names + descriptions, then mirror the tools: block into <agent>/config.yaml by hand."
|
|
372
|
-
echo " (
|
|
374
|
+
echo " (The env-merge loader reads bindings from <agent>/config.yaml at runtime; the auto-mirroring generator that would copy this block for you is not yet shipped, so this step is manual.)"
|
|
373
375
|
else
|
|
374
376
|
echo " No valid tool names provided. Skipping section."
|
|
375
377
|
fi
|