cc-dev-template 0.1.98 → 0.1.99

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cc-dev-template",
-  "version": "0.1.98",
+  "version": "0.1.99",
   "description": "Structured AI-assisted development framework for Claude Code",
   "bin": {
     "cc-dev-template": "./bin/install.js"

package/src/skills/creating-agent-skills/references/create-step-2-design.md

@@ -57,6 +57,45 @@ Configuration: No special setting needed
 
 Configuration: `context: fork` (optionally add `agent: Explore` or `agent: Plan` for specialized behavior)
 
+## Design Constraints
+
+Only relevant for skills that orchestrate sub-agents or have clear role boundaries. Skip this section for simple informational skills or single-step workflows.
+
+### Constraint Mechanisms
+
+From weakest to strongest:
+
+| Mechanism | What It Does | Use When |
+|-----------|-------------|----------|
+| Prompt instructions | Advisory guidance in skill/agent text | Soft guidance, not security-critical |
+| `allowed-tools` (skill frontmatter) | Auto-approves listed tools (no user prompt). Does NOT block anything. | Reducing user friction for known-safe tools |
+| `tools` (agent frontmatter) | Grants ONLY listed tools to sub-agent. Everything else denied. | Coarse tool-level restriction (e.g., read-only agent) |
+| PreToolUse hook (settings.json) | Script checks every tool call against policy rules. Can inspect file paths, commands, agent identity. | Path-level enforcement, per-phase rules, cross-agent policies |
+| Inline content passing | Pass file contents in Agent prompt instead of letting agent read files. Combined with restricted `tools`, agent physically cannot access unauthorized files. | Contamination prevention, strongest isolation |
+
+### Constraint Design Questions
+
+Ask the user these questions when the skill involves sub-agents:
+
+- Should the orchestrator be restricted? (e.g., blocked from source code, forced to delegate)
+- Should sub-agents only access specific files/directories?
+- Are there contamination concerns? (agents that should be blind to certain information)
+- Should certain deliverables only be writable by specific agents?
+
+### Constraint Map
+
+If constraints are needed, produce a constraint map before designing frontmatter: which agent can do what, and which mechanism enforces each rule. This feeds into the frontmatter design and may require a hook script.
+
+Example format:
+```
+Orchestrator: no Bash, no source code reads → PreToolUse hook
+Researcher agent: tools: Read, Grep, Glob, Write → agent frontmatter
+Writer agent: only writes to docs/output/ → PreToolUse hook (path check)
+Reviewer agent: receives content inline, no file reads → inline content passing + tools: Write
+```
+
+Reference the creating-sub-agents skill for detailed sub-agent constraint configuration (tool sets, permission modes, hook examples).
+
 ## Design the Frontmatter
 
 Every skill has YAML frontmatter. Required and optional fields:
@@ -75,7 +114,7 @@ Every skill has YAML frontmatter. Required and optional fields:
 | `argument-hint` | Placeholder shown after slash command (e.g., `[issue-number]`, `[filename]`) |
 | `disable-model-invocation` | Set `true` to prevent Claude from auto-activating — use for side-effect workflows like deploy or commit |
 | `user-invocable` | Set `false` to hide from the `/` menu — use for background knowledge skills |
-| `allowed-tools` | Restrict which tools the skill can use (e.g., `Read, Grep, Glob` for read-only) |
+| `allowed-tools` | Pre-approve tools for auto-acceptance (user won't be prompted for these). Does NOT restrict — unlisted tools still work, they just require user approval. |
 | `model` | Override the model used when this skill is active |
 | `context` | Set `fork` to run in an isolated sub-agent context |
 | `agent` | Sub-agent type when `context: fork` is set (`Explore`, `Plan`, `general-purpose`, or custom) |

package/src/skills/creating-agent-skills/references/create-step-4-review.md

@@ -49,6 +49,12 @@ Go through each file and verify:
 - For informational skills: reflection section at the end of SKILL.md?
 - For forked-context skills: "Skill Observations" section in the output format?
 
+### Constraints
+- If the skill spawns sub-agents: are tool grants appropriate for each agent's role?
+- Is `allowed-tools` used correctly? (auto-approval only, not restriction)
+- If path-level restrictions are needed: is a PreToolUse hook designed?
+- Are constraint decisions documented in the skill (so future editors understand why)?
+
 ## Run Validation
 
 ```bash

package/src/skills/creating-agent-skills/scripts/validate-skill.js

@@ -167,6 +167,14 @@ if (!frontmatter.valid) {
       null,
       'Remove all < and > characters from frontmatter values');
   }
+
+  // Check: allowed-tools usage awareness
+  if (frontmatter.data['allowed-tools']) {
+    addFinding('CONSTRAINT', 'info',
+      'Skill uses allowed-tools — this pre-approves tools for auto-acceptance, it does NOT restrict tool access. If restriction is intended, use the tools field on sub-agent definitions instead.',
+      null,
+      'See creating-sub-agents skill for sub-agent tool restriction patterns');
+  }
 }
 
 // Check 3: Second person violations