skill-web-implementation
- Repo stars 435
- Author updated Live
- Author repo nvim
- Domain
- Engineering
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @benbrastmckie · no license declared
- Token usage
- Moderate
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Shell exec
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: skill-web-implementation
description: Implement web (Astro/Tailwind/TypeScript) changes following a plan. Invoke for web-language impl…
category: engineering
runtime: no special runtime
---
# skill-web-implementation output preview
## PART A: Task fit
- Use case: Implement web (Astro/Tailwind/TypeScript) changes following a plan. Invoke for web-language implementation tasks. Thin wrapper that delegates web (Astro/Tailwind/TypeScript) implementation to web-implementation-agent subagent. runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Context References / Trigger Conditions / Execution” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Implement web (Astro/Tailwind/TypeScript) changes following a plan. Invoke for web-language implementation tasks. Thin wrapper that delegates web (Astro/Tailwind/TypeScript) implementation to web-implementation-agent subagent. runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “Context References / Trigger Conditions / Execution” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source mentions slash commands such as `/implement`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, run shell commands.
Start with a small task and check whether the result follows “Context References / Trigger Conditions / Execution”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: skill-web-implementation
description: Implement web (Astro/Tailwind/TypeScript) changes following a plan. Invoke for web-language impl…
category: engineering
source: benbrastmckie/nvim
---
# skill-web-implementation
## When to use
- Implement web (Astro/Tailwind/TypeScript) changes following a plan. Invoke for web-language implementation tasks. Thin…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Context References / Trigger Conditions / Execution” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "skill-web-implementation" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Context References / Trigger Conditions / Execution
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files, run shell commands | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Web Implementation Skill
Thin wrapper that delegates web (Astro/Tailwind/TypeScript) implementation to web-implementation-agent subagent.
IMPORTANT: This skill implements the skill-internal postflight pattern. After the subagent returns, this skill handles all postflight operations (status update, artifact linking, git commit) before returning. This eliminates the "continue" prompt issue between skill return and orchestrator.
Context References
Reference (do not load eagerly):
- Path:
.claude/context/project/web/README.md- Web context overview - Path:
.claude/context/project/web/domain/astro-framework.md- Astro reference - Path:
.claude/context/project/web/domain/tailwind-v4.md- Tailwind v4 reference
Note: This skill is a thin wrapper with internal postflight. Context is loaded by the delegated agent.
Trigger Conditions
This skill activates when:
- Task type is "web"
- /implement command targets a web (Astro/Tailwind/TypeScript) task
- Pages, components, layouts, or web styling needs to be created or modified
Execution
0. Preflight Status Update
Before delegating to the subagent, update task status to "implementing".
Update state.json:
jq --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
--arg status "implementing" \
--arg sid "$session_id" \
'(.active_projects[] | select(.project_number == '$task_number')) |= . + {
status: $status,
last_updated: $ts,
session_id: $sid,
started: $ts
}' specs/state.json > specs/tmp/state.json && mv specs/tmp/state.json specs/state.json
Update TODO.md: Use Edit tool to change status marker from [PLANNED] to [IMPLEMENTING].
Update plan file (if exists): Update the Status field in plan metadata:
# Find latest plan file
plan_file=$(ls -1 "specs/${padded_num}_${project_name}/plans/"*.md 2>/dev/null | sort -V | tail -1)
if [ -n "$plan_file" ] && [ -f "$plan_file" ]; then
sed -i "s/^\- \*\*Status\*\*: \[.*\]$/- **Status**: [IMPLEMENTING]/" "$plan_file"
fi
Create Postflight Marker:
# Ensure task directory exists
padded_num=$(printf "%03d" "$task_number")
mkdir -p "specs/${padded_num}_${project_name}"
cat > "specs/${padded_num}_${project_name}/.postflight-pending" << EOF
{
"session_id": "${session_id}",
"skill": "skill-web-implementation",
"task_number": ${task_number},
"operation": "implement",
"reason": "Postflight pending: status update, artifact linking, git commit",
"created": "$(date -u +%Y-%m-%dT%H:%M:%SZ)",
"stop_hook_active": false
}
EOF
1. Input Validation
Validate required inputs:
task_number- Must be provided and exist in state.json- Task status must allow implementation (planned, implementing, partial)
# Lookup task
task_data=$(jq -r --arg num "$task_number" \
'.active_projects[] | select(.project_number == ($num | tonumber))' \
specs/state.json)
# Validate exists
if [ -z "$task_data" ]; then
return error "Task $task_number not found"
fi
# Extract fields
task_type=$(echo "$task_data" | jq -r '.task_type // "general"')
status=$(echo "$task_data" | jq -r '.status')
project_name=$(echo "$task_data" | jq -r '.project_name')
description=$(echo "$task_data" | jq -r '.description // ""')
# Validate language
if [ "$task_type" != "web" ]; then
return error "Task $task_number is not a web task"
fi
# Validate status
if [ "$status" = "completed" ]; then
return error "Task already completed"
fi
2. Context Preparation
Prepare delegation context:
{
"session_id": "sess_{timestamp}_{random}",
"delegation_depth": 1,
"delegation_path": ["orchestrator", "implement", "skill-web-implementation"],
"timeout": 3600,
"task_context": {
"task_number": N,
"task_name": "{project_name}",
"description": "{description}",
"task_type": "web"
},
"plan_path": "specs/{NNN}_{SLUG}/plans/MM_{short-slug}.md",
"metadata_file_path": "specs/{NNN}_{SLUG}/.return-meta.json"
}
3. Invoke Subagent
CRITICAL: You MUST use the Agent tool to spawn the subagent.
The agent field in this skill's frontmatter specifies the target: web-implementation-agent
Required Tool Invocation:
Tool: Agent (NOT Skill, NOT Plan)
Parameters:
- subagent_type: "web-implementation-agent"
- prompt: [Include task_context, delegation_context, plan_path]
- description: "Execute web implementation for task {N}"
DO NOT use Skill(web-implementation-agent) - this will FAIL.
Agents live in .claude/agents/, not .claude/skills/.
The Skill tool can only invoke skills from .claude/skills/.
The subagent will:
- Load web-specific context files (Astro framework, Tailwind v4, style guide, etc.)
- Create/modify .astro, .ts, .tsx, .css files
- Execute build verification (pnpm build, pnpm check)
- Handle TypeScript and Astro errors
- Create implementation summary
- Write metadata to
specs/{NNN}_{SLUG}/.return-meta.json - Return a brief text summary (NOT JSON)
3a. Validate Subagent Return Format
IMPORTANT: Check if subagent accidentally returned JSON to console (v1 pattern) instead of writing to file (v2 pattern).
If the subagent's text return parses as valid JSON, log a warning:
# Check if subagent return looks like JSON (starts with { and is valid JSON)
subagent_return="$SUBAGENT_TEXT_RETURN"
if echo "$subagent_return" | grep -q '^{' && echo "$subagent_return" | jq empty 2>/dev/null; then
echo "WARNING: Subagent returned JSON to console instead of writing metadata file."
echo "This indicates the agent may have outdated instructions (v1 pattern instead of v2)."
echo "The skill will continue by reading the metadata file, but this should be fixed."
fi
This validation:
- Does NOT fail the operation (continues to read metadata file)
- Logs a warning for debugging
- Indicates the subagent instructions need updating
- Allows graceful handling of mixed v1/v2 agents
3b. Self-Execution Fallback
CRITICAL: If you performed the work above WITHOUT using the Agent tool (i.e., you read files,
wrote artifacts, or updated metadata directly instead of spawning a subagent), you MUST write a
.return-meta.json file now before proceeding to postflight. Use the schema from
return-metadata-file.md with status value "implemented".
If you DID use the Agent tool, skip this stage -- the subagent already wrote the metadata.
Postflight (ALWAYS EXECUTE)
The following stages MUST execute after work is complete, whether the work was done by a subagent or inline (Stage 3b). Do NOT skip these stages for any reason.
4. Parse Subagent Return (Read Metadata File)
Read the metadata file:
metadata_file="specs/${padded_num}_${project_name}/.return-meta.json"
if [ -f "$metadata_file" ] && jq empty "$metadata_file" 2>/dev/null; then
status=$(jq -r '.status' "$metadata_file")
artifact_path=$(jq -r '.artifacts[0].path // ""' "$metadata_file")
artifact_type=$(jq -r '.artifacts[0].type // ""' "$metadata_file")
artifact_summary=$(jq -r '.artifacts[0].summary // ""' "$metadata_file")
phases_completed=$(jq -r '.metadata.phases_completed // 0' "$metadata_file")
phases_total=$(jq -r '.metadata.phases_total // 0' "$metadata_file")
# Extract completion_data fields (if present)
completion_summary=$(jq -r '.completion_data.completion_summary // ""' "$metadata_file")
roadmap_items=$(jq -c '.completion_data.roadmap_items // []' "$metadata_file")
else
echo "Error: Invalid or missing metadata file"
status="failed"
fi
Validate the metadata contains required fields:
- Status is one of: implemented, partial, failed, blocked
- Summary is non-empty and <100 tokens
- Artifacts array present (source files, summary)
- Metadata contains session_id, agent_type, delegation info
5. Postflight Status Update
After implementation, update task status based on result.
If result.status == "implemented":
Update state.json to "completed" and add completion_data fields (two-step pattern):
# Step 1: Update status and timestamps
jq --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
--arg status "completed" \
'(.active_projects[] | select(.project_number == '$task_number')) |= . + {
status: $status,
last_updated: $ts,
completed: $ts
}' specs/state.json > specs/tmp/state.json && mv specs/tmp/state.json specs/state.json
# Step 2: Add completion_summary (always required for completed tasks)
if [ -n "$completion_summary" ]; then
jq --arg summary "$completion_summary" \
'(.active_projects[] | select(.project_number == '$task_number')).completion_summary = $summary' \
specs/state.json > specs/tmp/state.json && mv specs/tmp/state.json specs/state.json
fi
# Step 3: Add roadmap_items (if present and non-empty)
if [ "$roadmap_items" != "[]" ] && [ -n "$roadmap_items" ]; then
jq --argjson items "$roadmap_items" \
'(.active_projects[] | select(.project_number == '$task_number')).roadmap_items = $items' \
specs/state.json > specs/tmp/state.json && mv specs/tmp/state.json specs/state.json
fi
# Step 4: Filter out existing summary artifacts (use "| not" pattern to avoid != escaping)
jq '(.active_projects[] | select(.project_number == '$task_number')).artifacts =
[(.active_projects[] | select(.project_number == '$task_number')).artifacts // [] | .[] | select(.type == "summary" | not)]' \
specs/state.json > specs/tmp/state.json && mv specs/tmp/state.json specs/state.json
# Step 5: Add new summary artifact
jq --arg path "$artifact_path" \
'(.active_projects[] | select(.project_number == '$task_number')).artifacts += [{"path": $path, "type": "summary"}]' \
specs/state.json > specs/tmp/state.json && mv specs/tmp/state.json specs/state.json
Update TODO.md:
- Change status marker from
[IMPLEMENTING]to[COMPLETED] - Link artifact using count-aware format: apply the four-case Edit logic from
@.claude/context/patterns/artifact-linking-todo.mdwithfield_name=**Summary**,next_field=**Description**
Update plan file (if exists): Update the Status field to [COMPLETED]:
plan_file=$(ls -1 "specs/${padded_num}_${project_name}/plans/"*.md 2>/dev/null | sort -V | tail -1)
if [ -n "$plan_file" ] && [ -f "$plan_file" ]; then
sed -i "s/^\- \*\*Status\*\*: \[.*\]$/- **Status**: [COMPLETED]/" "$plan_file"
fi
If result.status == "partial":
Update state.json with resume point (keep status as "implementing"):
jq --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
--arg phase "$completed_phase" \
'(.active_projects[] | select(.project_number == '$task_number')) |= . + {
last_updated: $ts,
resume_phase: ($phase | tonumber + 1)
}' specs/state.json > specs/tmp/state.json && mv specs/tmp/state.json specs/state.json
TODO.md stays as [IMPLEMENTING].
Update plan file (if exists): Update the Status field to [PARTIAL]:
plan_file=$(ls -1 "specs/${padded_num}_${project_name}/plans/"*.md 2>/dev/null | sort -V | tail -1)
if [ -n "$plan_file" ] && [ -f "$plan_file" ]; then
sed -i "s/^\- \*\*Status\*\*: \[.*\]$/- **Status**: [PARTIAL]/" "$plan_file"
fi
On failed: Do NOT run postflight. Keep status as "implementing" for retry. Do not update plan file (leave as [IMPLEMENTING] for retry).
6. Git Commit
Commit changes with session ID:
git add -A
git commit -m "task ${task_number}: complete implementation
Session: ${session_id}
7. Cleanup
Remove marker and metadata files after postflight processing:
rm -f "specs/${padded_num}_${project_name}/.postflight-pending"
rm -f "specs/${padded_num}_${project_name}/.postflight-loop-guard"
rm -f "specs/${padded_num}_${project_name}/.return-meta.json"
8. Return Brief Summary
Return a brief text summary (NOT JSON) describing the implementation results.
Return Format
This skill returns a brief text summary (NOT JSON). The JSON metadata is written to the file and processed internally.
Example successful return:
Web implementation completed for task 10:
- All 3 phases executed, build passes cleanly
- Created about page with hero section and team grid
- Created summary at specs/10_create_about_page/summaries/01_web-feature-summary.md
- Status updated to [COMPLETED]
- Changes committed with session sess_1770319142_a293c5
Example partial return:
Web implementation partially completed for task 10:
- Phases 1-2 of 3 executed
- Phase 3 blocked: TypeScript error in ContactForm component
- Partial summary at specs/10_create_about_page/summaries/01_web-feature-summary.md
- Status remains [IMPLEMENTING] - run /implement 10 to resume
Error Handling
Input Validation Errors
Return immediately with failed status if task not found, wrong language, or status invalid.
Subagent Errors
Pass through the subagent's error return verbatim.
Timeout
Return partial status if subagent times out (default 3600s).
MUST NOT (Postflight Boundary)
After the agent returns, this skill MUST NOT:
- Edit .astro/.tsx/.ts files - All web implementation is done by agent
- Run pnpm build/check - Build verification is done by agent
- Analyze or grep source - Analysis is agent work
- Write summary/reports - Artifact creation is agent work
PROHIBITION: If the subagent returned partial or failed status, the lead skill MUST NOT attempt to continue, complete, or "fill in" the subagent's work. Report the partial/failed status and let the user re-run
/implementto resume.
The postflight phase is LIMITED TO:
- Reading agent metadata file
- Updating state.json via jq
- Updating TODO.md status marker via Edit
- Linking artifacts in state.json
- Git commit
- Cleanup of temp/marker files
Reference: @.claude/context/standards/postflight-tool-restrictions.md
Decide Fit First
Design Intent
How To Use It
Boundaries And Review